Identifying and Understanding Relevant System Safety Standards for use in the Automotive Industry

Size: px
Start display at page:

Download "Identifying and Understanding Relevant System Safety Standards for use in the Automotive Industry"

Transcription

1 SAE TECHNICAL PAPER SERIES Identifying and Understanding Relevant System Standards for use in the Automotive Industry Barbara J. Czerny, Joseph G. D Ambrosio, Paravila O. Jacob and Brian T. Murray Delphi Corporation Reprinted From: In-Vehicle Networks, Critical Systems, Accelerated Testing, and Reliability (SP-1783/SP-1783CD) 2003 SAE World Congress Detroit, Michigan March 3-6, Commonwealth Drive, Warrendale, PA U.S.A. Tel: (724) Fax: (724) Web:

2 All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of SAE. For permission and licensing requests contact: SAE Permissions 400 Commonwealth Drive Warrendale, PA USA permissions@sae.org Fax: Tel: For multiple print copies contact: SAE Customer Service Tel: (inside USA and Canada) Tel: (outside USA) Fax: CustomerService@sae.org ISSN Copyright 2003 SAE International Positions and opinions advanced in this paper are those of the author(s) and not necessarily those of SAE. The author is solely responsible for the content of the paper. A process is available by which discussions will be printed with the paper if it is published in SAE Transactions. Persons wishing to submit papers to be considered for presentation or publication by SAE should send the manuscript or a 300 word abstract of a proposed manuscript to: Secretary, Engineering Meetings Board, SAE. Printed in USA

3 Identifying and Understanding Relevant System Standards for use in the Automotive Industry Barbara J. Czerny, Joseph G. D Ambrosio, Paravila O. Jacob and Brian T. Murray Delphi Corporation Copyright 2003 SAE International ABSTRACT A new generation of software-controlled vehicle systems promises to help enhance vehicle safety, performance and comfort. As these new, often complex systems are added, system safety programs are followed to help eliminate potential hazards. An important part of planning for a safety program is to understand applicable standards. This paper identifies, reviews, categorizes, and summarizes the importance of several applicable standards for incorporation in a system safety program. INTRODUCTION Rapid advances in automotive electronics have fueled an ever-increasing number of new features within vehicles. In many cases, these are new entertainment or driver information features [1], in other cases, advanced control systems for powertrain or chassis. In addition to new features, there is a trend toward the integration of the functions, systems, and technologies that implement them. These new systems will help provide unprecedented increases in driver and passenger safety as well as comfort and convenience, however, their complexity is higher than previous systems and they will control essential vehicle functions. Such systems, under very unlikely, but possible scenarios, have the capacity to create safety-related issues when not operating properly, and are commonly called safety-critical systems [2]. -critical systems are designed and analyzed carefully in order to help confirm not only that they operate as they were intended, but also to help prevent them from operating in any way that is not desired. A system safety process facilitates this design process [2]. is intimately connected to the notion of risk, and popularly means a relatively high degree of freedom from harm. Risk is a combination of the likelihood and the severity of an unplanned, undesirable mishap. A system is generally considered to be safe if the level of risk is reasonable [3]. Reasonable risk must be evaluated according to societal, legal, and corporate concerns [4]. s are potential unsafe events or conditions that could lead to undesired consequences or mishaps. A hierarchy or interaction of undesired causes typically combine to result in a hazard. Faults are potential physical or logical nonconformances in the design or implementation of a device or system. Under certain conditions, they can lead to errors, that is, incorrect system states. Errors may induce failures, that is, deviations from appropriate system behavior. Failures are hazards if they can lead to undesired consequences. Note that not all hazards are the result of faults. s can also be caused by unanticipated sequences of interactions between components or subsystems. System safety engineering is the application of engineering and management principles, criteria, and technology, to provide a reasonable and achievable level of safety together with other system design constraints throughout all phases of the system lifecycle [5]. Reliability, R(t), is the probability that a system has not failed by some time t. The popular notion of a reliable system is that it is trouble-free for a long time. is not equivalent to reliability; a safe system may be unreliable, and uncovered hazards in ultrareliable systems may be severe. For example, an Anti-lock Brake System (ABS) with highly sensitive diagnostics may deactivate ABS frequently in one strategy to satisfy safety requirements. However, customers are unlikely to be satisfied with such a system. Ultrareliable systems, e.g., systems with calculated unreliability or smaller are hard to verify, and assumptions made to justify the achievement of such high reliability may not be valid in practice. Nevertheless, government regulations may require designing to specific high reliability targets. Moreover, as noted above, not all hazards are induced by faults in individual components. Each component may work correctly and the system itself may be operating according to specification, however, the specification may not account for all operating conditions, and as noted above, unanticipated component and subsystem interactions can also lead to potential hazards. System safety programs seek to identify potential hazards and help eliminate or mitigate them. Many of the constituent elements of a system safety process can be determined by standards proposed by

4 governments as well as various industry groups, such as the SAE. Moreover, standards affecting various subsystems, e.g., braking and steering, can have specific requirements intended to help improve safety. These requirements should be directly incorporated by any safety program for new systems that contain such subsystems as elements. In the next section, we describe the elements of a system safety program. This sets the stage for describing how various standards interface with such a program. The following sections identify, review, and categorize several applicable standards. Finally, we conclude with some recommendations. ELEMENTS OF A SYSTEM SAFETY PROGRAM Implementation of a system-safety program is an acknowledged best practice for helping to improve and document the safety of a product design [5]. The objectives of a system safety program include, but are not limited to: 1. Identify potential hazards and associated avoidance requirements; 2. Translate safety requirements into engineering requirements; 3. Provide design assessment and trade-off support to the ongoing design; 4. Assess relative compliance of design to requirements and document findings; 5. Direct and monitor specialized safety testing; and 6. Monitor and review test and field issues for safety trends. One major step towards achieving these objectives is to establish a system safety working group (SSWG) [3] for the product. A SSWG is comprised of senior design team members from the various disciplines involved in the product design. Typically, a SSWG is responsible for providing for the safety of the product design and for conducting and/or monitoring any necessary safety tasks. SSWG meetings are held on a regular basis, and serve as a forum for discussing the current status of safety-related activities and for discussing safety concerns. Once the SSWG has been established, the group can implement a system safety process to help achieve the safety program objectives. Figure 1 shows an example system safety process and how it relates to the overall design process. The top row of the figure shows the primary design process steps, while the bottom row shows the corresponding system safety activities. At the start of the design process, a system safety program plan (SSPP) is usually written [2]. The program plan includes the relevant safety tasks to be performed, the safety organization that will be established to perform and monitor the tasks, and relevant documents, such as applicable government regulations or standards. By writing a plan at the beginning of a product design, the design organization confirms that safety is a primary design concern throughout the design process, and reinforces the commitment to producing a safe product design. Conceptual Design Preliminary Concept Arch. Design Detailed Control Specifications Program Specific Activities Assessments Detailed Verification Design & Validation Verification Production & Deploy. Comprehensive Report Figure 1: Example System Process One of the first tasks in the SSPP is to perform a Preliminary (PHA). The SSWG participates in one or more brainstorming exercises to construct a Preliminary List (PHL), which describes the potential hazards of the system. The potential safety risk associated with each hazard is then evaluated by assessing the likelihood and severity of incidents that could result from the hazard. By identifying the potential risk associated with each hazard, PHA allows the SSWG to assess the safety of the proposed conceptual design, and to focus engineering activities on eliminating or mitigating potential safety problems. Once potential safety hazards have been identified, the SSWG must address them by developing system-safety requirements and hazard controls. requirements are behavioral constraints added to the requirements and specification documents of a given project for safety reasons, such as, the system should not cause unwanted steer. requirements may be general in that they address a range of potential hazards, or they may specific in that they address only one potential hazard. In addition, system safety requirements most often must be decomposed and allocated to the components of a system (Figure 2). In some cases, the initially identified safety requirements are of a qualitative nature, and these qualitative safety requirements must be translated into engineering requirements, quantifying acceptable levels of performance. The next step in addressing hazards is to define hazard controls. controls are any design feature implemented to satisfy safety requirements. An individual hazard control may help satisfy a large number of safety requirements, or it may address only a single requirement.

