Embedded System Design: Embedded Systems (ES) Foundations of Cyber-Physical Systems (CPS) Common characteristics Graphics: © Alexandra Nolte, Gesine Marwedel,

Präsentation zum Thema: "Embedded System Design: Embedded Systems (ES) Foundations of Cyber-Physical Systems (CPS) Common characteristics Graphics: © Alexandra Nolte, Gesine Marwedel,"—  Präsentation transkript:

1 Embedded System Design: Embedded Systems (ES) Foundations of Cyber-Physical Systems (CPS) Common characteristics Graphics: © Alexandra Nolte, Gesine Marwedel, 2003 Iwan Sonjaya,MT

2 Dependability CPS/ES must be dependable,
Reliability R(t) = probability of system working correctly provided that is was working at t=0 Maintainability M(d) = probability of system working correctly d time units after error occurred. Availability A(t): probability of system working at time t Safety: no harm to be caused Security: confidential and authentic communication Even perfectly designed systems can fail if the assumptions about the workload and possible errors turn out to be wrong. Making the system dependable must not be an after-thought, it must be considered from the very beginning

3 Efficiency CPS & ES must be efficient
Code-size efficient (especially for systems on a chip) Run-time efficient Weight efficient Cost efficient Energy efficient

4 Importance of Energy Efficiency
“inherent power efficiency of silicon“ Efficient software design needed, otherwise, the price for software flexibility cannot be paid.

5 CPS (Cyber-Physical Systems) & ES (Embedded Systems) Hardware
CPS & ES hardware is frequently used in a loop (“hardware in a loop“): Cyber-physical systems (!)

6 Real-time constraints
CPS must meet real-time constraints A real-time system must react to stimuli from the controlled object (or the operator) within the time interval dictated by the environment. t execute “A real-time constraint is called hard, if not meeting that constraint could result in a catastrophe“ [Kopetz, 1997]. All other time-constraints are called soft. A guaranteed system response has to be explained without statistical arguments [Kopetz, 1997].

7 Real-Time Systems & CPS
CPS, ES and Real-Time Systems synonymous? For some embedded systems, real-time behavior is less important (smart phones) For CPS, real-time behavior is essential, hence RTS  CPS CPS models also include a model of the physical system

8 Reactive & hybrid systems
Typically, CPS are reactive systems: “A reactive system is one which is in continual interaction with is environment and executes at a pace determined by that environment“ [Bergé, 1995] Behavior depends on input and current state.  automata model appropriate, model of computable functions inappropriate. Hybrid systems (analog + digital parts).

9 Dedicated systems Dedicated towards a certain application Knowledge about behavior at design time can be used to minimize resources and to maximize robustness Dedicated user interface (no mouse, keyboard and screen) Situation is slowly changing here: systems become less dedicated

10 Security Defending against Connectivity increases threats
Cyber crime („Annual U.S. Cybercrime Costs Estimated at $100 Billion; …[Wall Street Journal, ]) Cyber attacks ( Stuxnet) Cyber terrorism Cyber war (Cyber-Pearl-Harbor [Spiegel Online, ]) Connectivity increases threats entire production chains can be affected local islands provide some encapsulation, but contradict idea of global connectedness

11 Dynamics Frequent change of environment

12 Underrepresented in teaching
CPS & ES are underrepresented in teaching and public discussions: “Embedded chips aren‘t hyped in TV and magazine ads ...” [Mary Ryan, EEDesign, 1995] Not every CPS & ES has all of the above characteristics. Def.: Information processing systems having most of the above characteristics are called embedded systems. Course on embedded systems foundations of CPS makes sense because of the number of common characteristics.

13 Characteristics lead to corresponding challenges
Dependability Efficiency In particular: Energy efficiency Hardware properties, physical environment Meeting real time requirements …. © Graphics: P. Marwedel, 2011

14 Challenges for implementation in hardware
Early embedded systems frequently implemented in hardware (boards) Mask cost for specialized application specific integrated circuits (ASICs) becomes very expensive (M$ range, technology-dependent) Lack of flexibility (changing standards). Trend towards implementation in software (or possibly FPGAs, see chapter 3)

15 Challenges for implementation in software
If CPS/ES will be implemented mostly in software, then why don‘t we just use what software engineers have come up with?

