Good afternoon how address / ask translators It is my privilege today to share with you perspectives of systems engineering for safety critical

Transcription

1 Good afternoon how address / ask translators It is my privilege today to share with you perspectives of systems engineering for safety critical systems. Many of you come from impressive backgrounds and good understanding of software engineering so what can I add to your understanding of this domain? In a nutshell, as software engineers we focus on making good software, but as systems engineers we focus on making good systems. Even in this age of sophisticated software intensive systems, i these two perspectives are not identical, i with ihsignificant ifi consequences for the final results. 1

2 These are the primary topics of my presentation. 2

3 The Therac 25 case illustrates the difference between the perspectives of systems and software engineering. It is possible that this case is known already to many of you, but I will briefly outline the findings of many studies. This product was introduced in 1983 and used until 1987 when they were refitted to comply with FDA regulations. It was one of the early medical devices to rely more on software and computer based safety controls over hardware safety mechanisms and it qualified for pre market equivalence. Since the software was based on software already in use, and the linear accelerator was a minor modification i of existing i technology, designation of Therac 25 as equivalent to this earlier technology meant that Therac 25 bypassed the rigorous FDA testing procedures. In retrospect, this declaration of pre market equivalence seems optimistic in that most of the safety mechanisms were moved into the software, a major change from previous version of the machine. Analysts performing a Fault Tree Analysis assumed there were no design problems in the software and such events were assessed as highly improbable. After ceasing use of all machines, the company conducted an in depth analysis including the software, and finally received FDA approval for its final corrective action plan. This plan included numerous software fixes, the installation of independent, mechanical safety interlocks, and a variety of other safety related changes. Only by looking at the entire system, and not just the software as an independent deliverable, was the company able to overcome the initial weaknesses in the devices. 3

4 As we continue, I would like to review a few attributes that distinguish safety critical systems. Looking down the list, we see that many of these systems are used when time is collapsed; we can also observe that it is not the probability of such errors as much as their consequences, when they occur, that is the significant factor. As for the Therac 25, it is important that fault analysis scenarios also include these rare but devastating events. 4

5 Safety Critical Design is rooted in the disciplines of Human Factors and Ergonomics, the precursors of Interaction Design. Typical domains in which safety critical systems occur are process control, (for example, nuclear power plants), transportation (for example, air traffic control, railway signalling, intelligent transport systems), medical applications (for example, diagnostic and treatment devices in operating theatres) and emergency management (operations rooms). All of these domains have in common their increased reliance on software controls and the increased amount of embedded software. Safety measures can not be an afterthought, they must be designed into these products and into every relevant component. Identifying these opportunities to embedsafety into design is one role of the systems engineer. 5

6 Systems engineers address the specificities of Safety Critical Design by: Studying the socio technical context of the system Analysing the cognitive aspects and information needs of complex tasks (cognitive task analysis, link analysis) Eliciting and designing a (shared) mental model to support distributed cognition Developing patterns of interaction that enhance situational awareness Aiming to increase the resilience of the system as a whole, typically y through the addition of redundancy and fail safe shut down devices Performing a risk analysis to determine which risks can be tolerated, mitigated eliminated or transferred 6

7 It is often useful to broaden the discussion to include other "high consequence systems" whose failure can incur a high financial cost. Examples of such systems are broader than the previous one and include satellite or ambulance control, and financial systems. This figure represents the cycle of user's actions on the various components of a safety critical system. Retroaction is the situation where an action taken is contrary to a prior action. Interfaces must assist rather than hinder operators who must balance conflicting goals, e.g. air traffic controllers balancing the dual goals of efficient i air traffic management and the safety of the travelling public, onboard and on the ground. Designers of user interfaces in this area must address both usability and safety in an integrated way. Their methods must also accommodate a range of new technologies for supporting user interactions (i.e. internet based), and allow a collaboration between many kind of skills, viewpoints and disciplinary backgrounds. 7

8 What is usability in a safety critical context and how to evaluate it How to analyse and reduce the impact of human error through system specification and implementation What are possible models of human error that can improve our understanding of them How to guarantee the safety of the possible interactions How to design for robust co operation among the users in technologically mediated work One can observe some overlap between this list of issues, and the list of activities performed by systems engineers. 8

9 9