5 Preliminary Standards & Government Regulations Detailed System Component System Controls Component Controls why this level of risk is acceptable, and articulates the SSWG s belief that its assessment is accurate. The safety case is used to determine whether to accept the system's approach to safety. The standards, guidelines, and regulations discussed below provide useful information on carrying out the various aspects of a system safety program, including providing safety requirements, guidelines for performing different types of analyses, and system safety process requirements. We first discuss a framework for categorizing the various standards and guidelines, then we discuss individual standards. Figure 2: Relationship Among Standards, s,, and Controls At this point, the SSWG often creates a safety concept document, which describes the basic strategy for helping establish the safety of the system, and which may also contain the system-safety requirements and the system hazard controls. The requirements stated or implied in the safety concept are integrated with other engineering requirements, and form the specification for the architectural design of the system (Figure 1). The preliminary activities of the safety program, including the PHA, and determination of the safety requirements and hazard controls, permit the specification of a preliminary system architecture that satisfies the safety concept as well as functional requirements. At this point, a more detailed hazard analysis is initiated. The goal of detailed hazard analysis is to identify and justify all necessary hazard controls. Detailed hazard analysis provides a better understanding of the potential failure modes of the system, how they lead to potential hazards, and how proposed hazard controls can best be combined to satisfy safety requirements and eliminate or mitigate potential hazards. The SSWG combines the results of the applied techniques to generate detailed safety requirements (hazard control specifications) that are achieved during the detailed design of the system (Figure 1). For example, these include diagnostics and design safety margins. Once detailed design is complete, including implementation of necessary hazard controls, the SSWG verifies that potential hazards of the conceptual design have indeed been eliminated or mitigated. Fault injection testing can be performed on software models, bench fixtures, or engineering vehicles to verify that hazard controls operate as intended. All hazard controls must be verified before the SSWG can sign-off on the reasonableness of the system. Finally, the SSWG may write a safety case document for the system, documenting the SSWG s belief that the system is reasonably safe. In this document, the SSWG summarizes the results of analyses performed and the steps taken to reduce potential risk, identifies the residual potential risk remaining in the system, describes STANDARDS FRAMEWORK Standards vary according to their scope, detail level, and content. A standard can apply to the whole system or to specific parts of a system typically called safety-related subsystems. The level of detail contained in the standard can be low, allowing more flexibility in the application of the standard, or high, providing for a more consistent application of the standard. Standards can contain requirements or guidance or both; requirements state what must be achieved, while guidance may provide specific example methods for satisfying requirements. The requirements / guidelines are process oriented or implementation oriented (Figure 3). Process oriented requirements / guidelines are related to management and/or analysis processes, while implementation requirements / guidelines are related to the system architecture and/or specific components of the system. Management Process / Guidelines Architecture Implementation Components Figure 3: /Guidelines Framework Standards also differ according to their type. In the context of this paper, we identify three types of standards: System and Software Process standards, Government Regulations, and standards. There are also Reliability standards, however, reliability standards are beyond the scope of this paper. The different types of standards may apply to specific sectors, including mechanical, electrical / electronics, and software, and within each of these sectors they may apply to the overall architecture and to specific components (Figure 4). This paper will focus mainly on system and software safety process standards. The next section will provide overviews of some specific standards and discuss in more detail those standards that may be relevant to or applicable in the automotive domain.

6 Regula - tions Figure 4: Types of standards RELEVANT SYSTEM SAFETY STANDARDS System/SW Process Mechanical Electrical/ Electronics Architecture Components Reliability Software The most influential system safety standard in the United States is MIL-STD-882C. MIL-STD-882C specifies detailed requirements covering all aspects of a system safety process for all DOD (Department of Defense) systems and facilities. It applies to every activity of the system life cycle including research, technology development, design, test and evaluation, manufacturing, verification, calibration, operations, maintenance and support, and modification and disposal activities. Recently, this standard was superseded by MIL-STD-882D, a less structured standard than its predecessor, with fewer detailed requirements. MIL- STD-882D specifies only high-level requirements for a standard practice for conducting system safety. The details of how to carry out the high-level requirements are left to the program manager. MIL-STD-882C provides uniform requirements for developing and implementing a system safety program. The main objective of the safety program is to define a systematic approach to help ensure that safety, consistent with mission requirements, is designed into the system in a timely, cost-effective manner. Potential hazards associated with each system are identified, tracked, evaluated, and eliminated, or the associated risk reduced to a level deemed acceptable to the organization developing the system, and to society in general. The standards document itself is divided into several sections: Scope, Applicable Documents, Acronyms and Definitions, General, Detailed, Notes, and Appendices which provide additional information and guidance. The general requirements include both general process requirements and general implementation requirements. Examples of general process requirements include identification of potential hazards, assessment of mishap risk, and identification of mishap risk mitigation measures. Examples of general implementation requirements include providing the order of precedence for satisfying system safety and resolving identified potential hazards; that is, design to eliminate potential hazards or reduce the risk, incorporate safety devices, provide warning devices, develop procedures and training. The detailed requirements in MIL-STD-882C include requirements on safety program organization, design and integration, design evaluation, and compliance and verification (Figure 5). For example, detailed requirements for design and integration include requirements for preliminary hazard analysis, system safety requirements analysis, subsystem hazard analysis, etc. For design evaluation, detailed requirements are included for safety assessment, and test and evaluation safety. The majority of detailed requirements provided in each of the categories are applicable in the automotive domain. 100: Program Organization Program 101 Preliminary List 201 Assessment 301 SSPP : Design & Integration Preliminary : Design Evaluation Verification 401 Test & Evaluation : Compliance & Verification Compliance 402 Subcontractor 103 Sys. Req. 203 Reviews 104 Subsystem 204 Review Change Proposal & SW PRs 303 Explosive Classification 403 SSWG Participation 105 System 205 Explosive Ordnance Disposal 404 Tracking & Resolution 106 System Progress Reports 107 Operating 206 Health 207 Figure 5: MIL-STD-882C detailed requirements MOD DEF STAN Ministry of Defence Defence Standard (MOD DEF STAN 00-56) is a UK standard that was developed by the ministry of defence for contractors of defense systems. The standard consists of two parts: part 1 contains requirements and part 2 contains guidance. This standard provides uniform requirements for implementing a system safety program in order to identify potential hazards and to impose design techniques and management controls to identify, evaluate and reduce their associated risks to a tolerable level. The standard also defines the safety program management procedures, the analysis techniques and the safety verification activities, which are applicable during the project lifecycle. It applies to all phases in the project lifecycle from initiation through development, production, and disposal. The standard uses the concept of Integrity Levels (SILs) to determine the level of effort required for analysis and reliability requirements. integrity consists of random failure integrity and systematic failure integrity. Random failure is failure due to some physical change and its probability can be predicted reasonably accurately. Systematic failure is failure due to factors such as environmental factors, or errors in the specification and design. Predicting

