Software Development in the Fields of Embedded Systems, Safety, and Security

Transcription

1 Software in the Fields of Embedded Systems, Safety, and Security, Erlangen, May 2007 Maritta Heisel Joint work with Denis Hatebur and Holger Schmidt University Duisburg-Essen, Faculty of Engineering, Department of Computer Science and Applied Cognitive Science 1/ 17

2 Experience in teaching resilient computing master course Embedded Systems master course of Safe and Secure Software at the University of Duisburg-Essen for students of applied computer science computer engineering (in a program International Studies in Engineering ) both focused on software development 2/ 17

3 Embedded Systems concrete process for developing embedded systems consisting of 12 steps, including requirements analysis system architecture software architecture component specification and implementation systematic testing each step resulting in some document(s) expressed mostly in UML notations validation conditions for checking coherence between documents practical training: development of small embedded system, e.g., tea timer, sun-blind control, fire detection system. 3/ 17

4 of Safe and Secure Software ongoing new course goal: integrate safety and security concerns in software development take standards (IEC 61508, CC) and human factors into account teach safety and security techniques for the different phases of software development, try to combine and integrate them practical part: based on CSP and FDR2 4/ 17

5 for teaching resilient computing establish a clear terminology take a system view, i.e., take environment into account pay special attention to problem analysis use patterns apply model-based development techniques consider notations as well as processes stress quality assurance: validation conditions systematic testing Note These principles are not only important for teaching, but also for engineering practice! 5/ 17

6 [Jac01] Machine thing we are going to build; may consist of software and hardware part of the world where the machine will be integrated System consists of machine and its environment Requirements optative statements; describe how the environment should behave when the machine is in action Specification implementable requirements; describe the machine; are basis for its construction Domain knowledge indicative statements; consist of facts and assumptions; needed to derive specification 6/ 17

7 Modeling the environment: context diagrams crossing waiting area of main road waiting area of secondary road enter, leave road users on lanes enter, leave see_red see_green see_yellow enter, leave lights on, off broken vehicle_waiting traffic lights control emergency_request fire brigade 7/ 17

8 analysis: problem diagrams TLC fault tolerance tlc!{on,off} l!{broken} lights light settings R6 In case of a broken light bulb the traffic lights should blink in yellow for the secondary road, after all red lights have been switched on for a period of time. R6 8/ 17

9 analysis: problem frames are patterns for simple development problems fitting a problem to some problem frame means instantiating the frame diagram example: required behaviour problem frame Control machine CM!C1 CD!C2 Controlled domain C C3 Required behaviour problem of previous slide is instance of required behaviour 9/ 17

10 are templates for the documents set up during the software development process serve to represent and re-use existing knowledge re-use achieved by instantiation can be used in different development phases: safety patterns for expressing safety requirements problem frames for problem analysis structuring the machine with architectural styles fine-grained design with design patterns programming with idioms... 10/ 17

11 Model-based development develop sequence of models, each describing different aspects of the system/machine abstraction is crucial models can be analyzed and checked for coherence sd InductionLoopIAL InductionLoopIAL vehicle_ waiting () srr () InductionLoopIAL wait_for_srr vehicle_waiting () / srr () try to provide patterns for the different models 11/ 17

12 natural language is hard to handle, does not fit well with model-based development approach use diagrammatic notations to express models, e.g. Jackson s context and problem diagrams UML notations, e.g. sequence diagrams, composite structure diagrams,... formal notations: useful, but difficult to apply important: notation should not prevent expressing relevant aspects Note matters! 12/ 17

13 Representing processes: agendas [Hei98] 13/ 17 es presented as tables, consisting of numbering of steps description of steps possibly hints for expressing the result of the steps validation conditions to check coherence of models No Step Validation Conditions 1 Fix the domain vocabulary. The vocabulary must contain exactly the notions 2 State the facts, assumptions and occurring in the facts, assumptions, requirements concerning the system in natural language. requirements, op- erations and events. 3 List the possible system operations that can be invoked by the users, together with their input and output parameters....

14 assurance achieved by checking validation conditions as specified in process descriptions systematic testing systematic testing: develop test cases during earlier phases of the development, i.e., before the implementation test against requirements also, not only against specification for this purpose: model environment by stochastic processes 14/ 17

15 On the Fly test approach using state machines Violation (7) State Machine Executor Requirements Violation (5) Model 2 AS Input Event Generator 1 tick AO 6b AS 3b Adapters AO 6a 4 CO CS 3a System Under Test CO: Concrete Observation AO: Abstract Observation CS: Concrete Stimulus AS: Abstract Stimulus tick: Request for new Abstract Stimulus Violation: Test Result 15/ 17

16 positive experience in Embedded-Systems course practical training is mandatory students worked in groups; all groups were able to produce a running system checking validation conditions turned out to be crucial grades were better than for other courses 16/ 17

17 Maritta Heisel. Agendas a concept to guide software development activites. In R. N. Horspool, editor, Proc. Systems Implementation 2000, pages Chapman & Hall London, Michael Jackson. Frames. Analyzing and structuring software development problems. Addison-Wesley, / 17