10 When segue to this slide, build on prior keynote speaker in automotive. Automotive safety is a subject that is well known and practiced here in Japan, and appreciated where ever Japanese cars are sold. Illustrated here are critical components in the drive by wire capabilities of the modern automobile. The goal of modern automotive systems, such as this, is to make the average driver as skilled as a professional driver in stabilizing i the car under special driving i conditions i thereby increasing overall road safety as well as the safety factors of the individual vehicle. 10

11 Where this slide overlaps, give credit to prior speaker. Main mention of this slide is the importance of ISO and other standards to level the playing field so that all participants in a given marked to compliant to these documents. When a whole industry adopts a standard, it becomes a normal expense and guidance factor for new products. 11

12 Automotive embedded systems have strongly grown in complexity due to the amount of functionalities available, the large number of interactions between these functions as well as the different domains they cover. The development of automotive embedded system is confronted to two main problems. First, the development of such systems requires the coordination between experts from different domains (e.g. materials, vehicle dynamics, thermodynamics, computer science) and the efficient (seamless) integration of their expertise within a common development process. Second, the development process should ldbe able to provide a guarantee for the system reliability (e.g. using well defined development stages with good traceability in between). This non functional requirement is strongly required for every system in order to ensure a given quality and even mandatory for safety critical systems when human life and health depend on the correct operation of the car. These systems impact vehicular safety. They are responsible for highly safety critical vehicle functions such as braking, steeringor recovery. The automotive industry has realized the value of standards to achieve these goals across the industry. Automotive is just illustrative when we extract some characteristics of products in general: that is, the need for engineers of multiple disciplines to work together, the needfor a smooth developmentprocessprocess that integratesreliabilityandsafety, reliability and safety, and a third factor, the need for reliability and safety over a long useful life with many potential maintenance interventions. 12

13 The V model has been around for decades, and is not new, but it is integrated into the ISO The v model is also a basic tool of the Systems Engineer and here we see the overlapping attention of engineering specialists and systems engineers. For safety critical systems we want to see SYSTEMS ENGINEERING performed, with all the checks and balances, and careful document preparation and review. The challenge for industry is to execute these processes and still produce an affordable product. 13

14 IEC is the standard governing the functional safety of programmable electronic systems. IEC = International Electrotechnical Commission. IEC is well established in the industrial process control and automation industry and is also influential in automotive, heavy machinery, mining, and other fields where safety and reliability are critical. The standard presents a lifecycle approach including risk assessment, design, integration, i testing, modification i and maintenance and safety management. 14

15 The IEC EN standard defines the software requirements and sets the safety lifecycle for software, including validation and verification. The safety lifecycle begins with a risk analysis to determine the Safety Integrity Level (SIL) required. SIL is a quantification of the magnitude of risk reduction required. SIL is determined based on a number of quantitative factors in combination with qualitative factors such as development process and safety life cycle management. The standard IEC EN 61508, defines SIL using requirements grouped into two broad categories: hardware safety integrity i and systematic safety integrity. i A device or system must meet the requirements for both categories to achieve a given SIL. PFD (Probability of Failure on Demand) and RRF (Risk Reduction Factor) of low demand operation for different SILs as defined in IEC EN are shown on this slide. For continuous operation, these change to the (Probability of Failure per Hour) Because SIL has a simple number scheme to represent its levels (1 4), a high level understanding of each level is typically all that is necessary to convey SIL at management levels. This saves management from having to understand the technical aspects of SIL, while allowing them to discuss their concerns. 15

16 Comprehensive technical integration of data and the separation of systems in terms of hardware and software, are recommended: represents an independent layer of protection, for the SIS enables a guaranteed dtechnical absence of retroactive ti effects avoids safety critical design, programming and operating errors arising from the combining of safe and non safe elements within a complex software or distributed hardware system, something which can also lead to unwanted shut downs ( human common cause failures) guarantees that operation, maintenance and safety critical changes are only performed by trained personnel is in keeping with the spirit of IEC 61508/11 enables the use of reliable safety systems that have already proven their operational dependability under real conditions 16

