Over the past 73 years the concept of Nuclear Weapon Detonation Safety within the United States has evolved from a simple Safing Plug, used on Little Boy and Fat Man, to the Stronglinks, Weaklinks, Barrier and collocation used today. This tutorial begins with a review of the worst Nuclear Weapon Accidents the United States has had over the past 73 years. From there it goes into the safety concepts and analysis techniques that were used up to the late 1960's. The briefings then explore the concepts of modern Nuclear Weapon Detonation Safety, i.e. Enhanced Nuclear Detonation Safety (ENDS).This presentation is known as the "Burned Board" briefing and is referenced in Eric Schlosser's book Command and Control.

After some general background on system safety and the motivation for its application an overview of a generic safety process (best suited for small to medium sized projects), in relation to the project lifecycle, is given. For each major project phase the respective safety process phase, safety objectives and some state of the art analysis techniques are explained. Special emphasis is put on a case study for the major steps of a safety analysis, including Functional Failure Modes and Effects Analysis and Fault Tree Analysis. The content of this tutorial is based on experience from an international working company.

A critical aspect of any system safety program entails the identification of hazards, assessment of the risks associated with the identified hazards, the determination of effective mitigations to control the risks to acceptable levels, and verifying and validating the implementation of those mitigations. The process required to successfully identify and mitigate hazards is an ongoing activity beginning as early in the design phase as practical and continuing throughout the project development phase, and often extending through the operational, maintenance and disposal phases. This class addresses: Hazard identification and documentation techniquesTechniques for developing effective risk mitigationsThe risk assessment process and examples of how to use the assessments to achieve safer systemsAn overview illustrating the need, capabilities and value of common hazard identification/characterization techniques.The role System Safety engineering in the overall project development processMetrics that can guide decisions concerning the question of "what is good enough?"Methods for evaluating the effectiveness of system safety programs.This class emphasizes interaction and interdependence of system safety with other safety related activities, such as OSHA compliance, Human Factors engineering, Quality Control and Reliability Engineering – highlighting the strengths and weaknesses of each field in achieving a safe system.Special attention will be given to address strengths and limitations of system safety efforts within a design team, explicitly identifying the importance of others in the team in achieving a safe system. Participants will be able to identify key steps to the identification of hazards and the development of systems of mitigations that are effective and affordable within the overall technical and cost constraints of the overall project. Course concentration will be upon tailored, specific, focused effort vs. generic system safety efforts.This class is a core class being presented and developed for repeated presentation by the ISSS as part of an ongoing curriculum and career development for system safety and will be a regular part of conference tracks.

A "thread analysis" is a method to ensure identified hazards are analyzed and controlled. Hazards analysis can be intimating – a mistake can literally be a life-or-death issue. What happens if a hazard is missed? What happens if a hazard is mistakenly characterized? What happens if a hazard isn't adequately controlled?This 6-hour PDC will be divided into thirds. The first section provides an overview of the entire hazards analysis process from start to finish. The instructors will present a unified method for the hazards identification, hazards screening, and hazards evaluation as well as control derivation, and control hierarchy analysis. The hazards analysis process will be revealed in clear and concise discussion. This PDC will be a discussion – bring problems, bring experience, and bring questions. The second portion will be a hands-on hazards identification, screening, and analysis with a real-world example. Participants will work in groups to identify hazards, brainstorm hazard events, associated consequences, and identify/assign controls/safeguards. The final portion is a hands-on completion of a qualitative risk analysis using standardized consequence and frequency tables with a defined qualitative risk matrix. The risk matrix will be used to provide a control hierarchy. The instructors will provide an understanding for the performance and value of a "thread analysis" to ensure a connection from start to finish of any hazard analysis. Participants will leave the PDC with the experience of practical application of performing a hazards analysis with a connected Hazards Identification Checklist, Screening Evaluation, Hazards Analysis Table, and Qualitative Risk Analysis. 

The topic addresses the interrelationships developed from Quality, Quality Control, and Quality Engineering, pursuing Specialty Engineering Roles and Relationships, including: Reliability, Maintainability, Supportability, Human Factors, Safety, and Security (Information Assurance) from an overview perspective. The tutorial is designed to be somewhat interactive presenting examples and questions to the audience related to the various topics discussed, thereby engaging and providing participants with insights to the various disciplines and how they relate within "Specialty Engineering" and insights into to the various disciplines which support and are adjunct to System Safety.

Model-Based Systems Engineering (MBSE) has gained momentum as the predominant method of analyzing and deriving system requirements as well as verifying and validating system performance. Over the years, several frameworks have gained prominence as approved methods and formal techniques to model systems. MBSE technology continues to gain popularity and growth within the Systems Engineering domain, especially in the markets of complex systems. To remain relevant within the context of concurrent engineering, it is advantageous for system safety engineer to learn how these techniques are affecting system design so that safety is addressed within system development. This paper provides an overview of MBSE in theory and practice and provides high-level details on how the system safety engineer can utilize these methods to provide the most optimum impact for affecting safety design.

In recent years, the importance of a strong, positive safety culture has been studied, discussed, and written about extensively. Safety culture has been defined as the product of individual and group values, attitudes, perceptions, competencies, and patterns of behavior that determine the commitment to, and the style and proficiency of, an organization's health and safety management. The safety culture of an organization is often considered in the context of prevention of accidents and injuries to the employees of that organization. This situation falls within the domain of occupational safety. In this context, the need for safety culture is relatively well understood and directly relatable to the members of the organization, since the beneficiaries are from the population itself. Safety cultures of organizations engaged in system safety work have some aspects in common with their counterparts in occupational safety; however, many aspects are different, since system safety aims to reduce safety risks throughout the life cycle of the product or system in question, and therefore, the beneficiaries of the improved safety culture may include not only the workers of the facility or organization producing the product or system, but also the end users (customers, operators), as well as the general public and the environment. When implementing a system safety program, an organization should work to ensure that a strong, positive safety culture pervades the organization. With a weak, non-existent, or even negative safety culture, the system safety practitioner's work is burdened, and the effectiveness of the system safety effort is reduced. On the other hand, when the system safety effort is undertaken in a strong safety culture, the entire team, including designers, developers, system engineers, testers, quality engineers, configuration control specialists, and management are all constructively contributing to system safety.

The tutorial provides a brief overview of the key historical events that have shaped the modern U.S. nuclear weapon system safety design philosophy, followed by a brief overview of the nuclear weapon safety process after which there is a focus on describing the nuclear safety design principles of incompatibility, isolation, and inoperability, and the way they are implemented. Key considerations include subtle aspects of the incompatibility and isolation design principles and techniques for developing and integrating multiple safety layers (a.k.a., subsystems) of safety features each having independent failure causes such that the resulting system safety can be asserted to meet stringent safety requirements in a predictable manner in all relevant environments.

This tutorial will be an update to a tutorial I have presented at the 2016, 2017 and 2018 ISSC. Topics presented include:Historical examples of inherently unsafe systems being made safe by the application of design features to mitigate hazardsDiscussion of the unique ways in which electronics and software can fail and cause system failureA few examples of catastrophic failures and a few examples where mitigations averted catastrophic failureBrief review of system safety basic concepts: hazards, risksExamples of electronics systems designed for safety: automotive, aircraft, spacecraft, autonomous vehiclesDesign techniques for highly dependable electronics: redundancy, standby systems, voting systems, fault-tolerant sensor and actuator designsSummary and conclusions

The tutorial provides a historical overview of key considerations that have shaped modern nuclear weapon safety philosophy and, in turn, weapon safety architectures. Key considerations include the concept of a 'wooden' bomb, insights gained from weapon accidents, the introduction of standardized probabilistic safety requirements, and the development of the simplifying concept of assured safety implemented using the nuclear safety design principles of isolation, incompatibility, and inoperability. The decision framework used to assert that requirements are met and the technical evidence needed to support these assertions are also discussed.

This tutorial aims to provide an introduction to the challenges and potential solution routes for the assurance of safety-related robotic and autonomous systems based on the Sense, Understand, Decide, Act (SUDA) characterization of autonomy. The workshop will introduce the background technologies for machine learning, such as neural nets. As well as providing practical hands-on experience of performing analysis on a small case study, the tutorial will also introduce current work of the Assuring Autonomy International Programme (based in York, UK) and some of the work of partner demonstrator projects.

