Certification Authorities Software Team (CAST) Position Paper CAST-9

Size: px
Start display at page:

Download "Certification Authorities Software Team (CAST) Position Paper CAST-9"

Transcription

1 Certification Authorities Software Team (CAST) Position Paper CAST-9 Considerations for Evaluating Safety Engineering Approaches to Software Assurance Completed January, 2002 NOTE: This position paper has been coordinated among the software specialists of certification authorities from the United States, Europe, and Canada. However, it does not constitute official policy or guidance from any of the authorities. This document is provided for educational and informational purposes only and should be discussed with the appropriate certification authority

2 Considerations for Evaluating Safety Engineering Approaches to Software Assurance 1. Introduction. Safety engineering approaches for software assurance (SEASA) can be applied to software with the purpose of satisfying the requirements that are mandated by aviation regulations for equipment and systems installed on aircraft. However, policy to guide certification authority engineers in their assessment of SEASA proposals as a means of compliance for the software has been limited to issue papers applied to specific projects. The purpose of this position paper is to propose guidelines for certification authorities to consider when evaluating the acceptability of SEASA and for industry organizations considering such an approach as a method for providing safety, system and software compliance assurance. It should be noted that safety engineering approaches in general are not a replacement in total for the guidelines of DO-178B/ED-12B (reference a.). Rather, safety engineering approaches can be used in conjunction with DO-178B, supplementing and/or replacing some criteria of DO-178B for some software components, using all criteria of DO-178B for some other software components, and perhaps validating software assurance criteria for yet other components. The following sections of this paper will discuss some safety engineering approaches. It also indicates which assurance objectives are always common between SEASA and DO-178B, and which DO-178B objectives can potentially be supplemented, reduced or replaced by using a SEASA. Note: Safety engineering approaches are variously called safety directed development (SDD), systems safety engineering techniques (SSET), and safety engineering techniques for software (SETS). For this paper, all will be referred to by the acronym SEASA safety engineering approaches for software assurance. 2. Reference Documents. a. RTCA, Inc. document DO-178B and EUROCAE document ED-12B, Software Considerations in Airborne Systems and Equipment Certification, dated December 1, b. FAA Advisory Circular (AC) B, RTCA, Inc., Document RTCA/DO- 178B, dated January 11, c. FAA AC C, Equipment, Systems, and Installations in Part 23 Airplanes, dated March 12, d. FAA AC A, System Design and Analysis, dated June 21,

3 e. JAA Advisory Material-Joint (AMJ) , System Design and Analysis, dated May 11, f. JAA Temporary Guidance Leaflet (TGL) #4, Software Guidance, dated 1 October 1996 g. Society of Automotive Engineers (SAE) Aerospace Recommended Practice (ARP) 4754 and EUROCAE document ED-79, Certification Considerations for Highly-Integrated or Complex Aircraft Systems, dated November h. SAE ARP 4761, Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment, dated December i. RTCA, Inc. document DO-254 and EUROCAE document ED-80, Design Assurance Guidance for Airborne Electronic Hardware, dated 19 April j. RTCA, Inc. document DO-248B and EUROCAE document ED-94B, Final Report for Clarification of DO-178B(/ED-12B) Software Considerations In Airborne Systems and Equipment Certification, 2001 k. CAST Position Paper CAST-5, Alternate Means l. Capability Maturity Model for Software, Version 1.1, dated February, m. IEEE/EIA 12207, Software Life Cycle Processes, dated March, Background. Reference a. is recognized by the certification authorities directly by references b. and f., and indirectly by references c. through e. as providing an acceptable means of compliance for the software aspects of certification to aviation regulations when software is installed as part of an airborne system. Software aspects are usually associated primarily with FAR and JAR XX.1301, XX.1309 (XX = 23, 25, etc.) and (engine control systems). In fact, FAR is the only regulation that specifically uses the term software. Reference a. provides guidance for a structured, rigorous development and verification process. This rigor is based on the failure condition classification of the system functions in which the software is used. A software level is assigned, based on the worst-case failure condition category to which anomalous behavior of the software could cause or contribute. It provides software process assurance objectives and criteria for software planning, development, verification, configuration management, quality assurance and certification liaison. Verification in reference a. consists of reviews, analyses and testing conducted throughout the development process. Reviews and analyses are performed on the software data throughout the development to ensure that errors and deficiencies are not propagated from one development process to a subsequent process. Testing consists of requirements-based testing for normal range and abnormal range (robustness) at the software module level, integrated software module level and integrated hardware and software level, combined with requirements-based test coverage analysis and code 3

4 structural coverage analysis. The reference a. software verification objectives and criteria were developed to ensure that the software functions as specified and to reduce the likelihood that the software will contain errors or exhibit anomalous behavior that could effect safety. The amount of structure and rigor of the software verification process is dependent on the software level as specified in reference a. for software levels A through E. The software level for a specific software application is based upon a system safety assessment process, such as that described in reference h. This determines the worst-case failure conditions of the system that could result from software anomalous behaviors caused by errors. Reference g. also provides guidance for types of safety and system engineering analyses, methods and techniques that could be performed to ensure the safety of the system, satisfy the fail safe design techniques of references c. through e., and comply with the regulations. Because of the complex nature of many software applications, there are inherent difficulties in implementing and showing independence between those software components that could contribute to a failure condition affecting safety and those that could not. This is particularly the case when the software application is large, and if the code is not structured primarily for the compartmentalization of safety related elements. It may also be inherently difficult in such applications to identify a strict correspondence (traceability) between system safety requirements and the discrete components of the software application. With increasing size and complexity, safety analysis of the software becomes increasingly problematic for applications that are mainly constructed around performance and functional requirements rather than safety requirements. Therefore, aircraft certification programs have traditionally relied on software process assurance combined with a specified level of software verification to reduce the potential errors and anomalous behavior of the software. This approach has been accepted as the practical minimum requirement for showing compliance of the software components of a system, without directly addressing those safety elements inherently difficult to address in software. Industry and regulatory authorities have jointly formalized specific criteria for implementing this approach in reference a. Note: The reader should recognize that software process assurance and verification is only one aspect, and perhaps a small part, of the overall development, verification and validation of the system and of the system installed on the aircraft. Other significant activities include: system safety assessment, system design, hardware design, hardware environmental qualification testing, system validation and verification, aircraft architecture design, laboratory bench testing, aircraft installation testing, simulation, aircraft ground testing, and aircraft flight testing. The process assurance and verification criteria of reference a. do not provide safety assurance in and of themselves. They provide assurance that the software application adheres to the software requirements, including safety-related, functional, performance, etc. requirements. They also provide a relative measure of how much the code and its 4

5 structure have been exercised, considering the assigned software level of the application. However, software requirements may or may not be focused on safety or system failure conditions that can lead to aircraft hazards, and code can be exercised with no knowledge of the system failure conditions and aircraft hazards. Rather, aircraft hazard and system failure elimination, minimization, and control have typically been addressed at the aircraft level and the system level, respectively. Thus, error reduction of the software through process assurance and verification must be combined with analysis and validation at the aircraft and system levels and recognized as minimum requirements for showing that the safety objectives for the system (and the aircraft) have been met. While this approach is recognized as good practice, it is an indirect approach to the safety aspects of the software. Other software standards and guidance have proposed qualification of software developers process or organization as ensuring that the process or organization will produce high quality products. Examples of these are the Carnegie Mellon University (CMU) Software Engineering Institute s (SEI) Capability Maturity Model (CMM), the International Standards Organization s (ISO) 9001, part 3; and Institute of Electrical and Electronics Engineers (IEEE), Inc. s various software standards and guidance material (e.g., IEEE/EIA 12207). While all of these standards and guidance materials have merit and are useful for many applications, reference a. has become the de facto standard guidance for process assurance of airborne systems and equipment using digital computers and software intended for application on commercial aircraft. Some applicants have asserted that they prefer a more direct approach of tracing potential aircraft hazards and system failures to discrete software components, and then eliminating, minimizing, or controlling specific hazards and failure conditions to which the software could contribute, or providing protective mechanisms around susceptible software components, and thus directly assuring the safety of the software. Applicants have proposed that the development of a software safety program integrated with the system safety program offers a direct assurance of total system safety. Such an integrated safety program would use analysis techniques derived from system safety assessment methods, combined with complete safety related software requirements, and use safety-focused software design, coding, and verification. Applicants have also proposed that this approach of using an integrated software and system safety program may justifiably allow some relief from the criteria of reference a., the structural coverage criteria and, in some cases, perhaps a lowering or reduction of other assurance criteria or software levels from current reference a. criteria. When evaluating an applicant s or software developer s proposal for a safety program for software or other alternative methods, other industry standards and certainly other best engineering practices could be considered as criteria for determining the acceptability of the proposal. However, for practical purposes, such as certification authority s familiarity 5

