• Save
The Impact of RTCA DO-178C on Software Development
 

Like this? Share it with your network

Share

The Impact of RTCA DO-178C on Software Development

on

  • 2,384 views

By following DO-178C, organizations can implement aeronautical software that ties into existing systems and safety processes and address emerging trends and technologies across the industry.

By following DO-178C, organizations can implement aeronautical software that ties into existing systems and safety processes and address emerging trends and technologies across the industry.

Statistics

Views

Total Views
2,384
Views on SlideShare
2,196
Embed Views
188

Actions

Likes
0
Downloads
0
Comments
0

1 Embed 188

https://twitter.com 188

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

The Impact of RTCA DO-178C on Software Development Document Transcript

  • 1. • Cognizant 20-20 InsightsThe Impact of RTCA DO-178C onSoftware DevelopmentBy following DO-178C, organizations can implement aeronautical softwarewith clear and consistent ties to existing systems and safety processesand address emerging trends and technologies across the industry. Executive Summary The new guidance represents a significant change in the Federal Aviation Association’s A new guideline has emerged to help regulate the posture toward regulated software development. development and certification of software and The DO-178C guidelines tighten some previously the delivery of multiple supporting documents established controls, while also establishing and records used on aircraft or engines. The concrete guidance for greater flexibility in devel- previous guideline — called RTCA DO-178B, opment approaches. This flexibility, however, must Software Considerations in Airborne Systems be carefully examined in terms of the potential and Equipment Certification, and produced by costs and benefits, to establish the most efficient the Radio Technical Commission for Aeronautics certifiable product development approach. Inc. — served as a de facto standard for avionics equipment and software development worldwide. This white paper discusses these shifts from a technical perspective and provides management With the release of RTCA DO-178C — the new visibility into the emerging challenges and oppor- development guidance for certifiable aviation tunities associated with the updated guidance. software — executives and product managers for Lastly, this paper also examines the relationship manufacturers of airborne systems are examining between DO-178C and the supplements: DO-330 the short- and long-term impacts on the cost, (tool qualification), DO-331 (model-based develop- scheduling and risk of their certifiable product ment and verification), DO-332 (object-oriented development approaches. Although the changes technology and related techniques) and DO-333 within DO-178C proper are relatively few, manu- (formal methods). facturers can expect critical wide-ranging impli- cations. More significant are the four detailed RTCA Guideline Progression supplements intended to address 20 years of progress in technology and process since the last RTCA DO-178A was last revised in 1992, which major revisions of the development guidelines. begot DO-178B. DO-178C is the latest revision to the DO-178B guidelines released in January 2012, cognizant 20-20 insights | october 2012
  • 2. which describe objectives for software lifecycle the glossary and changing the text according-processes, activities and design considerations ly so that the use of those specific terms wasfor achieving the objectives and proving that the consistent throughout the document.objectives have been satisfied. • Wording improvements: DO-178C hasThe majority of DO-178B is dedicated to describing improved wording throughout the document,the sequential development methodology for new, with the objective of making the documentcustom-built avionics software. This approach is more precise, while maintaining the originala requirements-based development and verifica- intent of DO-178B.tion methodology that includes a number of alter- • Objectives and activities: DO-178C reinforcednative methods for satisfying these objectives. the point that, in order to fully understandDO-178B is not a strict or detailed standard; it is the recommendations, the full body of thea general software development framework for document should be considered. For example,developing provable, high-reliability software, Annex A now includes references to eachconsistently. Developers of avionics equipment activity, as well as to each objective. Moreover,and software must comply with the guidance Section 1.4, now titled “How to Use Thisprovided by DO-178B. Document,” reinforces the point that activities are a major part of the overall guidance.Comparing DO-178B and DO-178CThe new guidelines include both minor and sig- • Coordinated system/software aspects: Section 2 of DO-178B was updated withnificant changes, all of which will significantly software development principles to reflectimpact the way certifiable software development current system practices. The updates wereis managed. made based upon coordination with other avionics standards organizations that wereMinor Changes updating their system-level guidance at theThe minor changes include the removal of known same time that SC-205/WG-71 (EUROCAE)errors and inconsistencies, as well as the addition was updating the DO-178B’s software-levelof consistent terminology throughout the guidance.document. Wording improvements can be seenthroughout the guidelines, as well. • DO-178B hidden objectives: DO-178C has added so-called “hidden objectives” to AnnexCoordinated systems/software aspects are A, including:evident in the document, providing additionalrationale for the overall software development >> A means for detecting the object code that is not directly traceable to the source codeobjectives and their justifications. and to ensure its verification coverage is defined (Table A-1 #4).• Errors and inconsistencies: DO-178C has addressed the errata of DO-178B and has >> Assurance that software plans and stan- removed the inconsistencies among the tables dards are developed and reviewed for con- of DO-178B Annex A. To remove an inconsis- sistency (Table A-9#1). tency regarding software standards for Level D software, DO-178B objective A-9#1, plans >> An explicit objective to ensure that object code is directly traceable to source code and standards were split into two DO-178C “Source to Object Traceability” (Table objectives, specifically: A-7#9). >> Assurance is obtained that software devel- • DO-178B topic omissions: DO-178C has opment and integral processes comply with addressed a few general topics that resulted in approved software plans (Table A-9#2). changes to several sections of the document, >> Assurance is obtained that software devel- such as oversight of suppliers, parameter data opment and integral processes comply with items and traceability. In addressing these approved software standards (Table A-9#3). topics, two additional objectives were added to Annex A:• Consistent terminology: DO-178C has addressed DO-178B’s issues with the use >> Parameter Data Item File (PDIF) to be load- of specific terms, such as “guidance,” ed complies with low-level requirements “guidelines,” “purpose,” “goal,” “objective” and (Table A-6#6). “activity.” This was accomplished by expanding cognizant 20-20 insights 2
  • 3. >> Verification coverage of PDIF elements (Ta- current software development methodolo- ble A-7#9). gies (and being revised yet again to account for future software development methodolo- >> Added trace data, as required. gies), DO-178C acknowledges that one or more >> Lifecycle Data to be provided and verified technology supplements may be used in con- (Section 11.21). junction with DO-178C to modify the guidance• DO-178B gaps and clarifications: DO-178C for specific technologies or methodologies. addressed several specific issues that resulted Section 12’s addressing of tool qualification in changes to only one or two paragraphs. and alternative methods was heavily impacted, Each such change may have an impact on since planned technology supplements more the applicant, as they either addressed clear completely address such technologies. The gaps in DO-178B or clarified guidance that was technology supplements include the following: subject to differing interpretations. >> Model Based Development and VerificationExamples of gaps addressed include: Supplement to DO-178C and DO-278A (DO- 331.)• Changes to the “Modified Condition/Decision Coverage” definition. Masking MC/DC and >> Object-OrientedTechnology and Related Short Circuit, as well as DO-178B’s Unique Techniques Supplement to DO-178C and Cause MC/DC, are now allowed (Glossary). DO-278A (DO-332).• An addition to Level A, stating that “if a >> Formal Methods Supplement to DO-178C complier, linker or other means generates and DO-278A (DO-333). additional code that is not directly traceable >> Software Tool Qualification Considerations to source code statements, then additional (DO-330). verification should be performed to establish the correctness of such generated code These new supplements provide guidance and sequences” (6.4.4.2.b). objectives for both DO-178C and DO-278A. Rather than expanding the text in the body of• The need for derived requirements to be DO-178B, each supplement describes how the provided to the system processes, including the objectives of DO-178C are revised for specific system safety assessment process (rather than techniques, including: just provided to the system safety assessment process) (5.1.1b, 5.2.1b). >> Technology-specific interpretation.Examples of clarifications include: >> Modification of objectives.• The structural coverage analysis of data and >> Additional objectives. control coupling between code components Each supplement provides technology-specific should be achieved by assessing the require- supporting information to provide clarification ments-based tests (6.4.4.2.c). on the use of technology. Each supplement• All tests added to achieve structural coverage defines the scope of the supplement and the are based on requirements (6.4.4.2.d). objectives it contains.• All the code that may be classified as deacti- Objectives tables in the supplements follow vated code (6.4.4.3.d). the same structure as the objectives table in DO-178C, namely:Significant ChangesThe significant changes include the addition >> References to objective definitions.of technology supplements to keep the core of >> References to activity definitions.DO-178B intact for the future. New tool qualifica- >> Identification of the applicability by DAL.tion guidance helps ensure separation of airbornesoftware from tools that may not be airborne. >> Identification of the output, documenting compliance.• Technology supplements: DO-178C recognizes >> Reference to the output definition. that new software development methodolo- gies may result in new issues. Rather than >> Identification of the output configuration control category. expanding the text to account for all the cognizant 20-20 insights 3
  • 4. • Model-Based Development and Verifica- and integrity goals are met. These issues are tion Supplement to DO-178C and DO-278A: both directly related to language features and This supplement contains modifications and to complications encountered with meeting additions to DO-178C and DO-278A objectives, well-established safety objectives. activities, explanatory text and software lifecycle data that should be addressed when • Formal Methods Supplement to DO-178C and DO-278A: This supplement identifies model-based development and verification the additions, modifications and substitutions are used as part of the software lifecycle. to DO-178C and DO-278A objectives when This includes the artifacts that would be formal methods are used as part of a software expressed using models, as well as the veri- lifecycle and the additional guidance required. fication evidence that could be derived from It discusses those aspects of air-worthiness them. Therefore, this supplement also applies certification that pertain to the production of to the models developed in the system process software, using formal methods for systems that define software requirements or software approved using DO-178C. architecture. Formal methods are mathematically-based A model is an abstract representation of a set techniques for the specification, develop- of software aspects of a system that is used ment and verification of software aspects to support the software development process of digital systems. The mathematical basis or the software verification process. This of formal methods consists of formal logic, supplement addresses model(s) that have the discrete mathematics and computer-read- following characteristics: able languages. The use of formal methods is >> The model is completely described using an motivated by the expectation that, as in other explicitly identified modeling notation. The engineering disciplines, performing appropri- modeling notation may be graphical and/or ate mathematical analyses can contribute to textual. establishing the correctness and robustness of a design. >> The model contains software requirements and/or software architecture definition. • Software Tool Qualification Considerations (DO-178B Section 12.2): The terms “develop- >> The model is of a form and type that is used ment tool” and “verification tool” are replaced for direct analysis or behavioral evaluation by three qualification criteria that determine as supported by the software development the applicable tool qualification level (TQL) in process or the software verification pro- regard to the software level. The guidance to cess. qualify a tool is removed in DO-178C, but it is• Object-Oriented Technology and Related provided in a domain-independent, external Techniques Supplement to DO-178C and document referenced in Section 12.2. DO-278A: This supplement identifies the The tool criteria are as follows: additions, modifications and deletions to DO-178C and DO-278A objectives when object- >> Criteria #1: A tool whose output is part of the airborne software and thus could insert oriented technology or related techniques an error. are used as part of the software development lifecycle and additional guidance is required. >> Criteria #2: A tool that automates verifica- This supplement, in conjunction with DO-178C, tion processes and thus could fail to detect is intended to provide a common framework an error and whose output is used to justify for the evaluation and acceptance of object- the elimination or reduction of: oriented technology and related techniques- based systems. »» Verification processes other than auto- mated by the tool. Object-oriented technology has been widely adopted in non-critical software develop- »» Development processes that could have an impact on the airborne software. ment projects. The use of this technology for critical software applications in avionics has >> Criteria #3: A tool that, within the scope increased, but there are a number of issues of its intended use, could fail to detect an that need to be considered to ensure safety error. cognizant 20-20 insights 4
  • 5. The tool qualification criteria and qualification levels are shown in Figure 1. Design Assurance Level Criteria (DAL) Criteria 1 Criteria 2 Criteria 3 Level A TQL-1 TQL-4 TQL-5 Level B TQL-2 TQL-4 TQL-5 Level C TQL-3 TQL-5 TQL-5 Level D TQL-4 TQL-5 TQL-5Figure 1The objectives of DO-178B and DO-178C are summarized in Figure 2. Design Assurance Level(DAL) DO-178B DO-178C Level A 66 Objectives 71 Objectives Level B 65 Objectives 69 Objectives Level C 57 Objectives 62 Objectives Level D 28 Objectives 26 Objectives Level E No Objectives No ObjectivesFigure 2• New Lifecycle Data: There are now requests >> Test cases to test procedures for new data items to be made available, as >> Test procedures to test results well expansion of content for some existing data items. For example, the PSAC must ad- Conclusion dress the supplier oversight and describe the DO-178C has decreased the level of subjectivity means of ensuring that supplier processes and for many activities in the software development outputs will comply with approved software lifecycle objectives. Yet even today, the definition plans and standards. of the processes and plans for execution of the >> Section 11 adds two new lifecycle data items. process are key to successful compliance. »» PDIF (Section 11.22): To support new ob- Without question, the new DO-178C guidance jectives, and it has the control category 1 adopted by the avionics industry will impact for all DAL’s. established certifiable software development »» Trace Data (Section 11.21): Implied for processes. Manufacturers will need to modify DO-178B, it is now clarified that it has to their existing practices to accommodate the be bi-directional and control category on revised guidance. Although the benefits from the DAL. adoption of new technologies and tools will be significant, expectations — especially in the short• Trace Data: DO-178C has made an explicit data term — must be tempered by a clear vision of the item related to traceability. It also required bi- challenges associated with migration and early directional traceability. Trace data has to dem- adoption. onstrate associations between: >> Systems to high-level requirements Manufacturers must carefully consider both short- and long-term costs and benefits. A comprehen- »» High-level to low-level requirements, de- sive and detailed gap analysis — together with a pendent on level well-considered certifiable development process »» Low-level requirements to source code, roadmap — will be necessary for a certifiable dependent on level product manufacturer to prepare for an effective >> Requirements to test cases treatment of the revised guidance. Avoiding costly rework, while effectively leveraging new »» High-level and/or low-level, dependent technologies, is the key to remaining competitive. on level The time to plan is now; the costs of delay can be dramatic. cognizant 20-20 insights 5
  • 6. References• RTCA DO-178B – Software Considerations in Airborne Systems and Equipment Certification• RTCA DO-178C – Software Considerations in Airborne Systems and Equipment Certification• DO-330 – Software Tool Qualification Considerations• DO-331 – Model Based Development and Verification Supplement to DO-178C and DO-278A• DO-332 – Object-Oriented Technology and Related Techniques Supplement to DO-178C and DO-278A• DO-333 – Formal Methods Supplement to DO-178C and DO-278AAbout the AuthorMaddireddy Sudheer Reddy is a Senior Manager of System Engineering within Cognizant’s Engineer-ing Manufacturing Solutions Business Unit. He has more than 13 years of well-rounded engineeringand management experience in safety critical software development within the avionics and railwaydomains. Sudheer has led and executed multiple projects/programs, with responsibilities focused onmeeting program requirements, managing customer expectations and developing long-term relation-ships built on trust. His areas of expertise include systems engineering, software engineering andprogram management. Sudheer holds a master’s degree in software systems and computer science, aswell as an engineering degree. He can be reached at Sudheer.Maddireddy@cognizant.com.About CognizantCognizant (NASDAQ: CTSH) is a leading provider of information technology, consulting, and business process out-sourcing services, dedicated to helping the world’s leading companies build stronger businesses. Headquartered inTeaneck, New Jersey (U.S.), Cognizant combines a passion for client satisfaction, technology innovation, deep industryand business process expertise, and a global, collaborative workforce that embodies the future of work. With over 50delivery centers worldwide and approximately 145,200 employees as of June 30, 2012, Cognizant is a member of theNASDAQ-100, the S&P 500, the Forbes Global 2000, and the Fortune 500 and is ranked among the top performingand fastest growing companies in the world. Visit us online at www.cognizant.com or follow us on Twitter: Cognizant. World Headquarters European Headquarters India Operations Headquarters 500 Frank W. Burr Blvd. 1 Kingdom Street #5/535, Old Mahabalipuram Road Teaneck, NJ 07666 USA Paddington Central Okkiyam Pettai, Thoraipakkam Phone: +1 201 801 0233 London W2 6BD Chennai, 600 096 India Fax: +1 201 801 0243 Phone: +44 (0) 20 7297 7600 Phone: +91 (0) 44 4209 6000 Toll Free: +1 888 937 3277 Fax: +44 (0) 20 7121 0102 Fax: +91 (0) 44 4209 6060 Email: inquiry@cognizant.com Email: infouk@cognizant.com Email: inquiryindia@cognizant.com©­­ Copyright 2012, Cognizant. All rights reserved. No part of this document may be reproduced, stored in a retrieval system, transmitted in any form or by anymeans, electronic, mechanical, photocopying, recording, or otherwise, without the express written permission from Cognizant. The information contained herein issubject to change without notice. All other trademarks mentioned herein are the property of their respective owners.