A critical aspect of any system safety program entails the identification of hazards, assessment of the risks associated with the identified hazards, the determination of effective mitigations to control the risks to acceptable levels, and verifying and validating the implementation of those mitigations. The process required to successfully identify and mitigate hazards is an ongoing activity beginning as early in the design phase as practical and continuing throughout the project development phase, and often extending through the operational, maintenance and disposal phases. This class addresses: Hazard identification and documentation techniquesTechniques for developing effective risk mitigationsThe risk assessment process and examples of how to use the assessments to achieve safer systemsAn overview illustrating the need, capabilities and value of common hazard identification/characterization techniques.The role System Safety engineering in the overall project development processMetrics that can guide decisions concerning the question of "what is good enough?"Methods for evaluating the effectiveness of system safety programs.This class emphasizes interaction and interdependence of system safety with other safety related activities, such as OSHA compliance, Human Factors engineering, Quality Control and Reliability Engineering – highlighting the strengths and weaknesses of each field in achieving a safe system.Special attention will be given to address strengths and limitations of system safety efforts within a design team, explicitly identifying the importance of others in the team in achieving a safe system. Participants will be able to identify key steps to the identification of hazards and the development of systems of mitigations that are effective and affordable within the overall technical and cost constraints of the overall project. Course concentration will be upon tailored, specific, focused effort vs. generic system safety efforts.This class is a core class being presented and developed for repeated presentation by the ISSS as part of an ongoing curriculum and career development for system safety and will be a regular part of conference tracks.

A "thread analysis" is a method to ensure identified hazards are analyzed and controlled. Hazards analysis can be intimating – a mistake can literally be a life-or-death issue. What happens if a hazard is missed? What happens if a hazard is mistakenly characterized? What happens if a hazard isn't adequately controlled? This 6-hour PDC will be divided into thirds. The first section provides an overview of the entire hazards analysis process from start to finish. The instructors will present a unified method for the hazards identification, hazards screening, and hazards evaluation as well as control derivation, and control hierarchy analysis. The hazards analysis process will be revealed in clear and concise discussion. This PDC will be a discussion – bring problems, bring experience, and bring questions. The second portion will be a hands-on hazards identification, screening, and analysis with a real-world example. Participants will work in groups to identify hazards, brainstorm hazard events, associated consequences, and identify/assign controls/safeguards. The final portion is a hands-on completion of a qualitative risk analysis using standardized consequence and frequency tables with a defined qualitative risk matrix. The risk matrix will be used to provide a control hierarchy. The instructors will provide an understanding for the performance and value of a "thread analysis" to ensure a connection from start to finish of any hazard analysis. Participants will leave the PDC with the experience of practical application of performing a hazards analysis with a connected Hazards Identification Checklist, Screening Evaluation, Hazards Analysis Table, and Qualitative Risk Analysis. 

 With the increasing complexity of modern systems, traditional approaches to safety (most of which were created 50-70 years ago) are losing effectiveness and leading to avoidable losses. In this class, you will learn about a new approach based on systems theory and systems thinking. This approach and its tools, although relatively new, are now widely used in most industries, particularly automobiles, aviation, and defense and can handle very complex systems and so-called "systems of systems." The approach integrates safety and security. International standards have been created or are in progress.No prerequisites. The class will teach a new approach to safety engineering and thus should be understandable by anyone, even those without an extensive background in traditional safety engineering approaches. · Why accidents (losses) occur in complex, engineered systems · Handing complexity: Analytic Decomposition vs. Systems Theory · A top-down, integrated approach to analyzing and designing safety into complex systems containing hardware, software, and human components. · A new approach to investigating and analyzing losses called CAST (Causal Analysis based on System Theory) · A more powerful hazard analysis technique called STPA (System Theoretic Process Analysis)· Designing safety into systems from the beginning of the concept development process and using analysis to derive the functional safety and security design requirements and design process.· Safety Management and Safety Management Systems

System Safety is not a well-known field. When the word "engineering" is mentioned, words that come to mind are design, innovation, progression, but not safety. This can also be said for many high school and college engineering curricula, most do not have a focus in safety. The primary focus is on technical design and the design process. System Safety is a growing field and will require more highly skilled and knowledgeable individuals in the future as designs become more complex. How does management recruit talent coming from an academic background that purely focuses on design and not Safety? How can that talent be retained? In 2016 I graduated from Syracuse University with a degree in Aerospace Engineering. During those four years I had a difficult time determining what I would like to do with my degree. The curriculum was primarily focused on design, however, I was unsure if I wanted a career in design. Even though much of the curriculum was focused on design, there were instances where Safety could have been a focus. During a required Aerodynamics class, the professor tasked us with researching a fatal commercial airline accident. Through our research we discovered that an erroneous indication in the cockpit caused confusion among the pilots which set off a chain of events that led to the loss of the aircraft and its occupants. This exercise was used to reinforce an aerodynamic concept we had learned in a previous session, but could have also been used to demonstrate the need for System Safety. Even if there are not classes specifically dedicated to System Safety in a typical engineering curriculum today, the subject matter exists, the term "System Safety" just needs to be included.This paper provides experiences, impressions, and personal anecdotes regarding my career as a rookie system safety engineer. Topics include the training, mentoring, and other resources that were provided to me or what I would have preferred as I began my career. The goal is to initiate a discussion with management about providing ways to attract and retain new talent. As the world of system safety grows, it is important to keep up with the demand needed. One way of doing this would be to introduce System Safety to the young engineer as early as possible. This paper will recommend ways to accomplish this task as well as provide an example as to how I have begun doing this. During the last two International System Safety Conferences, there have been numerous instances of managers expressing concern that they were unable to retain young talent, while the focus of the Society has been to incorporate System Safety within academia. The society's approach to this issue is promising, but this is just one step of many that will be needed in order to attract the talent that this field will need. 

 Divergence theory and its practical application as an innovation exercise seeks to "open the aperture" and first expand the problem space, as opposed to just immediately converging toward a viable solution. This paper shares a use case application of a simple but powerful divergence methodology as an analytical technique to retire a major program critical risk believed by many to be technically impossible to address. The risk statement required system resilience against "critical omissions in the identification and classification of failure conditions, resultant hazards, and hazard severities." Many programs attack resilience by what-if-ing the problem until time and budget are exhausted and program leadership feels like due diligence has been served. But what else could be done to show resilience against truly unforeseen threats and critical omissions? Every time the what-if activity identifies a new threat it moves out of the unforeseen bucket into the known threats bucket. How do you prove resilience for everything that's left in the unforeseen bucket – the things that nobody's ever thought of? This paper provides a method to do just that, and which was sufficient to retire the subject major program's critical omission risk. 

The tutorial provides an overview of the U.S. nuclear weapon system safety design process and the approach taken to assess and manage system safety throughout the weapon lifecycle. Key considerations include the emergence of stringent safety requirements, the simplifying concept of assured safety implemented using the nuclear safety design principles of incompatibility, isolation, and inoperability, which are integrated using multiple safety layers (a.k.a., subsystems) of safety features having independent failure causes to assure safe responses are achieved in a predictable manner in all relevant environments. Emphasis is given to novel system safety design approaches and methods for achieving rigorous critical technical review of the state of safety of weapon systems by independent experts throughout its lifecycle.

This tutorial will present a case study and hands-on training regarding the design, analysis, test and certification of a commercial Lithium Ion Energy Storage System (ESS) that was involved in a recent fire event. The tutorial will go beyond the basics of hazard identification and risk mitigation, and explore areas that the System Safety Engineer/Manager should consider, including regulatory authority interface, legal liability, transfer of risk and enterprise liability. While the tutorial is based on actual experience from an international company, the fact pattern has been sanitized for educational purposes.The lecture presentation will begin with background on the commercial energy storage domain, and the industry-specific safety standards, guidelines, third-party safety certifications, and risk assessment and management. Differences from the MIL-STD-882E safety process and DoD risk assessment will be explored.The majority of the tutorial will be a case study of a recent failure and fire event that occurred with a fielded Lithium Ion Energy Storage Unit at a "green" energy generation site. The mishap description will be presented, and then attendees will be invited to discuss possible causal factors, including deficiencies in requirements definition, design and manufacturing defects, hardware failures, software flaws, and human errors. Subsequent presentation will detail the actual investigation and root cause analysis, corrective actions, modifications to fielded systems, subsequent risk assessment by both the manufacturer and its insurance company, conduct of the parties involved, and the legal outcome and findings. The session will conclude with an interactive discussion of what could have been done to prevent the incident, and "lessons learned" for System Safety Engineers of all experience levels.Upon completion of the tutorial, the attendee should have a basic understanding of:• MIL-STD-882E versus commercial energy industry safety programs• Energy System design and safety standards• Hazard analysis techniques for energy systems• Failure Review Board (FRB) and root cause analysis• Risk Assessment and Management techniques• Advantages/disadvantages of third party safety certifications during development and installation

A vital controller is safety critical and its failures, if not mitigated in time, can contribute to hazards in the application system. With electronics advancing and automation increasing, the expanding complexity of a vital controller creates challenges in designing it and assessing its safety integrity level. Typically, traditional safety engineering approaches are not effective for providing systematic guidance to design vital controllers and also not cost efficient for justifying their safety integrity. Through practice on developing multiple Communications-Based Train Control systems, we have identified an approach to using a set of safety concepts as guidance for both safety critical controller design and its safety integrity assessment. These safety concepts are categorized as intrinsic fail-safe, reactive fail-safe, and composite fail-safe. An effective combination of them is applying the composite fail-safe concept in checked redundancy techniques for designing the architecture of a controller, the reactive safety concept for identifying self-testing and monitoring mechanisms in each checked redundant channel, and the intrinsic fail-safe concept for ensuring safe interfaces to other controllers and controlled devices. This paper presents the approach for using these safety concepts and discusses their application principles and verification factors for achieving high safety integrity level of a controller.

