Engine-control equipment evidence support for TSO authorization

When this review is needed

• Engine-control equipment is heading for a TSO authorization and the software and hardware assurance evidence has never been reconciled to the safety assessment.
• The DO-254 hardware assurance and the DO-178C software life-cycle were run by separate teams and their assurance levels have not been cross-checked.
• A field-programmable or complex device carries an assurance level no one has traced to the failure conditions.
• A prior submission raised questions on hardware assurance and the supplier wants those gaps found before resubmitting.

The problem

Engine-control equipment sits on two assurance tracks at once: a DO-178C software life-cycle and a DO-254 assurance case for the complex electronic hardware, both anchored to a safety assessment that classifies the failure conditions. Those tracks are usually built by different specialists on different schedules, and nothing forces their assigned levels or their evidence to line up until someone assembles the package. The engineer doing that inherits a software stack and a hardware stack that each read as complete but do not clearly share a common safety basis.

What gets reviewed

• DO-178C software life-cycle data at the assigned assurance level
• DO-254 assurance case for the complex electronic hardware at its assigned level
• The safety assessment linking software and hardware assurance to the failure conditions
• DO-160G environmental qualification for the engine bay and installation environment
• Cross-checks that the software and hardware assurance levels share a consistent basis
• Deviations across either assurance stream identified with their substantiation

What gets validated

• The software and hardware assurance levels both trace to the same documented failure conditions
• DO-254 evidence exists for each complex electronic hardware item at its assigned level
• Software life-cycle objectives are complete at the DO-178C level assigned
• DO-160G coverage reflects the engine bay thermal and vibration environment, not a generic profile
• Any deviation in either assurance stream is recorded with the basis offered

Evidence normally required

• The safety assessment and its failure condition classification
• The DO-178C software life-cycle data and assigned level
• The DO-254 hardware assurance data and assigned level
• DO-160G environmental qualification results for the installation environment
• The hardware and software configuration definition for the article

Common discrepancies

• A hardware assurance level and a software assurance level derived from inconsistent failure conditions
• A complex electronic hardware item with no DO-254 evidence at its assigned level
• Software life-cycle objectives incomplete at the assigned level
• DO-160G thermal or vibration coverage below the engine-bay environment

What is at stake

A hardware assurance level that does not match the failure conditions is as costly to fix late as a software one, and often harder, because complex hardware evidence cannot be regenerated as quickly. An authority that sees the two assurance tracks disagree will hold the authorization, and a mismatch discovered downstream can force rework across both software and hardware at once.

How the work runs

What the buyer receives

• An evidence gap list spanning the software and hardware assurance streams
• A trace map from the safety assessment to each verified software and hardware item
• A closure sequence that keeps the two assurance streams aligned

Who uses the output

• Certification engineers assembling the engine-control TSO data package
• Software and hardware assurance leads confirming their streams share a basis
• Program managers judging which assurance gaps must close before submission

How the work fits into the transaction or program

This readiness pass reconciles the software and hardware assurance tracks against the safety assessment before the engine-control package reaches the authority. The trace map it produces gives every later installation approval a single, aligned basis to build on rather than two streams to reconcile again.

Jurisdiction-specific considerations

FAA and EASA both accept DO-178C and DO-254 for equipment at this criticality but differ in how the hardware assurance case is expected to be presented and reviewed. The gap list notes where a package built for one authority will need repackaging for the other, particularly around the DO-254 evidence.

Regulatory limits

The work checks and organizes the supplier's evidence against the assurance objectives. It does not perform the safety assessment, assign either assurance level, approve the software or hardware, or grant the TSO authorization. Those decisions rest with the applicant and the authority.

What this review does not cover

• Authoring the DO-254 hardware assurance case or the software life-cycle data
• Executing verification or environmental testing
• Submitting the package or negotiating its acceptance

Specific to this review

• Engine-control equipment carries two assurance tracks, and the most common defect is that the DO-178C software level and the DO-254 hardware level were derived from failure conditions that no longer agree.
• Complex electronic hardware evidence cannot be regenerated as fast as software, so a DO-254 shortfall found late is often the longest item on the critical path.
• DO-160G coverage for engine-control equipment is checked against engine-bay thermal and vibration levels specifically, because a generic environmental profile understates what the installation actually sees.

Sources

Frequently asked questions

Relevant glossary terms

Related pages

Where this fits