7 systematic failure rates is difficult since the failure rate depends on system inputs and transient conditions in the domain. One use of Integrity Level (SIL) is as an indicator of the required level of protection against systematic failure. In the early design stages a SIL is allocated to each abstract function. The allocated SIL is inherited by the components that implement the function. Appropriate design and analysis techniques are associated with each SIL. Claim limits are also set for each SIL. These claim limits provide a measure of the effectiveness of the techniques associated with each SIL by giving a minimum failure rate that can be claimed for a function or component of that level. The practices and procedures set out in this standard are intended to help ensure (through a rigorous process of safety assurance) that the potential for an equipment to enter service with unacceptable safety characteristics is minimized. The primary purpose of the safety assurance process is to maximize the visibility of equipment safety characteristics at all stages of the project lifecycle. This is achieved through selected analytical assessments and verification activities, carefully integrated with the overall project program in accordance with a Program Plan. The results and record of the ongoing analytical and verification activities help provide confidence that the desired safety characteristics have been designed into the system. The combined results of these activities provide evidence to support a logical argument, usually referred to as a Case, for the deployment of the system into service. was developed by the International Electrotechnical Commission (IEC) Industrial-Process Measurement Committee. was not intended to be used as a standard itself, but rather, to act as a generic standard to encourage and facilitate the development of application sector standards. It is applicable to safety-related systems of electrical/electronic/programmable electronic systems, both integrated with the Equipment Under Control (EUC) control system and separate from the EUC control system (Figure 6). Electrical/Electronic/Programmable Electronic System EUC Control System Equipment Under Control (A) Separate - Related System -Related System EUC Control System & -Related System Functions Equipment Under Control (B) Integrated - Related System Focus of Figure 6: -related system focus consists of seven parts: Part 1, General ; Part 2, for Electrical/Electronic/Programmable Electronic - Related Systems, Part 3, Software ; Part 4, Definitions and Abbreviations; Part 5, Examples of Methods for the Determination of Integrity Levels; Part 6, Guidelines for the Application of Parts 2 and 3; and Part 7, Overview of Techniques and Measures. The standard covers all aspects of a system from program requirements through architecture and hardware design requirements, to software requirements. The standard includes recommendations, and program, process, and product characteristic guidance. The general requirements, guidance, and recommendations provided are dependent on the determined safety integrity level (SIL) of the safety functions. The use of safety integrity levels in MOD DEF STAN and are not identical. For a given system, the EUC (Equipment Under Control) risk is assessed for each determined hazardous event, safety functions necessary to help ensure the required functional safety for each identified hazard are determined, risk reduction criteria are determined, safety integrity requirements are specified for each safety function based on the required risk reduction, and safety integrity levels are assigned to each safety function. The necessary risk reduction may be determined quantitatively and/or qualitatively. Part 5 of the standard provides guidance on methods that may be used to determine risk reduction. Annex A.3 of part 2 of the standard contains tables giving recommendations for techniques and measures that can be used to control systematic failures caused by hardware and software design, environmental stress or influence, etc. Annex B of part 2 contains tables that give recommendations for each SIL on techniques and measures that may be used to avoid systematic failures during the different phases of the lifecycle. -7 contains overviews of the specific techniques and measures cited in -2 and -3. SYSTEM SAFETY STANDARDS CATAGORIZATIONS AND COMPARISONS Using the framework described earlier, we can categorize and compare the standards discussed above. Figure 7 and Table 1 show the resulting categorizations and comparisons. and DEF-STAN apply to all aspects of the system: mechanical, electrical and electronics, and software. applies to the electrical and electronic, and software aspects of a system. The scope of the system safety process for and DEF-STAN is the whole system, both safety-related components and non-safety-related components; more stringent requirements are applied to the safety-critical aspects of the system. The scope of s process is the safety-related system, which is the portion of the system that is responsible for helping ensure that the overall system operates in a safe manner. The content of all of the standards discussed in this section includes both guidelines and requirements. A side-by-side comparison

8 of the standards shows that the level of detail in the standards, including both guidance and requirements is highest in. DEF-STAN contains the next highest level of detail, followed by MIL-STD-882C. MIL-STD-882D contains the lowest level of detail with respect to guidance and requirements. The level of information contained in and DEF-STAN make them useful references in applying any system safety process. Regula - tions System/SW Process DEF-STAN Mechanical Electrical/ Electronics - Std - DEF STAN Std Reliability Software Figure 7: Standard's Categorizations. Standard Scope Content Detail MIL-STD-882C Whole System Guidelines & Medium MIL-STD-882D Whole System Guidelines & Low DEF-STAN Whole System Guidelines & High -related Guidelines & System Highest Table 1: Standard's comparisons RELEVANT SOFTWARE SAFETY STANDARDS A key component of advanced automotive systems is software. Though software itself cannot fail or wear out, its complexity coupled with its interactions with the system and environment can directly and indirectly lead to potential system hazards. As such, software safety cannot be considered apart from system safety, but the unique aspects of software warrant its own set of guidelines and standards. A number of software safety standards and guidelines documents exist today. These documents come from various organizations, including the National Aeronautics and Space Administration (NASA), the DOD, the MOD, the IEC, the Institute for Electrical and Electronics Engineers (IEEE), the Motor Industry Software Reliability Association (MISRA), and the Radio Technical Commission for Aeronautics (RTCA). This section will focus on the MISRA guidelines, the RTCA/DO-178B standard, the MOD Defence Standard 00-55, and -3. MISRA GUIDELINES In the 1990 s, a consortium called MISRA was formed in response to the UK Critical Systems Research Programme. The consortium consisted of eight controlling members (organizations) associated with the automotive industry, four consultants, and a project manager. Initially, the consortium conducted a survey of existing work in the automotive sector, as well as in other industrial sectors. From this initial work, eight subgroups were formed to study specific issues relating to automotive software. These areas included diagnostics and integrated vehicle systems, integrity, noise, EMC and real-time, software in control systems, software metrics, verification and validation, subcontracting of automotive software, and human factors in software development. Each respective group generated a report containing detailed information and recommendations for each of the eight areas. The reports are summarized in another document, Development Guidelines for Vehicle Based Software. The MISRA guidelines were developed voluntarily to benefit both the industry and the public, and as such, they do not constitute requirements or standards that must be adhered to. Rather, they are guidelines to be adopted or used on a voluntary basis. The summary report contains information on the software lifecycle, including information on project planning, integrity, requirements specification, design, programming, testing, and product support, and information on software quality planning, including management responsibilities, quality assurance, documentation requirements, and subcontracting. In addition, the summary report contains a section on emerging technologies with short overviews on neural networks, object orientation, fuzzy logic, and formal mathematical methods. The document does not provide an overall process for software safety that can be followed, however, it does provide a good overview of some of the issues that need to be addressed when developing vehicle based software, and it also provides some good recommendations. The summary report should be used in conjunction with the more detailed individual reports to gain a better understanding of the issues and to gain an understanding for the reasons behind the recommendations. We will not discuss in detail all of the reports mentioned above. However, Report 2 on Integrity contains some important information that we will address. Report 2 describes three approaches for determining the integrity associated with an ECU: the standards based approach, the controllability approach, and the pragmatic approach. The standards based approach describes a method for determining integrity level that is based on existing generic computer system standards (IEC SC65A (Secretariat) 123, Interim Defence Standard 00-56, and DIN V19250). Risk is defined as a combination of the severity of events and the probability of occurrence of events (or combinations of events) that may lead to a potential hazard. In the controllability approach, five controllability categories are identified. These categories range from nuisance only, where safety is not considered to be affected, to uncontrollable, where the effects of a failure

9 are not controllable by the vehicle occupants and which will most likely lead to severe outcomes which cannot be influenced by a human response. Directly related to the five controllability categories are five levels of integrity that range from integrity level 0 to integrity level 4. Following the requirements to achieve integrity level 0 gives confidence that the likelihood of a nuisance only failure occurring is no worse than reasonably possible. Following the requirements to achieve integrity level 4 gives confidence that the likelihood of uncontrollable failures is extremely improbable. The third approach, the pragmatic approach, also contains five integrity levels, but these levels are approached qualitatively by associating each level with a given severity. Integrity level 4 is required to avoid disastrous accidents which are unlikely to be a feature of road travel unless certain mass transit concepts/situations apply, and integrity level 0 is required when there is no risk to persons; integrity level 0 essentially represents the don t care condition. The approach recommended by MISRA for the automotive industry is the controllability approach, since this approach recognizes that in an automotive system failure scenario, there is some loss of control between the occurrence of a failure and the resulting mishap, and that it is possible for a person to perform some action or actions to help avoid or mitigate the effects of the initial hazard before it leads to a mishap. MISRA C GUIDELINES In addition to the above, MISRA recognized that the trend in a programming language for embedded automotive systems was toward the C programming language. They also recognized that C has potential pitfalls and insecurities. Recognizing that C will be used in developing embedded automotive systems in spite of these issues, MISRA developed a set of Guidelines for the use of the C Language in Vehicle Based Software. The guidelines state that the full C language should not be used in safety-related systems, and they set forth a subset of C that is intended to be suitable for use in embedded automotive systems up to and including safety integrity level 3 as described in the MISRA guidelines summary report and in report 2. integrity level 3 is associated with controllability category difficult to control which is defined in terms of failures whose effects are not normally controllable by the vehicle occupants, but could be influenced by a mature human response under favorable circumstances. This category is likely to lead to very severe outcomes. Following the requirements to achieve level 3 gives confidence that the likelihood of a difficult to control failure occurring is very remote. The document contains a description of the MISRA C subset, the reasons why a subset is required, and guidance on how to use the subset. The MISRA C subset is described as a list of rules with justifications and examples. Each rule is classified either as required or advisory. Required rules are mandatory, whereas advisory rules should normally be followed, but do not have to be followed. There are commercial tools available that can be used to check compliance with the rules set forth in this document. RTCA/DO-178B The standard RTCA/DO-178B, Software Considerations in Airborne Systems and Equipment Certification, provides guidelines for determining that the software aspects of airborne systems and equipment comply with airworthiness criteria. The standard applies to all aircraft manufacturers and their suppliers. The standard describes the software planning process, the software development process, and integral processes which are performed to help ensure the correctness, control, and confidence of the other processes and their outputs. Software development guidelines are included for the software requirements, design, coding, and integration processes. Integral processes include the software verification, configuration management, quality assurance, and certification liaison processes. System aspects relating to software development and defining the information flow between system and software life cycle processes are given emphasis. The main reason for this is for safety and verification matters. Five categories are used to describe hazard severity: catastrophic, hazardous/severe-major, major, minor, and no effect. Software is classified as one of five levels corresponding to the five hazard severity categories, from level A (catastrophic) to level E (no effect). The classifications are made as software whose anomalous behavior would cause or contribute to a failure of system function resulting in a catastrophic / hazardous / major / minor failure condition for the aircraft, or have no effect. The software classifications provided in this document are not easily transferable to the automotive domain, however, the document contains much useful information regarding the software development process for safety-critical software. MOD DEF STAN MOD Defence Standard is divided into two parts; part 1 contains requirements and part 2 contains information and guidance on the requirements in part 1. DEF STAN describes the for Related Software in Defence Equipment. Software is classified into one of four Integrity Levels (S1, S2, S3, or S4), with S4 being the highest safety integrity level; the definition of safety integrity level here, is not the same as the definition of safety integrity level in the MISRA guidelines. integrity requirements of the safety related software components are determined by means of a preliminary hazard analysis and safety analysis done in accordance with DEF STAN DEF STAN specifies the requirements for all safety related software used in defense equipment. related software is software that relates to a safety function or system and is of any of the four safety integrity levels. In this standard, software that relates to