Most Fault Tree Analysis (FTA) guides and tutorials focus on building Fault Tree (FT) models or the development of data/probabilities to quantify the FT model. This tutorial takes a different perspective: How do I review a Fault Tree Analysis (FTA) to ensure it is correct and complete? This question is answered in the tutorial by identifying all of the key elements (data or information) that make up the "analysis" portion of the FTA, discussing why and how each element is used in the review of the FT model, and presenting lessons learned for each key element on how the data/information can be used to discover commonly seen errors or problems in FT models.

The Bhopal accident in 1984 was the worst process industry disaster of all time. It was not an act of greed, sabotage, or incompetence. There are surprising similarities between that accident, BP Texas City, and many others. This presentation will review both accidents, how many of the issues were not unique to those facilities, and how the same issues can be observed at many facilities today. More recent realization of the complexity of modern industrial processes, and the organizations responsible for designing, building, running, and maintaining them, has resulted in a broader understanding of accident causation, and what can be done to try and prevent further incidents. This presentation will review the previous thinking process and recommendations (which have not been very helpful in preventing other accidents) and offer an alternative approach and recommendations.

 In system security, it is important to be able to analytically investigate a system in a provable, quantitative way. Finding system vulnerabilities should not be left up to guess work. Without a verifiable method of demonstrating weak points, efforts to improve security may simply be wasted.Fault trees are a trusted and well-established method of investigating system reliability. This methodology graphically represents component failure events and how they logically interact to produce a system failure mode. Fault tree can help understand the likelihood of a system failure and the component failure events most likely to contribute to system failure.While fault trees usually consider random component failures as the inputs to the system, the methodology is flexible enough to consider any failure mode as an input. Likewise, the functional failure of a system is usually considered as the output of the model, but any system failure mode, or adverse occurrence, can be modeled. With a few tweaks, we could consider the inputs to the model as targeted attacks made by a malicious attacker, and the output system failure mode as a breach or compromise of system security. We can thus find the various paths an attacker might use to compromise a system, and which attacks are most likely to succeed. "Indicators" are an additional concept often found in attack trees. These values indicate how difficult an attack would be to perform by the attacker. Common indicators include the cost of the attack, if any special or hard-to-obtain equipment is required, and a ranking of the skill required to perform the attack. For any given path to compromise the system, we can calculate how much it will cost the attacker, how difficult it is to perform, if any special equipment is required, etc., and thus determine the simplest attack path to compromise the system.This can help us discover counter-intuitive features of a system. What we see as the most vulnerable access point to a system, and where we focus most of our security efforts may not in fact be the simplest attack vector. By modeling a system with an attack tree, we can quantify the difficulty and probability of success for each attack, determine our system's most vulnerable weaknesses, and plan our future system security improvements accordingly.This tutorial will use Isograph's Attack Tree software to introduce the concept of attack trees as a modification of fault trees. We will review basic methodologies common to both fault and attack trees, including the top-down approach to creating a tree and the Boolean algebra used to produce cut sets (failure paths). We will learn how to input quantitative data, such as indicator values and success probability, into our attack tree models. Lastly, we will look at example attack trees, and see where the attack tree analysis tells us an attacker is most likely to succeed, and how difficult this will be. We will also consider how these successful attacks can be mitigated by improved system security. 

 With the increasing complexity of modern systems, traditional approaches to safety (most of which were created 50-70 years ago) are losing effectiveness and leading to avoidable losses. In this class, you will learn about a new approach based on systems theory and systems thinking. This approach and its tools, although relatively new, are now widely used in most industries, particularly automobiles, aviation, and defense and can handle very complex systems and so-called "systems of systems." The approach integrates safety and security. International standards have been created or are in progress.No prerequisites. The class will teach a new approach to safety engineering and thus should be understandable by anyone, even those without an extensive background in traditional safety engineering approaches.Why accidents (losses) occur in complex, engineered systemsHanding complexity: Analytic Decomposition vs. Systems TheoryA top-down, integrated approach to analyzing and designing safety into complex systems containing hardware, software, and human components.A new approach to investigating and analyzing losses called CAST (Causal Analysis based on System Theory)A more powerful hazard analysis technique called STPA (System Theoretic Process Analysis)Designing safety into systems from the beginning of the concept development process and using analysis to derive the functional safety and security design requirements and design process.Safety Management and Safety Management Systems

This is a working meeting to continue plan the path forward and implementation for providing training and educational opportunities for system safety engineering professional development. These initiatives are vitally important as the need for experienced system safety practitioners increase exponentially in response to increasingly complex environments. This is an ideal time to get involved. The success of the initiatives is a team effort. An investment into these initiatives is an investment in the future.

Unit tests furnish assurance of error free operation of code modules, enhancing safe operation of code-intensive systems. The underlying vector space of a structured code module can be used to construct a minimal set of unit tests if a basis set of such a vector space can be found. This paper explores the use of basis sets to design a minimal set of unit tests and demonstrates how a basis set of tests is adequate for a logical test of a module containing a multitude of paths of execution.

We are able to consider the various risk factors when considering automotive safety: for example, malfunction, imperfect environmental recognition, and security violation. We have standards to treat those hazard types: ISO 26262 (functional safety), ISO/PAS 21448 (SoTIF) and SAE J3061 (security), respectively. However, those risk factors don't cover all. We can distinguish the factors relating to the collaboration of multiple ADASs or the difficulty of the decision of motion planner[1][2].In this paper, we provide the approach to identify the risk factors through analyzing the interface classes, that are communication between the environment-system, user-system, and system-system. We'll show the result of this analysis, and we believe this is useful for us to identify the hazard of the system from SAE level 2 to level 5. [1] https://doi.org/10.20485/jsaeijae.10.1_14[2] Ito, Masao. "Method of Evaluating the Influence Factor of Safety in the Automated Driving System: The Chasm Between SAE Level 2 and Level 3." European Conference on Software Process Improvement. 2018.

 This paper documents a proposed approach using Decision Analysis to aid in the selection of a software architecture intended to replace that of a legacy monolithic system. The new design supports a safety by design methodology, improves code maintenance by making the code base more easily maintainable, and reduces cost. "Frank's Seven Step Formalized Process" was used to formulate a decision. Three alternatives were analyzed with respect to safety, cost, and maintainability.  

Rarely as IH/OS Professionals are we given the luxury of developing anything from scratch and without boundaries. We typically inherit programs and processes that have been in place for years, developed nuances, and workarounds. Based on some of the most commonly seem violations and findings from Occupational Safety and Health Administration (OSHA) compliance audits for Process Safety Management (PSM) programs and Process Hazard Analysis (PHA) documentation. This course will provide the tools for reconstructing, streamlining, and revitalizing your PHA and PSM program while integrating already existing facility resources. The course will use interactive discussions coupled with videos presented by the Chemical Safety Board and Discovery Channel's Engineering\Disasters. The instructors will provide lessons learned reflecting a combined 40+ years experience with performing hazards analysis for general industry, private, and government clients. Course Outline:• 29 CFR 1910.119 Process Safety Management Regulation Overview• Process Hazard Analysis Methodology• Process Hazard Analysis Development• Avoiding Common Process Safety Management Program & Process Hazard Analysis Documentation Issues• Lessons Learned

