CAST-15

Last updated
Merging High-Level and Low-Level Requirements
US-FederalAviationAdmin-Seal.svg
FAA Publication
AbbreviationCAST-15
Year started2003
Organization Certification Authorities Software Team
Domain Avionics, type certification

CAST-15, Merging High-Level and Low-Level Requirements is a Certification Authorities Software Team (CAST) Position Paper. It is an FAA publication that "does not constitute official policy or guidance from any of the authorities", but is provided to applicants for software and hardware certification for educational and informational purposes only.

Contents

As established by the FAA advisory circular AC 20-115, the RTCA publication DO-178B/C defines an acceptable means of certification of airworthy software. Unique among development standards, DO-178B introduced a distinction between High-Level Requirements and Low-Level Requirements as formal products of software requirements analysis and design when developing airworthy software. [1] [2] [3]

DO-17B/C assigned different sets of objectives to these two levels of requirements. To accomplish compliance, the Applicant needs to fulfill both sets of objectives with their requirements. However, under narrow conditions, that standard's guidance permits combination of these two levels into just one level of requirements, but warns against the practice in general. [4]

This position paper is concerned with observed misuse of this guidance; some applicants were combining High-Level and Low-Level Requirements for "simple" products, but were not accomplishing all of the related objectives for both levels of requirements. [5]

This position paper is also an example of Certification Authorities using their "what" versus "how" distinction [6] between high-level and low-level requirements [7] [8] [9] that DO-178B/C does not clearly explain.

Background

Various stakeholders for software definition and verification have differing objectives and levels of abstraction. Those stakeholders responsible for defining or verifying high-level software product functionality are generally concerned with the structures and behaviors of the product's external interfaces, and details of internal software structures do not necessarily support that focus. On the other hand, those responsible for defining and verifying requirement coverage of all internal code need much finer details of internal software structures. This is the justification for DO-178B/C establishing distinct objectives for high-level and low-level requirements, with consideration for applicants developing additional requirement layering on large projects. [10]

However, DO-178B allowed for the possibility of developing only one level of requirements for particularly simple systems. That is, Certification Authorities (e.g., FAA-Designated Engineering Representatives) would not expect any more or fewer requirement layers than necessary. However, the Certification Authorities’ experience was that some applicants misused or abused this intention, and as a result, such applicants discovered late in their projects that they were unable to demonstrate compliance and had to repeat some activities.

This is also an issue for any usage of development tools that potentially reduce the resolution of requirements in a project, particularly those that use notations of higher abstraction (e.g., UML or block flow modeling). Applicants using such tools generally are expected to declare if their development processes use such tool's notation the role of describing either high-level requirements or low-level requirements, but usually not both. [11]

Status

In general, CAST Position Papers were issued to harmonize review of software projects conducted under DO-178B or DO-254. But, they were also intended to inform the development and eventual release of DO-178C and supporting publications. As much of the discussion and rationale recorded in the CASTs is not included in the newer publications, the CASTs remain a source of insight into the updated standards.

This CAST-15 Position Paper is no longer provided on the FAA's publications site as the team's concerns were addressed by FAQ #81 in DO-248C, Supporting Information for DO-178C and DO-278A [12] and by changes and clarification in the release of DO-178 Revision C:

However, neither DO-248C nor DO-178C completely incorporates the "full discussion of this topic" [5] [7] that is recorded CAST-15.

Much of the same content of the original CAST-15 Position Paper is published in the 2012 EASA Certification Memo EASA CM-SWCEH-002 (Section 23 Merging High-Level and Low-Level Requirements). [15]

Contents

DO-178C/DO-178B provides guidance for merging High-Level and Low-Level Software Requirements. Nominally, in the DO-178C/DO-178B context, the High-Level Requirements for a Certified Software Product are distinct from the Low-Level Software Requirements, the former being outputs of the Software Requirements Process and the latter being outputs of the Software Design Process. [16]

