Data sheet Position on the V: Design and build Revised
Safety-Critical Software Development
Embedded software under DO-178B/C up to Design Assurance Level (DAL) A and DO-297 for Integrated Modular Avionics, built with the evidence in from the start rather than reconstructed at the end.
- Standards
- DO-178C, DO-297, DO-330
- Assurance
- Up to DAL A
- When to call us
- Planning, or before design starts
- Delivery
- Mostly remote, on-site as needed
Scope
Build the evidence in; retrofitting it costs more than the code.
We develop embedded software under DO-178B/C, up to and including Design Assurance Level A, and under DO-297 for Integrated Modular Avionics platforms. That means disciplined planning (the Plan for Software Aspects of Certification, PSAC, and the development, verification, configuration-management and quality-assurance plans), requirements-based design, and structured lifecycle data that withstands audit and Stage of Involvement review.
Where a model-based approach fits, SCADE and similar qualifiable code-generation environments, we use it to reduce manual coding error and keep design and implementation traceable to a single source of truth. Where hand-written C is the right tool, we write it to the coding standard and the structural coverage target the level demands, with an informed position on tool qualification (DO-330) so that tooling choices do not become certification liabilities later.
Deliverables
What SOI 2 reads.
| Document | What it is | First reviewed |
|---|---|---|
| SDP | Software Development Plan: methods, environments and the transition criteria between processes | SOI 1 |
| Standards | Requirements, design and coding standards, each rule one the team actually enforces | SOI 1 |
| HLR | High-level requirements, uniquely identified and verifiable as written | SOI 2 |
| Design and low-level requirements (LLR) | Design data and low-level requirements, a level of their own, not a flat list | SOI 2 |
| Source | Code traced to low-level requirements, standards enforced, warnings dispositioned | SOI 2 |
| Trace | System requirement to high-level to low-level to code, with derived requirements fed back to safety | SOI 2 |
| SCI | Software Configuration Index: what would ship today, rebuildable from its baseline | SOI 4 |
SOI: the authority's Stage of Involvement reviews.
Transition criteria, not calendar dates
Four gates between plan and handover.
Transition criteria state what must be true before work moves from one process to the next. An auditor can pick any artifact and ask whether its entry criteria were met.
- 01 Plans and standards Written with the people who will execute them, and consistent with each other before anyone external reads them.
- 02 Requirements High-level and low-level requirements as separate levels, derived requirements identified and returned to the safety process.
- 03 Design and code To the standards, under configuration control, compiler and options baselined so builds do not differ between machines.
- 04 Integration and handover Integrated software and its lifecycle data, ready for the verification the Software Verification Plan (SVP) promised.
What sets the cost
Four decisions, three of them yours.
- Assurance level Sets the objective count, the independence staffing and the coverage criterion; the safety assessment decides it, the architecture influences it.
- Requirements stability Every change after verification starts re-runs a slice of the program; the one driver that dominates in practice.
- Reuse Genuine reuse credit removes whole objective areas; "it flew before" without evidence removes nothing.
- Tools A qualified tool retires manual labour but has a price of its own; a make-or-buy decision per tool, early.
Field notes