Integrated safety and security assurance for complex systems is difficult for many technical and socio-technical reasons such as mismatched processes, inadequate information, differing use of language and philosophies, etc.. Many co-assurance techniques rely on disregarding some of these challenges in order to present a unified methodology. Even with this simplification, no methodology has been widely adopted primarily because this approach is unrealistic when met with the complexity of real-world system development.  This paper presents an alternate approach by providing a Safety-Security Assurance Framework (SSAF) based on a core set of assurance principles. This is done so that safety and security can be co-assured independently, as opposed to unified co-assurance which has been shown to have significant drawbacks. This also allows for separate processes and expertise from practitioners in each domain. With this structure, the focus is shifted from simplified unification to integration through exchanging the correct information at the right time using synchronization activities.

 Personnel safety is a major concern throughout integrated space vehicle and launch vehicle operations and testing. The safety concern exists for the personnel that handle the launch vehicle and space vehicle. The hazard risks associated with integrated space vehicle and launch vehicle operations increases as the two vehicles are integrated together. These risks must be controlled to acceptable levels prior to the start of integrated operations. This paper will explore controls for cranes and hoists, sling assemblies, hydrasets and loadcells, handling structures, flight hardware lift points, work platforms, RF emitters, non-ionizing radiation sources, hazardous materials, flight hardware pressure systems, ordnance systems, electrical and electronic systems, and seismic designs. This paper will also explore hazed controls that must be in place to ensure ground operations safety. Range Safety requirements will be the catalyst of discussion for this paper as most launch operations occur on a military installation.   

 This tutorial will introduce you to the concept of safety cases. Safety cases are structured arguments that support the claim that a system is safe to be used for a given application in a given environment. Several standards require the production of such safety cases as a prerequisite for approval. The tutorial will highlight good and bad practices when developing safety cases and will introduce you to a notation specifically developed for the generation of safety cases, the Goal Structuring Notation (GSN). There will be practical examples which need to be solved by the attendees, so that hands-on practice and experience is gained.  Detailed outline of the tutorial: Introduction (1h): The tutorial will start with a survey of current safety standards (IEC 61508, ISO 26262, EN 50128, DO-178C,...) and analyse their views and requirements regarding safety cases. We will then delve into the nature of safety cases, briefly touch their historical origins, and clearly consider what can and what can't be expected from a safety case. Based on our practical experience we will also highlight some typical bad practices when constructing safety cases. This helps to correctly and critically read them, and is also a helpful guideline for reviewing other safety documentation. This part of the tutorial is largely a presentation. Goal Structuring Notation (45min): We will now introduce the main elements of the Goal Structuring Notation (GSN), which is a helpful tool to document safety cases. The presentation of the notation will be interleaved with brief examples, excercises and questions, so that attendees have the chance to fully understand the meaning and purpose of the various symbols. A structured method how to proceed when drafting safety cases will also be presented. Hence, this part of the tutorial is much more interactive, requiring active participation of attendees. Case Study (45min): A realistic case study will then be handed out. It is expected to be solved as a group work (groups of 3-5 people are expected). The task of the groups will be to draft and present a sound safety argument for a given claim that the system in the case study is acceptably safe for a specific application in a given environment. GSN shall be used as a notation for this purpose. At the end, the groups present their solutions, and the advantages/disadvantages of the presented solutions are discussed. This part of the tutorial is a group work. Concluding Remarks (30min): Finally, we will bring some concluding remarks, consisting of hints how to avoid common errors and fallacies in safety cases, show some examples of real-world safety cases and a we will finish with a personal conclusion.

This updated tutorial presents key concepts, techniques, and case studies of Quantitative Risk Management in a manner that can be comprehended by newcomers and appreciated by professionals seeking to better understand quantitative methods. With a focus on risk management, new topics include comparing cumulative fleet risk, risk per flight, and risk per flight hour in aviation and suitable aging parameters for other fields.Risk management begins with risk identification and assessment. Quantitative Risk Assessment (QRA) provides a data-driven process that is predictive instead of subjectively choosing categories from a red-yellow-green matrix. Some mathematical computations of QRA are complex and can be intimidating to non-mathematicians, but the basic elements and interpretation are fairly comprehensible, so even non-mathematicians can benefit from an understanding of the process. This mathematical complexity can lead to misunderstanding and skepticism so this tutorial presents a stepwise approach for performing QRA and includes lessons learned, case studies, and a comparison of the advantages and disadvantages of quantitative and qualitative methods. QRA is based on Life Data Analysis and can accurately predict future risk by analyzing the risk without corrective action (uncorrected risk), and then analyzing the risk with specific mitigating actions (corrected risk). Short term mitigation such as one-time and recurring inspections, reduced service life, shortened maintenance intervals, and more effective inspection methods are often necessary, and a QRA model can be created to perform comparative evaluation of the options. These actions contribute to maintaining a reasonable level of safety until the hazards can be eliminated or sustained below a risk level guideline. The data available for analysis is limited so the challenge is to provide accurate risk forecasts with limited data points, and Quantitative Risk Assessment is an appropriate tool. QRA also presents an opportunity to quantify events that might have occurred if corrective action had not been implemented, based on forecasts of the uncorrected and corrected risks and application of a hazard ratio. This in turn can be used in justifying the cost of preventative safety actions and supports the business case for safety. This will be a lively interactive tutorial given by two presenters. One is uniquely suited with degrees in mathematics and statistics, with a Ph.D. in Industrial and System Engineering and extensive knowledge of reliability theory, and the other is a user of the methodology who will provide commentary and help explain the complex subject matter to improve comprehension by non-mathematicians.

 In system security, it is important to be able to analytically investigate a system in a provable, quantitative way. Finding system vulnerabilities should not be left up to guess work. Without a verifiable method of demonstrating weak points, efforts to improve security may simply be wasted.Fault trees are a trusted and well-established method of investigating system reliability. This methodology graphically represents component failure events and how they logically interact to produce a system failure mode. Fault tree can help understand the likelihood of a system failure and the component failure events most likely to contribute to system failure.While fault trees usually consider random component failures as the inputs to the system, the methodology is flexible enough to consider any failure mode as an input. Likewise, the functional failure of a system is usually considered as the output of the model, but any system failure mode, or adverse occurrence, can be modeled. With a few tweaks, we could consider the inputs to the model as targeted attacks made by a malicious attacker, and the output system failure mode as a breach or compromise of system security. We can thus find the various paths an attacker might use to compromise a system, and which attacks are most likely to succeed. "Indicators" are an additional concept often found in attack trees. These values indicate how difficult an attack would be to perform by the attacker. Common indicators include the cost of the attack, if any special or hard-to-obtain equipment is required, and a ranking of the skill required to perform the attack. For any given path to compromise the system, we can calculate how much it will cost the attacker, how difficult it is to perform, if any special equipment is required, etc., and thus determine the simplest attack path to compromise the system.This can help us discover counter-intuitive features of a system. What we see as the most vulnerable access point to a system, and where we focus most of our security efforts may not in fact be the simplest attack vector. By modeling a system with an attack tree, we can quantify the difficulty and probability of success for each attack, determine our system's most vulnerable weaknesses, and plan our future system security improvements accordingly.This tutorial will use Isograph's Attack Tree software to introduce the concept of attack trees as a modification of fault trees. We will review basic methodologies common to both fault and attack trees, including the top-down approach to creating a tree and the Boolean algebra used to produce cut sets (failure paths). We will learn how to input quantitative data, such as indicator values and success probability, into our attack tree models. Lastly, we will look at example attack trees, and see where the attack tree analysis tells us an attacker is most likely to succeed, and how difficult this will be. We will also consider how these successful attacks can be mitigated by improved system security. 

 With the increasing complexity of modern systems, traditional approaches to safety (most of which were created 50-70 years ago) are losing effectiveness and leading to avoidable losses. In this class, you will learn about a new approach based on systems theory and systems thinking. This approach and its tools, although relatively new, are now widely used in most industries, particularly automobiles, aviation, and defense and can handle very complex systems and so-called "systems of systems." The approach integrates safety and security. International standards have been created or are in progress.No prerequisites. The class will teach a new approach to safety engineering and thus should be understandable by anyone, even those without an extensive background in traditional safety engineering approaches.Why accidents (losses) occur in complex, engineered systemsHanding complexity: Analytic Decomposition vs. Systems TheoryA top-down, integrated approach to analyzing and designing safety into complex systems containing hardware, software, and human components.A new approach to investigating and analyzing losses called CAST (Causal Analysis based on System Theory)A more powerful hazard analysis technique called STPA (System Theoretic Process Analysis)Designing safety into systems from the beginning of the concept development process and using analysis to derive the functional safety and security design requirements and design process.Safety Management and Safety Management Systems

This is a working meeting to continue plan the path forward and implementation for providing a guidance standard presenting the necessary and sufficient information for using System Safety Engineering in developing complex products and processes and programs in a variety of industries. These initiatives are vitally important as the need for experienced system safety practitioners increase exponentially in response to increasingly complex environments. This is an ideal time to get involved. The success of the initiatives is a team effort. An investment into these initiatives is an investment in the future.