6 with reference a.; and to expedite the certification process and to provide standardized and harmonized criteria and thus a level playing field for applicants, reference a. is most often used as the benchmark for determining the acceptability of alternative proposals for software assurance. See also reference k., the CAST paper on Alternate Means. Reference g. recognizes the use of a Safety Directed Development Concept as an alternative to the system development assurance methods of that document, without further specifying what a safety directed development concept is, what its criteria are, or why it is an acceptable alternative. Recently published hardware development assurance guidance (reference i.) also recognizes a Safety-Specific Analysis as an advanced verification method, which can be used in combination with a functional failure path analysis (FFPA), for providing electronic hardware design assurance for Levels A and B hardware functions in addition to the normative process and hardware data guidance of the document. According to reference i., safety-specific analysis focuses on exposing and correcting the design errors that could adversely affect the hardware outputs from a system safety perspective. Appendix B of reference i. provides some clarification of this method and mentions some hardware process and data needed to use this analysis method, in addition to the normative hardware process and data guidelines provided in reference i., sections 2 through 11 and Appendix A. In the past, a specific safety approach of an airborne system developer was accepted for showing software compliance on certain systems installed during the course of specific aircraft system certification programs. The original approach was approved as a supplement to DO-178[ ], not as an alternate. However, these specific criteria have been confined to issue papers applicable only to these specific systems on specific programs and reviewed on a project-by-project basis. Credit granted by the certification authority allowed some reduction in the software structural coverage analysis criteria for some systems. Some applicants and developers would like to see their proposed alternative safety approach accepted on a general basis, usable at their discretion and pre-approved for use on any of their projects and products. This has not yet been allowed by the certification authorities, except on a case-by-case basis. 6

7 4. Discussion. The application of a safety engineering approach for software assurance (SEASA) is intended to directly address system failure conditions and aircraft hazards related to the system s software. In its essentials, SEASA is the practice of applying common systems safety assessment, analysis and design techniques to software. It is a practice of continuing the system safety assessment into the software components, and assuring that the software meets the regulations (i.e., , , , , 33.28(e)). Some commonly used system safety assessment and analysis methods are documented in references g. and h. Fail-safe design techniques are documented in references c. through e. There is much commonality and consistency between these references for methods and techniques. Safety design techniques propose to identify all safety requirements for the aircraft, the system and its components, including hardware and software. SEASA proposes to identify all safety requirements for the software and all safety effects of the software. Then, by a method of iterative analysis and design, combined with safety-focused verification, SEASA proposes to show that those unacceptable hazards, failure conditions and anomalous behavior are prevented, mitigated or isolated and controlled, using various architectural constraints, monitors and design techniques (e.g., multiple, independent, dissimilar components performing the same function). Aircraft hazards and system failure conditions are traced through analysis to the software. Software requirements ( safety objectives and safety-related requirements in the reference a. vernacular) addressing the hazards and failure conditions are specified and verified for safety related completeness criteria. Code is analyzed, with hazards and failure conditions traced to the code itself. Code is designed for risk reduction, including the prevention, mitigation, isolation and/or control of specific failure conditions. Verification is focused on the safety related code, critical code. Like any other software development process, this SEASA process is iterative in nature with attendant feedback and refinement. It should be noted that the specific SEASA evaluated to-date is not a complete alternative for the criteria of reference a. In fact, the majority of reference a. criteria remain criteria for this or any SEASA as well. The process assurance objectives and criteria of reference a. are simply best industry practice, with additions for specific guidance for the aircraft certification and airborne systems domains, for assuring that the developed software is the specified software through the use of disciplined, rigorous processes and complete, correct data. This is needed for a SEASA approach in the same manner that it is needed for other software development approaches. Plans, procedures, standards, as well as processes for requirements, design, coding, integration, configuration management, quality assurance, and verification are all needed for a SEASA. Requirements-based testing and test coverage analysis are obviously critical to SEASA. Requirements completeness and assurance of safety related requirements are key elements of the 7

8 SEASA proposal. In fact, even by the admission of a specific airborne system developer, their specific SEASA requires more resources and effort than a program that just followed the guidance of reference a. for software assurance. Again, the main area that the specific SEASA was given credit and allowed to reduce the reference a. criteria was in the area of structural coverage. The rationale for allowing that reduction is, however, not documented, nor is the actual amount of credit granted known. Structural coverage analysis is a verification activity designed to assure that the software code has been adequately exercised in order to detect otherwise hidden software errors not revealed by requirements-based (functional) testing, and to reveal unreachable code in the software application. However, structural coverage can be achieved by testing in a technically correct, but perhaps inappropriate, manner: structural testing. Structural testing is testing the software, mostly at the software component level, using test procedures and cases developed on the basis of the code component itself, without necessarily being conscious of safety issues, system issues, integration considerations, or even requirements issues. Unless the software requirements, design and code have been developed very rigorously, this can lead to very non-value-added and inappropriate testing. See also related discussion paper 4.3 and frequently asked question (FAQ) 3.44 in reference i. The focus of reference a. is to conduct requirements-based testing of the software, including safety-related requirements, high-level requirements, low-level requirements, and derived requirements, at the highest level possible, measure the structural coverage achieved, and then supplement that testing by conducting lower level requirements-based tests until the structural coverage appropriate for the software level is achieved. Testing under SEASA is focused on safety related code, while code shown to be benign (i.e., non-safety related code) may not be exercised to the appropriate software level to satisfy the structural coverage criteria of reference a. It is unclear what other relaxation of reference a. assurance criteria may have been granted in the past or what may be possible using a SEASA. As a SEASA is used to identify and logically separate safety related code components from non-safety related code components (i.e., partitioning), it may be possible to reduce the reference a. criteria for the benign code components, as long as failures and anomalous behavior of those components cannot affect safety-related code components nor system availability or integrity, and it can be assured that any reduction will not lead to an undesirable safety affect. A SEASA proposal will likely include a partitioning strategy for using protective mechanisms for specific components and/or software operations. 8