16 It is not sufficient to consider CPS/ES as a special case of SW engineering
Knowledge from many areas must be available, Walls between disciplines must be torn down Zu den Problemen bei der Entwicklung eingebetteter Systeme gehört weiterhin, dass eigentlich eine enge Kooperation zwischen der Informatik und der Elektrotechnik erforderlich wäre. Ich habe einmal versucht, dies besonders drastisch darzustellen. <click> Nach wie vor gelingt, es aber immer noch nicht in dem erforderlichen Maß, die Wände einzureißen. Das Umbenennen von Fakultäten und Lehrstühlen stellt keinen wirklichen Fortschritt dar. Es gibt Ansätze der Kooperation, aber immer noch kann man meist erkennen, ob jemand „von Haus aus“ Informatiker oder Elektrotechniker ist. medicine, statistics, ME, biology Physics CS EE

17 Challenges for CPS/ES Software
Dynamic environments Capture the required behaviour! Validate specifications Efficient translation of specifications into implementations! How can we check that we meet real- time constraints? How do we validate embedded real- time software? (large volumes of data, testing may be safety-critical) © Graphics: P. Marwedel, 2011 Diese Komplexität ist daher auch ein Element in dieser Liste der Probleme mit eingebetteter Software. Dazu gehört weiter das Problem der sich rasch ändernden Umgebungen, für die existierende Protokolle vielfach nicht ausgelegt sind. Trotz neuer Technologien sind die Bandbreiten der Kommunikation in solchen Umgebungen begrenzt und die Verbindungen häufig nur temporär vorhanden. …. © Graphics: P. Marwedel, 2011

18 Software complexity is a challenge
Software in a TV set Source 1*:  Exponential increase in software complexity ... > 70% of the development cost for complex systems such as automotive electronics and communication systems are due to software development [A. Sangiovanni-Vincentelli, 1999] Year Size 1965 1979 1 kB 1990 64 kB 2000 2 MB Zu den Problemen gehört auch die konkrete Entwicklung eingebetteter Systeme: Applikationsspezifische Hardware kann in vielen Fällen nicht mehr eingesetzt werden, sei es wegen der hohen Kosten der Maskenherstellung bei fortgeschrittenen Technologien, sei es weil Algorithmen heute flexibel gehalten werden müssen und eine Änderung nach Auslieferung in vielen Bereichen unumgänglich wird. Allerdings ist auch die Entwicklung von Software nicht ohne Probleme. Aufgrund der Komplexität steigen die Kosten für die Entwicklung von Software stark an und sie machen in manchen Bereichen, wie hier für den Automobilbereich genannt, bereits einen hohen Prozentsatz der Kosten überhaupt aus. Weiter ist auch der stark steigende Umfang von Software ein Problem. Am Beispiel von Software in Fernsehern hat man einen exponentiell steigenden Umfang festgestellt. In manchen Bereichen steigt die Komplexität auf geradezu dramatische Weise. So wurde beispielsweise von ST Microelektronics berichtet, dass sich der Umfang an Software teilweise alle 9 Monate verdoppelt. Source 2°: 10x per 6-7 years Year Size 1986 10 KB 1992 100 kB 1998 1 MB 2008 15 MB * Rob van Ommering, COPA Tutorial, as cited by: Gerrit Müller: Opportunities and challenges in embedded systems, Eindhoven Embedded Systems Institute, 2004 ° R. Kommeren, P. Parviainen: Philips experiences in global distributed software development, Empir Software Eng. (2007) 12:

19 Design flows Graphics: © Alexandra Nolte, Gesine Marwedel, 2003

20 Hypothetical design flow
Design repository Specification Design ES-hardware Test * Application Knowledge Application mapping Evaluation & Validation (energy, cost, performance, …) Optimization System software (RTOS, middleware, …) * Could be integrated into loop Generic loop: tool chains differ in the number and type of iterations

21 Iterative design (1): - After unrolling loop -
Example: SpecC tools

22 Iterative design (2): - After unrolling loop -
Example: V-model Requirement analysis System architecture System design Software architecture Software design Unit tests Integration testing System integration Acceptance & use Skipping some explicit repository updates; very late integration, problems may be missed ..

23 Iterative design (3): - Gajski‘s Y-chart -

24 Summary Common characteristics
Challenges (resulting from common characteristics) Design Flows