In some applications, the System/High-Level Requirements are of sufficient simplicity and detail that the Source Code can be produced and verified directly. In this situation, the System/High-Level Requirements are also considered to be Low-Level Requirements, which means that, in addition to accomplishing the objectives for High-Level Requirements, the same requirements must also accomplish the objectives for Low-Level Requirements. [17]

The concern that prompted CAST-15 is that some applicants for software certification interpreted the above guidance as permitting combining both High-Level Software Requirements and Low-Level Software Requirements in a single software requirements document or other artifact without making any indication of which requirements are High-Level and which are Low-Level, but also omitting traceability between the Low-Level and High-Level Requirements and neglecting to identify derived requirements for feedback to System Processes, including System Safety.

This Position Paper discusses several problems and hazards that Certification Authorities see arising from merging Low-Level Requirements into the collection of High-Level Requirements, recommending that this not be done. [18] The replacement content published in FAQ #81 in DO-248C Supporting Information for DO-178C and DO-278A provides a shorter list of certification concerns for combining (or merging) these two "what" and "how" levels into a single set of requirements without distinguishing the relevant certification objectives of the two levels. FAQ #81 also recommends against merging High-Level and Low-Levels even in cases where the code can be written and verified in a "single step" of requirements as the original DO-178B/C guidance allows, but does offer suggestions on how to address concerns. [19] [20]

Model-based development

The distinction between, or combination of, High-Level and Low-Level Requirements is a particular issue with Model-based development. As vendors and applicants employ Model-Based Development tools in the development of airborne software, concern arises about automation and elimination of levels of certification evidence. Arguments are made for careful designation of which Model-Based artifacts represent High-Level Requirements and which represent Low-Level Requirements. Finally, the standard DO-331 (Model-Based Development and Verification), supplement to DO-178C has clarified these aspects stating that high level requirements are requirements located prior to the model from which the model has been developed, the low level requirements being those located in the model itself. DO-331 having clarified the issue for model based development, the level-merging concerns of CAST-15 are not applicable to model based development. [21]

Related Research Articles

In software engineering, code coverage is a percentage measure of the degree to which the source code of a program is executed when a particular test suite is run. A program with high test coverage has more of its source code executed during testing, which suggests it has a lower chance of containing undetected software bugs compared to a program with low test coverage. Many different metrics can be used to calculate test coverage. Some of the most basic are the percentage of program subroutines and the percentage of program statements called during execution of the test suite.

Avionics software is embedded software with legally mandated safety and reliability concerns used in avionics. The main difference between avionic software and conventional embedded software is that the development process is required by law and is optimized for safety. It is claimed that the process described below is only slightly slower and more costly than the normal ad hoc processes used for commercial software. Since most software fails because of mistakes, eliminating the mistakes at the earliest possible step is also a relatively inexpensive and reliable way to produce software. In some projects however, mistakes in the specifications may not be detected until deployment. At that point, they can be very expensive to fix.

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.

A hazard analysis is used as the first step in a process used to assess risk. The result of a hazard analysis is the identification of different types of hazards. A hazard is a potential condition and exists or not. It may, in single existence or in combination with other hazards and conditions, become an actual Functional Failure or Accident (Mishap). The way this exactly happens in one particular sequence is called a scenario. This scenario has a probability of occurrence. Often a system has many potential failure scenarios. It also is assigned a classification, based on the worst case severity of the end condition. Risk is the combination of probability and severity. Preliminary risk levels can be provided in the hazard analysis. The validation, more precise prediction (verification) and acceptance of risk is determined in the risk assessment (analysis). The main goal of both is to provide the best selection of means of controlling or eliminating the risk. The term is used in several engineering specialties, including avionics, food safety, occupational safety and health, process safety, reliability engineering.

<span class="mw-page-title-main">ARP4754</span>

ARP4754, Aerospace Recommended Practice (ARP) ARP4754A, is a guideline from SAE International, dealing with the development processes which support certification of Aircraft systems, addressing "the complete aircraft development cycle, from systems requirements through systems verification." Revision A was released in December 2010. It was recognized by the FAA in AC 20-174 published November 2011. EUROCAE jointly issues the document as ED–79.