10 a safety critical function or system, is safety critical software. critical software is software of the highest safety integrity level (S4), in that the failure of it could cause the highest risk to human life. DEF STAN places emphasis on describing the procedures necessary for specification, design, coding, production, and in-service maintenance and modification of S4 software, i.e., safety critical software. The requirements for producing S4 software and for assuring that the required safety integrity level has been achieved are more rigorous than those required for lower safety integrity levels. A less rigorous approach to the interpretation of some clauses contained in DEF STAN part 1 may be acceptable for lower safety integrity levels (S1, S2, and S3), but the decisions must be justified. Attributes illustrative of the topics that need to be considered for computer based applications when determining appropriate rules and techniques are tabularized in Table 3 of DEF STAN part 2. For example, for requirements and design specifications, the rules and techniques assigned in the table indicate that they should be formal (mathematical) for S4 and semiformal for S3. Annex D of DEF STAN part 2 provides detailed tailoring guidelines for all safety integrity levels, S1 to S4, with respect to the clauses in the standard. For certain clauses and integrity levels, the standard allows for justification to be used to not follow part or all of the particular clause. For all safety integrity levels, a safety case is required that uses objective evidence to present an organized and reasoned justification that the software does or will satisfy the safety aspects of the software requirements. The level of information provided in this standard makes it a useful reference in applying any system safety process. -3 Part 3 of describes the software requirements of the standard and is to be used only after a thorough understanding of -1 and This document applies to any software forming part of or used to develop a safety related system as described within the scope of parts 1 and 2. Use of this standard requires that the software safety functions and software SIL s are specified either as part of the specification of the safety-related system in -2, or in the application of this standard. A software SIL may be determined using qualitative techniques described in part 5. The level of analysis detail required is dependent on the determined software SIL. When the software is to implement safety functions of differing safety integrity levels, all of the software shall be treated as belonging to the highest safety integrity level unless it can be shown in the design that there is adequate independence between the safety functions of the different safety integrity levels. -3 includes requirements for safety lifecycle phases and activities to be applied during the design and development of the safety related software, and requirements for software safety validation to be passed by the organization responsible for system integration. The document also includes requirements for support tools such as certified compilers and operating systems. Annex A of -3 contains a tabularized guide to the selection of techniques and measures that are recommended in varying degrees (highly recommended, recommended, not recommended, and no recommendation) for each of the SIL s. Annex B contains more detailed tables that expand upon some of the entries in the tables in Annex A. -7 contains overviews of the specific techniques and measures cited in the tables of Annexes A and B. The level of information provided in this document makes it a useful reference in applying any system safety process. UL 1998 UL 1998, Standard For : Software In Programmable Components, was developed by Underwriters Laboratories to apply to software-controlled embedded systems whose failure could result in risk of injury to persons or loss of property. This standard mainly provides guidance on different software techniques that can be used to help mitigate controller hardware failure modes. There is no specific guidance provided regarding how to implement a safety program. SOFTWARE STANDARDS CATEGORIZATIONS AND COMPARISONS The MISRA guidelines are most closely applicable to the automotive industry since they were specifically created for the automotive domain. However, there are generic aspects related to software that are common among the various software standards/guidelines and that could be adapted to apply to the automotive domain. These include concepts related to all areas of the software lifecycle (planning, development, verification, configuration management, etc.), concepts related to safety analysis and determining a criticality or integrity level of software, etc. A good approach is to consider multiple standards/guidelines and adopt the aspects from each standard that will be most beneficial to the particular task at hand. This may change depending on the varying constraints of the system under development, or the phase of development the system is currently in. It would be good practice to tailor a general overall software safety process to each specific project. The different standards/guidelines use different definitions for classifying the criticality or integrity level of the software. In developing an organizational software safety process one scheme should be chosen and used on a consistent basis, rather than using different schemes throughout the organization or on different projects. Figure 8 adds the Software Standards to the standard s categorization framework. Table 2 provides a comparison of the Software Standards and Guidelines. In the Table, SRSW refers to -Related Software and SWHC refers to Software Controls. MISRA and RTCA/DO-178B apply to all of the software

11 in a system, whereas -3 applies to software contained in the safety-related system associated with the overall system, and DEF STAN applies to safety related software in the overall system. UL-1998 contains information on software hazard controls that can be applied, but no general information on software. All of the standards provide a high level of detail with respect to their different scopes. MISRA is not a standard, so it contains only guidelines and suggestions. Though MISRA does not spell out a software safety process, the information contained in it is useful for developing one. A good software safety process depends on a good underlying software development process. RTCA/DO-178B contains guidelines and some requirements. Both -3 and DEF STAN contain requirements and guidelines. The information contained in RTCA/DO-178B, -3, and DEF STAN relates to a software safety process. UL consists solely of requirements and does not include information for a software safety process. Faithful adherence to all of the requirements of software safety standards is challenging. Regula - tions System/SW Process DEF STAN DEF STAN DO - 178B MISRA Mechanical Electrical/ Software Electronics UL Std - DO - 178B DEF STAN Reliability MISRA Figure 8: Standard's Categorization. Standard Scope Content Detail SW Process MISRA All SW G High Helps RTCA/DO-178B All SW G (R) High Yes -3 SRSW R/G High Yes DEF STAN SRSW R/G High Yes UL-1998 SWHC R High No Table 2: Software standards comparisons RELEVANT GOVERNMENT STANDARDS In the United States, the National Highway Traffic Administration (NHTSA) has authority to set and enforce safety performance standards for motor vehicles and motor vehicle equipment. NHTSA, part of the U.S. Department of Transportation, was established by the Highway Act of NTSHA has developed a number of Federal Motor Vehicle Standards (FMVSS) to which manufacturers of motor vehicle and equipment items must conform and certify compliance. Canada also has a nearly identical set of safety standards (CMVSS), and the term MVSS is often used to refer to both collectively. In Europe, motor vehicle safety standards have been developed by both the European Economic Community (EEC) and the Economic Commission for Europe (ECE). The EEC, also known as the European Union, is comprised of mostly western European countries. The Economic Commission for Europe (ECE), is a United Nations organization with a wider membership than just western European countries. In the area of brake regulations, the ECE typically develops regulations first and the EEC follows their lead. Since the ECE has a wider membership, its regulations can be considered more readily acceptable over all European countries than EEC regulations. Table 3, Table 4, and Table 5 provide a summary of government regulations and standards most relevant to steer-by-wire and brake-by-wire systems. MVSS 135, for example, specifies brake performance requirements for both a fully functional system and a braking system with one circuit failed. During GMs development of the EV1 vehicle, which had electric rear brakes, NHTSA released MVSS 135 to supercede MVSS 105, which did not adequately cover the safety needs of electronic braking systems. In a similar manner, the ECE is working on regulation revisions necessary to allow by-wire vehicles in Europe. RELEVANT ANALYSIS STANDARDS Although there are many different potential analysis techniques that can be applied to help ensure the safety of a system [6], the following analysis techniques are applicable to many automotive safety critical systems: Preliminary HAZOP FMEA Fault Tree Common Cause Preliminary hazard analysis is a quick hazard analysis performed at the beginning of the product development process to identify the potential hazards of a system. and Operability (HAZOP) analysis is a structured analysis technique for identifying potentially hazardous deviations from design intent that could occur. Failure Modes and Effects (FMEA) is an inductive (bottom-up) technique to identify potential failure modes and their associated effects on the system being developed. Fault tree analysis is a deductive (top-down) technique for determining the possible cause of potential system hazards. Common cause analysis attempts to identify situations characterized by two or more component fault states that exist simultaneously and have the same cause. Table 6 shows applicable standards for these analysis techniques. Of these, the most commonly used subset in the automotive industry consists of the FMEA guidelines published by the following groups: The Automotive Industry Action Group (AIAG), which is comprised of the US automakers, and

