 |
 |
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
|
|
|
|
|
By
Wikipedia, DO-178B, Software Considerations in Airborne Systems and Equipment Certification is a guidance for software development published by RTCA, Incorporated. The standard was developed by RTCA and EUROCAE. The FAA accepts use of DO-178B as a means of certifying software in avionics. Software levelThe required Design Assurance Level (DAL) 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.
The number of objectives to be satisfied (eventually with independence) is determined by the software level. In the standard, "with independence" refers to a separation of responsibilities where the person(s) who verify an objective must not be the developers of the item in question. In some cases, an automated tool may be equivalent to independence.
Processes and documentsProcesses are intended to support the objectives, according to the software level (A through D - Level E is 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. Therefore, on a real project, the actual activities that will be done in the context of a process must be shown to support the objectives. In fact, 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. However, 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. Therefore, 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. The processes, activities and documents described here reflect naming and structure from DO-178B. This can be different in a real-life project. PlanningOutput documents from this process:
System requirements are typically input to the entire project. The last 3 documents (standards) are not required for software level D. DevelopmentThis process can be divided into sub-processes: requirements, design, code and integration. The development process output documents:
Traceability from system requirements to all source code or executable object code is typically required (depending on software level). Typically used software development process: VerificationDocument outputs made by this process:
Analysis of all code and traceability from tests and results to all requirements is typically required (depending on software level). This process typically also involves:
Other names for tests performed in this process can be:
Configuration managementDocuments maintained by the configuration management process:
This process handles problem reports, changes and related activities. The configuration management process typically provides archive and revision identification of:
Quality assuranceOutput documents from the quality assurance process:
This process performs reviews and audits to show compliance with DO-178B. The interface to the certification authority is also handled by the quality assurance process. Certification liaisonTypically a Designated Engineering Representative (DER) working for e.g. FAA in an airplane manufacturing company. Certification in EuropeToolsSoftware 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 . As a consequence, one can qualify a third party tool as verification tool, but development tools must have been developed following the DO-178 process. Companies providing this 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.
Requirements ManagementRequirements 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. Software such as
are quite helpful for the requirements management. Resources
See also
External links
Industry Websites
Text from Wikipedia is available under the Creative Commons Attribution/Share-Alike License; additional terms may apply.
Published in July 2009. Click here to read more articles related to aviation and space!
|
|
|
|
|
|
|
|
|
|
|
|
|
 |
|
|
|
|
|
|
Copyright 2004-2024 © by Airports-Worldwide.com, Vyshenskoho st. 36, Lviv 79010, Ukraine Legal Disclaimer |
|
|
|
|
|