RTCA DO-254 / EUROCAE ED-80, Design Assurance Guidance for Airborne Electronic Hardware is a document providing guidance for the development of airborne electronic hardware, published by RTCA, Incorporated and EUROCAE. The DO-254/ED-80 standard was formally recognized by the FAA in 2005 via AC 20-152 as a means of compliance for the design assurance of electronic hardware in airborne systems. The guidance in this document is applicable, but not limited, to such electronic hardware items as

DOD-STD-2167A, titled "Defense Systems Software Development", was a United States defense standard, published on February 29, 1988, which updated the less well known DOD-STD-2167 published 4 June 1985. This document established "uniform requirements for the software development that are applicable throughout the system life cycle." This revision was written to allow the contractor more flexibility and was a significant reorganization and reduction of the previous revision; e.g.., where the previous revision prescribed pages of design and coding standards, this revision only gave one page of general requirements for the contractor's coding standards; while DOD-STD-2167 listed 11 quality factors to be addressed for each software component in the SRS, DOD-STD-2167A only tasked the contractor to address relevant quality factors in the SRS. Like DOD-STD-2167, it was designed to be used with DOD-STD-2168, "Defense System Software Quality Program".

Lynx Software Technologies, Inc. is a San Jose, California software company founded in 1988. Lynx specializes in secure virtualization and open, reliable, certifiable real-time operating systems (RTOSes). Originally known as Lynx Real-Time Systems, the company changed its name to LynuxWorks in 2000 after acquiring, and merging with, ISDCorp, an embedded systems company with a strong Linux background. In May 2014, the company changed its name to Lynx Software Technologies.

<span class="mw-page-title-main">LDRA</span> Software companies of the United Kingdom

LDRA is a provider of software analysis, and test and requirements traceability tools for the Public and Private sectors, and is a pioneer in static and dynamic software analysis.

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 EUROC 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.

<span class="mw-page-title-main">AC 25.1309-1</span> American aviation regulatory document

AC 25.1309–1 is an FAA Advisory Circular (AC) that identifies acceptable means for showing compliance with the airworthiness requirements of § 25.1309 of the Federal Aviation Regulations. Revision A was released in 1988. In 2002, work was done on Revision B, but it was not formally released; the result is the Rulemaking Advisory Committee-recommended revision B-Arsenal Draft (2002). The Arsenal Draft is "considered to exist as a relatively mature draft". The FAA and EASA have subsequently accepted proposals by type certificate applicants to use the Arsenal Draft on development programs.

<span class="mw-page-title-main">FAA Order 8130.34</span>

FAA Order 8130.34D, Airworthiness Certification of Unmanned Aircraft Systems, establishes procedures for issuing either special airworthiness certificates in the experimental category or special flight permits to unmanned aircraft systems (UAS), optionally piloted aircraft (OPA), and aircraft intended to be flown as either a UAS or an OPA.

Cantata++, or simply Cantata in newer versions, is a commercial computer program for dynamic testing, specifically unit testing and integration testing, and code coverage at run time of C and C++ programs. It is developed and sold by QA Systems, and was formerly a product of IPL Information Processing Ltd.

<span class="mw-page-title-main">AC 20-115</span>

The Advisory Circular AC 20-115( ), Airborne Software Development Assurance Using EUROCAE ED-12( ) and RTCA DO-178( ), identifies the RTCA published standard DO-178 as defining a suitable means for demonstrating compliance for the use of software within aircraft systems. The present revision D of the circular identifies ED-12/DO-178 Revision C as the active revision of that standard and particularly acknowledges the synchronization of ED-12 and DO-178 at that revision.

<span class="mw-page-title-main">FAA Order 8110.105</span> American regulatory order

FAA Order 8110.105A, Simple and Complex Electronic Hardware Approval Guidance, supplements RTCA DO-254 by explaining how FAA aircraft certification staff can use that document "when working on certification projects". "The Order states specific topics of interest to the FAA that may go above and beyond content specific to DO-254." This order is recommended as a reference for developers applying under DO-254 for certification of electronic hardware designs, including those implemented in "custom micro-coded components".

