Deriving ISO 26262 Requirements from DBC and ARXML

Two files, two different views of the same ECU

A CAN DBC file and an AUTOSAR ARXML file describe overlapping but distinct things, and the overlap is where automated derivation earns its keep.

	DBC (CAN database)	ARXML (AUTOSAR)
Grain	Messages, signals, bit layout, scaling, min/max	Software components, ports, interfaces, runnables
Identity	Message ID and signal name	SHORT-NAME hierarchy forming a path
Answers	"What is on the wire, in what units"	"Which component owns this, through which port"
Silent about	Ownership, allocation, timing contracts	Physical encoding, bus loading

Note the identity mismatch: ARXML uses SHORT-NAME hierarchies rather than XMI IDs, and its element names are all-caps-with-hyphens. Joining the two views means resolving a DBC signal name against an ARXML port path, which is a naming-convention problem before it is a modelling problem. On most programmes this is where the effort actually goes.

What you can derive automatically

Importing both files into one graph and classifying the elements gets you a usable skeleton. In VectorMBE, a DBC signal, an AUTOSAR I-signal and an AADL signal all normalise to the same canonical class — vmbe:Signal in the logical layer — so a requirement written against a signal survives a change of source tool. Components normalise to vmbe:LogicalComponent, and physical items to vmbe:PhysicalComponent, vmbe:HardwareItem or vmbe:LRU depending on what the source says.

From that skeleton, three classes of requirement follow mechanically:

• Range and plausibility. The DBC gives you the physical minimum and maximum for every signal. Every safety-related signal needs a requirement rejecting out-of-range values, and the bound is already in the file.
• Interface contracts. Each ARXML port connection implies a requirement that the providing component supply the data the requiring component expects, in the units the DBC declares.
• Allocation traces. The SHORT-NAME path tells you which component owns which signal, which is exactly the allocation link ISO 26262 Part 6 expects between technical safety requirements and software architecture.

What neither file can give you

This is the part worth being blunt about, because tool vendors tend to blur it.

ISO 26262 requirements are derived from hazards, not from buses. The standard's chain runs hazard → safety goal with an ASIL → functional safety requirement → technical safety requirement → software or hardware requirement. A DBC file enters that chain only at the last step. Nothing in a bus definition tells you that unintended torque delivery is ASIL D while an inoperative trip computer is QM. That judgement comes from the HARA, and it is an engineering decision with legal weight.

So automated derivation from DBC and ARXML produces a well-formed lower half of the trace with an unattached top. The value is real — it is the tedious half — but a graph that cannot show a hazard above each requirement is not yet an ISO 26262 artefact.

Making the ASIL carry through the graph

Once hazards are in the model, the ASIL becomes an attribute you can query and constrain rather than a label in a spreadsheet. VectorMBE carries safety_level on requirements, so a query can ask directly for the elements that matter:

FIND requirement
            CONSTRAINED BY requirement.safety_level = "ASIL-D"

The more useful query is the negative one — safety-critical hazards with no requirement linked to them. VectorMBE's agent treats exactly that case as its highest-priority finding, for hazards at ASIL C, ASIL D, DAL A or DAL B, because an unlinked high-ASIL hazard is the defect most likely to survive to a review meeting.

ASIL decomposition adds a further constraint the graph should enforce: when an ASIL D requirement is decomposed into two ASIL B(D) elements, the decomposition is only valid if those elements are genuinely independent. Independence is a claim about the architecture — shared power supply, shared microcontroller, shared bus — and it is checkable against the physical layer of the same graph, which is a good reason to keep logical and physical elements in one model rather than two tools.

A practical sequence

1. Import the ARXML first. It establishes component identity and the SHORT-NAME paths everything else joins to.
2. Import the DBC and resolve signals onto the ports that carry them, fixing naming mismatches as you go.
3. Generate range, plausibility and interface requirements from the structure. This is the mechanical half.
4. Bring in the HARA and attach safety goals with their ASILs above the generated requirements.
5. Query for orphans in both directions: hazards with no requirement, and safety-related signals with no unwanted-behaviour requirement.
6. Check decomposition independence against the physical layer before accepting any ASIL reduction.

Steps 1 through 3 are automatable today. Step 4 is human judgement. Steps 5 and 6 are queries, and they are the ones worth running on every change.