In order to evaluate safety or risk on today's highly integrated and complex systems, system safety must become an active participant in the requirements capture and validation process. Application of requirements-based processes such as SAE ARP4754, RTCA DO-178, DO-254, and MIL-STD-882 software safety are used as primary mitigation for systemic failures within these highly integrated and complex systems. To support these processes, safety assessments can be used to establish safety specific requirements and also identify functional and design implementation requirements that are used to comply with those safety-specific requirements. This workshop will explore the different "safety requirement" definitions used within industry, discuss pros and cons of each definition and its usage, and demonstrate how the Functional Hazard Assessment (FHA), Fault Tree Analysis (FTA), and Functional Failure Mode and Effects Analysis (F-FMEA) can be used to define safety requirements and serve as supporting rationale. Using these same analysis techniques in support of safety requirement validation will also be demonstrated.As a caveat: this course will be limited to use of safety assessments and analyses to define requirements. It is not a workshop on how to write "good" requirements from a systems engineering perspective. Also, the workshop does not venture into the use of "model-based development techniques" to define safety requirements.

 (Note: This paper follows on from the paper presented last year at ISSC. This new paper serves to provide more technical detail (the how?) for the integration framework)There are many approaches to solving the safety-security integration problem. Regulatory bodies have also attempted to unify safety-security co-assurance through creating coherent standards. Indeed, there are examples of complementary standards in several domains such as industrial control, aerospace, defence, and healthcare. However, many of these are partial solutions that only look at a specific aspect of the interaction, and do not address interactions at each stage of the system lifecycle. These partial solutions are insufficient for co-assurance because they reveal a limited number of gaps and make it difficult to have confidence that an acceptable level of assurance has been reached. What is required to solve these challenges is a model of attribute co-assurance that allows for separation of concerns, and the ability to incorporate new information and to propagate the impact across the attributes. The Safety-Security Assurance Framework (SSAF) will be presented as a candidate solution with a small case study to explify its application. SSAF relies on the new paradigm of independent co-assurance, i.e. separated but interconnected concerns. It is possible to maintain separate teams, separate models, separate processes, but still exchange the right information at the right time. SSAF also enables practitioners to explore the subtle ways in which the socio-technical system interactions make assuring safety and security more difficult. In this way, changes (e.g. new vulnerabilities) can be responded to more effectively, and assurance in system safety and security maintained. In addition, SSAF has the potential to inform co-assurance standards of the future by providing a structure to analyse the interactions in detail.

Effective communication between the system safety engineer and the Project Manager is an essential characteristic of good risk management in a robust system safety program. However, these two disciplines utilize similar terms with disparate meanings than can lead to sub-optimal technical or programmatic outcomes. MIL-STD-882E defines risk as "A combination of the severity of the mishap and the probability that the mishap will occur." The Project Management Book of Knowledge (PMBOK) Guide, 6th Edition, defines individual project risk as "an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives."1 It is incumbent upon the system safety professional to clearly communicate safety-related issues, hazards, risks, and concerns using language most likely to be understood by the Project Manager to ensure he or she has the requisite information to make a sound programmatic decision. This paper explores discrepancies between project risk management and safety risk management standard processes that hinder clear communication and can drastically impact program performance. We present methods to consider that will improve understanding between the system safety professional and the Project Manager and two framework approaches for integrating safety and project risks.

This paper summarizes STPA activities and some of the lessons learned within General Motors Company. The presentation will include the following topics.Initial introduction activities are reviewed and instances of initial resistance from organizational elements are reviewed. This part of the paper will touch on typical scenarios new technologies or methodologies might experience as part of an introduction phase. Key activities such as finding an initial application "niche" for STPA that demonstrates the value of STPA as well as verifying STPA usefulness are reviewed.Comparison of STPA to other system safety analysis methodologies such as Failure Modes and Effects Analysis (FMEA), Fault Tree Analysis (FTA) and System Element Fault Analysis (SEFA) is presented. This section touches on how STPA can complement these other methodologies within a system safety process and when in the system safety process each method seems to have the most leverage. Also, STPA and Model-Base Systems Safety Representation activities are summarized.Expansion of STPA usage beyond initial niche application is outlined in the presentation. Use of "systems thinking" and "systems engineering" philosophies and techniques for such expansion are discussed. Topics such as STPA evaluation efforts and the effort to educate system safety engineers in the use of STPA is reviewed. In addition, a summary of attributes and skill sets beneficial for STPA practitioners is presented.The presentation concludes by outlining potential future areas of STPA usage within the General Motors System Safety group.

This workshop gives a short but comprehensive introduction to the processes and methodologies associated with the system safety of software-intensive safety-critical systems. Software Safety provides confidence that the safety-critical (and mission-critical) system operates with acceptable risk to personnel, equipment and the environment.The system safety activity is a fundamental element of the system design process and one that continues to present significant challenges with respect to system complexity, system design, maintenance and operations. This places the burden on system safety professionals to quickly develop in-depth knowledge of various system safety activities, analysis, methodologies and techniques. System safety methodology revolves around analyzing the systems, identifying hazards, categorizing and identifying safety-criticality of software, providing risk assessments, recommending actions and mitigations, and participating in life-cycle reviews to ensure an acceptable level of safety. In an interactive workshop, participants will use a commercially available hazard tracking system to collaborate with their functional teams to apply various standard hazard analyses techniques within a real-life corporate simulated environment.Note: The workshop is free for conference attendees, but seating will be limited. Please register now for the class so that example profiles can be set up for each participant in this comprehensive introduction to the processes and methodologies associated with the system safety of software-intensive safety-critical systems. Pre- register HereEach workshop participant will need to bring their personal laptop capable of accessing the internet to this workshopCMTIGroup's HTS software is completely cloud-based. No software will be installed on your computer.  

This is a working meeting to continue plan the path forward and implementation for providing credentialing for authoritative recognition and verification of SSE professional achievement. These initiatives are vitally important as the need for experienced system safety practitioners increase exponentially in response to increasingly complex environments. This is an ideal time to get involved. The success of the initiatives is a team effort. An investment into these initiatives is an investment in the future and expertise.

Non-deterministic latency and jitter issues have arisen with the increased use of commercial multicore processors (MCP) as the hardware platforms for hosting Department of Defense (DoD) systems. Within the civilian world of avionics flight control, an approach to dealing with non-deterministic latency issues arising from interference channels within multicore-based, hard real-time, flight control applications has been documented in the Certification Authorities Software Team (CAST) Position Paper (CAST-32A) on Multi-Core Processors and the Federal Aviation Administration's report on Assurance of Multicore Processors in Airborne Systems (DOT/FAA/TC-16/51, dated July 2017).Many, perhaps most, DoD safety-critical systems are not hard real-time. Missing some deadlines can be tolerated and adequately addressed with mitigations such as data time-stamps and checks to discard "stale" data. As firm or soft real-time systems, performance may degrade, but catastrophic consequences can be prevented. For these systems, the approach used for hard real-time avionics flight control systems is unnecessary and not cost effective.This paper discusses the mismatch of the CAST-32A approach for firm and soft real-time, non-avionics systems and presents a simpler, more agile, testable approach to MCP risk control based on a long-used criterion from the realm of network management.

The Hyperloop Transportation System is being designed and prototyped in a rapidly evolving, flexible and lean (i.e. agile) corporate environment by multiple engineering teams that span several continents. This effort by Hyperloop Transportation Technologies (HTT) represents the convergence of technologies categorized as either well known, evolving or revolutionary. When successfully combined and fielded as a large system, they will represent a mode of transportation not envisioned by current transportation or business regulations. HTT must build on relevant standards to close regulatory gaps. Where there is no regulatory precedence, HTT must exceed current transportation safety levels using an agile and yet robust design process that excels in system safety engineering. This is a business imperative in order to sustain both financial market and public confidence in Hyperloop as a beneficial undertaking. The Hyperloop is challenged by what is known as the "pacing problem", the ever-increasing gap between existing regulations and emerging technology. Thus, a fundamentally new regulatory approach is needed to ensure this new technology is both safely and timely deployed to solve the growing socioeconomic challenge of clean, safe and effective transportation. This reality will require effective public-private partnership to build and maintain a licensing structure and associated practices, an increasingly common approach to regulating innovation.Key Words: Transportation, technology, regulation, hyperloop

Internet of things (IoT), the growth of which is predicted to double from 2017 to 2022, will be widely applied in all fields. The concomitant IoT safety problem, which is closely related to first concerned human health, deserve prior and sufficient concentration. Different from other fields, security is a unique safety problem in IoT applications. Hackers can change the data and operation of IoT devices and cause safety accidents. To prevent potential hazards, a security integrated IoT safety model is proposed in this paper. This model, referring hazard analysis by Systems-Theoretic Process Analysis (STPA) in IoT field, contributes more blocks on security section. This model could identify abnormal signs and thus provide early warning for potentially hacked IoT devices. A case study is analyzed by this model to show its reliability.

 The importance of safety in the development of safety-critical automotive systems has been increasingly growing, especially with the introduction of integrated driver assist and automated driving systems. The ISO 26262: Functional Safety –Road Vehicles Standard defines safety as the absence of unreasonable risks arising from malfunctioning behavior of the system. However, for some systems potentially hazardous behavior can be caused by the intended functionality, for instance due to a sensor performance limitation. The latter is referred to as the Safety Of The Intended Functionality or SOTIF, and has been introduced by the recently published ISO PAS 21448. In this paper we present an overview of the ISO PAS 21448. SOTIF by definition deals with the absence of unreasonable risk resulting from functional insufficiencies or due to reasonably foreseeable misuses. Guidance on the applicable design, verification and validation measures needed to achieve SOTIF are discussed. This includes the system specification, identification and evaluation of hazards caused by the intended functionality, and any modifications needed to reduce the risk due to SOTIF. In addition, the verification and validation strategy and activities are discussed as well as the method to accept the residual risk following the SOTIF activities. The expectation is that ISO PAS 21448 is complementing the safety activities performed while following ISO 26262.  Finally, this paper introduces the timeline to publish an international standard on SOTIF, ISO 21448. 

