Skip to main content

Aerospace: Flight Control System

Overview​

This sample project demonstrates NirmIQ features for DO-178C Level A certified avionics software. The Primary Flight Control System (PFCS) project shows how to manage safety-critical flight software requirements, perform system safety analysis, and maintain complete traceability for FAA certification.

Project Details​

  • Domain: Aerospace (Commercial Aviation)
  • System: Primary Flight Control System (PFCS)
  • Compliance Standard: DO-178C Level A (DAL-A)
  • Additional Standards: ARP4754A, DO-254 (hardware aspects)
  • Lifecycle Phase: Certification & Validation
  • Organization: Sample - Aerospace Industry
  • Custom ID Prefix: FCS

Features Demonstrated​

Requirements Management​

The project uses a 4-level requirement hierarchy following ARP4754A:

  1. Aircraft Level Requirements (ALC) - High-level aircraft functions

    • Example: "Aircraft shall maintain controlled flight in all normal conditions"
    • Custom IDs: FCS-ALC-001, FCS-ALC-002, etc.

  2. System Requirements (SYS) - Flight control system capabilities

    • Example: "PFCS shall provide pitch, roll, and yaw control authority"
    • Custom IDs: FCS-SYS-001, FCS-SYS-002, etc.

  3. Software High-Level Requirements (HLR) - Software functional requirements

    • Example: "Flight control laws shall compute control surface commands at 50Hz"
    • Custom IDs: FCS-HLR-001, FCS-HLR-002, etc.

  4. Software Low-Level Requirements (LLR) - Detailed software specifications

    • Example: "Pitch rate feedback gain shall be K_q = -2.5 deg/s"
    • Custom IDs: FCS-LLR-001, FCS-LLR-002, etc.

Total Requirements: ~120 requirements covering:

  • Control law algorithms
  • Sensor input processing (air data, inertial)
  • Actuator command generation
  • Mode logic (normal, degraded, direct)
  • Fault detection and reconfiguration
  • Built-in test (BIT) functions
  • Redundancy management

Software Safety Analysis​

DO-178C Level A Rigor:

  • All requirements traceable to aircraft-level functions
  • 100% structural coverage (MC/DC for all code)
  • Complete verification for every requirement
  • Independent verification and validation (IV&V)

System Safety Assessment Integration:

  • Functional Hazard Assessment (FHA) linkage
  • Failure Modes and Effects Analysis (FMEA)
  • Fault Tree Analysis (FTA) for catastrophic failures
  • Common Cause Analysis (CCA)

Example Safety Analysis: "Elevator Actuator Control FMEA"

  • Function: Compute elevator surface angle command
  • Failure Mode: Erroneous command (hard-over)
  • Severity: 10 (Catastrophic - loss of aircraft)
  • Occurrence: 2 (Extremely remote with redundancy)
  • Detection: 3 (Monitored by independent channel)
  • RPN: 60
  • Action Priority: High (S = 10)
  • Mitigations: Triple redundancy, cross-channel monitoring, reversionary modes

Verification & Validation​

DO-178C Verification Objectives:

  • Requirements-based testing (100% coverage)
  • Structural coverage analysis (MC/DC achieved)
  • Robustness testing (boundary conditions, error injection)
  • Software/hardware integration testing

Test Case Management:

  • 300+ test cases linked to requirements
  • Automated test execution tracking
  • Coverage metrics per requirement type
  • Regression test suite for every build

Traceability Evidence:

  • Requirements → Design → Code → Tests (bidirectional)
  • Verification methods documented per requirement
  • Test procedures linked to HLR and LLR
  • Coverage data for certification audit

Certification Artifacts​

DO-178C Deliverables:

  • Plan for Software Aspects of Certification (PSAC)
  • Software Development Plan (SDP)
  • Software Verification Plan (SVP)
  • Software Configuration Management Plan (SCMP)
  • Software Quality Assurance Plan (SQAP)
  • Software Requirements Standards (SRS)
  • Software Design Standards (SDS)
  • Software Code Standards (SCS)

Traceability Data:

  • Requirements Traceability Matrix (RTM)
  • Verification Coverage Matrix (VCM)
  • Test Traceability Matrix (TTM)

How to Use This Project​

1. Explore DO-178C Requirements Structure​

  1. Open the project:

    • Select "Aerospace Flight Control System" from project list

  2. Navigate requirement levels:

    • Start at Aircraft Level (FCS-ALC-xxx)
    • Drill down to System (FCS-SYS-xxx)
    • Continue to High-Level Software (FCS-HLR-xxx)
    • Bottom level: Low-Level Software (FCS-LLR-xxx)

  3. Observe DAL-A rigor:

    • Every requirement has verification method defined
    • All HLRs traced to SYS requirements
    • All LLRs traced to HLRs
    • Safety annotations (DAL, criticality)

  4. Check derived requirements:

    • Look for requirements marked "Derived"
    • These are software requirements not directly from system level
    • Must be reviewed and approved per DO-178C 6.3.1d