9 5. Guidelines for evaluating a safety engineering approach for software assurance (SEASA). The following guidelines are intended to help determine the acceptability of an aircraft system applicant s or developer s proposal to use a SEASA for software assurance, software approvals and compliance to aircraft regulations: a. Integrated system, hardware and SEASA safety program. The applicant (or airborne system manufacturer or software developer) should develop and implement a safety program which is specific to the airborne product, and which combines and closely integrates the safety program and development processes for the product system, its hardware components and its software components. As any safety program for software relies on the identification and tracing of all aircraft hazards and all system failure conditions through the system requirements and architecture, hardware components, software requirements, software design and code, and the elimination or control of these hazards and failure conditions, it is imperative that the safety program be developed and implemented jointly by system developers, hardware developers and software developers. Safety assessment and elimination, minimization, and control of hazards and failure conditions should be a seamless process through the system development, hardware development and software development processes. The software developers must be informed of the system safety aspects of hardware failures and hardware and software behaviors, and the system developers must be informed of the potential hardware and software contributions to system failure conditions and aircraft hazards. Safety related system components should be identified to the software developers. Successful use of a SEASA relies on an approach where software developers are familiar with, and kept current on, safety aspects of the system. For example, software developers should be knowledgeable about system variables, such as input and output signals, which have potential safety consequences for the aircraft. This knowledge should then influence the manner in which software developers design the processing of these signals as well as the verification procedures for ensuring they are processed correctly, including handling signals and inputs that may be outside the normal tested ranges. Similarly, the hardware developers should be informed and knowledgeable about system variables that are processed by hardware. System developers should be knowledgeable about the safety aspects of the software and the hardware. This knowledge should influence how system requirements, architecture, design, constraints, and system level verification and validation procedures are specified. The integrated safety program should be designed to assure that safety-related information (i.e., requirements, design decisions, assumptions, constraints, problem reports, change impact analysis, etc.) is provided and used effectively between the system developers, hardware developers and software developers, and those responsible for validating and verifying the system, its hardware and its software. 9

10 b. Plans, procedures, and standards. All reference a. software planning and procedural data needed for compliance are also needed for compliance using a SEASA. In addition, system, hardware and software plans and procedures should define the integrated safety program, with safety related activities and data clearly specified. Standards should also be written to reflect safety-related requirements and constraints on development formats, methods, and practices. For example, software development standards should contain requirements and constraints on architectural elements related to isolation, partitioning, separation, monitoring, cohesion, and coupling of safety-related software components and parameters. Standards should also drive system, hardware and software designs towards simplification and verifiability. Design simplification and verifiability will provide better assurance that all safety related software aspects have been correctly implemented. c. Safety related software requirements, design, and code. All aircraft hazards, system failure conditions and safety-related requirements should be traced to the software-hardware interface, and software requirements specific to the hazards and failure conditions should be developed. Constraints on software behavior and software related system behavior should be specified. System states and state transitions should be completely specified. Each state should have a transition to a safe state specified. All states should be reachable and default transitions should be fully specified. Transitions to unsafe states should be identified by the safety assessment process and eliminated by specification of a replacement transition to a safe state. The system and software should always start in a safe state. All variables should be initialized correctly on system startup or initialization. All software components that perform safety related operations should be identified. These safety-related software components and the resources (i.e., processor, memory, clock, input/output devices, buses, etc.) should be isolated and protected from other non-safety-related components. The software architecture should be designed so that safety related components are highly cohesive and loosely coupled. Safety-related signal and data handling should be minimized. Hazard reduction design strategies and fail safe design techniques should be used to: eliminate hazards and failure conditions, minimize hazards and failure conditions, control the effects of hazards and failure conditions, or minimize the effects of hazards and failure conditions (listed by most desirable to least). Hazard reduction strategies for software-based systems include, for example: (1) Isolation and containment (partitioning) of safety-related software and hardware components, (2) Addition of protective features, such as safety monitoring software or hardware, (3) Recovery schemes from hardware failures and hardware or software anomalous behavior, (4) Addition of barriers, such as interlocks, lockouts, and lock-ins, (5) Functional cohesion, isolation, and decoupling (partitioning), 10

11 (6) Exposure reduction, (7) Simplification of design for increased verification and validation certainty. d. Traceability and verifiability. Aircraft hazards and system failure conditions to which software can contribute, or which are controlled by software, should be traceable to related software requirements, architecture, design components and constraints. These, in turn, should be traceable to the code, and to the verification procedures and cases that verify them under normal and abnormal conditions. Traceability should be shown from the hazards and failure conditions to the source code, and verification should be conducted to the same software level criteria as stated by reference a. criteria for the same software level. It is preferred that all safety-related software requirements-based testing be performed on the target executable code loaded on the target computer in the target environment. Testing on a high fidelity simulated environment can be acceptable if evidence exists to support the validity of the environment for the specific tests. A high fidelity simulated environment is one that provides identical or similar computing resources, peripherals, interfaces and inputs and outputs such that tests conducted on the simulated environment would result in identical, valid results to tests conducted in the actual operational environment. Qualification of the simulated environment as a verification tool may be needed. For a SEASA program, it is preferred that all safety-related requirements be verified on the executable object code integrated into the target computer and environment, or high fidelity simulated environment if applicable. If identical equipment cannot be used for technical reasons, deviations from the identical equipment must be presented to and accepted by the certification authority. e. Verification. A combination of both static and dynamic analyses should be specified by the applicant/developer and applied to the software. As with reference a., the emphasis of software verification should be focused on safety-related components and potential failure conditions of the software. Software reviews of requirements, design, architecture, code, integration, verification cases and procedures, and coverage analysis that would be expected under reference a., are applicable to SEASA as well. In addition, system safety analysis methods and fail-safe design techniques should be applied to the software to determine safety-related components and the safety effects of the software logic. Verification should be performed at the same level of rigor as specified by reference a. verification criteria for the same software level. Therefore, for a SEASA application, safety related requirements should be verified on the executable object code integrated into the target computer and environment. If safety related software components are properly isolated, partitioned, protected and decoupled from other software components, then structural coverage criteria of reference a. may be reduced for the non-safety related components, as is allowed by reference a. Software testing should concentrate on showing that the safety-related components perform according to the software safety requirements and that safety-related components are not 11

12 adversely affected by other, non-safety-related components (verifying the integrity of the partitioning). f. Software configuration management and software quality assurance. The configuration management and quality assurance criteria for a SEASA program are identical to those of reference a. and should include QA evaluation and oversight of SEASA processes as well as configuration management of all SEASA specific data items. g. Data items. All software life cycle data items of reference a. should be produced for a SEASA program, with the exception of items that the certification authority has allowed a reduction or replacement to the reference a. criteria. SEASA will likely result in additional SEASA-specific data items which replace reference a.-specified data items. Examples could be: system safety assessment results for software, justification of SEASA criteria as acceptable for satisfying one or more reference a. objectives, reference a. compliance matrix, structural coverage analysis of non-safety related components. In addition, all software data items needed to support the applicant's/developer s SEASA process are needed. This includes those needed to support the integrated safety for system, hardware and software program. Additions to the content of reference a. software data items will be needed to support a SEASA application. h. Software levels. Software levels are determined by the severity of the aircraft hazards and system failure conditions to which either the software could contribute, or is intended to control. Software levels should be determined consistent with system assurance level guidance in reference a. first and then reference g. If there is any difference in the determination of the software level as determined by references a. and g., the software level determination should be discussed and agreed-to by the specific project s certification authority. Any area of software to which SEASA will not be applied should comply with reference a. for the appropriate software level, as determined by the system safety assessment (SSA). i. Protective mechanisms and protected components. Where protective mechanisms are applied, the assignment of software level for a protected, safety-related software component should be determined by the worst case failure condition of that component, assuming the protective mechanism(s) are operable. The software level assigned to each protective mechanism should be based on the worst-case failure conditions that would result from a failure of that protective mechanism in combination with the failure of the protected software component. This assignment should consider: (1) The failure condition which could result from the failure or anomalous behavior of the protective mechanism to properly deploy and the failure or anomalous behavior of the protected component, and 12

