1. 1 Solution proposal Exam 19. Mai 2000 No help tools allowed

2. 2 Exercise 1a) When working with critical systems, there is some basic notation that needs to be known. Give a short description of the following expressions. i. Safety ii. Reliability

3. 3 Solution 1a) i.Safety: -A property of a system that means that it will not endanger human life or the environment. ii.Reliability: -The probability of a component, or system functioning correctly over a given period of time under a given set of operating.

4. 4 Exercise 1b) -A system can have requirements related to both safety and reliability. Explain and illustrate by using examples how it can be a conflict between these system requirements.

5. 5 Solution 1b) -Safety and reliability place conflicting requirements on a system. For example, a system with a failsafe state may guarantee safety by remaining in this safe ”failed” state. Such an arrangement would be safe, but would have zero reliability.

6. 6 Exercise 2a) There are many challenges when including software components into safety-critical systems. Which challenges will you emphasise?

7. 7 Solution 2a) Systems which includes software components will always involve high complexity, which make it difficult to develop a safe system and to assess the safety of the system. Small and unessential changes in input may have enormous effect on the software systems, contrary to hardware systems where small changes only gives small changes in the system’s behaviour (”bends before breaking”). We have limited experience and knowledge about this new technology compared to older hardware systems. The technology opens many possibilities, and often the focus is put on ”time to market”, ”cost to market” and ”fancy” functionality instead of good quality and sufficient safety.

8. 8 Exercise 2b) There are several programming languages one can choose between when creating a new system. Are all programming languages fitted for developing safety- critical systems? Give an argument for your answer.

9. 9 Solution 2b) No, not all languages are fitted for use in safety-critical systems. Only a minority of languages can be acceptable for such applications. In critical systems, the choice of language should be considered: The functional characteristics of the language: No standard programming language performs well in all of the functional characteristics defined by Carrè. One of the reasons for this is that most languages are developed for use in non-critical applications. Some languages are however more fitted than others. For example is Ada and Pascal better than C and C++. For very critical applications, safe subsets of languages as Ada and Pascal can be used. A subset is an restricted part of the language with the purpose to achieve higher safety and integrity in the language and to secure the verification. In addition, are annotations used, which means including formal comments in the program to define the programs functions and operations. The availability and quality of support tools: use well-known and validated compilators. The expertise available within the development team: developers working with a language they know well, will make less mistakes and work faster.

10. 10 Solution 2b) The main reason is that when developing safety- critical systems, one must have control on how the final system actually will behave when the program code is being developed. The language should therefore be clear and unambiguous defined, it should be fitted for implementing actual functionality, in addition to make it possible to verify the code with regard to its specification. -If testing should be possible, the system must be designed for testability –This puts constraints on the choice of programming language and on which properties in the languages that are used.

11. 11 Exercise 3a) What is meant by hazard and risk?

12. 12 Solution 3a) Hazard: -a situation in which there is actual or potential danger to people or to the environment. Risk: -The risk associated with a hazard is determined by its severity and its frequency of occurrence (quantitative). -By risk we mean the danger an unwanted event represents on people, environment or economical values (qualitative).

13. 13 Exercise 3b) What is the purpose of FMEA and HAZOP? Describe the basic characteristics of HAZOP.

14. 14 Solution 3b) Both are used to identify hazards. HAZOP: A structured ”brainstorming”. –A HazOp study is a systematic analysis on how deviations from normal operation in a system can arise and how these deviations can result in hazards. –The method is performed by using a set of guidewords and attributes. A HazOp study is typically conducted by a team of four to eight persons with detailed knowledge of the system. The group should include: –a hazop leader, which normally would be an engineer with extensive training in the use of HazOp. –experts in the application area as well as those directly concerned with the design of the system. Original list of guidewords com from chemical industry: –No, more, less, as well as, part of, reverse, other. Different guidewords will be given different interpretations depending on the industry concerned.

15. 15 Exercise 3c) What is the purpose of FTA and ETA? Describe the basic characteristics of these methods.

