Sofema Aviation Services (SAS) www.sassofia.com considers Aviation Safety and Certification of Digital Systems and Safety Critical Software.
Introduction
Aircrafts are increasingly dependent on digital systems for everything from flight controls to in-flight entertainment. These systems need to be both safe and reliable.
- In this context, safety means that the system will not cause harm to people or property, while reliability refers to the system performing its intended function under specified operating conditions for a specified period.
- Safety-critical software refers to software systems where a failure could result in loss of life, significant property damage, or damage to the environment. In aviation, this includes software that controls the aircraft’s flight systems, navigation, communication, and more.
The process of safety and certification of digital systems and safety-critical software is complex and rigorous. It involves multiple stages of design, testing, verification, and validation. In the context of aircraft certification, these processes are heavily regulated by EASA in Europe, following international standards such as DO-178C for software and DO-254 for hardware.
Software Criticality
Software criticality refers to the level of impact that a software component can have on the safety of the overall system. Software is classified in terms of its criticality level in the case of failure, from low to high. The safety-critical software is those systems where a failure could result in catastrophic outcomes, like a loss of life, severe injury, or significant property damage.
Safety-Critical Identifications
- Level A
– Anomalous behaviour – catastrophic failure condition – “prevent continued safe flight and landing”
- Level B
– Anomalous behaviour – hazardous / severe-major failure condition – “serious or potentially fatal injuries to a small number of occupants”
- Level C
– Anomalous behaviour – major failure condition – “discomfort to occupants, possibly including injuries”
- Level D
– Anomalous behaviour – minor failure condition – “some inconvenience to occupants”
- Level E
– Anomalous behaviour – no effect on aircraft operational capability or Pilot workload
Introduction to Software Certification Standards
- DO-178C: This standard is used for the production of airborne systems and equipment software.
– The level of rigour required by DO-178C in the development of the software is directly proportional to the criticality of the software. It contains guidance for the entire lifecycle of the software.
- Planning
- Requirements capture
- Design
- Coding
- Integration
- Verification
- Validation
- Configuration management
- Quality assurance
- Certification liaison
- DO-254: This standard guides the development of airborne electronic hardware, including both custom and commercial off-the-shelf (COTS) components.
Now consider the following:
Standards Compliance:
- Several international standards guide the safety and reliability of aircraft software. For example, DO-178C (Software Considerations in Airborne Systems and Equipment Certification) is the primary standard for commercial avionics software development. Compliance with these standards is required for certification.
Rigorous Testing:
- Safety-critical software needs to be tested under all foreseeable conditions. This includes normal operation, edge cases, and potential failure scenarios.
– Simulating different flight conditions, hardware failures, and more.
Redundancy:
- Redundancy is a common approach to improving the safety and reliability of aircraft systems.
– Multiple independent software systems might be developed to perform the same function. If one fails, the others can take over.
Error Detection and Recovery:
- Safety-critical systems should have the capability to detect errors and recover from them.
- This could involve restarting a failed system, switching to a backup, or, in the worst-case scenario, safely shutting down the system.
Security:
- With the increasing interconnectivity of aircraft systems, cybersecurity has become an important part of aviation safety.
- Digital systems and safety-critical software need to be protected against threats like hacking and malware.
Lifecycle Management:
- Aviation systems have long lifecycles and need to be maintained and updated over time.
- This includes making sure that changes and updates to software systems do not introduce new safety risks.
EASA Software Certification Process
Review the following Document – EASA CM No.: EASA CM – SWCEH – 002
Issue: 01 Revision: 01 09th of March 2012
Issued by: Software & Complex Electronic Hardware section
Regulatory Requirement(s): CS 25.1301 and 1309 for Large Aeroplanes, CS 23.1301 and 23.1309 for Small Aeroplanes, CS 27.1301 and 27.1309 for Small Rotorcraft, CS 29.1301 and 29.1309 for Large Rotorcraft, CS E-50 (d,f) for engines, CS-P, CS-APU and CS-ETSO.
The guidance contained in this Certification Memorandum applies to any applicants seeking approval from EASA for software embedded in aircraft systems or engines that are intended to comply with ED-12B / DO-178B. It also applies to any personnel involved in the ED-12B / DO-178B activities related to the airborne software of those applicants.
- For TCs and STCs, applicants should ensure that they use the appropriate version of the Certification Memorandum called up in the applicable CRI.
- For an ETSO, the applicant may decide to take into account all or part of this guidance contained herein and may substantiate the details of their compliance in specific documentation (i.e. Declaration of Design and Performance, Software Accomplishment Summary, Hardware Accomplishment Summary or equivalent). Caution should be taken as the content of the Certification Memoranda may have changed by the time the equipment is installed in the Aircraft/Engine. In any case, the installed equipment should finally comply with the Aircraft/Engine Certification Basis (including certain Certification Review Items).
Note – When this Certification Memorandum is used outside of the scope of a TC, STC or ETSO (e.g.for pre-consultancy, pre-application, etc.), this guidance is provided for information only and caution should be taken as the content of the Certification Memorandum may have changed by the time of the application.
Software Acceptance by FAA
The Federal Aviation Administration (FAA) has the authority to determine whether compliance with Federal Aviation Regulations has been achieved:
- For software, compliance with the Federal Aviation Regulations is defined in the FAA Advisory Circular 20-115B. The advisory circular states that software can use compliance to RTCA/DO-178B to show compliance with the Federal Aviation Regulations.
- Since the FAA determines compliance with Federal Aviation Regulations, then for software the FAA determines compliance to RTCA/DO-178B.
- RTCA/DO-178B was created by an RTCA committee. The FAA had participants in the committee.
The DO-178B guidelines apply to civil aviation for aircraft, helicopters and engines as mandated by the Federal Aviation Regulations (FAA).
- The guidelines also apply to the systems and equipment that utilize software or airborne electronic hardware used in aviation.
When is DO-178B compliance required?
- For systems and equipment using software to fulfil a safety-related aircraft function. FAA Advisory Circular 20-115B cites RTCA/DO-178B as a means of compliance with the Federal Aviation Regulations Part 21, 23, 25, 27, 29 and 33.
- DO-178B is used for all new software development as well as for software changes to legacy systems containing software. The FAA defines DO-178B as a means, but not the only means of compliance with the Federal Aviation Regulations. It is an extremely rare exception that an alternative means of compliance is used for software in avionics applications.
Software Design Assurance Level
- Levels A, B & C require that the test cases provide normal range and robustness coverage of all software high-level and low-level requirements.
- Level D only requires test cases that provide normal range and robustness coverage of all software high-level requirements.
The amount of testing needed to achieve the structural coverage objectives
- Level A software requires modified condition decision coverage; + Decision Coverage + Statement coverage.
- Level B software requires decision coverage and
- Level C software requires only statement coverage.
- Level D software does not require coverage metrics. In general, the test cases do not need to be as comprehensive as those for Levels A, B or C.
Next Steps
Follow this link to our Library to find & download related documents for Free.
Sofema Aviation Services (www.sassofia.com) offers training to cover CS 25 System Safety Assessments
Tags:
aviation safety, Security, Certification, SAS blogs, Aviation Safety Standards, Certification of Digital Systems, Safety Critical Software, Standards Compliance, Rigorous Testing, Error Detection and Recovery, EASA Software Certification Process