13 (2) The worst case failure condition of an inadvertent deployment of the protective mechanism. j. Software level exceptions. Exceptions to i(2) may occur where application of SEASA results in mitigation of the effect of the inadvertent deployment. k. Reference a. criteria exceptions. Once the software level is assigned, all objectives of reference a. should be satisfied for the assigned software level; except where the applicant or developer has negotiated and obtained concurrence from the certification authority that their SEASA criteria, activity or data represents an equivalent means of satisfying the objective. Exceptions and equivalent means to reference a. criteria should be justified, documented, and agreed-to early in the product development with the certification authority. Analysis from the actual application of their SEASA may, in some cases, determine that additional verification is needed to augment the SEASA method. In these cases, the applicant or developer should provide appropriate verification results. l. Software Reviews. Software reviews should be conducted by the certification authority (and designees, if delegated) in the same manner and to the same criteria as with a reference a. review. The approval of SEASA processes and data should not require any extraordinary compliance monitoring beyond that required for a standard reference a. program. However, the reviewers should be familiar with the application of system safety assessment methods and fail-safe design techniques. m. SEASA proposals. An applicant or developer should present their SEASA proposal to the certification authority and gain their approval of the proposal early in the aircraft program or system life cycle to reduce the risk to the aircraft program or system project associated with non-concurrence by the certification authority. The proposal should include a reference a. compliance matrix showing which objectives will be satisfied by their SEASA criteria, activities and data, including independence and data control categories, which will be partially satisfied by their SEASA criteria, activities and data, and which will not be satisfied by their SEASA criteria, activities and data. The proposal should include a justification for any objectives that will not be fully satisfied by the SEASA proposal. Failure of the applicant or developer to submit the compliance matrix and justification would be grounds to disallow the SEASA proposal immediately. n. SEASA evaluations. The certification authority should make every reasonable effort to evaluate the applicant s or developer s SEASA proposal in a timely manner, and accept the proposal, accept the proposal with conditions, or reject the proposal with rationale for its unacceptability. It is in the best interests of the certification authority, the aircraft manufacturer, the applicant, the system developer and the software 13

14 developer to resolve and come to agreement on SEASA proposals early in the certification program. 6. Conclusion. This paper presents some considerations and guidelines for certification authorities to use when evaluating applicants proposals to use system safety assessment and engineering methods and techniques to providing software assurance for airborne systems and equipment. Although alternate approaches were considered, they must still be carefully evaluated on a case-by-case basis. The use of these approaches may be acceptable, but should be combined with a total system safety program and current best-practice software guidelines. Applicants should prepare and provide descriptions of their proposed approach and rationale for its acceptability for software assurance, which can then be evaluated by the certification authorities to determine the acceptability of their proposed alternative approach. 14

Certification Authorities Software Team (CAST) Position Paper CAST-3

Certification Authorities Software Team (CAST) Position Paper CAST-3 Certification Authorities Software Team (CAST) Position Paper CAST-3 Guidelines for Assuring the Software Aspects of Certification When Replacing Obsolete Electronic Parts Used in Airborne Systems and

More information

AC 20-148 REUSABLE SOFTWARE COMPONENTS

AC 20-148 REUSABLE SOFTWARE COMPONENTS AC 20-148 REUSABLE SOFTWARE COMPONENTS December 7, 2004 12/7/04 AC 20-148 CONTENTS Paragraph Title Page 1. Purpose....1 2. Motivation for this Guidance....1 3. Document Overview...1 4. General Guidelines

More information

Certification Authorities Software Team (CAST) Position Paper CAST-13

Certification Authorities Software Team (CAST) Position Paper CAST-13 Certification Authorities Software Team (CAST) Position Paper CAST-13 Automatic Code Generation Tools Development Assurance Completed June 2002 NOTE: This position paper has been coordinated among the

More information

Certification Authorities Software Team (CAST) Position Paper CAST-10

Certification Authorities Software Team (CAST) Position Paper CAST-10 Certification Authorities Software Team (CAST) Position Paper CAST-10 What is a Decision in Application of Modified Condition/Decision Coverage (MC/DC) and Decision Coverage (DC)? Completed June 2002 NOTE:

More information

b. We, the Federal Aviation Administration or FAA, wrote this AC to recognize the following RTCA, Inc. documents (RTCA DO):

b. We, the Federal Aviation Administration or FAA, wrote this AC to recognize the following RTCA, Inc. documents (RTCA DO): U.S. Department of Transportation Federal Aviation Administration Advisory Circular Subject: Airborne Software Assurance Date: mm/dd/yyyy Initiated by: AIR-120 AC : 20-115C Change: 1. Purpose of this Advisory

More information

Subject Software Aspects of Certification

Subject Software Aspects of Certification EASA NOTIFICATION OF A PROPOSAL TO ISSUE A CERTIFICATION MEMORANDUM EASA Proposed CM No.: EASA CM - SWAEH 002 Issue: 02 Issue Date: 22 nd of October 2013 Issued by: Safety, Software & Airborne Electronic

More information

Certification Authorities Software Team (CAST) Position Paper CAST-19

Certification Authorities Software Team (CAST) Position Paper CAST-19 Certification Authorities Software Team (CAST) Position Paper CAST-19 Clarification of Structural Coverage Analyses of Data Coupling and Control Coupling Completed January 2004 (Rev 2) NOTE: This position

More information

SAFE SOFTWARE FOR SPACE APPLICATIONS: BUILDING ON THE DO-178 EXPERIENCE. Cheryl A. Dorsey Digital Flight / Solutions cadorsey@df-solutions.

SAFE SOFTWARE FOR SPACE APPLICATIONS: BUILDING ON THE DO-178 EXPERIENCE. Cheryl A. Dorsey Digital Flight / Solutions cadorsey@df-solutions. SAFE SOFTWARE FOR SPACE APPLICATIONS: BUILDING ON THE DO-178 EXPERIENCE Cheryl A. Dorsey Digital Flight / Solutions cadorsey@df-solutions.com DIGITAL FLIGHT / SOLUTIONS Presentation Outline DO-178 Overview

More information

Certification Authorities Software Team (CAST) Position Paper CAST-26

Certification Authorities Software Team (CAST) Position Paper CAST-26 Certification Authorities Software Team (CAST) Position Paper CAST-26 VERIFICATION INDEPENDENCE COMPLETED January 2006 (Rev 0) NOTE: This position paper has been coordinated among the software specialists

More information

Certification Authorities Software Team (CAST) Position Paper CAST-15

Certification Authorities Software Team (CAST) Position Paper CAST-15 Certification Authorities Software Team (CAST) Position Paper CAST-15 Merging High-Level and Low-Level Requirements Completed February 2003 NOTE: This position paper has been coordinated among the software

More information

Complying with DO-178C and DO-331 using Model-Based Design

Complying with DO-178C and DO-331 using Model-Based Design 12AEAS-0090 Complying with DO-178C and DO-331 using Model-Based Design Bill Potter MathWorks, Inc. Copyright 2012 The MathWorks, Inc. ABSTRACT This paper addresses how recently published revisions of aircraft

More information

Parameters for Efficient Software Certification

Parameters for Efficient Software Certification Parameters for Efficient Software Certification Roland Wolfig, e0327070@student.tuwien.ac.at Vienna University of Technology, Real-Time Systems Group 1 Abstract Software certification is a common approach

More information

WORKSHOP RC 2011. EVI Integração de Sistemas Junho de 2011 Eng. Nelson José Wilmers Júnior

WORKSHOP RC 2011. EVI Integração de Sistemas Junho de 2011 Eng. Nelson José Wilmers Júnior WORKSHOP RC 2011 EVI Integração de Sistemas Junho de 2011 Eng. Nelson José Wilmers Júnior Comparison between ARP4754 A Guidelines for Development of Civil Aircraft and Systems (2010) and ARP4754 Certification

More information

DO-330/ED-215 Benefits of the New Tool Qualification Document

DO-330/ED-215 Benefits of the New Tool Qualification Document Frédéric Pothon ACG Solutions DO-330/ED-215 Benefits of the New Tool Qualification Document Frédéric Pothon, 2013 This work is licensed under a Creative Commons January 2013 Contributions and Reviews Laurent

More information

Meeting DO-178B Software Verification Guidelines with Coverity Integrity Center

Meeting DO-178B Software Verification Guidelines with Coverity Integrity Center Meeting DO-178B Software Verification Guidelines with Coverity Integrity Center May, 2009 Thomas Schultz Director of Product Strategy, Coverity, Inc. Executive Summary Development organizations that create

More information

Federal Aviation Administration FAA Status on Multi- Core Processors