17 Systems and software engineering System life cycle processes This Slide illustrates the system lifecycle processes defined in the standard, and the relationship of the Technical Processes to the Project, Agreement, and Organizational Project Enabling Processes. Without the Technical Processes, the risk of project failure, especially for complex projects, is unacceptably high. One can notice that the processes map neatly to the previously displayed v model. The ISO/IEC 15288:2008 Technical Processes are invoked throughout the lifecycle stages of a system. Technical Processes are defined df d in ISO/IEC 15288:2008 as follows: The Technical Processes are used to define the requirements for a system, to transform the requirements into an effective product, to permit consistent reproduction of the product where necessary, to use the product to provide the required services, to sustain the provision of those services and to dispose of the product when it is retired from service. The Technical Processes define the activities that enable organization and project functions to optimize the benefits and reduce the risks that arise from technical decisions and actions. These activities enable products and services to possess the timeliness and availability, the cost effectiveness, and the functionality, reliability, maintainability, producibility, usability and other qualities required by acquiring and supplying organizations. They also enable products and services to conform to the expectations or legislated requirements of society, including health, safety, security and environmental factors. 17

18 Level 1: A sub system, substantially within one engineering discipline and one organisation. Examples include a PC motherboard, a car gearbox, a sand filter for water treatment, air conditioning, the antenna for an aircraft radio. Level 2: A system that involves two or more engineering disciplines and/or requires two or more organisations to design, build, operate or maintain it. Examples include an electricity power station, railway signalling, a car, a waste water treatment plant, a hotel. Level 3: A system of systems that impacts, or is impacted by, many disciplines and economic, social or environmental factors. Examples include the national rail and roads network, the telephone network and electricity supply. Extractedfrom Creatingsystems that work : A publication of the UK Royal Academy of Engineering

19 Systems engineering is an interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, performance, test, manufacturing, cost & schedule, training & support, and disposal. Take away // systemic (holistic) i and systematic 19

20 Systems Engineering integrates all the necessary disciplines and specialty groups into a team effort forming a structured development process that proceeds from concept to production to operation. Systems Engineering considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs. 20

21 Integrated system design encompasses a wide range of disciplines, skills and ideas. The six principles provide a pervasive framework for understanding the challenges of a system design problem and for educating engineers to rise to those challenges: 1.Debate, define, revise and pursue the purpose 2.Think holistically 3.Follow a systematic procedure 4.Be creative 5.Take account of the people 6.Manage the project and the relationships. 21

22 I then stepped back and considered what characteristics distinguish SE from other engineering disciplines. These emerged naturally from both experience and the literature. 22

23 23

24 The International Council on Systems Engineering (INCOSE) is a not for profit membership organization founded to advance the art and practice of systems engineering by helping individuals and enterprises turn complexity into competitive advantage. The Council is committed to shaping a future where systems approaches are preferred and valued in solving problems, whether providing solutions for product development or enabling holistic i solutions to global lchallenges. hll 24

25 Share, promote and advance the best of systems engineering from across the globe for the benefit of humanity and the planet. 25

26 To provide a focal point for the dissemination of systems engineering knowledge To promote international collaboration in systems engineering practice, education, and research To assure the establishment of competitive, scalable professional standards in the practice of systems To improve the professional status of all persons engaged in the practice of systems engineering To encourage governmental and industrial support for research and educational programs that will improve the systems engineering process and its practice 26

27 INSIGHT, quarterly newsletter since 1994 Systems Engineering: peer reviewed Journal since 1998, 4 issues per year Journal of Enterprise Transformation peer reviewed journal with IIE since 2011 Conference Proceedings since 1993 enote, periodic notifications 27

28 Products from Working Groups Free to the public on the Wb Web ( Tools Database Technical resource center From the Members Area on INCOSE Connect Measurement Primer Systems Engineering Handbook Systems Engineering gtechnical Vision 2020 Webinar archives Products and publications available for purchase through INCOSE Store 28

29 In 2004 INCOSE initiated the Certified Systems Engineering Professional (CSEP) program; ASEP and CSEP ACQ (2008); ESEP (2009) Certification Is Open to Everyone interested in being recognized formally for their knowledge of systems engineering Participation Is Voluntary INCOSE Members Receive Reduced Rates for Initial Certification and Renewal 29

30 30

31 31

32 Network with systems engineering professionals Subscriptions to publications Access to all INCOSE products and resources online Discounted prices for all INCOSE events and publications 32

33 33

34 34