Beágyazott elektronikus rendszerek P-ITEEA_0033
Kiber-fizikai rendszerek (Cyber-Physical Systems)
11. előadás 2015. május 6.
Á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
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)
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)
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. 5 Azaz az irányító felület azt mondja, merre menjen, és nem azt, hogy hogyan.
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
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
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
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
12
A
Jövő: magukat vezető, egymással kommunikáló járművek
13
14
15
Example 4: Smart Industry (Industrie 4.0)
16
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
19
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
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
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
CPS Requirements 1. Safety – 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
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
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
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
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
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
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
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!
Implementation 20%
– 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…
80% Debugging & Verification Avionic Development Cost 31
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… (by Prof. Edward Lee)
• This is fine for general purpose computing, but not for CPS – the physical system uses real time!
32
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.
33 (by Prof. Edward Lee)
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
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
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.
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
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
Ajánlott irodalom E. A. Lee and S. A. Seshia: Introduction to Embedded Systems - A CyberPhysical Systems Approach, Edition 1.5, LeeSeshia.org, 2014.
Internetről letölthető!
39