This paper first discusses the limitations of the standard risk matrix. It then suggests some changes to the risk matrix and its use to improve the accuracy of the results.

A weapon system might cause unintended harm to its operators or their teammates. A system of complex weapon systems may produce the same undesired result. As our systems are integrated or interoperated as never before, hazard analysis must assess the risk inherent in this context. A safety practitioner can assess the system's contribution to a fratricide event outside the system boundary. Even if the other systems are necessary to realize such a mishap, is it even possible to define this contribution. The best assessment of Integration and Interoperability (I&I) Fratricide hazards will come from the system's safety program since these safety practitioners understand the system's hazards better than anyone else does. The Functional Hazard Analysis (FHA) identifies the system functions and safety hazards associated with functional failure. How could a safety practitioner use the FHA to assess system hazards in the I&I context? This study will develop an I&I Fratricide FHA framework to efficiently assess system hazards related to potential mishaps that could be realized by functional interaction with another system.

Human space transportation safety and risk management has evolved significantly over the sixty-plus years of strict oversight by the National Aeronautics and Space Administration (NASA). Beginning in the 1960s, the criticality of transparency and open reporting of safety concerns and potential areas of under addressed risk analysis have proven disastrous in high-visibility accidents such as the Apollo 1 fire, and the Space Shuttle Challenger and Columbia accidents. Now, both domestically and internationally, a commercial space industry is rapidly growing, serving private consumption and providing services to NASA and the U.S. military space complex. The new model of oversight, however, was built with the desire to rapidly grow the commercialization of space, counter to the slow, methodical, safety-based growth of the civil space programs of the past. From a regulatory perspective, The Federal Aviation Administration, Office of Commercial Space Transportation (FAA/AST) is responsible for oversight of the commercial space industry. However, since the industry has become largely driven by entrepreneurial innovation and business models, Congress has written laws pertaining to the commercialism of space that ensure a non-intrusive approach, with an expectation that the industry be the one to develop and adopt consensus standards that evolve with the growth of space commercialism. Congress' vision was that commercial operators would develop industry-based safety excellence in their safety management programs and systems through a type of self-regulation. FAA/AST is responsible for regulating commercial space transportation operations only to the extent necessary to ensure public health and safety and the safety of property, with the ability of FAA/AST to enact regulations mandating safety management system requirements on commercial operators specifically limited to ensure that regulations do not hinder the development and growth of private space flight operators. Considering the FAA's limited role in oversight of commercial space operator safety, the emergence of the true private sector is shifting the role of the primary risk taker from the government (government as both the only launch provider and the primary customer) to private entities, in which the market bears the risk (government one of many customers). This rapid expansion of privatization in the launch, suborbital and orbital space markets, with minimal government oversight of safety, introduces unknown opportunities for incidents and accidents that may involve the public, private operator employees, and space flight participants (passengers). Of particular concern within the industry is how to prevent actions taken by one or two highly risk-tolerant launch providers that would adversely impact the industry as a whole. An industry-specific safety reporting system has multiple risk-reduction advantages, and conceptually can be developed alleviating concerns of over proprietary information. Much as NASA operates the Aviation Safety Reporting System (ASRS) for commercial aviation and the Confidential Close Call Reporting System (C3RS) for the railroads, these systems can be models for a safety reporting system that supports managing risks collectively, better ensuring the survivability of each operator by communicating openly among all operators. This paper will explore such a system for commercial space.

All aviation organizations in the world are preparing to cope with the new ICAO standards for Safety Management System Safety. Managers are working on Safety Performance Indicators to evaluate deviations from the ideal operation. Most of these indicators are reactive because they measure parameter exceedances. A new tool is required to guide safety managers on the identification of proactive indicators. The solution is the use of an active version of STPA (Systems-Theoretic Process Analysis). The Active STPA uses different sources to diagnose the safety status of a system, such as data collected in Flight Data Monitoring and events from voluntary reporting. The input messages of those sources updates the STPA on specific subjects (e.g., unstable approaches). The output of the process is a set of new preventing and mitigating measures. The Active STPA allows the generation of cumulative knowledge by guiding the reasoning on assumptions about the system. The feedback on SMS activities allows targeted Safety Promotion activities and provides qualitative information for hazard management and risk assessment. This Integrated SMS provides organized safety information for management, fostering better planning on the use of human and financial and resources. The results include the identification of new trends on safety, and the diagnose of the organization's Safety Culture and Safety Communication channels.

Past tragic events such as the fatal explosion and crash of Nimrod XV230, Space Shuttle Challenger or Columbia disasters, SHELL Moerdijk explosion, Herald of Free Enterprise, Kings Cross fire and Texas City refinery explosion occurred in entirely different areas or industry sectors. There is, however, an aspect which is common in these cases, namely the phenomenon known as creeping change. The IChemE Safety Centre has recently addressed this topic presenting a case study in its quarterly publication, the Safety Lore. They also provided practical tips to managers, process safety engineers, supervisors and operators of industrial sites to learn how such major incidents involving creeping changes can be avoided. This paper demonstrates the phenomenon of creeping changes via two case studies from two different sectors. In addition, it suggests lead metrics associated with these events to help monitor the changes. Finally, it provides ideas to managers, supervisors, process engineers and operators how to address those changes in their work.

This paper introduces a top-down approach to analyzing safety of self-driving vehicles. A System-Theoretic Process Analysis (STPA) is applied to a real case study involving human safety driver interactions, engineering and management interactions, and complex software interactions. Specific software functions like path planning and perception are analyzed to understand indirect and subtle causes of potential accidents and to drive key design decisions. The process identifies hazards and accident scenarios, and generates safety requirements for related to all levels of operation including program managment, safety driver training, and software interactions.

This tutorial illustrates a step-by-step process to apply a quantitative analysis methodology to mishap data to approximate the distribution of both the probability and severity of a mishap and examine likely behavior of the co-distribution of probability and severity as the risk reduction process is executed. Utilizing Microsoft Excel®, the appropriate statistical metrics for risk assessment are calculated and will be graphed. With this quantitative analysis methodology, risk now becomes a quantitative item with a known probability distribution, providing a new metric for safety program effectiveness. 

The course is based on the principles and methodologies presented in the Redbook, "The Guidelines for Hazard Evaluation Procedures", 3rd Edition for using the What-If/Checklist hazards analysis method. The Redbook is a standard industry reference for hazard evaluation procedures published by the Center for Chemical Process Safety (CCPS). The Qualitative Risk Analysis (QRA) technique can be used in combination with many of the traditional hazard evaluation techniques. Risk is a combination of both the consequence of a loss event and the frequency of event occurrence. The integration of a QRA into the hazard analysis process helps to address the unmitigated risk, mitigated risk, and adequacy of safeguards. The course will use interactive discussions coupled with videos presented by the Chemical Safety Board and Discovery Channel's Engineering Disasters. The instructors will provide lessons learned reflecting a combined 40+ years experience with performing hazards analysis. Course Outline:• Resources• Qualitative Risk Analysis Methodology• Qualitative Risk Matrix Development• Qualitative Risk Matrix Practical Application• Lessons Learned

 Safety and Security are two characteristics that are required in many systems simultaneously, such as in critical infrastructure like air navigation or public transport. The need for state-of-the-art security will continue to increase in the light of the continuously increasing number of cyber-attacks. Today's safety-related systems frequently contain interfaces to IP-networks and are often based on so-called COTS (commercial-off-the-shelf) components resulting in rising risks of cyber-attacks. The tutorial will address this growing importance of security in safety-related systems. This tutorial provides a holistic view on the rising topic of Cyber Safety with respect to the connection between security threats and safety hazards. Participants learn about the often conflicting requirements of Safety and Security and gain knowledge on possible analysis approaches.

This is a working meeting to continue plan the path forward and implementation for integrating System Safety concepts into all engineering curriculum. This is a working meeting. These initiatives are vitally important as the need for experienced system safety practitioners increase exponentially in response to increasingly complex environments. This is an ideal time to get involved. The success of the initiatives is a team effort. An investment into these initiatives is an investment in the future.

This paper summarizes and examines the United States government's current probabilistic criteria intended to ensure that the systems on commercial airplanes are designed to be acceptably safe. The author divides those criteria into The Primary Regulation, The Secondary Regulation, and The Guidance, explains several specialized terms, and interprets the criteria as a whole in an attempt to make them more understandable. Then he critically examines the criteria, explains why he contends that they are both ambiguous and flawed, and demonstrates how those ambiguities and flaws can cause both airplane systems and flight-crew procedures and training to be grossly underdesigned for safety. Finally he illustrates with an example how the flaws in the criteria can contribute to accidents that involve relatively large flight-crew-failure probabilities as was obviously the case in two recent 737 MAX airplane catastrophic accidents, and suggests how the criteria might be improved to prevent similar accidents in the future.