12 works to establish common methods for the US automotive industry. The German Association of the Automotive Industry (VDA), which is comprised of automotive manufactures and their suppliers, and works to establish common methods for the German automotive industry. The Society of Automotive Engineers, an international organization devoted to the development of automotive standards and the exchange of information. The SAE and AIAG FMEA standards are practically identical, but the AIAG often publishes new revisions first. Identification Document Title APPLICATION MVSS 135 Standard No. 135 Light Vehicle Brake Systems North America MVSS 106 Motor Vehicle Standard NO. 106 Brake North America Hoses MVSS 116 Motor Vehicle Standard NO. 116 Motor North America Vehicle Brake Fluids ECE R13.09 Economic Commission for Europe Brake Regulations Europe ECE R90 Economic Commission for Europe Brake Linings Regulations (required by ECE Europe R13.09) ECE R64 Spare tire brake standard (required by ECE R13.09) Europe R13-H Harmonized MVSS135 & ECE R13.09 Brake Japan Regulations ADR 31/00 Australian brake regulations Australia Table 3: Applicable Braking Standards and Regulations. Identification Document Title Application MVSS 203 Standard No. 203 Impact Protection for the Driver from North America the Steering Control System MVSS 204 Standard No. 204 Steering Control Rearward Displacement North America Commission Directive 92/62/EEC of July Adapting to Technical Progress EEC Directive Council Directive 70/311/EEC 92/62/EEC Relating to Steering Equipment Europe for Motor Vehicles and their Trailers ECE Economic Commission for Europe Steering Equipment Europe Regulations ECE/P/377 Proposed revision to ECE allowing steer-by-wire. Earliest approval is Jan 1, 2005 Europe Table 4: Applicable Steering Standards and Regulations. Identification Document Title Application MVSS 101 Standard No. 101 Controls and Displays North America Table 5: Other Applicable Standards and Regulations. Identification MOD DEF STAN MOD DEF STAN AIAG FMEA SAE J1739 VDA System- FMEA NUREG-0492 NUREG/CR Document Title Management for Defence Systems HAZOP Studies on Systems Containing Programmable Electronics Potential Failure Mode and Effects : FMEA Potential Failure Modes and Effects Reference Manual Quality Management in the Automobile Industry, Vol. 4 Fault Tree Handbook Procedures for Treating Common Cause Failures in and Reliability Studies Type Preliminary HAZOP FMEA FMEA FMEA Fault Tree Common Cause Table 6: Applicable Standards and Guidelines. Figure 9 shows the categorization of the Federal regulations and analysis standards added onto the standards framework figure. Regulations System/SW Process DEF STAN DEF STAN DO - 178B MISRA Mechanical Electrical/ Software FMVSS 135 Electronics UL Std - DEF STAN Reliability DO-178B MISRA SAE FMEA VDA FMEA NUREG 0492 FTA... Figure 9: Standards and regulations categorizations RECOMMENDATIONS Many system and software safety standards currently exist. These standards differ in their coverage of process and implementation, scope, detail, and content. They also have some commonalities. Many parts of the standards are applicable to the automotive domain. Faithful adherence to current software safety standards requirements is challenging. In addition to standards related to system and software safety, there are standards that apply to analysis techniques to provide consistency between analyses. There are also government regulations and standards that must be satisfied. A good system safety standard can provide a system safety process to facilitate the identification of and adherence to relevant process and analysis standards, and to relevant government regulations and standards. It is Delphi s recommendation that the automotive industry move toward a common process for developing safety-critical automotive systems such as x-by-wire systems. This

13 can be achieved by applying a common subset of the standards identified in this paper. REFERENCES 1. S. Buckley and K. Johnson, Concepts Designed to Enhance the Customer s Driving Experience, Proceedings, SAE International Congress on Transportation Electronics, C031, Oct , S. Amberkar et. al., A System Process for By-Wire Automotive Systems, in Design and Technologies for Automotive -Critical Systems SP-1507, Society of Automotive Engineers, Inc., 2000, pp N. J. Bahr, System Engineering and Risk Assessment: A Practical Approach, Taylor and Francis, Wash. DC, P. L. Goddard, "Automotive Embedded Computing: The Current Non-Fault-Tolerant Baseline for Embedded Systems", in Proc Workshop on Embedded Fault-Tolerant Systems, pp , May M. Allocco, G. McIntyre, and S. Smith, "The Application of System Tools, Processes, and Methodologies within the FAA to Meet Future Aviation Challenges", in Proc. 17th International System Conference, pp. 1-9, System Handbook, 2 nd Ed., System Society, 1997 CONTACT Barbara J. Czerny, Delphi Corporation, barbara.j.czerny@delphiauto.com

A System-Safety Process For By-Wire Automotive Systems

A System-Safety Process For By-Wire Automotive Systems SAE TECHNICAL PAPER SERIES 2000-01-1056 A System-Safety Process For By-Wire Automotive Systems Sanket Amberkar, Joseph G. D Ambrosio and Brian T. Murray Delphi Automotive Systems Joseph Wysocki HRL Laboratories

More information

A System-safety process for by-wire automotive systems

A System-safety process for by-wire automotive systems A System-safety process for by-wire automotive systems Steer-by-wire and other by-wire systems (as defined in this article) offer many passive and active safety advantages. To help ensure these advantages

More information

Dr. Brian Murray March 4, 2011

Dr. Brian Murray March 4, 2011 Event that could lead to an accident GM Autonomy HAZARD 1 Q=6e-7 Event that could lead to a hazard Control to prevent HAZARDOUS EVENT 1 HAZARDOUS EVENT 1 HAZARD CONTROL 1 r=6e-008 Q=0.0006 Q=0.001 Q=0.001

More information

2005-01-0785. Effective Application of Software Safety Techniques for Automotive Embedded Control Systems SAE TECHNICAL PAPER SERIES

2005-01-0785. Effective Application of Software Safety Techniques for Automotive Embedded Control Systems SAE TECHNICAL PAPER SERIES 2005-01-0785 SAE TECHNICAL PAPER SERIES Effective Application of Software Safety Techniques for Automotive Embedded Control Systems Barbara J. Czerny, Joseph G. D Ambrosio, Brian T. Murray and Padma Sundaram

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

Space project management

Space project management ECSS-M-ST-80C Space project management Risk management ECSS Secretariat ESA-ESTEC Requirements & Standards Division Noordwijk, The Netherlands Foreword This Standard is one of the series of ECSS Standards

More information

University of Paderborn Software Engineering Group II-25. Dr. Holger Giese. University of Paderborn Software Engineering Group. External facilities

University of Paderborn Software Engineering Group II-25. Dr. Holger Giese. University of Paderborn Software Engineering Group. External facilities II.2 Life Cycle and Safety Safety Life Cycle: The necessary activities involving safety-related systems, occurring during a period of time that starts at the concept phase of a project and finishes when

More information

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

Certification Authorities Software Team (CAST) Position Paper CAST-9 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

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

Session 4. System Engineering Management. Session Speaker : Dr. Govind R. Kadambi. M S Ramaiah School of Advanced Studies 1

Session 4. System Engineering Management. Session Speaker : Dr. Govind R. Kadambi. M S Ramaiah School of Advanced Studies 1 Session 4 System Engineering Management Session Speaker : Dr. Govind R. Kadambi M S Ramaiah School of Advanced Studies 1 Session Objectives To learn and understand the tasks involved in system engineering