Federal Aviation Administration FAA Status on Multi- Core Processors FAA Status on Multi- Core Processors April 2014 John Strasburger Outline FAA Certification Process How is the Civil Aviation Community Addressing MCPs? Challenges CAST 32 Processor Evolution Summary Questions

More information

DO-178B/C Differences Tool

DO-178B/C Differences Tool FAA/AVS DO-178B/C Differences Tool Revision: 8 DATE: 9/16/213 Revision History Date Rev Change summary 7/21/213 Draft 1 Draft Release - prototype 7/22/213 Draft 2 Draft Release for review 7/23/213 Draft

More information

Integrating System Safety and Software Assurance

Integrating System Safety and Software Assurance Integrating System Safety and Software Assurance Systems Certification and Integrity Directorate of Aviation Engineering Directorate General Technical Airworthiness 1 Overview Integration of software assurance

More information

Software Service History Handbook

Software Service History Handbook DOT/FAA/AR-01/116 Office of Aviation Research Washington, D.C. 20591 Software Service History Handbook January 2002 Final Report This document is available to the U.S. public through the National Technical

More information

8. Master Test Plan (MTP)

8. Master Test Plan (MTP) 8. Master Test Plan (MTP) The purpose of the Master Test Plan (MTP) is to provide an overall test planning and test management document for multiple levels of test (either within one project or across

More information

SCADE SUITE SOFTWARE VERIFICATION PLAN FOR DO-178B LEVEL A & B

SCADE SUITE SOFTWARE VERIFICATION PLAN FOR DO-178B LEVEL A & B SCADE SUITE SOFTWARE VERIFICATION PLAN FOR DO-78B LEVEL A & B TABLE OF CONTENTS. INTRODUCTION..... PURPOSE..... RELATED DOCUMENTS..... GLOSSARY... 9.. CONVENTIONS..... RELATION WITH OTHER PLANS....6. MODIFICATION

More information

Certification Authorities Software Team (CAST) Position Paper CAST-18

Certification Authorities Software Team (CAST) Position Paper CAST-18 Certification Authorities Software Team (CAST) Position Paper CAST-18 Reverse Engineering in Certification Projects Completed June 2003 (Rev 1) NOTE: This position paper has been coordinated among the

More information

The Impact of RTCA DO-178C on Software Development

The Impact of RTCA DO-178C on Software Development Cognizant 20-20 Insights The Impact of RTCA DO-178C on Software Development By following DO-178C, organizations can implement aeronautical software with clear and consistent ties to existing systems and

More information

RTCA DO-178B/EUROCAE ED-12B

RTCA DO-178B/EUROCAE ED-12B 27 RTCA DO-178B/EUROCAE ED-12B Thomas K. Ferrell Ferrell and Associates Consulting Uma D. Ferrell Ferrell and Associates Consulting 27.1 Introduction Comparison with Other Software Standards Document Overview

More information

CERTIFICATION MEMORANDUM

CERTIFICATION MEMORANDUM EASA CM No.: EASA CM SWCEH 002 Issue: 01 EASA CERTIFICATION MEMORANDUM EASA CM No.: EASA CM - SWCEH 002 Issue: 01 Issue Date: 11 th of August 2011 Issued by: Software & Complex Electronic Hardware section

More information

QUALITY MANAGEMENT SYSTEM FOR THE AEROSPACE INDUSTRY

QUALITY MANAGEMENT SYSTEM FOR THE AEROSPACE INDUSTRY I International Symposium Engineering Management And Competitiveness 2011 (EMC2011) June 24-25, 2011, Zrenjanin, Serbia QUALITY MANAGEMENT SYSTEM FOR THE AEROSPACE INDUSTRY Branislav Tomić * Senior Quality

More information

Software Review Job Aid - Supplement #1

Software Review Job Aid - Supplement #1 Software Review Job Aid - Supplement #1 1010011101010011110001101001101101101101000100100010101011100010110 1010011101010011110001101001101101101101000100101110101011100010111 0110100110110110110100010010001010101110001011000100111010100111100

More information

SOFTWARE VERIFICATION RESEARCH CENTRE SCHOOL OF INFORMATION TECHNOLOGY THE UNIVERSITY OF QUEENSLAND. Queensland 4072 Australia TECHNICAL REPORT

SOFTWARE VERIFICATION RESEARCH CENTRE SCHOOL OF INFORMATION TECHNOLOGY THE UNIVERSITY OF QUEENSLAND. Queensland 4072 Australia TECHNICAL REPORT SOFTWARE VERIFICATION RESEARCH CENTRE SCHOOL OF INFORMATION TECHNOLOGY THE UNIVERSITY OF QUEENSLAND Queensland 4072 Australia TECHNICAL REPORT No. 99-30 A Survey of International Safety Standards Axel

More information

Medical Device Software - Software Life Cycle Processes

Medical Device Software - Software Life Cycle Processes 1 Medical Device Software - Software Life Cycle Processes IEC 62304 2 Credits John F. Murray Software Compliance Expert U.S. Food and Drug Administration Marcie R. Williams Medical Device Fellow Ph.D.

More information

Introduction to a Requirements Engineering Framework for Aeronautics

Introduction to a Requirements Engineering Framework for Aeronautics J. Software Engineering & Applications, 2010, 3, 894-900 doi:10.4236/jsea.2010.39105 Published Online September 2010 (http://www.scirp.org/journal/jsea) Introduction to a Requirements Engineering Framework

More information

Using CMM with DO-178B/ED-12B for Airborne System Development

Using CMM with DO-178B/ED-12B for Airborne System Development Using CMM with DO-178B/ED-12B for Airborne System Development WHITE PAPER Author : Narasimha Swamy (Project Manager, Avionics Practice) Most aircraft companies develop onboard systems software for civilian

More information

Advisory Circular. U.S. Department of Transportation Federal Aviation Administration

Advisory Circular. U.S. Department of Transportation Federal Aviation Administration U.S. Department of Transportation Federal Aviation Administration Advisory Circular Subject: Airborne Software Assurance Date: 07/19/2013 AC No: 20-115C Initiated by: AIR-120 Change: 1. Purpose of this

More information

asuresign Aero (NATEP Grant MA005)

asuresign Aero (NATEP Grant MA005) asuresign Aero (NATEP Grant MA005) WP2 Workshop: Identification of Needs for Tool Support in Meeting Aircraft Avionics Systems, Hardware & Software Certification Standards Dr Chris Harper Systems & Safety

More information

Technical Standard Order

Technical Standard Order Department of Transportation Federal Aviation Administration Aircraft Certification Service Washington, D.C. TSO-C166b Effective Date: 12/02/09 Technical Standard Order Subject: Extended Squitter Automatic

More information

Best practices for developing DO-178 compliant software using Model-Based Design

Best practices for developing DO-178 compliant software using Model-Based Design Best practices for developing DO-178 compliant software using Model-Based Design Raymond G. Estrada, Jr. 1 The MathWorks, Torrance, CA Eric Dillaber. 2 The MathWorks, Natick, MA Gen Sasaki 3 The MathWorks,

More information

AN EFFECTIVE VERIFICATION AND VALIDATION STRATEGY FOR SAFETY-CRITICAL EMBEDDED SYSTEMS

AN EFFECTIVE VERIFICATION AND VALIDATION STRATEGY FOR SAFETY-CRITICAL EMBEDDED SYSTEMS AN EFFECTIVE VERIFICATION AND VALIDATION STRATEGY FOR SAFETY-CRITICAL EMBEDDED SYSTEMS Manju Nanda 1, Jayanthi J² 1 Scientist, National Aerospace Laboratories, Bangalore, India manjun@nal.res.in 2 Scientist,

More information

System Development Life Cycle Guide

System Development Life Cycle Guide TEXAS DEPARTMENT OF INFORMATION RESOURCES System Development Life Cycle Guide Version 1.1 30 MAY 2008 Version History This and other Framework Extension tools are available on Framework Web site. Release

More information

The new software standard for the avionic industry: goals, changes and challenges

The new software standard for the avionic industry: goals, changes and challenges WHITEPAPER DO-178C/ED-12C The new software standard for the avionic industry: goals, changes and challenges SVEN NORDHOFF Aerospace Certification / Process Assurance & SPICE Assessor sven.nordhoff@sqs.com

More information

DO-254 Requirements Traceability

DO-254 Requirements Traceability DO-254 Requirements Traceability Louie De Luna, Aldec - June 04, 2013 DO-254 enforces a strict requirements-driven process for the development of commercial airborne electronic hardware. For DO-254, requirements

More information

TERMS OF REFERENCE REFERENCE N TOR WG-106)

TERMS OF REFERENCE REFERENCE N TOR WG-106) WG-106 Electronic Flight Bag (EFB) TERMS OF REFERENCE REFERENCE N TOR WG-106) Approved by EUROCAE Council on (date: 20 October 2016) BACKGROUND AND SCOPE General: The quick development of the Electronic