DO-248C, Supporting Information for DO-178C and DO-278A, published by RTCA, Incorporated, is a collection of Frequently Asked Questions and Discussion Papers addressing applications of DO-178C and DO-278A in the safety assurance of software for aircraft and software for CNS/ATM systems, respectively. Like DO-178C and DO-278A, it is a joint RTCA undertaking with EUROCAE and the document is also published as ED-94C, Supporting Information for ED-12C and ED-109A. The publication does not provide any guidance additional to DO-178C or DO-278A; rather, it only provides clarification for the guidance established in those standards. The present revision is also expanded to include the "Rationale for DO-178C/DO-278A" section to document items that were considered when developing DO-178B and then DO-178C, DO-278A, and DO-330, as well as the supplements that accompany those publications.

CAST-32A, Multi-core Processors is a position paper, by the Certification Authorities Software Team (CAST). It is not official guidance, but is considered informational by certification authorities such as the FAA and EASA. A key point is that Multi-core processor "interference can affect execution timing behavior, including worst case execution time (WCET)."

The Advisory Circular AC 00-69, Best Practices for Airborne Software Development Assurance Using EUROCAE ED-12( ) and RTCA DO-178( ), initially issued in 2017, supports application of the active revisions of ED-12C/DO-178C and AC 20-115. The AC does not state FAA guidance, but rather provides information in the form of "best practices" complementary to the objectives of ED-12C/DO-178C.

<span class="mw-page-title-main">CAST-31</span> Certified Authorities Software Team position paper

CAST-31, Technical Clarifications Identified for RTCA DO-254 / EUROCAE ED-80 is a Certification Authorities Software Team (CAST) Position Paper. It is an FAA publication that "does not constitute official policy or guidance from any of the authorities", but is provided for educational and informational purposes only for applicants for software and hardware certification.

The Certification Authorities Software Team (CAST) is an international group of aviation certification and regulatory authority representatives. The organization of has been a means of coordination among representatives from certification authorities in North and South America, Europe, and Asia, in particular, the FAA and EASA. The focus of the organization has been harmonization of Certification Authorities activities in part though clarification and improvement of the guidance provided by DO-178 and DO-254.

