Kiber-fizikai rendszerek (Cyber-Physical Systems)

Átírás

1 Beágyazott elektronikus rendszerek P-ITEEA_0033 Kiber-fizikai rendszerek (Cyber-Physical Systems) 11. előadás május 6.

2 Áttekintés A kiber-fizikai rendszerek definíciója Példák a kiber-fizikai rendszerekre A kiber-fizikai rendszerek tervezésének alapgondolatai 2

3 The Next Computing Revolution Mainframe computing (60 s 70 s) Large computers to execute big data processing applications Desktop computing & Internet (80 s 90 s) One computer at every desk to do business/personal activities Ubiquitous computing (00 s) (mindenütt jelenlevő) Numerous computing devices in every place/person Millions for desktops vs. billions for embedded processors Cyber Physical Systems (10 s)

4 Kiber-fizikai rendszerek eredete Informatikus szemmel a számítógépek PC-k, szerverek Kézi eszközök, beágyazott rendszerek Beágyazott rendszerek 70-es évektől (mp megjelenése) léteznek A számítástudomány nagyon erősen optimalizált kis számítógépekként kezelte Internet of things (IoT) Industrial Internet, Machine-to-Machine (M2M), the Internet of Everything, the Smarter Planet, TSensors (Trillion Sensors), or The Fog (like The Cloud, but closer to the ground), Hálózatba kapcsolt érzékelő beavatkozók, de még nem élnek annyira együtt a fizikai valósággal, illetve nincsenek kritikus helyzetekre is kidolgozva, hogy kiber-fizikai rendszereknek lehessen hívni őket 4 (mobiltelefon vs. autó ABS rendszere)

5 Kiber-fizikai rendszerek definíciója Cyber-Physical Systems Cyber Számítás, kommunikáció, kontroll (diszkrét, logikai vagy kapcsolt) Physical Természetes vagy ember által készített valós fizikai rendszerek, amelyek a fizika törvényei szerint működnek, folytonos dinamikával rendelkeznek Cyber-Physical Systems (CPS) Olyan rendszerek, amelyekben a két világ szorosan összeforr minden szinten Nem csak a beágyazott mikroprocesszoros egység a CPS, hanem a teljes irányított fizikai rendszer. Az ember alkotta fizikai rendszer és az azt vezérlő kiber és hálózati tér együtt kerül megtervezésre és kialakításra A kiber-fizikai rendszerek várhatóan úgy átalakítják a fizikai rendszerek világát, ahogy az emberek kapcsolat rendszerét az Internet. Példa: 10 éve egy modell helikopter távirányítója a kormányműveket direkt vezérelte. Mivel a rendszer instabil, tapasztalatlan ember azonnal összetörte. Ma egy ilyen helikopternek ha elengedi az ember a kormányát, akkor az megáll a levegőben. Azaz az irányító felület azt mondja, merre menjen, és nem azt, hogy hogyan. 5

6 Kiber-fizikai rendszerek jellemzői Kiber-fizikai rendszerek (Industrie 4.0 németül) Kiber-fizika illetve a kiber-tér szavakat a görög kibernetes (kubernhthz) irányító szóból származtatják (kibernetika) Fizikai rendszereknek monitorozása/vezérlése/irányítása érzékelés-beavatkozás kommunikáció A kiber-fizikai rendszerek együtt élnek a fizikai környezettel (szimbiózis) A környezet dinamikája és a számítógép dinamikája összeforr Új fogalmat kap az időzítés, mivel a fizikai rendszer dinamikájával kell együttműködnie Egy PC-nél ha egy szoftver lassan válaszol, arra nem azt mondjuk, hogy hibás, hanem azt, hogy kevésbé értékes Egy autó légzsákja ha késik egy másodpercet, azt hibásnak tekintjük Kiber-fizikai rendszerek hálózaton keresztül kommunikálnak Kihívás A fizikai rendszerek dinamikája sok párhuzamos folytonos dinamikából áll össze A számítógép szekvenciális program diszkrét idejű végrehajtásával kell olyan szoftvert készíteni, amely a fizikai rendszer párhuzamos dinamikai folyamatait vezényli

7 Tipikus kiber-fizikai rendszer Három fő komponens Fizikai rendszer Egy vagy több számító egység Kommunikációs hálózat Fizikai rendszer irányítása Teljes irányító hurok megvalósul Szenzor Kontrol egység Beavatkozó 7

8 8