More information

U.S. DEPARTMENT OF TRANSPORTATION FEDERAL AVIATION ADMINISTRATION. Air Traffic Organization Policy

U.S. DEPARTMENT OF TRANSPORTATION FEDERAL AVIATION ADMINISTRATION. Air Traffic Organization Policy U.S. DEPARTMENT OF TRANSPORTATION FEDERAL AVIATION ADMINISTRATION Air Traffic Organization Policy ORDER JO 1000.37A SUBJ: Air Traffic Organization Safety Management System Effective Date: 5/30/14 The mission

More information

Standards in Avionics System Development (Overview on DO-178B)

Standards in Avionics System Development (Overview on DO-178B) Standards in Avionics System Development (Overview on DO-178B) Ákos Horváth Dept. of Measurement and Information Systems Budapest University of Technology and Economics Department of Measurement and Information

More information

WIND RIVER RTCA DO-178 SOFTWARE CERTIFICATION SERVICES

WIND RIVER RTCA DO-178 SOFTWARE CERTIFICATION SERVICES WIND RIVER RTCA DO-178 SOFTWARE CERTIFICATION SERVICES Wind River Professional Services RTCA DO-178 Practice provides software certification services to help our customers address their demanding software

More information

Safety-Critical Systems: Processes, Standards and Certification

Safety-Critical Systems: Processes, Standards and Certification Fachbereich 17 - Mathematik/Informatik Arbeitsgruppe Softwaretechnik Warburger Straße 100 33098 Paderborn Safety-Critical Systems: Processes, Standards and Certification for the Seminar Analysis, Design

More information

Rev 1 January 16, 2004

Rev 1 January 16, 2004 1010011101010011110001101001101101101101000100110010101011100010110 0110100110110110110100010010001010101110001011000100111010100111100 1110100110110110110100010010001010101110001011000100111010100111100

More information

DO-178B compliance: turn an overhead expense into a competitive advantage

DO-178B compliance: turn an overhead expense into a competitive advantage IBM Software Rational Aerospace and Defense DO-178B compliance: turn an overhead expense into a competitive advantage 2 DO-178B compliance: turn an overhead expense into a competitive advantage Contents

More information

Camar Aircraft Products Co. QUALITY MANUAL Revision D

Camar Aircraft Products Co. QUALITY MANUAL Revision D QUALITY MANUAL Revision D Gujll'y Manual Introduction The purpose of this manual is to describe the Quality Assurance Program implemented by Camar Aircraft Products Co. (hereafter referred to as C.A.P.C.)

More information

Safety Analysis and Certification of Open Distributed Systems. P. M. Conmy; Department of Computer Science, University of York, York, YO10 5DD U.K.

Safety Analysis and Certification of Open Distributed Systems. P. M. Conmy; Department of Computer Science, University of York, York, YO10 5DD U.K. Safety Analysis and Certification of Open Distributed Systems P. M. Conmy; Department of Computer Science, University of York, York, YO10 5DD U.K. M. Nicholson; Department of Computer Science, University

More information

Certification of a Scade 6 compiler

Certification of a Scade 6 compiler Certification of a Scade 6 compiler F-X Fornari Esterel Technologies 1 Introduction Topic : What does mean developping a certified software? In particular, using embedded sofware development rules! What

More information

Software Quality Assurance Plan

Software Quality Assurance Plan Company Name Software Quality Assurance Plan Copyright 2012 Template.org Version: (n) Date: (mm/dd/yyyy) adapted from the IEEE Standard for Software Test Documentation Document History and Distribution

More information

An Interactive Video Teletraining Course. IVT Course 62823 Self-Study Video Course 25823

An Interactive Video Teletraining Course. IVT Course 62823 Self-Study Video Course 25823 Software Change Impact Analysis An Interactive Video Teletraining Course IVT Course 62823 Self-Study Video Course 25823 Developed and Presented by Leanna Rierson FAA, National Resource Specialist For Aircraft

More information

2015. All rights reserved.

2015. All rights reserved. DOCUMENT: Future AAMI/IEC 62304:2006/AMD1, 18-August-2015 Final Draft International Standard for Vote, Amendment 1 to IEC 62304: Medical device software Software life cycle processes. Public Review Draft

More information

Byron Birkedahl 1 and Ted Bonk 2 Honeywell Aerospace, Glendale, Arizona, 85308

Byron Birkedahl 1 and Ted Bonk 2 Honeywell Aerospace, Glendale, Arizona, 85308 AIAA SPACE 2010 Conference & Exposition 30 August - 2 September 2010, Anaheim, California AIAA 2010-8837 System Engineering & Integration Lessons Learned from Commercial Aircraft Modular Avionics Systems

More information

Software Quality Assurance Plan

Software Quality Assurance Plan For Database Applications Document ID: Version: 2.1a Planning Installation & Acceptance Integration & Test Requirements Definition Design Development 1 / 54 Copyright 2000-2006 Digital Publications LLC.

More information

Implementation of ANSI/AAMI/IEC 62304 Medical Device Software Lifecycle Processes.

Implementation of ANSI/AAMI/IEC 62304 Medical Device Software Lifecycle Processes. Implementation of ANSI/AAMI/IEC 62304 Medical Device Software Lifecycle Processes.. www.pharmout.net Page 1 of 15 Version-02 1. Scope 1.1. Purpose This paper reviews the implementation of the ANSI/AAMI/IEC

More information

SOFTWARE DEVELOPMENT STANDARD FOR SPACECRAFT

SOFTWARE DEVELOPMENT STANDARD FOR SPACECRAFT SOFTWARE DEVELOPMENT STANDARD FOR SPACECRAFT Mar 31, 2014 Japan Aerospace Exploration Agency This is an English translation of JERG-2-610. Whenever there is anything ambiguous in this document, the original

More information

Methodological Handbook. Efficient Development of Safe Avionics Software with DO-178B Objectives Using SCADE Suite

Methodological Handbook. Efficient Development of Safe Avionics Software with DO-178B Objectives Using SCADE Suite Efficient Development of Safe Avionics Software with DO-178B Objectives Using SCADE Suite CONTACTS Legal Contact Esterel Technologies SA Parc Euclide - 8, rue Blaise Pascal 78990 Elancourt FRANCE Phone:

More information

An Increase in Software Testing Robustness: Enhancing the Software Development Standard for Space Systems

An Increase in Software Testing Robustness: Enhancing the Software Development Standard for Space Systems An Increase in Software Robustness: Enhancing the Software Development Standard for Space Systems Karen Owens and Suellen Eslinger Software Engineering Subdivision 15 th Ground System Architectures Workshop

More information

1.0 Safety Management System

1.0 Safety Management System 1.0 Safety Management System 1 Scope and Applicability 1 1.1 Purpose....................................................................... 1 1.2 Scope.........................................................................

More information

1. Software Engineering Overview

