DO-178C is a civil aviation software standard. Its formal title is "Software Considerations in Airborne Systems and Equipment Certification." It sets the framework for developing and verifying software in FAA-regulated aircraft. Commercial spacecraft programs have no DO-178C regulatory route, and literal application to a NewSpace mission would be costly and unsuitable in some areas. Still, DO-178C concepts around traceability and verification coverage are entering commercial spacecraft work, making its terminology useful for teams conducting serious flight-software V&V.
What DO-178C Defines
DO-178C assigns software development assurance levels from A to E. Level A covers software whose failure could be catastrophic, while Level E covers software with no safety effect. Each level has objectives that the development and verification process must meet. They address requirements capture, software architecture, detailed design, coding standards, integration, and testing. At Level A, every executable statement needs at least one test. Every code condition and decision must also be independently exercised as true and false, known as Modified Condition/Decision Coverage, or MC/DC.
The document also calls for structural coverage analysis, a formal measure of which code paths the test suite executes. Functional coverage instead asks whether testing exercises every function the software is intended to perform. Structural coverage asks whether testing reaches every path through the code as written, whether or not those paths represent specified behavior. Higher assurance levels require both.
Why This Reaches Commercial Spacecraft Programs
Customer requirements are the immediate cause. Institutional customers, including government space agencies and commercial operators with long-term mission commitments, increasingly ask spacecraft suppliers to show that flight software was developed to a defined assurance level and that verification coverage was measured. DO-178C is not always named, but its terminology is: design assurance level, requirements traceability matrix, and structural coverage percentage.
Insurance is another factor. Insurers covering commercial satellite programs are examining software practices more closely. Poorly documented flight-software development creates financial risk, so launch and in-orbit underwriters are raising the same questions as institutional customers.
A further factor is that teams building a requirements traceability matrix and measuring structural coverage find that the work exposes defects. Missing test cases, untested code paths, and requirements without linked tests all become visible. Those benefits apply whether or not a regulator demands them.
Using the Traceability Matrix
For a small NewSpace team, the requirements traceability matrix, or RTM, is among the most applicable DO-178C artifacts. It connects each software requirement to its implementing design element and its verifying test case. In flight software, the ICD is a natural starting point: each ICD field definition effectively requires a packet encoder, packet decoder, and test suite that verifies them.
Creating an RTM from an ICD field table is largely mechanical. Each row yields an RTM entry containing the field identifier, the requirement statement derived from its definition, the code module implementing encoding or decoding, and the test case identifier that verifies it. Automatically generating this table from a parsed ICD is the kind of artifact that speeds later reviews. The question shifts from "does this link exist?" to "are these links correct?"
Coverage for Small Teams
Achieving MC/DC coverage at Level A is costly for complex logic. Test cases must be designed so each condition in a compound boolean expression can independently determine the result. That effort is warranted for safety-critical avionics software. For a commercial CubeSat mission, applying MC/DC to all code is likely an unsuitable tradeoff.
A practical goal for small NewSpace teams is statement coverage for packet encoding and decoding, plus branch coverage for flight-software state-machine logic. Statement coverage requires every executable statement to run in at least one test. Branch coverage requires every branch from a decision point to be taken by at least one test. Generated test stubs can achieve these at reasonable cost, while catching a substantial share of defects that matter in practice.
For paths handling errors, corrupted input, or off-nominal field values, deliberate boundary tests provide more value than coverage metrics alone. A coverage tool can show that an error-handling branch ran, but not whether its handler behaved correctly. Such tests require intentional design, so the generated stubs add assertions for field minimum and maximum values and for out-of-range inputs.
Limits of DO-178C Awareness
Knowing DO-178C terminology and using some of its practices does not make software DO-178C compliant. Compliance requires a qualified tool chain, formally approved software development and verification plans, independence between development and verification roles at Levels A through C, and a compliance review by a Designated Engineering Representative or equivalent. Those requirements are outside a commercial spacecraft mission not pursuing civil aviation certification.
DO-178C awareness is valuable for adopting engineering discipline, not for asserting that the standard applies. When a customer asks whether flight software has a requirements traceability matrix or asks about test coverage, a team that builds RTMs and measures coverage can respond directly and accurately. That is the practical gain. Calling software DO-178C compliant without the required formal approval process is fabrication, and borrowed terminology cannot change that.
Getting Started
For a small spacecraft team new to DO-178C, a sensible start has three parts: record every software requirement derived from ICD field definitions, create a test for each requirement, and document the requirement-to-test link. In minimal form, that is an RTM. It requires no DO-178C tool chain, DER, or development-process overhaul. It does require discipline, some time, and a way to generate the initial requirements and tests from the ICD instead of creating them manually.
