Cyber-physical Systems A UMIC Perspective. Stefan Kowalewski

Transkript

1 Cyber-physical Systems A UMIC Perspective Stefan Kowalewski

2 Cyber-physical Systems: Characteristics Integration of control systems with web/internet/cloud services Closing of control loops via networks Dynamic changes to the composition, structure, interconnection, and requirements of CPS at runtime - Permanent upgrades and additions of functionality ( apps ) - Dynamically changing environments/contexts - Rapidly changing requirements

3 Cyber-physical Systems: Consequences The boundary between design-time and run-time is blurring. Changes will be partly unforeseeable and discrete in nature. Success of a control system is critically depending on its ability to efficiently cope with such changes à Need for appropriate methods à Need for appropriate IT platforms

4 Positionspapier des GMA-Fachausschusses 7.20 Cyber-Physical Systems Thesen und Handlungsfelder Cyber-Physical Systems: Chancen und Nutzen aus Sicht der Automation April 2013 Folie 4 / Westerkamp Kowalewski / Januar Juli

5 Von der Automatisierungspyramide zur CPS-basierten Automation echtzeitkritisch Unternehmensleitebene Betriebsleitebene Feldebene Prozessleitebene Steuerungsebene Automatisierungspyramide CPS-basierte Automation Folie 5 / Westerkamp / Januar 2013

6 Statusreport des GMA-Fachausschusses 7.20 Cyber-Physical Systems Industrie 4.0 CPS-basierte Automation Forschungsbedarf anhand konkreter Fallbeispiele Juli Fallbeispiele 4 Themenbereiche Statusreport Industrie 4.0 CPS-basierte Automation Forschungsbedarf anhand konkreter Fallbeispiele Juli 2014 Als Konkretisierung und Ergänzung des Whitepapers Forschungs- und Entwicklungsaktivitäten der Plattform Industrie 4.0 Folie 6 / Westerkamp Kowalewski / Januar Juli

7 Vier Themenbereiche im Überblick 1. Übertragung von Standard-IT-Lösungen 2. Anpassung von Automatisierungslösungen 3. Änderungsfähigkeit zur Laufzeit 4. Durchgängiges Systems-Engineering Folie 7 / Westerkamp Kowalewski / Januar Juli

8 Vier Themenbereiche im Überblick 1. Übertragung von Standard-IT-Lösungen 2. Anpassung von Automatisierungslösungen 3. Änderungsfähigkeit zur Laufzeit 4. Durchgängiges Systems-Engineering Folie 8 / Westerkamp Kowalewski / Januar Juli

9 Three examples Real-time capable mobile devices Run-time validation Architecture M1 M2 M3 V1 V2 V3 V4 V5 V6 Wrapper DPL Operating System Hardware Abstraction Layer

10 Three examples Real-time capable mobile devices Run-time validation Architecture M1 M2 M3 V1 V2 V3 V4 V5 V6 Wrapper DPL Operating System Hardware Abstraction Layer

11 Android RTAndroid - Real-time capable scheduling - Automatic real-time Garbage Collection - Reliable wireless communication - Accessing peripheral I/O - Full backward compatibility Applica9ons Applica9on Framework Libraries Run9me Linux Kernel

12 Available Hardware Google G1 Google Nexus 10 Galaxy S4 Android 2.2 CPU: 528 MHz RAM: 192 MB Android CPU: 2 x 1.7 GHz RAM: 2 GB Android CPU: 4 x 1.9 GHz RAM: 2 GB

13 Scheduling Latency Periodic execution: every 5 ms Non-RT process vs. RT process Additional CPU load [ms] 1000 Non-RT Process [µs] 1000 RT Process Latency Latency

14 Proof of concept: Android-PLC Everything on a single device - Write PLC programs - Compile - Generate UI - Run and simulate I/O Write Execute Model transformation & code generation ST C++ {} Parse Generate Compile Original Code Abstract Syntax Tree Generated Code Shared Library

15 Performance Evaluation Structured Text PROGRAM PLC_PRG1 VAR i : DINT; counter : DINT; END_VAR VAR_OUTPUT out : BYTE; END_VAR FOR i := 0 TO DO counter := counter + 1; END_FOR out := out + 1; END_PROGRAM PLC: ABB PM554 RTAndroid - Google G1 and Nexus 10 - Inside a real-time process - With or without CPU load Device Avg. (µs) Max. (µs) ABB PM ,0 6000,0 Google G1 1072,3 1220,7 Nexus ,6 182,2

16 Three examples Real-time capable mobile devices Run-time validation Architecture M1 M2 M3 V1 V2 V3 V4 V5 V6 Wrapper DPL Operating System Hardware Abstraction Layer

17 Formal Verifica9on of SoRware Code (or Model) sa9sfies? Requirements Formal Model Formal Specifica9on Checking Algorithm Yes Hint for bug search

18 Model of PLC Program Execu9on Inputs TRUE PLC program var 1 =7, var 2 =10 Outputs 47 FALSE FALSE 0

19 Model of PLC Program Execu9on Inputs TRUE PLC program var 1 =7, var 2 =10 Outputs 47 FALSE FALSE 0 State : in var out

20 Model of PLC Program Execu9on in var out

21 Model of PLC Program Execu9on in var out in var out in var out

22 Model of PLC Program Execu9on in var out in var out in var out

23 Model of PLC Program Execu9on in var out in var out in var out

24 Searching the State Space input0, input1 INPUT output0 OUTPUT var0 GLOBAL Type BYTE IF input0+50 =< 100 THEN output0 := var0; ELSE var0 := input1; ENDIF; input0 = input1 =

25 Searching the State Space : Abstrac9on input0, input1 INPUT output0 OUTPUT var0 GLOBAL Type BYTE IF input0+50 =< 100 THEN output0 := var0; ELSE var0 := input1; ENDIF; input0 = input1 = [0, 49] [0, 255] [50, 255] [0, 0] [50, 255] [50, 255] [1, 1] [255, 255] 25

26 Example: Value Set Analysis in ARCADE.PLC 26

27 Three examples Real-time capable mobile devices Run-time validation Architecture M1 M2 M3 V1 V2 V3 V4 V5 V6 Wrapper DPL Operating System Hardware Abstraction Layer

28 Example: Extra-corporal membrane oxygenation (ECMO) 2.0 l/min 2.0 l/min

29 ECMO: State of the art Completely manual operation Permanent supervision

30 Automated ECMO à SmartECLA (extra-corporal lung assistance)

31 Measurement Validation - Blood Gas Sensor

32 According Simulink Model

33 Software System Architecture Model Wrapping Layer Data Provisioning Layer Operating System Hardware Abstraction Layer

34 Wrapping Layer in Detail M1 M2 M3 V1 V2 V3 V4 V5 V6 Wrapper DPL Operating System Hardware Abstraction Layer

35 Workflow Generation (exhaustive) S-Functions universal DPL Model development Simulink Model Preprocessor Compiler Translation (RTW) C-Code Customised Code (specialized DPL) Binary (ELF)

36 Prof. Dr- Ing. Stefan Kowalewski

37 Thank you!