1. Software Engineering Overview 1. Overview 1. Overview...1 1.1 Total programme structure...1 1.2 Topics covered in module...2 1.3 Examples of SW eng. practice in some industrial sectors...4 1.3.1 European Space Agency (ESA), software

More information

R214 SPECIFIC REQUIREMENTS: INFORMATION TECHNOLOGY TESTING LABORATORY ACCREDITATION PROGRAM

R214 SPECIFIC REQUIREMENTS: INFORMATION TECHNOLOGY TESTING LABORATORY ACCREDITATION PROGRAM The American Association for Laboratory Accreditation Document Revised: R214: Specific Requirements: Information Technology Testing Laboratory Accreditation July 13, 2010 Program Page 1 of 26 R214 SPECIFIC

More information

Table of Contents. Page 2 of 16

Table of Contents. Page 2 of 16 Table of Contents I. PURPOSE, SCOPE, AND EXCLUSIONS... 3 II. ROLES & RESPONSIBILITIES... 4 III. GRADED APPROACH TO SQA... 5 IV. SQA PROGRAM ELEMENTS... 6 4.1 Lifecycle Activities... 6 4.1.1 Requirements...

More information

TITLE: Control of Software

TITLE: Control of Software Page 1 of 8 TITLE: Control of Software WARNING This document is the property of United Technologies Corporation (UTC). You may not possess, use, copy or disclose this document or any information in it,

More information

Maturity Model. March 2006. Version 1.0. P2MM Version 1.0 The OGC logo is a Registered Trade Mark of the Office of Government Commerce

Maturity Model. March 2006. Version 1.0. P2MM Version 1.0 The OGC logo is a Registered Trade Mark of the Office of Government Commerce Maturity Model March 2006 Version 1.0 P2MM Version 1.0 The OGC logo is a Registered Trade Mark of the Office of Government Commerce This is a Value Added product which is outside the scope of the HMSO

More information

Tool Qualification Kit for NI TestStand Test Management Software

Tool Qualification Kit for NI TestStand Test Management Software www.certtech.com Tool Qualification Kit for NI TestStand Test Management Software CertTech, L.L.C. 14425 College Blvd. Suite 140 Lenexa, KS 66215 P (913-814-9770) F (913-817-0837) CertTech s TestStand

More information

Design & Manufacture Seminar SOFTWARE SECURITY & DESIGN ASSURANCE JAYSON ROWE SENIOR ENGINEER AVIONICS

Design & Manufacture Seminar SOFTWARE SECURITY & DESIGN ASSURANCE JAYSON ROWE SENIOR ENGINEER AVIONICS Design & Manufacture Seminar SOFTWARE SECURITY & DESIGN ASSURANCE JAYSON ROWE SENIOR ENGINEER AVIONICS Aircraft Network Security Development was required for B787 B787 over 1400 Loadable Software Parts

More information

Vertical and Horizontal Requirements Relationships By Theresa Hunt

Vertical and Horizontal Requirements Relationships By Theresa Hunt Vertical and Horizontal Requirements Relationships By Theresa Hunt www.westfallteam.com This article explores a common question raised about Capability Maturity Model Integration (CMMI ) expectations regarding

More information

UNCONTROLLED IF PRINTED IN-SERVICE MANAGEMENT OF SOFTWARE FOR AIRBORNE AND RELATED SYSTEMS

UNCONTROLLED IF PRINTED IN-SERVICE MANAGEMENT OF SOFTWARE FOR AIRBORNE AND RELATED SYSTEMS UNCONTROLLED IF PRINTED AAP 7001.054 Sect 2 Chap 17 SECTION 2 CHAPTER 17 IN-SERVICE MANAGEMENT OF SOFTWARE FOR AIRBORNE AND RELATED SYSTEMS INTRODUCTION 1. The in-service maintenance and development of

More information

Merging Safety and Assurance: The Process of Dual Certification for Software

Merging Safety and Assurance: The Process of Dual Certification for Software Merging Safety and Assurance: The Process of Dual Certification for Software Carol Taylor, Jim Alves-Foss, and Bob Rinker Center for Secure and Dependable Systems University of Idaho Track 5 250-B High

More information

Your Software Quality is Our Business. INDEPENDENT VERIFICATION AND VALIDATION (IV&V) WHITE PAPER Prepared by Adnet, Inc.

Your Software Quality is Our Business. INDEPENDENT VERIFICATION AND VALIDATION (IV&V) WHITE PAPER Prepared by Adnet, Inc. INDEPENDENT VERIFICATION AND VALIDATION (IV&V) WHITE PAPER Prepared by Adnet, Inc. February 2013 1 Executive Summary Adnet is pleased to provide this white paper, describing our approach to performing

More information

DRAFT (Public comments phase August 2006) Date: XX/XX/XX. Initiated by: ANE-110

DRAFT (Public comments phase August 2006) Date: XX/XX/XX. Initiated by: ANE-110 (Public comments phase August 2006) Advisory Circular Subject: PROPOSED DRAFT Turbine Engine Repairs and Alterations Approval of Technical and Substantiation Data Date: XX/XX/XX Initiated by: ANE-110 AC

More information

Date: 9/30/15 AC No: 119-1 Initiated by: AFS-300 Change: 0

Date: 9/30/15 AC No: 119-1 Initiated by: AFS-300 Change: 0 U.S. Department of Transportation Federal Aviation Administration Subject: Airworthiness and Operational Authorization of Aircraft Network Security Program (ANSP) Advisory Circular Date: 9/30/15 AC No:

More information

Introduction of ISO/DIS 26262 (ISO 26262) Parts of ISO 26262 ASIL Levels Part 6 : Product Development Software Level

Introduction of ISO/DIS 26262 (ISO 26262) Parts of ISO 26262 ASIL Levels Part 6 : Product Development Software Level ISO 26262 the Emerging Automotive Safety Standard Agenda Introduction of ISO/DIS 26262 (ISO 26262) Parts of ISO 26262 ASIL Levels Part 4 : Product Development System Level Part 6 : Product Development

More information

Reaping the benefits of Reusable Software Components

Reaping the benefits of Reusable Software Components Safety & Security for the Connected World Reaping the benefits of Reusable Software Components The Significance of FAA Reusable Software Component Certification Mark Pitchford The conflicting demands on

More information

STANDARD REVIEW PLAN

STANDARD REVIEW PLAN NUREG-0800 U.S. NUCLEAR REGULATORY COMMISSION STANDARD REVIEW PLAN BRANCH TECHNICAL POSITION 7-14 GUIDANCE ON SOFTWARE REVIEWS FOR DIGITAL COMPUTER-BASED INSTRUMENTATION AND CONTROL SYSTEMS REVIEW RESPONSIBILITIES

More information

U.S. NUCLEAR REGULATORY COMMISSION STANDARD REVIEW PLAN. Organization responsible for the review of instrumentation and controls

U.S. NUCLEAR REGULATORY COMMISSION STANDARD REVIEW PLAN. Organization responsible for the review of instrumentation and controls U.S. NUCLEAR REGULATORY COMMISSION STANDARD REVIEW PLAN NUREG-0800 BRANCH TECHNICAL POSITION 7-14 GUIDANCE ON SOFTWARE REVIEWS FOR DIGITAL COMPUTER-BASED INSTRUMENTATION AND CONTROL SYSTEMS REVIEW RESPONSIBILITIES

More information

Software Project Management Plan

<name of project> Software Project Management Plan The document in this file is adapted from the IEEE standards for Software Project Management Plans, 1058-1998, which conforms to the requirements of ISO standard 12207 Software Life Cycle Processes. Tailor

More information

THE ROLE OF SOFTWARE QUALITY ASSURANCE IN DO-178B/C SOFTWARE DEVELOPMENT PROCESS