More information

Interrelationship with other "Ability Engineering" and Logistics Groups

Interrelationship with other Ability Engineering and Logistics Groups Reliability and Maintainability Programs General This section introduces high level considerations associated with the implementation of Reliability, Availability, Maintainability, Safety (RAMS) and Logistics

More information

Safety Management Systems (SMS) guidance for organisations

Safety Management Systems (SMS) guidance for organisations Safety and Airspace Regulation Group Safety Management Systems (SMS) guidance for organisations CAP 795 Published by the Civil Aviation Authority, 2014 Civil Aviation Authority, CAA House, 45-59 Kingsway,

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

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

SUCCESSFUL INTERFACE RISK MANAGEMENT FROM BLAME CULTURE TO JOINT ACTION

SUCCESSFUL INTERFACE RISK MANAGEMENT FROM BLAME CULTURE TO JOINT ACTION SUCCESSFUL INTERFACE RISK MANAGEMENT FROM BLAME CULTURE TO JOINT ACTION SUMMARY Axel Kappeler, Principal James Catmur, Director Interfaces are important because they are everywhere. However, interfaces

More information

Software-based medical devices from defibrillators

Software-based medical devices from defibrillators C O V E R F E A T U R E Coping with Defective Software in Medical Devices Steven R. Rakitin Software Quality Consulting Inc. Embedding defective software in medical devices increases safety risks. Given

More information

Frequently Asked Questions

Frequently Asked Questions Frequently Asked Questions The exida Certification Program Functional Safety (SIL) Cyber-Security V2 R3 June 14, 2012 exida Sellersville, PA 18960, USA, +1-215-453-1720 Munich, Germany, +49 89 4900 0547

More information

AEROSPACE STANDARD. Quality Management Systems - Requirements for Aviation, Space and Defense Organizations RATIONALE

AEROSPACE STANDARD. Quality Management Systems - Requirements for Aviation, Space and Defense Organizations RATIONALE AEROSPACE STANDARD AS9100C Issued 1999-11 Revised 2009-01 Superseding AS9100B Quality Management Systems - Requirements for Aviation, Space and Defense Organizations RATIONALE This standard has been revised

More information

ISO 26262 Functional Safety Draft International Standard for Road Vehicles: Background, Status, and Overview

ISO 26262 Functional Safety Draft International Standard for Road Vehicles: Background, Status, and Overview ISO 26262 Functional Safety Draft International Standard for Road Vehicles: Background, Status, and Overview Barbara J. Czerny, Joseph D Ambrosio, Rami Debouk, General Motors Research and Development Kelly

More information

Design of automatic testing tool for railway signalling systems software safety assessment

Design of automatic testing tool for railway signalling systems software safety assessment Risk Analysis VI 513 Design of automatic testing tool for railway signalling systems software safety assessment J.-G. Hwang 1, H.-J. Jo 1 & H.-S. Kim 2 1 Train Control Research Team, Korea Railroad Research

More information

Controlling Risks Safety Lifecycle

Controlling Risks Safety Lifecycle Controlling Risks Safety Lifecycle Objective Introduce the concept of a safety lifecycle and the applicability and context in safety systems. Lifecycle Management A risk based management plan for a system

More information

Reaching CMM Levels 2 and 3 with the Rational Unified Process

Reaching CMM Levels 2 and 3 with the Rational Unified Process Reaching CMM Levels 2 and 3 with the Rational Unified Process Rational Software White Paper TP174 Table of Contents INTRODUCTION... 1 LEVEL-2, REPEATABLE... 3 Requirements Management... 3 Software Project

More information

ASSESSMENT OF THE ISO 26262 STANDARD, ROAD VEHICLES FUNCTIONAL SAFETY

ASSESSMENT OF THE ISO 26262 STANDARD, ROAD VEHICLES FUNCTIONAL SAFETY ASSESSMENT OF THE ISO 26262 STANDARD, ROAD VEHICLES FUNCTIONAL SAFETY Dr. Qi Van Eikema Hommes SAE 2012 Government/Industry Meeting January 25, 2012 1 Outline ISO 26262 Overview Scope of the Assessment

More information

Safety Regulation Group SAFETY MANAGEMENT SYSTEMS GUIDANCE TO ORGANISATIONS. April 2008 1

Safety Regulation Group SAFETY MANAGEMENT SYSTEMS GUIDANCE TO ORGANISATIONS. April 2008 1 Safety Regulation Group SAFETY MANAGEMENT SYSTEMS GUIDANCE TO ORGANISATIONS April 2008 1 Contents 1 Introduction 3 2 Management Systems 2.1 Management Systems Introduction 3 2.2 Quality Management System

More information

A Methodology for Safety Critical Software Systems Planning

A Methodology for Safety Critical Software Systems Planning A Methodology for Safety Critical Software Systems Planning EHAB SHAFEI 1, IBRAHIM F. MOAWAD 2, HANY SALLAM 1, ZAKI TAHA 3, MOSTAFA AREF 3 1 Operation Safety and Human Factors Department, 2 Information

More information

Failure Analysis Methods What, Why and How. MEEG 466 Special Topics in Design Jim Glancey Spring, 2006

Failure Analysis Methods What, Why and How. MEEG 466 Special Topics in Design Jim Glancey Spring, 2006 Failure Analysis Methods What, Why and How MEEG 466 Special Topics in Design Jim Glancey Spring, 2006 Failure Analysis Methods Every product or process has modes of failure. An analysis of potential failures

More information

Safety Integrity Levels

Safety Integrity Levels Séminaire de Sûreté de Fonctionnement de l X Safety Integrity Levels Antoine Rauzy École Polytechnique Agenda Safety Integrity Levels and related measures as introduced by the Standards How to interpreted

More information

Systems Assurance Management in Railway through the Project Life Cycle

Systems Assurance Management in Railway through the Project Life Cycle Systems Assurance Management in Railway through the Project Life Cycle Vivian Papen Ronald Harvey Hamid Qaasim Peregrin Spielholz ABSTRACT Systems assurance management is essential for transit agencies

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

IEC 61508 Overview Report

IEC 61508 Overview Report IEC 61508 Overview Report A Summary of the IEC 61508 Standard for Functional Safety of Electrical/Electronic/Programmable Electronic Safety-Related Systems exida Sellersville, PA 18960, USA +1-215-453-1720

More information

Understanding Safety Integrity Levels (SIL) and its Effects for Field Instruments

Understanding Safety Integrity Levels (SIL) and its Effects for Field Instruments Understanding Safety Integrity Levels (SIL) and its Effects for Field Instruments Introduction The Industrial process industry is experiencing a dynamic growth in Functional Process Safety applications.

More information

IBM Rational Rhapsody

IBM Rational Rhapsody IBM Rational Rhapsody IBM Rational Rhapsody Reference Workflow Guide Version 1.9 License Agreement No part of this publication may be reproduced, transmitted, stored in a retrieval system, nor translated

More information

Rigorous Methods for Software Engineering (F21RS1) High Integrity Software Development

Rigorous Methods for Software Engineering (F21RS1) High Integrity Software Development Rigorous Methods for Software Engineering (F21RS1) High Integrity Software Development Andrew Ireland Department of Computer Science School of Mathematical and Computer Sciences Heriot-Watt University

More information

Space Project Management

Space Project Management EUROPEAN COOPERATION FOR SPACE STANDARDIZATION Space Project Management Configuration Management Secretariat ESA ESTEC Requirements & Standards Division Noordwijk, The Netherlands Published by: Price:

More information

ISO 9001:2008 Quality Management System Requirements (Third Revision)

ISO 9001:2008 Quality Management System Requirements (Third Revision) ISO 9001:2008 Quality Management System Requirements (Third Revision) Contents Page 1 Scope 1 1.1 General. 1 1.2 Application.. 1 2 Normative references.. 1 3 Terms and definitions. 1 4 Quality management

More information

SAFETY LIFECYCLE WORKBOOK FOR THE PROCESS INDUSTRY SECTOR

SAFETY LIFECYCLE WORKBOOK FOR THE PROCESS INDUSTRY SECTOR SAFETY LIFECYCLE WORKBOOK FOR THE PROCESS INDUSTRY SECTOR SAFETY LIFECYCLE WORKBOOK FOR THE PROCESS INDUSTRY SECTOR The information and any recommendations that may be provided herein are not intended

More information

