• Save
Safety-Critical Embedded Systems Course
Upcoming SlideShare
Loading in...5
×
 

Safety-Critical Embedded Systems Course

on

  • 9,293 views

 

Statistics

Views

Total Views
9,293
Views on SlideShare
9,255
Embed Views
38

Actions

Likes
3
Downloads
0
Comments
0

3 Embeds 38

http://www2.imm.dtu.dk 23
http://www.slideshare.net 11
http://eselab.imm.dtu.dk 4

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Safety-Critical Embedded Systems Course Safety-Critical Embedded Systems Course Presentation Transcript

    • 02229: Safety-Critical Embedded Systems Lecture 1: Introduction Paul.Pop@imm.dtu.dk
    • Lecture outline • Course information – Examination: project • Embedded systems – Non-functional requirements • Real-time systems – Hard vs. soft • Safety-critical systems – Dependability attributes • Example application area – Automotive electronics Lecture 1/2
    • Course information • Contact – Paul Pop, course leader and examiner • Email: paul.pop@imm.dtu.dk • Phone: 4525 3732 • Office: building 322, office 228 • Webpage – CampusNet – http://eselab.imm.dtu.dk/cgi-bin/wiki.cgi/SCESCourse/Home • FeedBack [Edit this page] – anonymously add feedback about the course Lecture 1/3
    • Course information, cont. • Lectures – Language: English – 12 lectures + 1 invited lecture (from industry) – Lecture notes • available on CampusNet as a PDF file the day before – Reading materials • available on CampusNet as PDFs the day before • Examination – Project: 70% report + 20% presentation + 10% opposition • 5 ECTS points Lecture 1/4
    • Course information, cont. • Course literature (available as PDFs via CampusNet or DTV) 1. Laprie et al., Fundamental Concepts of Dependability 2. Barry W. Johnson, An Introduction to the Design and Analysis of Fault-Tolerant Systems 3. Neil Storey, Safety Critical Computer Systems, Addison Wesley (selected chapters) 4. Hermann Kopetz, Real-time Systems: Design Principles for Distributed Embedded Applications, Springer (selected chapters) 5. Giorgio Buttazzo, Hard Real-time Computing Systems: Predictable Scheduling Algorithms and Applications, Springer (selected chapters) Lecture 1/5
    • Project, cont. • Topic categories 1. Literature survey • See the “references” and “further reading” in the course literature 2. Tool case-study • Select a commercial or research tool and use it on a case-study 3. Software implementation • Implement a technique, e.g., error detection or fault-tolerance technique – Suggested topics on the course website: http://eselab.imm.dtu.dk/cgi-bin/wiki.cgi/SCESCourse/Project Lecture 1/6
    • Project, cont. • Examples of last year’s projects – Worst case execution time analysis— Theory and application – Scheduling Anomalies – A Fault-Tolerant Scheduling Algorithm for Real-Time Period Tasks with Possible Software Faults – Mars Climate Orbiter failure – ARIANE 5: Flight 501 Failure – London Ambulance Service – Hamming Correcting Code Implementation in Transmitting System – Application of a Fault Tolerance to a Wind Turbine Lecture 1/7
    • Project, cont. • Milestones – Sept. 21: Group registration and topic selection • Email to paul.pop@imm.dtu.dk – Oct. 26: Project report draft • Upload draft to CampusNet – Nov. 23: Report submission • Upload final report to CampusNet – Dec. 4: Project presentation and oral opposition • Upload presentation to CampusNet Lecture 1/8
    • Project, cont. • Project registration – E-mail Paul Pop, paul.pop@imm.dtu.dk Deadline: • Subject: 02229 registration Sept. 21 • Body: – Name student #1, CPR number, e-mail – Name student #2, CPR number, e-mail – Name student #3, CPR number, e-mail – Project title – Project details Project approval • Notes – Groups of up to 3 persons – Contact me if you can’t find project partners Lecture 1/9
    • Project presentation & opposition • Presentation of project Deadline: – 15 min. + 5 min. questions Dec. 5 • Oral opposition – Read the draft report – Prepare at least one question per group member • Ask the questions after the presentation Lecture 1/10
    • Project deliverables 1. Literature survey 2. Tool case-study – Written report – Case-study files • ~5000 words – Report • Structure • Document your work – Title, authors – Abstract 3. Software implementation – Introduction – Body – Source code with comments – Conclusions – Report – References • Document your work Deadline for draft: Deadline for final version Oct. 26 Nov. 23 Lecture 1/11
    • Project: important dates September 2007 October 2007 Su Mo Tu We Th Fr Sa Su Mo Tu We Th Fr Sa 2 34567 8 123 45 6 9 10 11 12 13 14 15 7 8 9 10 11 12 13 16 17 18 19 20 21 22 14 15 16 17 18 19 20 23 24 25 26 27 28 29 Upload Register 21 22 23 24 25 26 27 draft 30 28 29 30 31 November 2007 December 2007 Su Mo Tu We Th Fr Sa Su Mo Tu We Th Fr Sa 12 3 1 4 56789 10 2345678 Upload Present & final report oppose 11 12 13 14 15 16 17 9 10 11 12 13 14 15 18 19 20 21 22 23 24 16 17 18 19 20 21 22 25 26 27 28 29 30 23 24 25 26 27 28 29 Lecture 1/12
    • Embedded systems • Computing systems are everywhere • Most of us think of “desktop” computers – PC’s – Laptops – Mainframes – Servers • But there’s another type of computing system – Far more common... Lecture 1/13
    • Embedded systems, cont. • Embedded computing systems Computers are in here... – Computing systems embedded within electronic devices and here... – Hard to define. Nearly any computing and even here... system other than a desktop computer – Billions of units produced yearly, versus millions of desktop units – Perhaps 50 per household and per automobile Lots more of these, though they cost a lot less each. Lecture 1/14
    • A “short list” of embedded systems Anti-lock brakes Modems Auto-focus cameras MPEG decoders Automatic teller machines Network cards Automatic toll systems Network switches/routers Automatic transmission On-board navigation Avionic systems Pagers Battery chargers Photocopiers Camcorders Point-of-sale systems Cell phones Portable video games Cell-phone base stations Printers Cordless phones Satellite phones Cruise control Scanners Curbside check-in systems Smart ovens/dishwashers Digital cameras Speech recognizers Disk drives Stereo systems Electronic card readers Teleconferencing systems Electronic instruments Televisions Electronic toys/games Temperature controllers Factory control Theft tracking systems Fax machines TV set-top boxes Fingerprint identifiers VCR’s, DVD players Home security systems Video game consoles Life-support systems Video phones Medical testing systems Washers and dryers Our daily lives depend on embedded systems Lecture 1/15
    • General-purpose vs. special-purpose General-purpose systems Special-purpose systems Microprocessor market shares 99% 1% Lecture 1/16
    • What is an embedded system? • Definition – an embedded system special-purpose computer system, part of a larger system which it controls. • Notes – A computer is used in such devices primarily as a means to simplify the system design and to provide flexibility. – Often the user of the device is not even aware that a computer is present. Lecture 1/17
    • Characteristics of embedded systems • Single-functioned – Dedicated to perform a single function • Complex functionality – Often have to run sophisticated algorithms or multiple algorithms. • Cell phone, laser printer. • Tightly-constrained – Low cost, low power, small, fast, etc. • Reactive and real-time – Continually reacts to changes in the system’s environment – Must compute certain results in real-time without delay • Safety-critical – Must not endanger human life and the environment Lecture 1/18
    • Functional vs. non-functional requirements • Functional requirements – output as a function of input • Non-functional requirements: – Time required to compute output – Reliability, availability, integrity, maintainability, dependability – Size, weight, power consumption, etc. Lecture 1/19
    • Real-time systems • Time – The correctness of the system behavior depends not only on the logical results of the computations, but also on the time at which these results are produced. • Real – The reaction to the outside events must occur during their evolution. The system time must be measured using the same time scale used for measuring the time in the controlled environment. Lecture 1/20
    • Real-time systems, cont. Lecture 1/21
    • Real-time systems, cont. Lecture 1/22
    • Hard vs. soft • Definitions – A real-time task is said to be hard if missing its deadline may cause catastrophic consequences on the environment under control. – A real-time task is said to be soft if meeting its deadline is desirable for performance reasons, but missing its deadline does not cause serious damage to the environment and does not jeopardize correct system behaviour. • Definition – A real-time system that is able to handle hard real-time tasks is called a hard real-time system. Lecture 1/23
    • Hard vs. soft, cont. • Examples of hard activities – Sensory data acquisition – Detection of critical conditions – Actuator serving – Low-level control of critical system components – Planning sensory-motor actions that tightly interact with the environment • Examples of soft activities – The command interpreter of the user interface – Handling input data from the keyboard – Displaying messages on the screen – Representation of system state variables – Graphical activities – Saving report data Lecture 1/24
    • Murphy’s laws • Murphy’s general law – “If something can go wrong, it will go wrong” Major Edward A. Murphy, Jr., US Air Force, 1949 • Murphy’s constant – Damage to an object is proportional to its value. • Troutman postulates – Any software bug will tend to maximize the damage. – The worst software bug will be discovered six months after the filed test. • Green’s law – If the system is designed to be tolerant to a set of faults, there will always exist an idiot so skilled to cause a nontolerated fault. • Corollary – Dummies are always more skilled than measures taken to keep them from harm. • Johnson’s first law – If a system stops working, it will do it a the worst possible time. • Sodd’s second law – Sooner or later, the worst possible combination of circumstances will happen. • Corollary – A system must always be designed to resist the worst possible combination of circumstances Lecture 1/25
    • Genesis Space Capsule • Genesis capsule – Cost: $260 million – Collecting samples of the solar wind over 3 years period – Crashed in Sept 2004 due to the failure of the parachutes • Reason of crash – The accelerometers were all installed backwards. The craft’s autopilot never got a clue that it had hit an atmosphere and that hard ground was just ahead. Lecture 1/26
    • Mars Orbiter • One of the Mars Orbiter probes crashed into the planet in 1999. • It did turn out that engineers who built the Mars Climate Orbiter had provided a data table in “pound-force” rather than Newtons, the metric measure of force. • NASA flight controllers at the Jet Propulsion Laboratory in Pasadena, Calif., had used the faulty table for their navigation calculations during the long trip from Earth to Mars. Lecture 1/27
    • Lockheed Martin Titan 4 • In 1998, a LockMart Titan 4 booster carrying a $1 billion LockMart Vortex-class spy satellite pitched sideways and exploded 40 seconds after liftoff from Cape Canaveral, Fla. • Reason: fried wiring that apparently had not been inspected. The guidance systems were without power for a fraction of a second. Lecture 1/28
    • Therac-25 • Therac-25: – the most serious computer-related accidents to date (at least nonmilitary and admitted) – machine for radiation therapy (treating cancer) – between June 1985 and January 1987 (at least) six patients received severe overdoses (two died shortly afterward, two might have died but died because of cancer, the other two had permanent disabilities) – scanning magnets are used to spread the beam and vary the beam energy – dual-mode: electron beams for surface tumors, X-ray for deep tumors Lecture 1/29
    • Lecture 1/30
    • Denver Airport • Denver International Airport, Colorado: intelligent luggage transportation system with 4000 “Telecars”, 35km rails, controlled by a network of 100 computers with 5000 sensors, 400 radio antennas, and 56 barcode readers. Price: $186 million (BAE Automated Systems). • Due to SW problems about one year delay which costs $1.1 million per day (1993). • Abondoned in 2005 to save $1 million per month on maintenance Lecture 1/31
    • Reliability • Definition – Reliability is the probability of a component, or system, functioning correctly over a period of time under a given set of operating conditions. • Notes – “Function correctly” means: • Operating as defined within its specification • Was functioning correctly at the beginning of the period • No maintenance is carried out during the period – Reliability varies with time • The probability of operating correctly over one year is much lower than over a month – Important where continuous uninterrupted operation is essential • Flight-critical aircraft system Lecture 1/32
    • Availability • Definition – The availability of a system is the probability that the system will be functioning correctly at any given time. • Notes – Relates to a particular point in time, not period as reliability – Average availability • Example: during 1000 hours the system is out of operation for 1 hour, the average availability is 900/1000 = 0.999 – Important • High availability systems: telephone exchanges have just a few hours of “downtime” during their life-time • Safety-critical systems: a nuclear reactor shutdown system is employed infrequently, but it has to work correctly when needed Lecture 1/33
    • Failsafe operation • Definition – A system is failsafe if it adopts “safe” output states in the event of failure and inability to recover. • Notes – Example of failsafe operation • Railway signaling system: failsafe corresponds to all the lights on red – Many systems are not failsafe • Fly-by-wire system in an aircraft: the only safe state is on the ground Lecture 1/34
    • System integrity • Definition – The integrity of a system is its ability to detect faults in its own operation and to inform the human operator. • Notes – The system will enter a failsafe state if faults are detected – High-integrity system • Failure could result large financial loss • Examples: telephone exchanges, communication satellites Lecture 1/35
    • Safety-critical systems • Definitions – Safety is a property of a system that will not endanger human life or the environment. – A safety-related system is one by which the safety of the equipment or plant is ensured. • Safety-critical system is: – Safety-related system, or – High-integrity system Lecture 1/36
    • Developing safety-critical systems Requirements Completed system Hazard and Hazard and Certification Certification risk analysis risk analysis System System Specification Specification validation validation Architectural System Architectural System design verification design verification System System Module Module integration integration design design and testing and testing Module Module construction construction and testing and testing Lecture 1/37
    • Preliminary topics • Introduction • Fundamental concepts: faults, types, models; error detection • Dependability analysis • Fault-tolerance, techniques • Hazard and risk analysis • Scheduling, fundamental concepts • Time, clock synchronization • Periodic scheduling, schedulability analysis • System architecture and design Lecture 1/38
    • Example application area: automotive electronics • What is “automotive electronics”? – Vehicle functions implemented with electronics • Body electronics • System electronics (chassis, engine) • Information/entertainment Lecture 1/39
    • Automotive electronics market Cost of Electronics / Car ($) 1400 1200 1000 800 600 400 200 0 1998 1999 2000 2001 2002 2003 2004 2005 Market 8.9 10.5 13.1 14.1 15.8 17.4 19.3 21.0 ($billions) More than 25% of the total cost of a car is electronics Lecture 1/40
    • Typical automotive application Driver Switches Instruments Discrete Modes Reference Controller Actuators Continuous Sensors Physical environment (vehicle) Lecture 1/41
    • Non-critical: body and Infotainment Lecture 1/42
    • Safety-critical: brake-by-wire Lecture 1/43