Misplaced Pages

#108891

36-427: MC/DC requires all of the below during testing: Independence of a condition is shown by proving that only one condition changes at a time. MC/DC is used in avionics software development guidance DO-178B and DO-178C to ensure adequate testing of the most critical (Level A) software , which is defined as that software which could provide (or prevent failure of) continued safe flight and landing of an aircraft. It

72-469: 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

108-673: A decision and may produce false positives (reporting 100% code coverage when indeed this is not the case). In 2002 Sergiy Vilkomir proposed reinforced condition/decision coverage ( RC/DC ) as a stronger version of the MC/DC coverage criterion that is suitable for safety-critical systems . Jonathan Bowen and his co-author analyzed several variants of MC/DC and RC/DC and concluded that at least some MC/DC variants have superior coverage over RC/DC. DO-178B DO-178B, Software Considerations in Airborne Systems and Equipment Certification

144-406: A decision is treated as if it is a boolean expression that changes the control flow of the program (the text in brackets in an 'if' statement) then one may think that Function B is likely to have higher MC/DC than Function A for a given set of test cases (easier to test because it needs less tests to achieve 100% MC/DC coverage), even though functionally both are the same. However, what is wrong in

180-415: 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

216-518: 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

252-495: A survey they conducted "revealed that members of the public, librarians, researchers, students, attorneys, and small business owners continue to rely on the print" version of the Federal Register . AALL also argued that the lack of print versions of the Federal Register and CFR would mean the 15 percent of Americans who do not use the internet would lose their access to that material. The House voted on July 14, 2014, to pass

288-402: A switch statement or by using a table with an enumeration value as an index. The number of tests required based on the source code could be considerably different depending upon the coverage required, although semantically we would want to test both approaches with a minimum number of tests. Another example that could be considered as "cheating" to achieve higher MC/DC is: if the definition of

324-467: 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. Requirements traceability

360-566: 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

396-493: Is also highly recommended for SIL 4 in part 3 Annex B of the basic safety publication and ASIL D in part 6 of automotive standard ISO 26262 . Additionally, NASA requires 100% MC/DC coverage for any safety critical software component in Section 3.7.4 of NPR 7150.2D. It is a misunderstanding that by purely syntactic rearrangements of decisions (breaking them into several independently evaluated conditions using temporary variables,

SECTION 10

#1733085232109

432-422: 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

468-844: 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-178B alone is not intended to guarantee software safety aspects. Safety attributes in the design and 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

504-491: 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. In some cases, an automated tool may be equivalent to independence. However, the tool itself must then be qualified if it substitutes for human review. Processes are intended to support

540-504: 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. Code of Federal Regulations In the law of the United States , the Code of Federal Regulations ( CFR ) is the codification of the general and permanent regulations promulgated by the executive departments and agencies of

576-435: Is structured into 50 subject matter titles. Agencies are assigned chapters within these titles. The titles are broken down into chapters, parts, sections and paragraphs. For example, 42 C.F.R. § 260.11(a)(1) would indicate "title 42, part 260, section 11, paragraph (a)(1)." Conversationally, it would be read as "forty-two C F R two-sixty point eleven a one" or similar. While new regulations are continually becoming effective,

612-557: 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

648-408: Is typically required (depending on software level). This process typically also involves: Other names for tests performed in this process can be: Documents 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: Output documents from

684-597: The Administrative Procedure Act (APA), Paperwork Reduction Act (PRA, codified at 44 U.S.C.   §§ 3501 – 3521 ), Regulatory Flexibility Act (RFA, codified at 5 U.S.C.   §§ 601 – 612 ), and several executive orders (primarily Executive Order 12866 )). Generally, each of these laws requires a process that includes (a) publication of the proposed rules in a notice of proposed rulemaking (NPRM), (b) certain cost-benefit analyses, and (c) request for public comment and participation in

720-693: The federal government of the United States . The CFR is divided into 50 titles that represent broad areas subject to federal regulation. The CFR annual edition is published as a special issue of the Federal Register by the Office of the Federal Register (part of the National Archives and Records Administration ) and the Government Publishing Office . In addition to this annual edition,

756-690: The CFR is published online on the Electronic CFR (eCFR) website, which is updated daily. Congress frequently delegates authority to an executive branch agency to issue regulations to govern some sphere. These statutes are called "authorizing statute" or "enabling statute" (or "authorizing legislation"). Authorizing statutes typically have two parts: a substantive scope (typically using language such as "The Secretary shall promulgate regulations to [accomplish some purpose or within some scope]" and (b) procedural requirements (typically to invoke rulemaking requirements of

SECTION 20

#1733085232109

792-459: The CFR. The CFR is divided into 50 titles that represent broad subject areas: The Federal Register Act originally provided for a complete compilation of all existing regulations promulgated prior to the first publication of the Federal Register , but was amended in 1937 to provide a codification of all regulations every five years. The first edition of the CFR was published in 1938. Beginning in 1963 for some titles and for all titles in 1967,

828-537: The Office of the Federal Register began publishing yearly revisions, and beginning in 1972 published revisions in staggered quarters. On March 11, 2014, Rep. Darrell Issa introduced the Federal Register Modernization Act (H.R. 4195; 113th Congress) , a bill that would revise requirements for the filing of documents with the Office of the Federal Register for inclusion in the Federal Register and for

864-774: 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. The Software Level , also termed the Design Assurance Level (DAL) or Item Development Assurance Level (IDAL) as defined in ARP4754 ( DO-178C only mentions IDAL as synonymous with Software Level ),

900-416: 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

936-447: The decision-making, and (d) adoption and publication of the final rule, via the Federal Register . Rulemaking culminates in the inclusion of a regulation in the Code of Federal Regulations. Such regulations are often referred to as "implementing regulations" vis-a-vis the authorizing statute. The rules and regulations are first promulgated or published in the Federal Register . The CFR

972-597: The entire project. The last 3 documents (standards) are not required for software level D.. DO-178B is not intended as a software development standard; it is software assurance using a set of tasks to meet objectives and levels of rigor. 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 : Document outputs made by this process: Analysis of all code and traceability from tests and results to all requirements

1008-401: 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

1044-570: 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

1080-404: The previous statement is the definition of decision. A decision includes 'any' boolean expression, even for assignments to variables. In this case, the three assignments should be treated as a decision for MC/DC purposes and therefore the changed code needs exactly the same tests and number of tests to achieve MC/DC than the first one. Some code coverage tools do not use this strict interpretation of

1116-410: The printed volumes of the CFR are issued once each calendar year, on this schedule: The Office of the Federal Register also keeps an unofficial, online version of the CFR, the e-CFR, which is normally updated within two days after changes that have been published in the Federal Register become effective. The Parallel Table of Authorities and Rules lists rulemaking authority for regulations codified in

Modified condition/decision coverage - Misplaced Pages Continue

1152-399: 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

1188-424: The publication of the Code of Federal Regulations to reflect the changed publication requirement in which they would be available online but would not be required to be printed. The American Association of Law Libraries (AALL) strongly opposed the bill, arguing that the bill undermines citizens' right to be informed by making it more difficult for citizens to find their government's regulations. According to AALL,

1224-522: 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. 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

1260-413: 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

1296-442: The values of which are then used in the decision) which do not change the semantics of a program can lower the difficulty of obtaining complete MC/DC coverage. This is because MC/DC is driven by the program syntax. However, this kind of "cheating" can be done to simplify expressions, not simply to avoid MC/DC complexities. For example, assignment of the number of days in a month (excluding leap years) could be achieved by using either

#108891