Copyright 2014 Carnegie Mellon University The Cyber Resilience Review is based on the Cyber Resilience Evaluation Method and the CERT Resilience

Copyright 2014 Carnegie Mellon University The Cyber Resilience Review is based on the Cyber Resilience Evaluation Method and the CERT Resilience Copyright 2014 Carnegie Mellon University The Cyber Resilience Review is based on the Cyber Resilience Evaluation Method and the CERT Resilience Management Model (CERT-RMM), both developed at Carnegie

More information

Medical Device Software Standards for Safety and Regulatory Compliance

Medical Device Software Standards for Safety and Regulatory Compliance Medical Device Software Standards for Safety and Regulatory Compliance Sherman Eagles +1 612-865-0107 seagles@softwarecpr.com www.softwarecpr.com Assuring safe software SAFE All hazards have been addressed

More information

Title: Basic Principles of Risk Management for Medical Device Design

Title: Basic Principles of Risk Management for Medical Device Design Title: Basic Principles of Risk Management for Medical Device Design WHITE PAPER Author: Ganeshkumar Palanichamy Abstract Medical devices developed for human application are used for diagnostic or treatment

More information

How to Upgrade SPICE-Compliant Processes for Functional Safety

How to Upgrade SPICE-Compliant Processes for Functional Safety How to Upgrade SPICE-Compliant Processes for Functional Safety Dr. Erwin Petry KUGLER MAAG CIE GmbH Leibnizstraße 11 70806 Kornwestheim Germany Mobile: +49 173 67 87 337 Tel: +49 7154-1796-222 Fax: +49

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

Title: Rio Tinto management system

Title: Rio Tinto management system Standard Rio Tinto management system December 2014 Group Title: Rio Tinto management system Document No: HSEC-B-01 Standard Function: Health, Safety, Environment and Communities (HSEC) No. of pages: 23

More information

Space product assurance

Space product assurance Space product assurance Software dependability and safety ECSS Secretariat ESA-ESTEC Requirements & Standards Division Noordwijk, The Netherlands Foreword This Handbook is one document of the series of

More information

Designing an Effective Risk Matrix

Designing an Effective Risk Matrix Designing an Effective Risk Matrix HENRY OZOG INTRODUCTION Risk assessment is an effective means of identifying process safety risks and determining the most cost-effective means to reduce risk. Many organizations

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

Understanding the Use, Misuse and Abuse of Safety Integrity Levels 1

Understanding the Use, Misuse and Abuse of Safety Integrity Levels 1 Understanding the Use, Misuse and Abuse of Safety Integrity Levels 1 Felix Redmill Redmill Consultancy Email: Felix.Redmill@ncl.ac.uk Abstract Modern standards on system safety employ the concept of safety

More information

Frequently Asked Questions

Frequently Asked Questions Frequently Asked Questions The exida 61508 Certification Program V1 R8 October 19, 2007 exida Geneva, Switzerland Sellersville, PA 18960, USA, +1-215-453-1720 Munich, Germany, +49 89 4900 0547 1 Exida

More information

LSST Hazard Analysis Plan

LSST Hazard Analysis Plan LSST Hazard Analysis Plan Large Synoptic Survey Telescope 950 N. Cherry Avenue Tucson, AZ 85719 www.lsst.org 1. REVISION SUMMARY: Contents 1 Introduction... 5 2 Definition of Terms... 5 2.1 System... 5

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

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

Software in safety critical systems

Software in safety critical systems Software in safety critical systems Software safety requirements Software safety integrity Budapest University of Technology and Economics Department of Measurement and Information Systems Definitions

More information

SAFETY LIFE-CYCLE HOW TO IMPLEMENT A

SAFETY LIFE-CYCLE HOW TO IMPLEMENT A AS SEEN IN THE SUMMER 2007 ISSUE OF... HOW TO IMPLEMENT A SAFETY LIFE-CYCLE A SAFER PLANT, DECREASED ENGINEERING, OPERATION AND MAINTENANCE COSTS, AND INCREASED PROCESS UP-TIME ARE ALL ACHIEVABLE WITH

More information

REQUIREMENTS FOR SAFETY RELATED SOFTWARE IN DEFENCE EQUIPMENT

REQUIREMENTS FOR SAFETY RELATED SOFTWARE IN DEFENCE EQUIPMENT Ministry of Defence Defence Standard 00-55(PART 2)/Issue 2 1 August 1997 REQUIREMENTS FOR SAFETY RELATED SOFTWARE IN DEFENCE EQUIPMENT PART 2: GUIDANCE This Part 2 of Def Stan 00-55 supersedes INTERIM

More information

Controlling Risks Risk Assessment

Controlling Risks Risk Assessment Controlling Risks Risk Assessment Hazard/Risk Assessment Having identified the hazards, one must assess the risks by considering the severity and likelihood of bad outcomes. If the risks are not sufficiently

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

Design Verification. Introduction

Design Verification. Introduction Design verification is an essential step in the development of any product. Also referred to as qualification testing, design verification ensures that the product as designed is the same as the product

More information

ELECTROTECHNIQUE IEC INTERNATIONALE 61508-3 INTERNATIONAL ELECTROTECHNICAL

ELECTROTECHNIQUE IEC INTERNATIONALE 61508-3 INTERNATIONAL ELECTROTECHNICAL 61508-3 ª IEC: 1997 1 Version 12.0 05/12/97 COMMISSION CEI ELECTROTECHNIQUE IEC INTERNATIONALE 61508-3 INTERNATIONAL ELECTROTECHNICAL COMMISSION Functional safety of electrical/electronic/ programmable

More information

Software Testing Standards: Do They Know What They re Talking About?

Software Testing Standards: Do They Know What They re Talking About? Presentation Paper Bio Return to Main Menu P R E S E N T A T I O N T3 Thursday, Dec 7, 2000 Software Testing Standards: Do They Know What They re Talking About? Stuart Reid International Conference On

More information

Occupational safety risk management in Australian mining

Occupational safety risk management in Australian mining IN-DEPTH REVIEW Occupational Medicine 2004;54:311 315 doi:10.1093/occmed/kqh074 Occupational safety risk management in Australian mining J. Joy Abstract Key words In the past 15 years, there has been a

More information

HazLog: Tool support for hazard management

HazLog: Tool support for hazard management HazLog: Tool support for hazard management Christian Hamoy, David Hemer and Peter Lindsay School of Information Technology and Electrical Engineering The University of Queensland. Brisbane. Queensland

More information

Safety Issues in Automotive Software

Safety Issues in Automotive Software Safety Issues in Automotive Software Paolo Panaroni, Giovanni Sartori INTECS S.p.A. SAFEWARE 1 INTECS & Safety A very large number of safety software development, V&V activities and research project on

More information

CMS Policy for Configuration Management

CMS Policy for Configuration Management Chief Information Officer Centers for Medicare & Medicaid Services CMS Policy for Configuration April 2012 Document Number: CMS-CIO-POL-MGT01-01 TABLE OF CONTENTS 1. PURPOSE...1 2. BACKGROUND...1 3. CONFIGURATION

More information

Managing Design Changes using Safety-Guided Design for a Safety Critical Automotive System

Managing Design Changes using Safety-Guided Design for a Safety Critical Automotive System Managing Design Changes using Safety-Guided Design for a Safety Critical Automotive System by John Sgueglia B.S. Electrical Engineering Rochester Institute of Technology, 2000 SUBMITTED TO THE SYSTEM DESIGN

More information

Building a Safety Case in Compliance with ISO 26262 for Fuel Level Estimation and Display System

Building a Safety Case in Compliance with ISO 26262 for Fuel Level Estimation and Display System Building a Safety Case in Compliance with ISO 26262 for Fuel Level Estimation and Display System Master Thesis in Intelligent Embedded Systems School of Innovation, Design and Engineering Mälardalen University

More information

Functional Safety Hazard & Risk Analysis

Functional Safety Hazard & Risk Analysis Embedded - IC & Automation Fortronic Functional Safety Hazard & Risk Analysis MILANO - April, 23 rd 2013 CEFRIEL 2013; FOR DISCUSSION PURPOSES ONLY: ANY OTHER USE OF THIS PRESENTATION - INCLUDING REPRODUCTION

More information

Risk Management and the Impact of EN ISO 14971:2012 Annex Z