9 A kiber-fizikai rendszerek lehetőségei A CPS rendszerek új tulajdonságokkal ruházzák fel a fizikai rendszerinket A számítás és a kommunikáció összeházasítása a fizikai folyamatinkkal Biztonságosabb és hatékonyabb rendszerek Alacsonyabb üzemeltetési költségek Új lehetőségek megjelenése az egyes rendszerekben A CPS fejlődésének technológiai és gazdasági hajtóerői A számítás/érzékelés/kommunikáció egyre alacsonyabb ára A nagy kiépült rendszerekhez könnyű/olcsó akár globális szinten is csatlakozni (GPS, GSM) A társadalmi és gazdasági elvárások a fizikai rendszereink hatékonyabb kihasználását igénylik 9

10 A kiber-fizikai rendszerek szintjei Egy autó egyes alrendszereinek kiber-fizikai rendszerekkel való lecserélése (mai gyakorlat) Pl: fék, kormány, gáz Ezeknek a rendszereknek az összehangolása (mai gyakorlat) Pl: adapítv tempomat, sávkövetés Az autó teljes vezetése (kísérleti stádium) Autó konvojok együttes automatikus vezetése (kísérleti stádium) Teljes közúti közlekedés automatizálása (terv) Szállítási feladatok globális optimalizálása (terv) A közlekedés összekötése más globális alrendszerekkel (terv) Pl: energia alrendszer, környezetvédelem, 10

11 11

12 12

13 A Jövő: magukat vezető, egymással kommunikáló járművek 13

14 14

15 15

16 Example 4: Smart Industry (Industrie 4.0) 16

17 Example 4: Smart Industry (Industrie 4.0) Egymással kommunikáló Gépek Termékek Gyárak Operátorok Automatizált külső és belső anyagmozgatás Gyártás ütemezése, szétterítése különböző üzemek szabad kapacitásai között Gyártásközi ellenőrzés által talált sorozatos hibák azonnali automatizált gyártósor adaptációval történő javítása 17

18 18

19 19

20 Example 7: Smart agriculture Lokálisan: Öntözés, permetezés trágyázás csak oda és annyi és olyan, amelyik annak a bizonyos területnek kell Lokálisan időzített betakarítás Automatizált, egymással is kommunikáló munkagépek Globálisan: Összehangolt célzott termelés a gazdák között Automatizált hatékony szállítás Igények és a termékek automatikus találkozása Szállítás minimalizálás 20

21 Example 8: Smart grid Lokálisan: A fogyasztás összehangolása házon belül pl: ha mindegy mikor megy a mosó- vagy mosogatógép, akkor használjuk olyankor, amikor megy a napelem Fogyasztás összehangolása egy-egy kerületen belül pl: az ELMÜ szétosztja az elektromos autók töltését az éjszakára alhálózat szinten Globálisan: Termelés tárolás fogyasztás kontinens szintű ütemezése Önjavító hálózatok a hibák detektálásával és az egyes alternatív útvonalak pontos terheltségének ismeretében 21

22 Example 9: Military, law enforcement, rescue Gépesített felderítés Harctér teljes gépesítése Ember nélküli Gyalogság Légierő Flotta Önálló döntési jogkör átruházása a gépesített fegyvereknek Nem szükséges minden fegyvert távolról irányítani 22

23 23

24 1. Safety CPS Requirements All such systems interact with the environment. System failure can have catastrophic consequences. System correctness depends on both logical results and the time at which results are produced (real-time). 2. Performance Safety is number#1 requirement, but we still need to achieve sufficient performance. Many systems are resource constrained (in either weight, power, cost, etc.) 3. Interoperability Individual subsystems connected by open protocols. External attacks are possible! 24

25 CPS as multidisciplinary approach CPS design requires competences in Computer Architecture CAD & Embedded Design Software Engineering Control Formal Verification Real-Time Analysis plus whatever engineering field(s) are related to the design of the plant/actuator. Problem: all such field and subfields have very different design & development conventions. Perhaps we need a new science of CPS design? 25

26 Current Design Flow The picture below exemplifies a typical design flow for a subsystem. Analysis is required to verify that requirements are met. Analysis can only be performed after implementation. 26

27 Reliable CPS: not so much! In 2007, 12 F-22s were going from Hawaii to Japan. After crossing the IDL, all 12 experienced multiple crashes. No navigation No fuel subsystems Limited communications Rebooting didn t help F-22 has 1.7 million lines of code. F-22 Raptor

