Қауіпсіздікке маңызды авиациялық бағдарламалық құралдар стандарты

RTCA standard for safety critical software

DO 178B, Software Considerations in Airborne Systems and Equipment Certification is a guideline dealing with the safety of safety critical software used in certain airborne systems. It was jointly developed by the safety critical working group RTCA SC 167 of the Radio Technical Commission for Aeronautics (RTCA) and WG 12 of the European Organisation for Civil Aviation Equipment (EUROCAE). RTCA published the document as RTCA/DO 178B, while EUROCAE published the document as ED 12B. Although technically a guideline, it was a de facto standard for developing avionics software systems until it was replaced in 2012 by DO 178C. The Federal Aviation Administration (FAA) applies DO 178B as the document it uses for guidance to determine if the software will perform reliably in an airborne environment, when specified by the Technical Standard Order (TSO) for which certification is sought. In the United States, the introduction of TSOs into the airworthiness certification process, and by extension DO 178B, is explicitly established in Title 14: Aeronautics and Space of the Code of Federal Regulations (CFR), also known as the Federal Aviation Regulations, Part 21, Subpart O.

Processes are intended to support the objectives, according to the software level (A through D—Level E was outside the purview of DO 178B). Processes are described as abstract areas of work in DO 178B, 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 178B 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 178B, and a project must show that it is respecting those criteria as it performs the activities in the process. The flexible nature of DO 178B'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 178B 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 178B training and consulting. For a generic DO 178B based process, a visual summary is provided including the Stages of Involvement (SOIs) defined by FAA on the "Guidance and Job Aids for Software and Complex Electronic Hardware".

System requirements are typically input to the entire project. The last 3 documents (standards) are not required for software level D

Typically a Designated Engineering Representative (DER) reviews technical data as part of the submission to the FAA for approval.

Software can automate, assist or otherwise handle or help in the DO 178B processes. All tools used for DO 178B development must be part of the certification process. Tools generating embedded code are qualified as development tools, with the same constraints as the embedded code. Tools used to verify the code (simulators, test execution tool, coverage tools, reporting tools, etc.) must be qualified as verification tools, a much lighter process consisting in a comprehensive black box testing of the tool. A third party tool can be qualified as a verification tool, but development tools must have been developed following the DO 178 process. Companies providing these kind of tools as COTS are subject to audits from the certification authorities, to which they give complete access to source code, specifications and all certification artifacts. Outside of this scope, output of any used tool must be manually verified by humans. A problem management tool can provide traceability for changes. SCI and SECI can be created from logs in a revision control tool.

Requirements traceability is concerned with documenting the life of a requirement. It should be possible to trace back to the origin of each requirement and every change made to the requirement should therefore be documented in order to achieve traceability. Even the use of the requirement after the implemented features have been deployed and used should be traceable.

VDC Research notes that DO 178B has become "somewhat antiquated" in that it is not adapting well to the needs and preferences of today's engineers. In the same report, they also note that DO 178C seems well poised to address this issue.