2. Review Safety Analysis​

  1. Open FMEA for critical functions:

    • Go to FMEA → Advanced FMEA
    • Find "Pitch Control Law FMEA" or "Actuator Command FMEA"
    • Review failure modes for flight-critical software

  2. Examine catastrophic failure scenarios:

    • Filter for Severity = 10 (Catastrophic)
    • See how redundancy and monitoring reduce RPN
    • Check Action Priority = High items

  3. Understand mitigation strategy:

    • Multiple lanes of computation (triplex/quadruplex)
    • Cross-channel monitoring
    • Voting algorithms
    • Reversionary modes (degraded control laws)

3. Verify Test Coverage​

  1. Open Analytics → Coverage:

    • See overall test coverage percentage
    • Check coverage by requirement type:
      • Aircraft Level: Traced to system tests
      • System: Traced to integration tests
      • HLR: Traced to software tests
      • LLR: Traced to unit tests

  2. Drill into specific requirement:

    • Select any HLR (e.g., "Compute pitch rate feedback")
    • Click "Tests" tab in right panel
    • See all linked test cases
    • Verify each requirement has ≥1 test

  3. Check structural coverage:

    • For Level A software, need MC/DC
    • View coverage metrics per requirement
    • Identify any gaps requiring additional tests

4. Generate Certification Reports​

  1. Traceability Matrix Export:

    • Analytics → Traceability Matrix
    • Export to Excel for certification package
    • Shows complete requirements chain

  2. Verification Coverage Report:

    • Analytics → Coverage
    • Export coverage statistics
    • Demonstrates 100% verification per DO-178C

  3. Compliance Dashboard:

    • Analytics → Compliance
    • Map to DO-178C objectives
    • Show compliance status for each objective

Key Learning Points​

DO-178C Requirements Process​

  • Requirement levels follow standard decomposition
  • Derived requirements must be identified and justified
  • Bidirectional traceability mandatory for Level A
  • Verification method must be defined for each requirement

Safety-Critical Software Development​

  • Catastrophic failures drive redundancy architecture
  • Independent verification catches design errors
  • Regression testing ensures changes don't break existing functionality
  • Configuration management critical for certification

Certification Evidence​

  • Tool-generated reports save hundreds of hours
  • Automated traceability reduces human error
  • Audit trail shows when requirements changed
  • Compliance mapping demonstrates standard coverage

Avionics-Specific Practices​

  • Control law requirements need precise mathematical specs
  • Timing requirements critical (e.g., 50Hz control loop)
  • Fault tolerance built into requirements (not afterthought)
  • Reversionary modes specified as functional requirements

Comparison to Other Standards​

AspectDO-178C (Avionics)ISO 26262 (Automotive)IEC 62304 (Medical)
LevelsA/B/C/D (DAL)A/B/C/D (ASIL)A/B/C (Class)
CoverageMC/DC for Level AHigh coverage for ASIL-DMedium for Class C
TraceabilityBidirectionalBidirectionalForward trace OK
AnalysisFHA, FMEA, FTAHARA, FMEA, FTAHazard analysis, FMEA
RegulatorFAA/EASANone (self-cert)FDA/EU MDR

Tips for Adapting to Your Project​

  1. Requirements Hierarchy: Adjust levels based on your system complexity
  2. DAL Assignment: Mark each requirement with Design Assurance Level (A/B/C/D)
  3. Verification Methods: Define for each requirement (test, analysis, inspection, review)
  4. Derived Requirements: Track separately and justify their existence
  5. Tool Qualification: If using IntelliSE for certification evidence, may need tool qualification per DO-330

Common Pitfalls to Avoid​

  1. Missing derived requirements: Software often creates requirements not in system spec
  2. Incomplete traceability: Every requirement must trace up and down
  3. Weak verification: "Test TBD" is not acceptable for Level A
  4. Ambiguous requirements: Use "shall" for mandatory, avoid "should" or "may"
  5. Forgetting reversionary modes: Failure handling must be specified

Next Steps​

  1. Explore the project to see DO-178C best practices in action
  2. Clone for your project and adapt the structure
  3. Add your requirements following the 4-level hierarchy
  4. Link to tests as you implement verification
  5. Generate reports for certification reviews

This sample project demonstrates the rigor required for FAA certification of flight-critical software. Use it as a template for your own DO-178C projects, or reference it when auditors ask for traceability evidence.