|
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. Although technically a guideline, it is (or was) a ''de facto'' standard for developing avionics software systems. The FAA applies DO-178B as the document it uses for guidance to determine if the software will perform reliably in an airborne environment,〔(FAA Advisory Circular 20-115B )〕 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. It was jointly developed by the safety-critical working group RTCA SC-167 of RTCA and WG-12 of EUROCAE. RTCA published the document as RTCA/DO-178B, while EUROCAE published the document as ED-12B. ==Software level== The Software Level, also known as the Design Assurance Level (DAL) or also '"Item Development Assurance Level"' (IDAL)〔RTCA/DO-178B "Software Considerations in Airborne Systems and Equipment Certification", p. 7〕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. * Catastrophic – Failure may cause a crash. Error or loss of critical function required to safely fly and land aircraft. * Hazardous – Failure has a large negative impact on safety or performance, or reduces the ability of the crew to operate the aircraft due to physical distress or a higher workload, or causes serious or fatal injuries among the passengers. (Safety-significant) * Major – Failure is significant, but has a lesser impact than a Hazardous failure (for example, leads to passenger discomfort rather than injuries) or significantly increases crew workload (safety related) * Minor – Failure is noticeable, but has a lesser impact than a Major failure (for example, causing passenger inconvenience or a routine flight plan change) * No Effect – Failure has no impact on safety, aircraft operation, or crew workload. DO-178B 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. Typically IEEE STD-1228-1994 Software Safety Plans are allocated and software safety analyses tasks are accomplished in sequential steps (requirements analysis, top level design analysis, detailed design analysis, code level analysis, test analysis and change analysis). These software safety tasks and artifacts are integral supporting parts of the process for hazard severity and DAL determination to be documented in system safety assessments (SSA). The certification authorities require and DO-178B specifies the correct DAL be established using these comprehensive analyses methods to establish the software level A-E. Any software that commands, controls, and monitors safety-critical functions should receive the highest DAL - Level A. It is the software safety analyses that drive the system safety assessments that determine the DAL that drives the appropriate level of rigor in DO-178B. The system safety assessments combined with methods such as SAE ARP 4754A determine the after mitigation DAL and may allow reduction of the DO-178B software level objectives to be satisfied if redundancy, design safety features and other architectural forms of hazard mitigation are in requirements driven by the safety analyses. Therefore, DO-178B central theme is design assurance and verification after the prerequisite safety requirements have been established. The number of objectives to be satisfied (eventually 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.〔RTCA/DO-178B "Software Considerations in Airborne Systems and Equipment Certification", p. 82〕 In some cases, an automated tool may be equivalent to independence.〔RTCA/DO-178B "Software Considerations in Airborne Systems and Equipment Certification", p.82〕 However, the tool itself must then be qualified if it substitutes for human review. 抄文引用元・出典: フリー百科事典『 ウィキペディア（Wikipedia）』 ■ウィキペディアで「DO-178B」の詳細全文を読む スポンサード リンク
|