DO-178C, Software Considerations in Airborne Systems and Equipment Certification is the primary document by which the certification authorities such as FAA, EASA and Transport Canada approve all commercial software-based aerospace systems. The document is published by RTCA, Incorporated, in a joint effort with EUROCAE, and replaces DO-178B. The new document is called DO-178C/ED-12C and was completed in November 2011 and approved by the RTCA in December 2011. It became available for sale and use in January 2012.
The FAA approved AC 20-115C on 19 Jul 2013, making DO-178C a recognized "acceptable means, but not the only means, for showing compliance with the applicable airworthiness regulations for the software aspects of airborne systems and equipment certification."
The Software Level, also known as the Development Assurance Level (DAL) or Item Development Assurance Level (IDAL) as defined in ARP4754 (DO-178C only mentions IDAL as synonymous with Software Level[10]), is determined from the safety assessment process and hazard analysis by examining the effects of a failure condition in the system. The failure conditions are categorized by their effects on the aircraft, crew, and passengers.
DO-178C alone is not intended to guarantee software safety aspects. Safety attributes in the design and as implemented as functionality must receive additional mandatory system safety tasks to drive and show objective evidence of meeting explicit safety requirements. The certification authorities require and DO-178C specifies the correct DAL be established using these comprehensive analyses methods to establish the software level A-E. "The software level establishes the rigor necessary to demonstrate compliance" with DO-178C.[10] Any software that commands, controls, and monitors safety-critical functions should receive the highest DAL - Level A.
The number of objectives to be satisfied (some with independence) is determined by the software level A-E. The phrase "with independence" refers to a separation of responsibilities where the objectivity of the verification and validation processes is ensured by virtue of their "independence" from the software development team. For objectives that must be satisfied with independence, the person verifying the item (such as a requirement or source code) may not be the person who authored the item and this separation must be clearly documented.
Level Failure condition Objectives With independence:
A Catastrophic 71 30
B Hazardous 69 18
C Major 62 5
D Minor 26 2
E No Safety Effect 0 0
Processes are intended to support the objectives, according to the software level (A through D—Level E was outside the purview of DO-178C). Processes are described as abstract areas of work in DO-178C, and it is up to the planners of a real project to define and document the specifics of how a process will be carried out. On a real project, the actual activities that will be done in the context of a process must be shown to support the objectives. These activities are defined by the project planners as part of the Planning process.
This objective-based nature of DO-178C allows a great deal of flexibility in regard to following different styles of software life cycle. Once an activity within a process has been defined, it is generally expected that the project respect that documented activity within its process. Furthermore, processes (and their concrete activities) must have well defined entry and exit criteria, according to DO-178C, and a project must show that it is respecting those criteria as it performs the activities in the process.
The flexible nature of DO-178C's processes and entry/exit criteria make it difficult to implement the first time, because these aspects are abstract and there is no "base set" of activities from which to work. The intention of DO-178C was not to be prescriptive. There are many possible and acceptable ways for a real project to define these aspects. This can be difficult the first time a company attempts to develop a civil avionics system under this standard, and has created a niche market for DO-178C training and consulting.
For a generic DO-178C based process, Stages of Involvements (SOI) are the minimum gates that a Certification Authority gets involved in reviewing a system or sub-system as defined by EASA on the Certification Memorandum SWCEH – 002: SW Approval Guidelines and FAA on the Order 8110.49: SW Approval Guidelines.
DO-178C PLANS & STANDARDS
📷
DO-178C PLANS & STANDARDS
· DO-178C Plan for Software Aspects of Certification (PSAC)
· DO-178C Plan for Software Software Aspects of Certification (PSSAC)
· DO-178C Software Quality Assurance Plan (SQAP)
· DO-178C Software Configuration Management Plan (SCMP)
· DO-178C Software Development Plan (SDP)
· DO-178C Software Verification Plan (SVP)
· DO-178C Software Traceability (ST)
· DO-178C Software Requirement Standard (SRS)
· DO-178C Software Design Standard (SDS)
· DO-178C Software Coding Standard (SCS)
· DO-178C Software Accomplishment Summary (SAS)
DO-178C Stage of Involvement (SOI)
DO-178C CHECKLISTS for PLANS & STANDARDS
📷
DO-178C CHECKLISTS
DO-178C Stage of Involvement (SOI)
'LIFE ' is the most critical of all Safety-Critical Systems.
We hold these truths to be self-evident, that all people:
Black, White, Brown, Red, Yellow, and Mixed lives matter;
Native, Immigrant, and Non-Immigrant lives matter;
Male, Female, and Gender Fluid lives matter;
Challenged and Unchallenged, lives matter;
Young and Old lives matter;
Your and My life matter.
.. Black Lives Matter (BLM).
.... All Lives Matter (ALM)...