Aircraft are being networked and equipped with technology that enables onboard and air-to-ground connectivity, increasing the importance of information security in aircraft avionics. These networked systems provide access to and share real-time data for responsive decision-making and control – supporting enhanced safety, increased efficiency, and cost savings for users. The increase in net-enabled aircraft raises the concern that they may be susceptible to attacks that could impact aircraft and passenger safety. Understanding the true potential of these attacks is critical for designing effective security measures, creating appropriate policies and procedures, and ensuring overall flight system safety. Therefore, the aviation industry needs a repeatable methodology that consistently and correctly identifies, prioritizes, and mitigates safety risks associated with aircraft information systems while considering adversarial action.Such a methodology should include guidelines and procedural steps that exercise careful analysis, testing, and strategizing in order to advance up-to-date airworthiness security and protection. This work documents the adjustment of an extension on STPA[1], STPA-Sec[2], to better fit aviation cyber security, and the application of that modified process, STPA-Sec of Aircraft Systems(STPA-SecA), to Aircraft Systems Information Security/Protection (ASISP). We will cover the changes made to Hazardous Control Action (HCA) types; the addition of attack trees as scenario representations; the common lists of capabilities, weaknesses, and vulnerabilities; the replacement of probability with capability when evaluating risk; and the lessons learned in implementation.[1] Nancy G. Leveson and John Thomas. STPA Handbook. 2018.[2] William Young and Reed Porada. System-Theoretic Process Analysis for Security (STPA-SEC): Cyber Security and STPA. Boston, MA, Mar. 2017. url: http://psas.scripts.mit.edu/home/wp-content/uploads/2017/04/STAMP_2017_STPA_SEC_TUTORIAL_as-presented.pdf (visited on 11/28/2018).

 This paper summarizes the application of system safety engineering methods to the evaluation, management and mitigation of some potential safety risks of high voltage automotive battery systems. The battery system in electric vehicles is very complex and must balance many attributes such as performance, cost and timing while not compromising safety criteria. Among other things, a thorough and methodical approach to battery safety is necessary to achieve this balance. System safety engineering methodology provides such an approach and can be applied as a useful framework. Potentially hazardous conditions related to functional safety (for example, charge control) as well as primary safety (for example, chemical and mechanical hazards) may both be addressed by applying such a system safety engineering methodology. Hazard identification and assessment, safety requirements development and definition, application of various safety analysis methods, and verification / validation activities are all part of this approach. Typical battery abuse testing, as well as newly defined limit testing, supports the effort. Documentation, traceability and reviews provide a method to verify that all issues are addressed as well as providing a method to retain information for future reference. A description of the process and specific examples of its application are provided so that both new and experienced system safety practitioners can gain insights to the application of the system safety process to systems which include both functional and primary safety hazards. 

Mr. Brian Connell and Mr. David Musgrave of the Combat Capabilities Development Center Armaments Center (CCDC AC) at Picatinny Arsenal, New Jersey, have adapted a Gamification approach to Software Safety Instruction from a technique previously used to teach the Agile Development Philosophy. The Gamification approach employs the use of gaming dice and fictional safety features as a means of keeping students engaged while they learn the process of assigning Severity, Control and ultimately Criticality Indices per MIL-STD-882E. Students are given a budget as they compete via round-by-round scoring in which they incur fiscal penalties for overly conservative Criticality ratings and risk stiffer penalties (dictated by gaming dice) for liberal/unsafe assessments. The approach leverages the competitive nature of individuals and the strengths of active learning to maximize retention of critical software safety concepts. It has the added dividend of incorporating programmatic concerns such as budgetary constraints and risk management. The tutorial was received a Best Tutorial Award at the 35th ISSC in Albuquerque and has maintained ISSS interest as a prospective tool for bringing software safety instruction to institutions of higher learning. This year, at the invitation of the society, Mr. Connell returns with an improved tutorial designed to minimize past controversies over Severity assignment, address delays in scoring and maintain a focus on learning objectives.  

Safely developing self-driving vehicles presents technical challenges. Among the key technical challenges are how to confidently demonstrate the safety of a self-driving vehicle when the number of permutations of operating conditions, scenarios, system inputs, etc. are complex, uncertain, and potentially limitless. This paper provides a broad survey of the various types of uncertainty in the development of self-driving vehicles and will outline several possible strategies for handling uncertainty. Advantages and challenges of different approaches, including qualitative and quantitative methods, will also be discussed.

As the scope and range of unmanned lethal weapon systems grow, the requirement to maintain effective human control authority over ever-growing autonomy in the functionality allocated to the system's software grows more and more challenging. Ensuring necessary human in-the-loop or on-the-loop control authority under greater and greater separation in space and time requires greater attention to the design of the right redundancies in hardware, software, communication, and data through the entire infrastructure involved in mission command and control. Adding to these challenges is the mounting challenge of machine learning allocated to more and more of the software functionality that comprises the mission architecture for unmanned weapon systems. This paper provides an overview of this constellation of challenges and some of the means being employed to address them.

Fully automatic and autonomous medical systems are already released and being used. Nurses and doctors have started adopting the technology to reduce manual work, and to provide more accurate service and impactful interventions to patients. Increased access, better outcomes, reduced costs and more personal and customized healthcare are the promise of AI. But unlike other commercial systems where performance is paramount, in healthcare, patient safety is the primary concern. There is a tremendous drive to capitalize on AI capabilities as soon as possible and as much as possible. However, there is a risk to AI's success. People expect infallibility from AI – far more than they expect from human physicians. As a result, only a few catastrophic events involving AI could spell doom for AI in healthcare.

In system safety practice a clear understanding of the terms we use, helps use accurately assess and communicate risk in the endeavor of achieving the safety of systems, products and services. Terms that have been a source of confusion in the past include hazard, risk, causal factor, catastrophic, critical, negligible, marginal, criticality, acceptable, control (as in "control" a hazard), conservative, failure condition, failure condition, source, mechanism and outcome. Some system safety practitioners use some of these terms a lot and some avoid them like the plaque. Some words like "hazard" have a variety of meanings depending on what industry they are used in. Some terms appear in some domains and never are used in another. Some terms are used by practitioners with a vague notion of their meaning and no sense of what the really mean. Miscommunication can be avoided by understanding that this can be a problem in communicating with other companies and domains, clearly defining terms and not assuming other practitioners have the same sense of a term as you do.

The integration of security measures into a well-founded safety assurance process is a growing demand in the domain of safety-critical systems. In many cases, the safety assurance procedures are well-established at companies. Even to tie in the most necessary security actions already present a major challenge. This paper deals with the first steps to setup a viable procedure to (co-)assure systems' safety and security at Frequentis AG, primarily in the sector of air traffic management.A research on the state of the art of co-assurance approaches has been conducted: existing analysis and risk evaluation methods, proposed procedures of certain certification standards, as well as novel approaches like the Safety-Security Assurance Framework. Furthermore, Frequentis' internal procedures, needs and (pre)conditions have been evaluated. Based on this research, a concept for a suitable co-assurance process has been developed. Additionally, interfacing gates during system development and handovers in system operation between the safety and security specialists of Frequentis have been created and already practiced. The results of this work can be used as an approach for a step-wise integration of security objectives into an existing safety assurance infrastructure to improve the safety management system.  

When a system Safety Function fails it is imperative to be able to identify and analyze the potential causal contributors in a timely way and support the conclusion with compelling evidence. Yet experience has shown that this can be a formidable challenge and far too often opinions and unsubstantiated claims end up being used to support the conclusion. This tutorial will separate problem solving from Root Cause Analysis (RCA) and provide necessary conditions for starting a causal analysis. A basic understanding of probability and data analysis is also included in this tutorial to enable the investigator to make informed decisions on how to navigate the process. Navigating a RCA is a step wise decision dependent process, and coverage of decision making using a hierarchical methodology is included. The tutorial provides guidance on how to create a comprehensive RCA that shows all relevant data and decision points, with supportive decision evidence, which converges onto the most likely causal contributors with closure (corrective actions). The contents of this tutorial are applicable to wide range of problem types and useful to practitioners in all walks of life and is not restricted to system failures.

