Architecture and interface completeness audit

The problem this solves

A generated document is only as complete as the model behind it. An interface with no flow becomes an empty table row, a safety chain with a missing link becomes an architecture section that stops mid-sentence, and a system with no states has no operating description at all. Running this audit before the machine description workflow means the gaps get fixed in the model, not discovered in the document.

How it works

The holes in structure and behaviour, found before the operating description is generated around them. Every part described, every interface typed and quantified, every safety chain unbroken from sensor to actuator, operating modes present, and budget expressions evaluated against their stored values.

Where this sits in the Regulation

Regulation (EU) 2023/1230 applies from 20 January 2027, and Annex IV Part A items (a) and (d) are the description and operating explanation this audit prepares the model for; the technical file is kept for ten years after the machine is placed on the market. This audit reads the model and reports gaps: it is a readiness check, not a conformity assessment.

Audit the architecture and interfaces in the connected Dalus model for completeness. Do not modify the model.

Step 1. Read the system part, all subsystems and parts with attributes and notes, all ports, all connections and flows, all variables, and any states, transitions and actions.

Step 2. Parts. Flag parts with no attributes and no notes. Flag subsystems whose function cannot be stated from their name, notes, parts and flows.

Step 3. Ports and connections. Flag ports with no connection. Flag connections with no flow. Flag flows with no quantity variable or a variable with no unit. Flag connections between a top-level part and a nested part that bypass a delegation port on the parent.

Step 4. Safety chains. Identify chains from a sensing element through a safety controller to an actuator, using part names, connection names, notes and requirement links as evidence. For each chain, list the elements and connections and flag any missing link. Do not assert a performance level unless a model attribute or requirement states one.

Step 5. Behaviour. Report whether the system part has states and transitions. If it does, flag states with no transitions in or out, and transitions with no trigger. If it does not, list the operating modes the safety chains and interfaces imply, labelled as a suggestion, and state that the operating description cannot be generated until modes exist.

Step 6. Budgets. For every variable with an expression, evaluate it and report whether the stored value matches. Flag mismatches.

Step 7. Findings, ranked: broken safety chains, unconnected ports, connections without flows, missing states, flows without quantities, parts without description, expression mismatches.

Step 8. Provenance: element IDs behind each finding.

Output: a findings report with counts per category, the safety chain list, the ranked findings, and provenance.

What you get

Common questions