Risk Management and the Impact of EN ISO 14971:2012 Annex Z Risk Management and the Impact of EN ISO 14971:2012 Annex Z BSI 2014 Medical Device Mini-Roadshow Ibim Tariah Ph.D Technical Director, Healthcare Solutions Copyright 2014 BSI. All rights reserved. 1 Risk

More information

Criteria for Flight Project Critical Milestone Reviews

Criteria for Flight Project Critical Milestone Reviews Criteria for Flight Project Critical Milestone Reviews GSFC-STD-1001 Baseline Release February 2005 Approved By: Original signed by Date: 2/19/05 Richard M. Day Director, Independent Technical Authority

More information

Best Practices for Verification, Validation, and Test in Model- Based Design

Best Practices for Verification, Validation, and Test in Model- Based Design 2008-01-1469 Best Practices for Verification, Validation, and in Model- Based Design Copyright 2008 The MathWorks, Inc. Brett Murphy, Amory Wakefield, and Jon Friedman The MathWorks, Inc. ABSTRACT Model-Based

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

Introduction CHAPTER 1

Introduction CHAPTER 1 CHAPTER 1 Introduction Ever since the development of the first integrated circuits in the late 1950s the complexity of such devices doubled every 20 months. A development which has been anticipated by

More information

ISO 26262 Introduction

ISO 26262 Introduction ISO 26262 Introduction Prof. Christian Madritsch 2012 Table of Contents Structure of ISO 26262 Management of Functional Safety Product Development System Level Product Development Hardware Level Product

More information

SOFTWARE-IMPLEMENTED SAFETY LOGIC Angela E. Summers, Ph.D., P.E., President, SIS-TECH Solutions, LP

SOFTWARE-IMPLEMENTED SAFETY LOGIC Angela E. Summers, Ph.D., P.E., President, SIS-TECH Solutions, LP SOFTWARE-IMPLEMENTED SAFETY LOGIC Angela E. Summers, Ph.D., P.E., President, SIS-TECH Solutions, LP Software-Implemented Safety Logic, Loss Prevention Symposium, American Institute of Chemical Engineers,

More information

Software Safety Hazard Analysis

Software Safety Hazard Analysis UCRL-ID-122514 Software Safety Hazard Analysis Version 2.0 Prepared by J. Dennis Lawrence Prepared for U.S. Nuclear Regulatory Commission Disclaimer This document was prepared as an account of work sponsored

More information

Moving from BS 25999-2 to ISO 22301. The new international standard for business continuity management systems. Transition Guide

Moving from BS 25999-2 to ISO 22301. The new international standard for business continuity management systems. Transition Guide Transition Guide Moving from BS 25999-2 to ISO 22301 The new international standard for business continuity management systems Extract from The Route Map to Business Continuity Management: Meeting the

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

Value Paper Author: Edgar C. Ramirez. Diverse redundancy used in SIS technology to achieve higher safety integrity

Value Paper Author: Edgar C. Ramirez. Diverse redundancy used in SIS technology to achieve higher safety integrity Value Paper Author: Edgar C. Ramirez Diverse redundancy used in SIS technology to achieve higher safety integrity Diverse redundancy used in SIS technology to achieve higher safety integrity Abstract SIS

More information

Requirements-driven Verification Methodology for Standards Compliance

Requirements-driven Verification Methodology for Standards Compliance Requirements-driven Verification Methodology for Standards Compliance Serrie-justine Chapman (TVS) serrie@testandverification.com Mike Bartley (TVS) mike@testandverification.com Darren Galpin (Infineon)

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

The anglo american Safety way. Safety Management System Standards

The anglo american Safety way. Safety Management System Standards The anglo american Safety way Safety Management System Standards 2 The Anglo American Safety Way CONTENTS Introduction 04 Anglo American Safety Framework 05 Safety in anglo american 06 Monitoring and review

More information

Software Safety -- Process Overview and Application

Software Safety -- Process Overview and Application Software Safety -- Process Overview and Application Dr. Michael F. Siok, PE, ESEP Dr. Michael F. Siok, PE, ESEP Lockheed Martin Aeronautics Company P.O. Box 748, MZ 5924 Fort Worth, TX 76101 Tel: (817)

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

Guidance for Industry: Quality Risk Management

Guidance for Industry: Quality Risk Management Guidance for Industry: Quality Risk Management Version 1.0 Drug Office Department of Health Contents 1. Introduction... 3 2. Purpose of this document... 3 3. Scope... 3 4. What is risk?... 4 5. Integrating

More information

Announcement of a new IAEA Co-ordinated Research Programme (CRP)

Announcement of a new IAEA Co-ordinated Research Programme (CRP) Announcement of a new IAEA Co-ordinated Research Programme (CRP) 1. Title of Co-ordinated Research Programme Design and engineering aspects of the robustness of digital instrumentation and control (I&C)

More information

DEFENCE INSTRUCTIONS (GENERAL)

DEFENCE INSTRUCTIONS (GENERAL) DEFENCE INSTRUCTIONS (GENERAL) New instruction 0 LOG 4 5 012 Regulation of technical integrity of Australian Defence Force materiel Department of Defence CANBERRA ACT 2600 10 September 2010 Issued with

More information

IEC 61508 Functional Safety Assessment. Project: K-TEK Corporation AT100, AT100S, AT200 Magnetostrictive Level Transmitter.

IEC 61508 Functional Safety Assessment. Project: K-TEK Corporation AT100, AT100S, AT200 Magnetostrictive Level Transmitter. 61508 SIL 3 CAPABLE IEC 61508 Functional Safety Assessment Project: K-TEK Corporation AT100, AT100S, AT200 Magnetostrictive Level Transmitter Customer: K-TEK Corporation Prairieville, LA USA Contract No.:

More information

AS9100 B to C Revision

AS9100 B to C Revision AS9100 B to C Revision Key: Additions Deletions Clarifications 1.2 Application AS9100C Key Additions This standard is intended for use by organizations that design, develop and/or produce aviation, space

More information

Functional Safety Management: As Easy As (SIL) 1, 2, 3

Functional Safety Management: As Easy As (SIL) 1, 2, 3 Functional Safety Management: As Easy As (SIL) 1, 2, 3 Abstract This paper outlines the need for planning in functional safety management. Recent events such as the Montara blowout and the Deepwater Horizon

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

An integrated approach to implement system engineering and safety engineering processes: SASHA Project

An integrated approach to implement system engineering and safety engineering processes: SASHA Project An integrated approach to implement system engineering and safety engineering processes: SASHA Project Hycham Aboutaleb 1,2, Mohamed Bouali 1, Morayo Adedjouma 3, Emilia Suomalainen 1 1 Knowledge Inside,

More information

Intelligent development tools Design methods and tools Functional safety

Intelligent development tools Design methods and tools Functional safety Intelligent development tools Design methods and tools Functional safety Flanders DRIVE Index: Flanders DRIVE 1 Importance of functional safety 2 Functional safety for mechatronic systems 4 Global functional

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

Quality Risk Management Tools Quality Risk Management Tool Selection When to Select FMEA: QRM Tool Selection Matrix

Quality Risk Management Tools Quality Risk Management Tool Selection When to Select FMEA: QRM Tool Selection Matrix Quality Risk Management Tools Quality Risk Management Tool Selection When to Select FMEA: QRM Tool Selection Matrix 26 Quality Risk Management Tools The ICH Q9 guideline, Quality Risk Management, provides

More information

DRAFT REGULATORY GUIDE

DRAFT REGULATORY GUIDE U.S. NUCLEAR REGULATORY COMMISSION August 2012 OFFICE OF NUCLEAR REGULATORY RESEARCH Division 1 DRAFT REGULATORY GUIDE Contact: K. Sturzebecher (301) 251-7494 DRAFT REGULATORY GUIDE DG-1206 (Proposed Revision

More information

How To Write A Contract For Software Quality Assurance

How To Write A Contract For Software Quality Assurance U.S. Department of Energy Washington, D.C. NOTICE DOE N 203.1 Approved: Expires: 06-02-01 SUBJECT: SOFTWARE QUALITY ASSURANCE 1. OBJECTIVES. To define requirements and responsibilities for software quality

More information

Reduce Medical Device Compliance Costs with Best Practices. mark.pitchford@ldra.com

Reduce Medical Device Compliance Costs with Best Practices. mark.pitchford@ldra.com Reduce Medical Device Compliance Costs with Best Practices mark.pitchford@ldra.com 1 Agenda Medical Software Certification How new is Critical Software Certification? What do we need to do? What Best Practises

More information