References

  1. ↑ David L. Lempia and Steven P. Miller (2009). DOT/FAA/AR-08/32 Requirements Engineering Management Handbook (PDF). Federal Aviation Administration . Retrieved 2022-07-09. DO-178B [27] specifies that the software requirements should be organized into high-level and low-level software requirements. Also, the high-level software requirements should comply with the system requirements (objective 1 of table A-3 in appendix A), and the low-level software requirements should comply with the high-level software requirements (objective 1 of table A-4 in appendix A). These are defined in DO-178B as
    High-level requirements: Software requirements developed from analysis of system requirements, safety-related requirements, and system architecture.
    Low-level requirements: Software requirements derived from high-level requirements, derived requirements, and design constraints from which source code can be directly implemented without further information.
  2. ↑ Johnny Cardoso Marques, Sarasuaty Megume Hayashi Yelisetty, Luiz Alberto Vieira Dias, Adilson Marques da Cunha (2012). "Using Model-Based Development as Software Low-Level Requirements to Achieve Airborne Software Certification". Conference: Information Technology: New Generations (ITNG). Retrieved 2022-07-09. The DO-178B defines two levels of software requirements. The SW-HLR usually represents "what" is to be designed and SW-LLR represents "how" to carryout the design. .... This formalized design should contain sufficient details of such aspects as code structures and data/control flow for source code to be produced directly from it, either manually or by the use of a tool, without any further information.{{cite journal}}: CS1 maint: multiple names: authors list (link)
  3. ↑ Vance Hilderman and Tony Baghai (2007). Avionics Certification, A Complete Guide to DO-178 (Software) DO-254 (Hardware). Leesburg, VA: Avionics Communications, Inc. ISBN   978-1-885544-25-4. DO-178B is unique among software "standards" in that it requires two or more levels of requirements.
  4. ↑ Leanna Rierson (19 December 2017) [7 January 2013]. Developing Safety-Critical Software: A Practical Guide for Aviation Software and DO-178C Compliance. CRC Press. p. 114. ISBN   9781351834056 . Retrieved 2022-02-14. ... Certification Authorities Software Team (CAST)* paper CAST-15 ... warn against merging software requirements into a single level. There are a few projects where one level of software requirements is needed (...) but they are in the minority.
  5. 1 2 3 Daniels, Dewi (January 1, 2001). "Are we there yet? A practitioners View of DO-178C/ED-12C". In Chris Dale, Tom Anderson (ed.). Advances in Systems Safety: Proceedings of the Nineteenth Safety-Critical Systems Symposium, Southampton, UK, 8-10th February 2011. Springer Publishing. p. 299. ISBN   978-0-85729-132-5. Another related issue is that DO-178B allowed for the possibility of a single level of requirements, in which case the high-level requirements are also considered low-level requirements. The intent was to avoid forcing the creation of two levels of requirements even for trivially simple software applications. Applicants sometimes misuse this paragraph to justify producing a single level of requirements for complex software applications. This may result in a development process that does not comply with DO-178B. This was the topic of Certification Authorities Software Team (CAST) positions paper CAST-15 …. A note was added to section 5 that the applicant may be required to justify software development processes that produce a single level of requirements. A full discussion of this topic may be found in CAST-15. [emphasis added]
  6. ↑ Rierson, p. 113, "In order to avoid this slippery slope, I suggest that engineers ... Clearly define the division between requirements (what) and design (how) .... "
  7. 1 2 Volponi, Allan J.; Rajamani, Ravi (2012). "12. Hybrid Models for Engine Health Management". In Ashok N. Srivastava, Jiawei Han (ed.). Machine Learning and Knowledge Discovery for Engineering Systems Health Management. Data Mining and Knowledge Discovery Series. Chapman & Hall/CRC Press. p. 299. ISBN   978-1-4398-4179-2. ... For the most part, software system requirements can be traced back to ... system requirements. Software requirements can be further broken down into high level requirements and detailed (low-level) requirements. High level requirements describe functional aspects of the system; i.e., they describe "what" is being designed. Low level requirements describe the actual design of the software; i.e., "how" the software is designed. Traceability ensures that all the requirements have been implemented as software functions (forward traceability) and, conversely, that all implemented functions are linked to a requirement (backward traceability). For an interesting discussion on this topic the reader may look at a short position paper issued by the Federal Aviation Administration [8] ... [8] FAA Certification Authorities Software Team (CAST), Merging High-Level and Low-Level Requirements, Position Paper, CAST-15, February 2003 [emphasis added]
  8. ↑ Jamie P. White, Hassan Reza (2012). "Deriving DO-178C Requirements Within the Appropriate Level of Hierarchy". ICSEA 2012 : The Seventh International Conference on Software Engineering Advances. p. 432. ISBN   978-1-61208-230-1 . Retrieved 2022-02-08. In addition, the CAST-15 position paper provides guidance that for software requirements a high-level requirements document should describe the "what" and a low-level requirements document should describe the "how". [emphasis added]
  9. ↑ Raymond G. Estrada, Eric Dillaber, Gen Sasaki (2013). "Best practices for developing DO-178 compliant software using Model-Based Design". AIAA Guidance, Navigation, and Control (GNC) Conference (PDF). Retrieved 2022-02-08. According to Position Paper CAST-15 (Certification Authorities Software Team) [15], the HLR generally represent "what" is to be designed and LLR represent "how" to carry out the design. [emphasis added]{{cite book}}: CS1 maint: multiple names: authors list (link)
  10. ↑ Jamie P. White, Hassan Reza, p. 432. "The end goal is to place requirements in the requirements document that provides the most visibility to the stakeholders while preserving the scope of the document. Hence, there is a fine line between putting too much information in a high-level requirements document and providing an appropriate amount of visibility to stakeholders."
  11. ↑ Raymond G. Estrada, Eric Dillaber, Gen Sasaki, "... [15]. This is because of the different purposes of each level of requirements; HLR state what the system software is to do, while the LLR state how it is done and what components are used to do it. Verification must be performed on the data for both HLR and LLR separately, and merging the two may make this impossible. Note that although Section 5 of DO-178C allows a single level of requirements, it is typically not done because it requires the system level requirements to contain additional detail to allow traceability to the combined HLR/LLR data item."
  12. ↑ Rierson, p. 113, "DO-248C's FAQ #81 ... and the ... CAST-15"
  13. ↑ Frédéric Pothon, ACG Solutions, "DO-178C/ED-12C versus DO-178B/ED-12B - Changes and Improvements", 2012. "The main concern is possible gaps in the requirement refinement, which prevent a sufficient traceability analysis and thus compliance with verification objectives."
  14. ↑ "DO-178B/C Differences Tool" Revision: 008, page 12, etc., 2013. "If the developer is proposing merging of high level and low level requirements, the ASE will find the justification and determine whether the reasoning supports a smooth transition between abstraction layers of system and the single level of requirements. Some indications where this may not be appropriate would be single system requirements tracing to an inordinately large number of merged high/low level requirements."
  15. ↑ "Software Aspects of Certification" (PDF). Certification Memorandum. EASA (CM-SWCEH-002 Issue 1): 12. 9 March 2012. Retrieved 2023-04-19. The following sections of the guidance of this Certification Memorandum do not correspond to the contents of FAA Order 8110.49, but they do correspond to the contents of existing CAST Papers ... Section 21, Merging High-Level and Low-Level Requirements (CAST 15)
  16. ↑ RTCA/DO-248C "Supporting Information for DO-178C and DO-278A", FAQ #81, pages 43-44. "When airborne software components are large or complex, the software requirements process produces the HLRs and the software design process produces the LLRs and architecture. Thus, HLRs and LLRs are not the outputs of the same development processes."
  17. 1 2 RTCA/DO-178C "Software Considerations in Airborne Systems and Equipment Certification", p. 31. "Low-level requirements are software requirements from which Source Code can be directly implemented without further information." ... "However, if Source Code is generated directly from high-level requirements, then the high-level requirements are also considered low-level requirements and the guidance for low-level requirements also apply."
  18. ↑ Raymond G. Estrada, Eric Dillaber, Gen Sasaki, "Merging the HLR and LLR into a single model or data item is not recommended [15]."
  19. ↑ RTCA/DO-248C "Supporting Information for DO-178C and DO-278A", FAQ #81, pages 43-44. "There may be some systems where the system level requirements are refined into software requirements suitable for coding in one refinement step. In this case, a single level of software requirements may be feasible; however, ...."
  20. ↑ Alec Banks and Rob Ashmore (2019). "Requirements Assurance in Machine Learning" (PDF). CEUR Workshop Proceedings. CEUR Workshop (CEUR-WS.org). 2301 (paper 8). Retrieved 2022-07-09. [citing CAST-15] In safety-related applications these principles usually drive the software requirement decomposition to two distinct levels. High-Level Requirements (HLR) detail 'what is required' in the design. These are then systematically decomposed into Low-Level Requirements (LLR), which provide coders with information on 'how to implement' that design. To minimize ambiguity LLR often include pseudo-code or mathematical formulae. ... Certification Authorities Software Team (CAST). 2003. Merging High-Level and Low-Level Requirements. Position Paper CAST-15, completed February 2003.
  21. ↑ Markus Tobias Hochstrasser (2020). Modular model-based development of safety-critical flight control software (PDF). Universitätsbibliothek der TU München. Retrieved 2022-07-09. Example 4 is reasoned with the higher abstraction of Design Models compared to LLRs. For example, traditional HLRs often contain figures of state diagrams or truth tables. These diagrams are very close to the implementation in SF. In such cases, separate HLRs are just an artificially introduced level leading to "copy-and-paste development". Important to mention is that this workflow does not merge HLRs and LLRs, since the system requirements take over the role of HLRs including all necessary activities and objectives (cf. DO-331 MB.5.0). The concerns of Position Paper CAST-15 "Merging High-Level and Low-Level Requirements" [87] are not applicable.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.