Planning (Stage 2)
Planning takes the Discovery output and produces a structured migration roadmap: units assigned to phases, effort estimates, blocker detection, and a CPM-calculated critical path.
The plan is generated automatically after Discovery completes. You review and approve it before migration begins.
Phases
Every migration unit is assigned to one of 10 sequential phases:
| Phase | Description |
|---|---|
foundation | Shared utilities, helper macros, base types — no external dependencies |
bsp | Board Support Package: clocks, memory map, startup, linker sections |
schema | Data schema and memory-map definitions |
core-logic | Core firmware/PLC/application logic — bulk of translation work |
hal-layer | HAL drivers, peripheral abstractions, RTOS integration |
api-layer | External API surface, protocol adapters (Modbus, OPC-UA, CAN) |
integration | Fieldbus and protocol integrations (Modbus, OPC-UA, CAN, MQTT) |
compliance | Compliance review and GRC sign-off |
safety-critical | SIL-rated functions — functional safety sign-off required |
cutover | System init and top-level orchestrators — migrated last |
Phase Assignment
Units are assigned to phases using a priority cascade:
- AI override (from the roadmap supplement)
- Regulated data hit or hardcoded credential →
safety-critical - Blocking GRC violation on a critical unit →
safety-critical - Unit defines a data schema (table, FD, entity) →
bsp - Level-0 root unit with dependents, not API-facing →
foundation - Exposes fieldbus or protocol endpoint →
integration - Exposes REST, CICS, or gRPC →
api-layer - Level ≥ 3 with no dependents (top-level orchestrator) →
cutover - Default →
core-logic
Language-specific overrides:
- AUTOSAR ARXML, SVD, linker scripts →
bsp - CAN DBC, TTCN-3 →
integration
Critical Path Method (CPM)
The planner calculates forward and backward passes across all units to identify the critical path — the sequence of units with zero slack that determines the minimum migration duration.
Each unit on the schedule includes:
| Field | Description |
|---|---|
effortHoursHigh | Upper-bound effort estimate |
level | Dependency depth (0 = root, no dependencies) |
isCritical | True if this unit is on the critical path |
earliestStart | Forward pass: earliest possible start |
earliestFinish | Forward pass: earliest possible finish |
latestStart | Backward pass: latest allowable start |
latestFinish | Backward pass: latest allowable finish |
slack | Total float = latestStart − earliestStart |
Units with slack = 0 are on the critical path. Delaying any of them delays the entire migration.
Blockers
The planner detects units that cannot be translated without manual intervention. Blockers must be resolved before a unit can proceed to migration.
Generic Blockers
| Blocker | Description |
|---|---|
god-unit | Too large and complex to translate reliably in one pass |
no-target-equivalent | No known target language equivalent for this construct |
hardcoded-credential | Must be extracted before translation |
circular-dependency | Circular import chain — must be broken manually |
xlarge-effort-critical | XL effort + critical risk combination |
blocking-grc-violation | Active GRC violation blocks translation |
unbounded-loop | Algorithmic risk — requires human review |
deep-nesting | Refactor required before reliable translation |
implicit-type-coercion | Type precision risk requiring explicit handling |
Firmware Blockers
| Blocker | Description |
|---|---|
unsafe-pointer-arithmetic | MMIO cast must be abstracted via HAL |
isr-reentrance-risk | Critical section must be added before translation |
misra-c-critical-violation | Mandatory MISRA rule violation |
hardware-dependency | Direct MCU register access — HAL abstraction required |
no-hal-equivalent | No HAL function available for target platform |
watchdog-gap | Missing watchdog refresh (IEC 61508 violation) |
timing-constraint | Hard real-time constraint not expressible in target RTOS |
Automotive Blockers
| Blocker | Description |
|---|---|
autosar-rte-dependency | AUTOSAR Classic RTE with no Adaptive mapping |
e2e-protection-gap | E2E CRC or counter missing |
asil-decomposition-break | ASIL-D decomposition without formal rationale |
can-signal-scaling-mismatch | DBC factor/offset not preserved |
Telecom Blockers
| Blocker | Description |
|---|---|
security-key-material | 3GPP AS/NAS keys must be externalised to HSM/TEE |
protocol-state-machine-break | Non-serialisable RRC/NAS state |
ttcn3-verdict-suppression | INCONC verdict must link to test reference |
Energy / OT Blockers
| Blocker | Description |
|---|---|
goose-protection-relay | IEC 61850 GOOSE bridged via TCP/MQTT — prohibited |
dnp3-secure-auth-gap | DNP3 SA_CHALLENGE response missing |
sis-sil-downgrade | Change would reduce SIL rating |
Compliance Gates
Domain-specific gates must pass before migration reaches the compliance and safety-critical phases.
Automotive (ISO 26262 / AUTOSAR)
- ASIL-D formal verification evidence required (model checking or abstract interpretation)
- E2E protection profile configuration (CRC + counter) verified
Energy / Critical Infrastructure (IEC 61850 / IEC 61511)
- GOOSE protection path must be isolated — OPC-UA/MQTT bridging prohibited
- SIL verification report required (IEC 61511-1 Section 11)
Telecom (3GPP / GSMA)
- 3GPP key material must be externalised to HSM or TEE before migration proceeds
- TTCN-3 verdict traceability must be established
Industrial IoT / OT (IEC 62443)
- IEC 62443 zone and conduit isolation verified
Approving the Plan
Review the plan in the Planning pane:
- Inspect phase assignment per unit
- Review the blocker list and resolve any blockers
- Check the critical path
Click Approve Plan → to unlock Stage 3 (Migration). The plan is locked after approval — units can be re-translated but phase assignments cannot change.
Last edited