This tutorial supports the ISSC37 theme regarding "training for both beginners to learn to utilize system safety methodology in their Journey to Excellence and for those more experienced safety professionals who want to discuss, explore and incorporate how others are effectively utilizing system safety in their on-going Journey to Excellence" by focusing on understanding and employing various system safety evaluation methodologies.Various system safety processes such as ISO-26262, MIL-STD-882E, and ARP-4761 are compared highlighting how each looks at identifying hazards, assessing risk, and developing safety critical requirements to prevent or manage potential hazardous situations. In addition, requirements development methodologies such as System Element Fault Analysis (SEFA, used within GM's System Safety Process) and STPA from MIT will be explored. As in past tutorials by these presenters, this tutorial uses a high-voltage automotive propulsion system as the example to illustrate how to identify potential hazards and then goes on to demonstrate how to determine and define associate safety requirements.The tutorial includes interactive sessions for attendees to participate in discussions and in activities that enable the attendees to use real world examples (via the high-voltage propulsion system framework) in a manner that illustrates the above-mentioned concepts and approaches.The tutorial concludes with a question and answer session related to system safety processes and methodologies presented.

The G-48 Committee develops technical and program criteria, procedures, and methodology for the application of system safety engineering at all phases of the life cycle of a system or equipment. It documents and disseminates standard analytical techniques for enhancing system safety and conducting industry surveys for the purpose of improving techniques for testing, collecting, and distributing historical operational system safety data.

This tutorial teaches fundamentals of system safety management with practical applications of establishing and maintaining a system safety department within an organization, and the use of standard recognized system safety tools to plan projects. Use of Preliminary Hazard Lists, Work Breakdown Structures/ parts lists, and use cases/processes or tasks in the envisioned life cycle will be emphasized. Using these tools, the attendee will see how to tailor the system safety programs and activities to maximize the return on system safety efforts, build project leadership's trust through leading indicators and be able to justify the cost through real project improvement.

The term Black Swan is a familiar concept in the context of high consequence operations. There is the continual concern that there may be an 'as yet' undiscovered flaw or lack of understanding in the design of a product, process or facility that could lead to a catastrophic event. Concern lies in the potential incompleteness of understanding of any design concept, implementation and associated assessment. Given that 'absolute confidence' may never be possible, the question arises as to how best to continue to search for such a possible flaw with a view to subsequent removal or mitigation. This at first sight appears to be a process without end but the level of commitment must be balanced against the detrimental consequence that could ensue given that a Black Swan might exist. But when is 'enough enough'? This subject is covered in the context of the ownership of nuclear warheads where the Black Swan can indeed be catastrophic should it exist. The paper is framed somewhat in terms of what can be learned from the general literature associated with Black Swan thinking.

Safety-Critical Systems and Safety-Critical Functions (SCF) must be the focus when conducting Functional Hazard Analyses and Functional Hazard Assessments (FHA). FHAs have become the prerequisite for software safety analyses since behavior of the software and systems must be well understood in the safety domain. Functional Safety models should focus on how the architecture and the physical system, the computer system and embedded software contributions ensure correct and predictable system behavior. On complex systems with software intensive SCFs, in-depth software safety analyses must go beyond the traditional hazard analysis process of documenting summaries of severity, probability, risk and mitigation. Functional Safety should be ingrained in the detailed design and code level software safety analyses using various proven models and modern tools to depict the safety attributes in the design of various complex system architectures. Model Based System Engineering (MBSE) Functional Analyses and Functional Safety subsets should focus on the many complex interactions in software and functional failure and fault conditions and situations that can lead to hazards. Functional safety tasks as part of, and beyond, the FHAs and software safety analyses should be integrated into models producing Safety Use Cases, Safety Activity Diagrams, and Functional Flow Diagrams to influence system and explicit safety requirements, design safety features, hazard mitigation, safety verification, and risk reduction actions in the design and operations leading to system certification. The end goal is to reduce the level of abstraction and depict safety attributes clearly with objective safety evidence in safety documentation to be used for approval and certification. Functional Safety can be implemented for various safety policies, methods, and best practices of different agencies, companies, and product lines.

This paper addresses the idea and concept development of a program to challenge Science, Engineering, and Technology Students (SETS) to incorporate a system safety component into their science and engineering fair projects. This concept development initiative was undertaken by the Virtual Chapter of the International System Safety Society (ISSS) to address a lack of criteria or guidance to assist local ISSS Chapters in promoting and and/or judging science and engineering fair projects in terms of system safety. Expectations are that such a program would be sponsored by the ISSS and its member Chapters. The development of the project concept has taken the form of a "Guidance and Criteria Handbook". The handbook would provide fair organizers an "all inclusive" source for the essential information, guidance, criteria, and basic system safety teaching aids necessary to successfully incorporate system safety into student project competitions. Further, it would provide the ISSS and its member Chapters the essential guidance and criteria for assisting fair organizers, sponsoring awards, mentoring, and judging the system safety component of the student projects. It will be noted that the program is not intended as a project "safety" program – it is specifically intended as a "system safety engineering" exercise. Most importantly, incorporating system safety concepts and processes into SETS science and engineering fair projects will: introduce aspiring young engineers, scientist, and technologist to the system safety engineering discipline and profession; and, encourage participants to actually employ basic system safety methodologies and techniques in the concept and design phases of their projects.

Undergraduate engineering degree programs in the United States as well as some other countries are accredited with reference to general criteria (which must be met by programs in all engineering disciplines) and program-specific criteria (which apply to a single engineering discipline (e.g., chemical engineering, mechanical engineering). Language pertaining to health, safety and environmental protection as a part of the student educational outcomes is found in the general accreditation criteria, historically (i.e., ABET's Criteria 2000) in section 3c. Recently, these general criteria have been substantially restructured, and the current criteria were approved in October 2017, with mandatory use beginning in the 2019-2020 accreditation cycle. This paper examines the impact of these accreditation criteria changes on the opportunities for infusing system safety philosophy and techniques into engineering curricula, and identifies opportunities for practicing system safety engineers to contribute to the improvement of engineering curricula.

According to the U.S. Bureau of Labor Statistics, the field of engineering is expected to expand as much as 10 percent over the next 10 years. The demand for engineers and scientists will continue to grow as governments and industry work to meet the challenges of a growing global population and dwindling resources. Contrary to this growth, a decreasing number of U.S. students are entering Science, Technology, Engineering and Math (STEM) degree programs that will prepare them for STEM careers. STEM outreach to youth has become a critical area of national interest to reverse this trend. Corporations, schools, recreational facilities and the like are implementing STEM outreach programming to expose youth to STEM fields which can provide exciting and engaging ways to inspire youth to pursue careers in these fields.This abstract proposes a roundtable discussion on STEM outreach. The roundtable will involve a panel of participants actively engaged in STEM outreach efforts to discuss activities, partnerships and best practices for STEM outreach. Additionally, specific initiatives and programming ideas to expose youth to system safety engineering via STEM outreach will be reviewed. Hands on demonstrations and activities will be provided during the panel. By informing and empowering conference attendees with techniques to perform STEM outreach in their local communities they will assist in developing future generations of scientists and engineers.

There has been a series of challenges to develop appropriate safety standards and methodologies as technology evolves, to ensure their safe implementation. These challenges, which first arose at the dawn of the industrial revolution, will inevitably continue. New technologies will always seek to forge ahead in a competitive marketplace, failure to do so will inevitably lead to organisational demise. However, such developments must be matched by a complement of research activity seeking to ensure that appropriate new safety standards and methodologies are put in place to maintain acceptable levels of risk. A new challenge now confronts us in the form of artificial intelligence (AI) where we stand at the frontiers of decison making in relation to what roles machines and humans should play with regard to optimal decision making and how these impact on safety. These impact on both, organisations which propose AI application and those which are responsible for setting standards and regulation. This is the subject for discussion in this paper.

As an engineering discipline System Safety Engineering is relatively new, with an origin in the 1960s. During the last 60 years the management approaches used by the discipline have evolved and six discrete ideas have come to the fore which can be characterized as phases or eras. The newer ideas have been implemented successfully by a few organizations whereas the larger government sponsored system safety programs within DOD, NASA and DOT for the most part remain using methods developed in the earlier eras. This paper describes the six eras, identifies their distinguishing features, and points to best practice documents which embrace and define each era.

The G-48 Committee develops technical and program criteria, procedures, and methodology for the application of system safety engineering at all phases of the life cycle of a system or equipment. It documents and disseminates standard analytical techniques for enhancing system safety and conducting industry surveys for the purpose of improving techniques for testing, collecting, and distributing historical operational system safety data.

When a system Safety Function fails it is imperative to be able to identify and analyze the potential causal contributors in a timely way and support the conclusion with compelling evidence. Yet experience has shown that this can be a formidable challenge and far too often opinions and unsubstantiated claims end up being used to support the conclusion. This tutorial will separate problem solving from Root Cause Analysis (RCA) and provide necessary conditions for starting a causal analysis. A basic understanding of probability and data analysis is also included in this tutorial to enable the investigator to make informed decisions on how to navigate the process. Navigating a RCA is a step wise decision dependent process, and coverage of decision making using a hierarchal methodology is included. The tutorial provides guidance on how to create a comprehensive RCA that shows all relevant data and decision points, with supportive decision evidence, which converges onto the most likely causal contributors with closure (corrective actions). The contents of this tutorial are applicable to wide range of problem types and useful to practitioners in all walks of life and is not restricted to system failures.