THE ROLE OF SOFTWARE QUALITY ASSURANCE IN DO-178B/C SOFTWARE DEVELOPMENT PROCESS 2015 White Paper THE ROLE OF SOFTWARE QUALITY ASSURANCE IN DO-178B/C SOFTWARE DEVELOPMENT PROCESS Contents Introduction 01 Definitions 01 Backdrop 01 Discussion 01 Conclusion 08 Author 08 References 08

More information

Flight Safety Information Journal

Flight Safety Information Journal Flight Safety Information Journal January 2008 In this Issue: A Brief Overview of Safety Management Systems (SMS) Curt Lewis, P.E., CSP, ATP L. Christopher, Ed. SMS A Brief Overview of Safety Management

More information

Certification of Civil Avionics

Certification of Civil Avionics 23 Certification of Civil Avionics Frank McCormick Certification Services, Inc. 23.1 Introduction 23.2 Regulatory Basis of the Federal Aviation Administration 23.3 FAA Approvals of Avionics Equipment Technical

More information

Build (develop) and document Acceptance Transition to production (installation) Operations and maintenance support (postinstallation)

Build (develop) and document Acceptance Transition to production (installation) Operations and maintenance support (postinstallation) It is a well-known fact in computer security that security problems are very often a direct result of software bugs. That leads security researches to pay lots of attention to software engineering. The

More information

Air Force Mentor-Protégé Program. Configuration Management & Control. ERP Methodology and Project Management. Professor Duane Truex III.

Air Force Mentor-Protégé Program. Configuration Management & Control. ERP Methodology and Project Management. Professor Duane Truex III. Air Force Mentor-Protégé Program Configuration Management & Control Ronald E. Giachetti, Ph.D. Associate Professor Industrial and Systems Engineering Florida International University Duane P. Truex, Ph.D.

More information

IMPLEMENTATION OF A SOFTWARE PROJECT OFFICE AT HONEYWELL AIR TRANSPORT SYSTEMS. by Michael A. Ross

IMPLEMENTATION OF A SOFTWARE PROJECT OFFICE AT HONEYWELL AIR TRANSPORT SYSTEMS. by Michael A. Ross IMPLEMENTATION OF A SOFTWARE PROJECT OFFICE AT HONEYWELL AIR TRANSPORT SYSTEMS by Michael A. Ross Abstract. This paper justifies, defines and describes an organization-level software project management

More information

SoBran, Inc. Corporate Quality Management Plan for Projects and Activities

SoBran, Inc. Corporate Quality Management Plan for Projects and Activities SoBran, Inc. Corporate Quality Management Plan for Projects and Activities This proposal or quotation includes data that shall not be disclosed outside the government and shall not be duplicated, used,

More information

Chapter 10. System Software Safety

Chapter 10. System Software Safety Chapter 10 System Software Safety 10.0 SYSTEM SOFTWARE SAFETY...2 10.1 INTRODUCTION...2 10.2 THE IMPORTANCE OF SYSTEM SAFETY...3 10.3 SOFTWARE SAFETY DEVELOPMENT PROCESS...5 10.4 SYSTEM SAFETY ASSESSMENT

More information

SOFTWARE SAFETY STANDARD

SOFTWARE SAFETY STANDARD NOT MEASUREMENT SENSITIVE National Aeronautics and NASA-STD-8719.13B w/change 1 Space Administration July 8, 2004 SOFTWARE SAFETY STANDARD NASA TECHNICAL STANDARD REPLACES NASA-STD-8719.13A DATED SEPTEMBER

More information

AP1000 European 18. Human Factors Engineering Design Control Document

AP1000 European 18. Human Factors Engineering Design Control Document 18.2 Human Factors Engineering Program Management The purpose of this section is to describe the goals of the AP1000 human factors engineering program, the technical program to accomplish these goals,

More information

Procedure for Assessment of System and Software

Procedure for Assessment of System and Software Doc. No: STQC IT/ Assessment/ 01, Version 1.0 Procedure for Assessment of System and Software May, 2014 STQC - IT Services STQC Directorate, Department of Electronics and Information Technology, Ministry

More information

Quality in Aviation Software. Chris Hartgroves C.Eng. CQP Design Assurance SELEX Galileo

Quality in Aviation Software. Chris Hartgroves C.Eng. CQP Design Assurance SELEX Galileo Quality in Aviation Software Chris Hartgroves C.Eng. CQP Design Assurance SELEX Galileo CQI North London : October 13 th 2011 Contents Introduction Terminology Historical context Poor quality aerospace

More information

Quality Assurance QUALITY ASSURANCE PLAN

Quality Assurance QUALITY ASSURANCE PLAN Revision 2 Page 1 of 40 QUALITY ASSURANCE PLAN PLAN APPROVALS: Jeff Shouse Signature on File DIRECTOR OF QUALITY ASSURANCE DIRECTOR OF QUALITY ASSURANCE (signature) DATE Rodney Baltzer Signature on File

More information

ARINC 653. An Avionics Standard for Safe, Partitioned Systems

ARINC 653. An Avionics Standard for Safe, Partitioned Systems ARINC 653 An Avionics Standard for Safe, Partitioned Systems 1 Courtesy of Wind River Inc. 2008 IEEE-CS Seminar June 4 th, 2008 Agenda Aerospace Trends IMA vs. Federated ARINC 653 Main concepts Safety

More information

Certification Report

Certification Report Certification Report EAL 2+ Evaluation of Symantec Endpoint Protection Version 11.0 Issued by: Communications Security Establishment Canada Certification Body Canadian Common Criteria Evaluation and Certification

More information

Software Test Plan (STP) Template

Software Test Plan (STP) Template (STP) Template Items that are intended to stay in as part of your document are in bold; explanatory comments are in italic text. Plain text is used where you might insert wording about your project. This

More information

TL 9000 and TS16949 Comparison

TL 9000 and TS16949 Comparison TL 9000 and TS16949 Comparison www.questforum.org Copyright QuEST Forum 2007 1 Purpose This summary is intended to give those familiar with TS16949 requirements a general sense of the additional requirements

More information

Modular Safety Cases

Modular Safety Cases Modular Safety Cases Facilitating Incremental Upgrade to Military Capability by Managing the Complexity of Safety Assurance Executive Summary Maintaining military capability at state of the art levels,

More information

ENEA: THE PROVEN LEADER IN SAFETY CRITICAL AVIONICS SYSTEMS

ENEA: THE PROVEN LEADER IN SAFETY CRITICAL AVIONICS SYSTEMS ENEA: THE PROVEN LEADER IN SAFETY CRITICAL AVIONICS SYSTEMS info@enea.com. www.enea.com For over 40 years, we have been one of the fastest growing avionics consulting companies in the world. Today our

More information

Repair Station Training Program

Repair Station Training Program AC 145 RSTP DATE: Repair Station Training Program Initiated by: AFS-300 TABLE OF CONTENTS CHAPTER 1. INTRODUCTION... 1 100. Purpose of this advisory circular (AC).... 1 101. Who should use this AC....

More information

Program Lifecycle Methodology Version 1.7

Program Lifecycle Methodology Version 1.7 Version 1.7 March 30, 2011 REVISION HISTORY VERSION NO. DATE DESCRIPTION AUTHOR 1.0 Initial Draft Hkelley 1.2 10/22/08 Updated with feedback Hkelley 1.3 1/7/2009 Copy edited Kevans 1.4 4/22/2010 Updated

More information

Certification Report

Certification Report Certification Report EAL 2+ Evaluation of Issued by: Communications Security Establishment Certification Body Canadian Common Criteria Evaluation and Certification Scheme 2008 Government of Canada, Communications

More information

Lecture Slides for Managing and Leading Software Projects. Chapter 1: Introduction

Lecture Slides for Managing and Leading Software Projects. Chapter 1: Introduction Lecture Slides for Managing and Leading Software Projects Chapter 1: Introduction developed by Richard E. (Dick) Fairley, Ph.D. to accompany the text Managing and Leading Software Projects published by

More information