28 CPS Challenges - Safety Safety is hard to guarantee in interconnected and interdependent systems. 1. Do not trust communication channels. Ex: medical plug-and-play initiative is looking to interconnect medical devices using wireless technology. Problem: what happens if somebody jams the signal? Each subsystem must be independently safe. 2. Do not trust the users. Users are an (unfortunate) part of the systems. Users are very error prone: over 90% of avionic accidents are caused by flight crew/controllers. System must be protected against user mistakes 28

29 CPS Challenges - Safety 3. Do not trust lower-criticality subsystems. Medical pacemaker composed of multiple subsystems. Life-critical functionalities: base pacing, wiring, battery Non-critical functionalities: adaptive pacing, logging, programming, RF communication. Protect life-critical subsystem. Pacemaker 29

30 Verification & Certification How do we ensure safety? 1. Formal Verification Build a model of the systems. Prove (mathematically) that the system satisfies some safety property. Problem#1: no good model for the whole system. Problem#2: model is not implementation. 2. Certification Usually a process-based mechanism: show that you have performed all process step according to some standard (ex: DO178a/b/c, IEC 61508). Typically includes extensive testing. Very expensive. 30

31 CPS Challenges - Integration Putting the system together is much more challenging that implementing the individual subsystems. Individual productivity for safety-critical code is reported as 6 lines/day! F22: 1.7 million lines / 6 = 776 man-years Perhaps the US$66.7billion program cost is not a surprise Clearly the design process must be improved Debugging & Verification 80% Implementation 20% Avionic Development Cost 31

32 CPS Challenges - Timing Predictability The biggest architectural challenge. The lowest abstraction layer (transistors) is pretty deterministic we know how to compute exact timings. However, higher levels lose all concept of timing. Deep pipelining, caches, out-of-order and speculative execution Thread models, locking, interrupts This is fine for general purpose computing, but not for CPS the physical system uses real time! (by Prof. Edward Lee) 32

33 CPS Challenges - Timing Predictability We need to ensure that computation always finishes within guarantee time windows -> We are interested in worst-case performance, not average performance! Timing predictability The time that the system requires to perform an operation should exhibit little variation Such time should be easy to compute It should not be affected by other parallel operations in the system. (by Prof. Edward Lee) 33

34 Real-Time and Composability System correctness depends on: Logical correctness: system produces correct results. Temporal correctness: system produces results at the right time. Timing (real-time) analysis = verify temporal correctness. Ideally, we want composable analysis Verify each subsystem in isolation Then verify that there interaction is correct Unfortunately, this is very hard in practice Main issue: hardware and software resources shared among multiple subsystems. 34

35 Ex: Memory and Composability Issues Consider a dual-core system where last-level cache is shared among the cores. We run two virtual machines, each on one core. VM#A is safety critical, VM#B is not. If VM#B suffers a cache miss, it can replace a cache line of VM#A in last-level cache Result: VM#B delays VM#A. Criticality-inversion: the safety of VM#A depends on VM#B Plenty of other examples in modern architecture! Main memory I/O data transfers Interrupts Etc. 35

36 COTS Components So why don t we use more predictable components? Partially a performance problem. Commercial-Off-The-Shelf (COTS) components are often much faster than components designed for safety-critical systems. Ex: avionic SAFEbus: 60 Mbit/s PCI Express 3.0: over 16Gbyte/s Unfortunately, these hardware components are not designed to provide predictable performance.

37 What is Required - Isolation Isolation: one subsystem should not affect another unrelated subsystem. Current architectures are pretty good at logical isolation Ex: memory protection and privilege levels in the CPU make sure that a process can not mess with the memory of another process or the OS. but fairly poor at temporal isolation. Note #1: any and all hw isolation mechanisms are useless if not supported by the OS. Note #2: after the first OS was created, it took a while before hw architects started implementing protection mechanisms. 37

38 CPS Challenges Software Models Current software programming models and languages are inadequate to support CPS design. C is by far the most popular language for embedded systems. C has no intrinsic support for concurrency, timing parameters, synchronization, etc. POSIX libraries (ex: threads) are often used, but again lack any explicit concept of timing. Extremely common operations in controller implementation: specify that I want to execute an operation after a given amount of time specify that I want to complete an operation within a given amount of time Why do I need to use OS constructs (times, watchdogs) for this? 38

39 Ajánlott irodalom E. A. Lee and S. A. Seshia: Introduction to Embedded Systems - A Cyber- Physical Systems Approach, Edition 1.5, LeeSeshia.org, Internetről letölthető! 39