16. 16 Solution 3c) ETA: consequence analysis Takes as its starting point the event that can affect the system and tracks them forward to determine their possible consequences. Work forward! These events include both those associated with the expected operation of the system and fault conditions. Focus on barriers, which means special properties a system has to stop a potentially dangerous development.

17. 17 Solution 3c) FTA: a casual analysis Graphical method, which starts with an event directly related to an identified hazard, the top-event, and works backwards to determine their possible causes. -uses logical operators (AND-/OR-gates). Can be used for both qualitative and quantitative analyses. Deductive method: –Works –Find the causes.

18. 18 Exercise 3d) -Use the system sketch and the descriptions of the different system components given, and perform a FMEA of the components “avstandmåler”, fartsmåler” and “ kontrollenhet” Note, that a complete analysis is not required. The objective is to show how a FMEA is performed.

19. 19 Solution 3d) You should identify at least two failure modes for each component, and identify the following table :

20. 20 Exercise 3e) Perform a fault tree analysis on the code with the top event: Car speed will be more than 5 km/h higher than the car in front. This can be formulated as “delta>5”, were delta is the difference in speed between your own car and the car in front.

22. 22 Exercise 3f) -Is there something about the code that worries you?

23. 23 Solution 3f) In the code, the car’s speed will be changed in every loop in the while-loop. If not set_speed(speed()+d) is called, than set_speed(speed()-d) is called instead. A simple solution to this problem is to switch “else” to “else if distance() < 200”. As long as the distance is between 200 and 300 cm, the car’s speed will not be changed.

24. 24 Exercise 4a) -Give a short description of the various phases when developing safety-critical systems.

25. 25 Solution 4a) Hazard and risk analysis should be performed during the entire development process, integrated in the other activities. The planning of testing, verification and certification should start early in the development process.

26. 26 Solution 4a) Requirements and hazard analysis: The starting point of any development project is determined by the customers requirements which gives an abstract definition of what the system should do. These abstract requirements must be formalised into a functional requirements document. Once the functional requirements of the system have been established, hazard and risk analysis is performed to identify potential dangers in the system and to allocate an overall level of integrity. One of the outputs from these analyses is the safety requirements of the system. Hazard and risk analysis should then be performed during the entire development process, integrated in the other activities. Specification: From the functional and the safety requirements of the system a specification is produced, which will include measures for safety assurance in line with the integrity level assigned. Architectural design: Once the specification has been produced, this is used as the basis for top-level design, which defines the system architecture. The top-level design will split the system into smaller, more manageable modules to simplify design and testing. Specification will be produced for each module.

27. 27 Solution 4a) Module design: In detailed design each module will be designed. Module construction and testing. Then the modules will be coded and tested individually. System integration: Once the modules have been completed and verified, the process of system integration can begin Verification and validation: Once the system is complete and appears to be functioning correctly, the verification and validation of the entire system may begin. Certification: The final stage in highly critical project is to convince some external regulating body that the system is safe (use of standards and guidelines simplifies the certification process).

28. 28 Exercise 4b) -Explain how the development process may be understood in terms of diverse definitions and transformations. Discuss the process of verification with respect to this model.

29. 29 Solution 4b) The specification of a system undergoes a series of transformations as the system moves from its original customer requirements, through the specification, top- level design, detailed design etc. Each of these transformations produces a new, but hopefully equivalent definition of the original system. When producing critical systems it is vital that each of these transformations is correct. The task of ensuring that a new definition is equivalent to the previous form is referred as verification.

30. 30 Exercise 4c) -Why can a specification only be validated and not verified. What is the difference between validation and verification?

31. 31 Solution 4c) -Since the specification is compared to the requirements and the nature of the requirements are less precise and rarely complete, the specification can not be verified. Since the requirements not can be a complete system description, but the specification should be, it will not be possible to map the whole specification back to the requirements Verification: -the process of determining whether the output of a lifecycle phase fulfils the requirements specified by the previous phase -To demonstrate that the output of a phase conforms to its input, and not to show that the output is actually correct Validation: -the process of confirming that the specification of a phase, or the complete system, is appropriate and consistent with the customer requirements.

32. 32 Exercise 4d) Not relevant