Systems Engineering for Safety-Critical Products
Requirements, architecture and safety assessment for products that have to meet IEC 61508, DO-178C, DO-254, ARP-4754A or ARP-4761. From customer requirement through to verified code and the certification artefacts.
The requirement chain, the architecture model and the safety assessment are built as the product is designed. We work alongside your engineers. You do not need an existing requirements process, a modelling tool, or a document set to start.
The Chain from Requirement to Evidence
Every requirement sits on one chain. Each link is bidirectional.
Customer Requirement
derive
System Requirement — controlled natural language, implementation removed
allocate
Physical Architecture — the component that carries the behaviour
formalise
Formal Requirement — the handover from systems engineering to a discipline
derive
Discipline High-Level Requirement — hardware, software, programmable logic, mechanical
decompose
Discipline Low-Level Requirement
implement
Source code, schematic, RTL or CAD geometry
verify
Requirements-based test
compile
Certification artefacts — compiled from the model
The Formal requirement is the handover from systems engineering to a discipline. It is atomic, allocated to a named component, and states the value or option to be built.
Below the Formal requirement the chain splits by discipline. Each discipline carries its own high-level and low-level requirements down to its own implementation. Requirements allocated to programmable logic follow DO-254. Requirements allocated to software follow DO-178C.
The artefacts are compiled from the same model at the end of the chain: trace matrices, the lifecycle data the applicable standard calls for, the safety assessment output, and the interface control documents. Each one carries the requirement, component and test identifiers it was built from.
Requirement Types
Each type is a distinct object in the model, with its own fields, its own trace links and its own position in the chain.
The chain
Customer Requirement
The requirement in the customer’s own voice, transcribed rather than interpreted. It may carry implementation intent. Each one is linked to the source document and clause.
System Requirement
Controlled natural language. One atomic testable statement with implementation removed. No component designators, no part numbers, and a defined pass or fail criterion.
Formal Requirement
The handover between systems engineering and a discipline. Allocated to a named component in the physical architecture and stated as the value or option to be built.
Formal requirement types
Behavioural
What a behavioural component does. Attached to the software, hardware or mechanical behaviour deployed on a physical component.
Functional
What a physical function performs. The finest-grained statement of behaviour in the model.
Safety
A safety property of a physical component, derived from the hazard assessment.
Physical
A physical property of a component: mass, envelope, mounting, environment.
Interface
What crosses a physical link between two components. The source of the interface control document.
Performance
A measurable property of a physical link: bandwidth, latency, accuracy, range.
Discipline requirements
Hardware
High-level and low-level requirements against a circuit board. Followed under IEC 61508 Part 2 or DO-254 depending on the product.
Implements to → PCB Assembly
Implements to → PCB Assembly
Software
High-level and low-level requirements against a firmware project or an application. Low-level requirements sit with the code module they describe and are bound to the source by an annotation on the function that implements them.
Implements to → Firmware Project / Application
Implements to → Firmware Project / Application
Programmable Logic
High-level and low-level requirements against an FPGA bitstream and the IP modules within it. Programmable logic is DO-254 hardware and is held in its own discipline.
Implements to → FPGA Bitstream / IP Module
Implements to → FPGA Bitstream / IP Module
Mechanical
High-level and low-level requirements against a mechanical assembly or a manufactured component.
Implements to → Assembly / Machined Part
Implements to → Assembly / Machined Part
Mechanical Interface Requirement
The dimensional and mounting interface between mechanical items. The interface control document is generated from these.
Safety analysis
Functional Hazard Assessment
Each system function is assessed for failure using the ARP-4761 guide words: no function, erroneous function, function provided when not commanded, and the rest. The assessment produces the failure conditions and their severity classification.
Failure Condition
A specific way a system function can fail, raised against that function and classified by severity. Failure conditions are the input to the development assurance level or SIL allocation.
Failure Effect
The local effect and the system effect of a failure condition, and its severity.
Fault Tree
A failure condition taken as the top event and decomposed through AND and OR gates to basic failure events. Fault trees quantify the probability of the top event, show whether the architecture meets its target, and expose single points of failure and common cause.
Failure Event
A basic event at the base of a fault tree, carrying its failure rate. Component failure rates come from manufacturer data, IEC 61709 reference conditions or recognised handbooks.
Safety Function
An IEC 61508 safety function with its SIL target, operating mode, safe state, response time and probability target, either probability of failure on demand or probability of dangerous failure per hour.
Risk Graph
The IEC 61508-5 Annex D risk graph: consequence, frequency and exposure, possibility of avoidance, and probability of the unwanted occurrence. The SIL is determined by the assessment.
Standards We Work To
The same model and the same traceability apply to each.
ARP-4754A
Development of civil aircraft and systems. Governs how requirements are captured, decomposed and validated across a system, and how development assurance levels are assigned and flowed down. Function development assurance level is derived from the worst-case severity of the failure conditions a function contributes to.
ARP-4761
Safety assessment. The functional hazard assessment identifies failure conditions and classifies their severity. The preliminary system safety assessment shows the architecture can meet the resulting targets. The system safety assessment shows the built product does. Fault tree analysis, common cause analysis and failure modes and effects analysis sit underneath.
DO-178C
Airborne software. High-level requirements derive from system requirements, low-level requirements decompose from those, source code implements the low-level requirements, and requirements-based tests verify them, with structural coverage including modified condition decision coverage where the assurance level requires it. Lifecycle data runs from the plan for software aspects of certification through to the software accomplishment summary.
DO-254
Airborne electronic hardware. It applies to programmable logic devices, so a field programmable gate array is a DO-254 item and follows a hardware lifecycle with its own plan for hardware aspects of certification, its own requirements, its own validation and verification, and its own conformity evidence. Programmable logic is held in its own discipline with its own requirement layers.
IEC 61508
Functional safety of electrical, electronic and programmable electronic systems, covered end to end. Part 1 sets the overall lifecycle and the management of functional safety. Part 2 governs the hardware: hardware fault tolerance, safe failure fraction, diagnostic coverage, and the Type A or Type B classification that sets the architectural constraints for a target SIL. Part 3 governs the software, with the required techniques changing by SIL, from coding standards and modular design through to defensive programming and static analysis. Part 5 provides the risk graph used to determine the SIL.
Where a product is machinery rather than process equipment, the system level is governed by IEC 62061 and the hardware and software subsystems meet IEC 61508 Parts 2 and 3 at the SIL allocated to them.
Architecture with Arcadia
Architecture is modelled with the Arcadia method, across three phases.
Operational Analysis
What the user is trying to achieve, independent of any solution. Operational activities describe the job to be done.
System Analysis
The product as a black box, decomposed into what it must do. System functions describe behaviour, function ports define inputs and outputs, functional exchanges connect an output port on one function to an input port on another, exchange items type the data that flows, and functional chains describe an end-to-end path. The functional hazard assessment is run at this level.
Physical Architecture
What will be built. Physical components carry part numbers and map to real assemblies, boards, firmware projects and applications. Behavioural components describe what is deployed on them, typed as hardware, software, hardware and software, mechanical, or programmable logic. Physical functions allocate behaviour to those components, and physical links describe the connections between them.
Logical architecture is not modelled. States and modes machines are modelled where behaviour depends on them.
How ARPTool Implements It
ARPTool is the model-based systems engineering platform we built, and it holds the model on every project.
One Model
Every requirement, function, component, failure condition and test case is an object in the model with a stable identifier.
Bidirectional Traceability
Trace links run in both directions. What a test verifies and what verifies a requirement are the same query. Untraced requirements are reported as coverage gaps.
Requirements Bound to Source
Low-level requirements are bound to source code by an annotation in the function header carrying the requirement identifier. The link is checked by tooling.
Generated Documents
The design definition document, trade studies, interface control documents, hazard assessment output and the DO-178C and IEC 61508 Part 3 trace matrices are generated from the model.
What You Receive
Where we also build the hardware, firmware or programmable logic, the same model carries through to the implementation.
Requirements
Every level, traced end to end, from customer requirement to the low-level requirement a line of code implements.
Architecture Model
The operational, system and physical architecture, with part numbers against real assemblies, boards and firmware.
Safety Assessment
Functional hazard assessment, failure conditions and effects, fault trees, and the SIL or development assurance level justification.
Interfaces
Interface definitions between components, and the interface control documents generated from them.
Test Cases and Results
Requirements-based test cases bound to the requirement they verify, and their recorded results.
Certification Artefacts
The artefact set the applicable standard calls for, including the trace matrices and lifecycle data, compiled from the model.
Talk to Us About Your Product
Tell us about the product and the standard it has to meet, and we will tell you what the systems engineering effort looks like.