Putting It Together: The Engineering Spine End-to-End

11.1 The depth-chart mental model

The five engineering-spine artifact types (.fml, .fun, .req, .blk + .ifc + .smd, .tst) form a layered structure. Experienced practitioners learn to navigate it as a depth chart: a mental map of which level a concern belongs to, and which neighboring levels it should connect to.

In this subchapter I'll give you that depth chart, and with it a reliable answer to a question you'll keep asking: which file should this concern go into?

The five layers

Expand

1. Features (.fml): what the customer chooses among. The customer-facing variability surface. Example: dual-motor caliper vs single-motor caliper.
2. Functions (.fun): what the system does, named at a level a stakeholder would discuss. The behavioral abstraction. Example: MotorCrosscheck (compares the two motors' positions and flags divergence).
3. Requirements (.req): what the system shall do, prescriptively, with safety levels and traceability. Example: REQ_EPB_003, cross-check dual-motor positions within 50 ms.
4. Architecture (.blk, .ifc, .smd): how the system is built (blocks), how the parts communicate (interfaces) and how each block behaves (state machines). The structural and behavioral implementation specification. Example: the EpbController block hosting the MotorCrosscheck function.
5. Tests (.tst): how we verify. The evidence the safety case cites. Example: TC_EPB_MOTOR_MISMATCH, a HIL test of the motor cross-check.

The layers aren't strictly waterfall; a real project iterates across all of them at once. But the dependency direction is one-way: each layer references the layer above it for context, not the reverse.

Features reference no upstream artifacts: they're the top layer, and their only upstream context is the .ple. Functions enable features (an upward reference). Requirements derive from safety goals (which derive from hazards, in the safety chain of Part IV) and implement functions. Architecture realizes requirements and functions, and tests satisfy requirements.

Using the depth chart

The depth chart earns its keep by answering the authoring question you'll ask most often: which file should this concern go into? Two heuristics work well in practice.

Heuristic 1: ask 'who would discuss this?' A concern a customer would discuss belongs in features; one an engineering peer would discuss belongs in functions. A concern a regulator or auditor would discuss belongs in requirements, and one a manufacturing or test engineer would discuss belongs in architecture or tests respectively. Most authoring confusions resolve once you ask which audience would naturally encounter the concern.

Heuristic 2: ask 'what is the artifact's role in the safety case?' Each artifact type has a specific role, and the role usually tells you which type a concern belongs to:

• Features are the customer-visible scope. They appear in the marketing material and the product brief.
• Functions are the behavioral abstraction. They appear in the technical safety concept (per ISO 26262 Part 3).
• Requirements are the prescriptive content. They appear in the safety requirement specification.
• Architecture is the realization. It appears in the technical safety concept (Part 4) and the safety analysis.
• Tests are the verification evidence. They appear in the verification report.

What follows

Subchapter 11.2 walks the EPB's upstream artifacts (.ple, .fml, .fun, .req): the layers closest to the customer-facing and prescriptive content. Subchapter 11.3 walks the architecture and tests. Subchapter 11.4 covers the cross-cutting concerns: naming, file layout, project hygiene, version control and agent coordination.

Exercises

11.2 Walking the EPB upstream artifacts: .ple to .req

In this subchapter we'll walk the EPB's upstream artifacts in the order a real project writes them: .ple first, then .fml, then .fun, then .req. I've keyed the walk to one slice of the EPB's scope, the dual-motor caliper engagement sequence with hill-hold. That way you can watch every file type converge on one cohesive behavior.

The .ple: product-line root

The walk starts at EpbProductLine.ple. It's a short file (fewer than twenty lines), and it's rarely modified once it's written. Its job is to anchor the project: every .fml's listedfor references it, and the compliance and safety-level metadata it carries are the project's identity card.

Open EpbProductLine.ple and you'll see the metadata for the EPB platform: ISO 26262 ASIL-D, automotive chassis domain, global region. This one file answers what product line is this project for? in machine-readable form. Auditors evaluating an EPB safety case begin here.

The .fml: features and variants

Next in the usual authoring order is System/EpbFeatures.fml. It declares the EPB's variability space across five axes (caliper actuation, engagement strategy, hold features, drive-away release, diagnostics), with the appropriate variability flags on each sibling group. The dual-motor caliper variant, our focus here, is one of two alternatives under CaliperActuation.

In the .fml, the DualMotorCaliper feature carries performs ref function DualMotorDriver, MotorCrosscheck: the forward link to the function model. The .fun will carry the inverse, enables ref feature DualMotorCaliper, on each of those functions. That bilateral pair is the first concrete edge of the engineering spine in the dual-motor walk.

The .fun: functional decomposition

System/EpbFunctions.fun declares the function model. Three functions are central to the dual-motor walk: EngageController (top-level), MotorCommandIssuer (translates current commands to PWM) and MotorCrosscheck (the dual-motor-specific cross-check). The first two are variant-agnostic. The third carries when ref config c_DualMotorCaliper, which gates its presence on the dual-motor variant.

MotorCrosscheck carries four outgoing edges that link it into the spine:

• enables ref feature DualMotorCaliper: the upstream feature link.
• needs ref signal MotorPositionFeedback: the interface input.
• provides ref signal MotorMismatchFlag: the interface output.
• detects ref failuremode MotorDivergence, MotorStall: the downstream link to safety analysis.

The .req: prescriptive requirements

System/EpbSafetyRequirements.req holds the safety requirements derived from the safety goals. For the dual-motor walk, the central one is REQ_EPB_003: the EPB shall cross-check the positions of the two independent caliper motors at 20 Hz, and shall flag MotorMismatchFlag when the position differential exceeds MotorMismatchThreshold.

The requirement carries reqtype safety and safetylevel ASIL-D, plus four edges. Together they place the requirement precisely in the spine, so its role in the safety case is unambiguous:

• when ref config c_DualMotorCaliper: variant gating consistent with the function.
• derivedfrom ref safetygoal SG_NoLatentMotorFault: the upstream link.
• implements ref function MotorCrosscheck: the lateral link to the function.
• allocatedto ref block EpbController: the downstream link to the architecture.

The requirement's rationale cites the dual-motor caliper design's claim of ASIL-D motor independence; a single motor failure that goes undetected becomes a latent fault. Its verificationcriteria specify inject open-circuit on motor B during engage sequence. Verify MotorMismatchFlag asserts within 50 ms. Verify Fault state entered.

What follows

The upstream walk has taken the EPB from product-line root to safety requirement. Subchapter 11.3 continues with the architecture (the EpbController block, the EpbInterfaces and the state machine) and the verification (TC_EPB_MOTOR_MISMATCH and its companions). Bringing all five artifact types together around the dual-motor scenario completes the picture of the engineering spine.

11.3 Walking the EPB downstream: architecture and tests

Now we pick up the dual-motor walk from Subchapter 11.2 and follow the spine downward. We go from the safety requirement, through the architecture (block, interfaces, state machine), to the verifying test case. You'll see how the upstream artifacts (feature, function, requirement) constrain and give context to the downstream realization. You'll also see how the downstream artifacts trace back up the spine to support the safety case.

The .blk: EpbController

PowerStage/EpbController.blk is the architectural block that hosts the dual-motor cross-check function. Its hdef declares the architectural classification: blocktype component, safetylevel ASIL-D, level component. Its outgoing relationships include implements ref function EngageController, MotorCrosscheck (among several others), the bilateral inverse of the function's allocatedto.

Notice that the block does not gate on when ref config c_DualMotorCaliper, even though MotorCrosscheck, one of its implemented functions, does. The block is variant-agnostic at its declaration level. The gating of specific functions inside it propagates to the cross-check behavior without the block itself having to be variant-specific.

The .ifc: interfaces

PowerStage/EpbInterfaces.ifc declares the operations, signals, datatypes and parameters that flow between the EPB's blocks and across its external boundaries. Two signals are central to the dual-motor walk: MotorPositionFeedback (from the motor driver to the controller) and MotorMismatchFlag (from the controller's cross-check logic to the controller's state machine). They carry the datatypes Angle_deg and BooleanFlag respectively, both declared in the same .ifc file.

The parameter MotorMismatchThreshold, referenced by REQ_EPB_003 and by the MotorCrosscheck function, also lives in EpbInterfaces.ifc, with a default value of 10 degrees. If the dual-motor variant needed a tighter threshold than suits the single-motor one, you'd express it with a variant-specific override parameter. The present anchor uses the same threshold for both variants.

The .smd: state machine

PowerStage/EpbStateMachine.smd declares the EPB's operational state machine: Released → Engaging → Engaged → Releasing → Released, with Engaging → Fault on cross-check failure or timeout. The MotorMismatchFault transition uses the MotorMismatchFlag signal as its triggering condition. When the cross-check function asserts the flag during the Engaging state, the state machine transitions to Fault.

The state machine's allocatedto ref block EpbController binds it to the controller block. The controller's implements ref function relationships include the functions whose state-machine-mediated behavior is realized here. Think of the state machine as the connective tissue between the block's structural role and the functions' behavioral specification.

The .tst: TC_EPB_MOTOR_MISMATCH

PowerStage/EpbTests.tst holds the test case that verifies REQ_EPB_003. TC_EPB_MOTOR_MISMATCH carries method HIL, safetylevel ASIL-D, when ref config c_DualMotorCaliper and satisfies ref requirement REQ_EPB_003. Its body specifies four things:

• Setup: the HIL rig configuration.
• Procedure: inject a position offset on motor B, ramp through the threshold, measure detection time.
• Expected behavior: MotorMismatchFlag asserts within 50 ms; Fault state entered.
• Pass criteria: detection time ≤ 50 ms in all 20 trial runs.

The test case completes the trace. It runs from the DualMotorCaliper feature in the .fml, through the MotorCrosscheck function in the .fun and REQ_EPB_003 in the .req. From there it passes through the EpbController block, the MotorMismatchFlag signal and the state-machine transition in the architecture, and ends at the verifying test case.

What follows

Subchapter 11.4 closes the chapter with the cross-cutting concerns: naming conventions, file layout, project hygiene, version control and agent coordination. They're what hold the spine together as a project grows from a modest example like the dual-motor walk to production scope.

11.4 Cross-cutting concerns: naming, file layout, hygiene

The dual-motor walk in Subchapters 11.2 and 11.3 showed the engineering spine for one cohesive behavior. A production project has hundreds of such behaviors, thousands of artifacts, and several agents and human reviewers contributing at the same time. At that scale, the project's coherence depends on a small number of cross-cutting conventions. That's what this subchapter covers.

Identifier naming conventions

Identifiers are unique across the whole project (Chapter 3). Two related conventions keep them manageable at scale.

Convention 1: a project-wide prefix. Top-level artifact identifiers carry a project-specific prefix that sets them apart from artifacts in any other project the same engineer might encounter. The EPB anchor uses EPB_ (REQ_EPB_001, TC_EPB_CLAMP_UNDERSHOOT, SG_EPB_NoUnintendedRelease). The insulin pump uses INS_ (REQ_INS_001, SG_INS_NoBolusOverdose), the aerospace anchor uses AP_, and the cobot uses COB_.

Convention 2: hierarchical identifier composition. Child identifiers often include the parent identifier as a prefix. The EPB's RollawayInTraffic situation lives under the UnintendedRelease hazard. The parent context is implicit in the file's structure, but the child could have been named UnintendedRelease_RollawayInTraffic to make the relationship visible in the identifier itself.

It's a tradeoff. Explicit parent context aids readability but produces long identifiers; implicit context relies on the file structure to carry the relationship. Most projects mix the two: explicit prefixes for prominent artifacts, implicit context for routine ones.

File layout and directory conventions

Your directory layout should reflect the engineering decomposition, not the file-type taxonomy. The EPB anchor's directories (System/, PowerStage/, Variants/, Agents/, Sprints/, Reports/) group artifacts by engineering concern rather than by file extension. A subsystem-level requirement lives in the subsystem's directory, alongside the subsystem's blocks and tests; a system-level requirement lives under System/.

This scales well to projects with many subsystems. Each subsystem gets its own directory with all the file types relevant to its engineering scope. The single common parent (the project root containing the .ple) anchors the whole structure. A few directories sit at the root:

• Variants/: variant configurations, one per shipping variant.
• Agents/ and Sprints/: agent definitions and sprint plans respectively, typically one or two files in each.
• Reports/: reactive-documentation artifacts.

Project hygiene: version control and CI

Because Sylang artifacts are plain text, the standard software-engineering hygiene practices apply: git, pull requests, code review, continuous integration. The conventions that work well for software carry over to MBSE artifacts with minor adjustment.

• Feature branches per task. Each sprint task (Chapter 5) gets its own feature branch, and the task's outputfile is the branch's primary deliverable. The branch's commit history captures how the artifact evolved.
• CI validator runs. Every push to any branch runs the Sylang validator across the project, and broken refs and other validator errors block the build. That keeps the trunk continuously valid.
• Branch protection on safety-relevant files. Pull requests that change safety goals, hazard analyses or ASIL-D requirements need explicit approval from designated reviewers (typically the SafetyManager human role). Git platform conventions enforce the protection (CODEOWNERS in GitHub, equivalents elsewhere).
• Coverage-report-gated merges. Some projects configure CI to require that the project's coverage report (Chapter 15) shows no new orphans or broken refs from the merge. The check catches the most common authoring regressions before they reach the trunk.

My working estimate is that projects mature enough to apply these practices hit fewer late-cycle integration surprises than projects without them. The practices do have an operational cost: someone has to maintain the CI pipeline and administer the branch protection rules. I'd expect that cost to be small next to the engineering effort it preserves.

Agent coordination at project scale

The agent set defined in .agt (Chapter 5) and the sprint planning in .spr together coordinate several AI agents working on the same project at once. Three patterns work well at project scale.

Pattern 1: one agent owns one file type at a time. Concurrent modifications to the same file by several agents produce merge conflicts. Coordinating by file-type ownership removes the source of conflict. The SafetyManager owns the .haz / .sgl / .sam files, the RequirementsEngineer owns the .req files, and so on, as documented in the .agt's expertise and context fields.

Pattern 2: review agents on commit, not on schedule. A reviewer agent (per Chapter 5 Subchapter 4) runs on every commit. It produces structured review feedback that the authoring agent receives on its next turn.

Pattern 3: humans gate the move to approved. AI agents may move artifacts from draft to review, but a human reviewer should be required for the move to approved. That keeps humans in the loop for the consequential decisions without burdening them with routine drafts. You implement it as a git platform rule (status transitions to approved require human reviewer sign-off), not as a Sylang language rule.

Closing Chapter 11

Chapter 11 has closed Part III by showing the engineering spine as one integrated whole. You've covered the depth-chart mental model (11.1) and the upstream walk of the EPB dual-motor scenario (11.2). Then came the downstream walk through architecture and verification (11.3), and the cross-cutting conventions that hold a project together at production scale (this subchapter).

Part IV (Chapters 12 to 15) builds the safety-engineering artifact set on the foundation Part III has laid. Chapter 12 covers the full ISO 26262 safety chain (item, hazards, goals, mechanisms). Chapter 13 covers FMEA, Chapter 14 covers FTA, and Chapter 15 covers the traceability and coverage analyses that make the entire artifact set auditable.

Exercises