Cyber-physical Systems – A UMIC Perspective€¦ · Cyber-physical Systems: Consequences ! The...

Post on 18-Oct-2020

0 views 0 download

Transcript of Cyber-physical Systems – A UMIC Perspective€¦ · Cyber-physical Systems: Consequences ! The...

Cyber-physical Systems – A UMIC Perspective

Stefan Kowalewski

©Prof.  Dr-­‐Ing.  Stefan  Kowalewski  

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

©Prof.  Dr-­‐Ing.  Stefan  Kowalewski  

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

Folie 4 / Westerkamp / Januar 2013

Positionspapier des GMA-Fachausschusses 7.20 „Cyber-Physical Systems“

Thesen und Handlungsfelder „Cyber-Physical Systems: Chancen und Nutzen aus Sicht der Automation“ April 2013

Kowalewski Juli 2014

Folie 5 / Westerkamp / Januar 2013

Von der Automatisierungspyramide zur CPS-basierten Automation

Automatisierungspyramide

Betriebsleitebene

Prozess-leitebene

Steuerungs-ebene

Feld- ebene

CPS-basierte Automation

echtzeit-kritisch

Unternehmens-leitebene

Folie 6 / Westerkamp / Januar 2013

Statusreport des GMA-Fachausschusses 7.20 „Cyber-Physical Systems“

Industrie 4.0 CPS-basierte Automation „Forschungsbedarf anhand konkreter Fallbeispiele“ Juli 2014 •  3 Fallbeispiele •  4 Themenbereiche Als Konkretisierung und Ergänzung des Whitepapers „Forschungs- und Entwicklungsaktivitäten“ der Plattform Industrie 4.0

Statusreport

Industrie 4.0

CPS-basierte Automation

Forschungsbedarf anhand konkreter Fallbeispiele

CPS-basierte Automation: Forschungsbedarf anhand konkreter Fallbeispiele

Juli 2014

Kowalewski Juli 2014

Folie 7 / Westerkamp / Januar 2013

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

Kowalewski Juli 2014

Folie 8 / Westerkamp / Januar 2013

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

Kowalewski Juli 2014

©Prof.  Dr-­‐Ing.  Stefan  Kowalewski  

Three examples

Real-time capable

mobile devices Run-time validation Architecture

DPL

M1 M2 M3

V1 V2 V3 V6V4 V5

Wrapper

Operating System

Hardware Abstraction Layer

©Prof.  Dr-­‐Ing.  Stefan  Kowalewski  

Three examples

Real-time capable

mobile devices Run-time validation Architecture

DPL

M1 M2 M3

V1 V2 V3 V6V4 V5

Wrapper

Operating System

Hardware Abstraction Layer

©Prof.  Dr-­‐Ing.  Stefan  Kowalewski  

Android

§  RTAndroid -  Real-time capable scheduling -  Automatic real-time Garbage Collection -  Reliable wireless communication -  Accessing peripheral I/O -  Full backward compatibility

Run9me  Libraries  

Applica9on    Framework  

Applica9ons  

Linux  Kernel  

©Prof.  Dr-­‐Ing.  Stefan  Kowalewski  

§  Android 2.2 §  CPU: 528 MHz §  RAM: 192 MB

Available Hardware

§  Android 4.2.2 §  CPU: 2 x 1.7 GHz §  RAM: 2 GB

Google G1 Google Nexus 10 Galaxy S4

§  Android 4.2.2 §  CPU: 4 x 1.9 GHz §  RAM: 2 GB

©Prof.  Dr-­‐Ing.  Stefan  Kowalewski  

Scheduling Latency

§  Periodic execution: every 5 ms §  Non-RT process vs. RT process §  Additional CPU load

0

200

400

600

800

1000

0 5000 10000 15000 20000

Late

ncy

7780 2449

0 5000 10000 15000 20000 0

200

400

600

800

1000

Late

ncy

[ms] [µs] Non-RT Process RT Process

©Prof.  Dr-­‐Ing.  Stefan  Kowalewski  

Proof of concept: Android-PLC

§  Everything on a single device -  Write PLC programs -  Compile -  Generate UI -  Run and simulate I/O

Write Execute

Parse Generate Compile

Shared Library

C++ {}

Abstract Syntax Tree

ST

Original Code Generated Code

§  Model transformation & code generation

©Prof.  Dr-­‐Ing.  Stefan  Kowalewski  

Performance Evaluation

PROGRAM PLC_PRG1 VAR i : DINT; counter : DINT; END_VAR VAR_OUTPUT out : BYTE; END_VAR FOR i := 0 TO 10000 DO counter := counter + 1; END_FOR out := out + 1; END_PROGRAM

Structured Text

Device   Avg.  (µs)   Max.  (µs)  

ABB  PM554   5000,0   6000,0  

Google  G1   1072,3   1220,7  

Nexus  10   128,6   182,2  

§  PLC: ABB PM554 §  RTAndroid

-  Google G1 and Nexus 10 -  Inside a real-time process -  With or without CPU load

©Prof.  Dr-­‐Ing.  Stefan  Kowalewski  

Three examples

Real-time capable

mobile devices Run-time validation Architecture

DPL

M1 M2 M3

V1 V2 V3 V6V4 V5

Wrapper

Operating System

Hardware Abstraction Layer

Formal  Verifica9on  of  SoRware  

Code  (or  Model)  

Formal  Model  

Requirements  

Formal  Specifica9on  

Checking  Algorithm    

sa9sfies?  

„Yes“   Hint  for  bug  search  

Model  of  PLC  Program  Execu9on  

PLC  program  

var1=7,  var2=10  

Inputs   Outputs  0  0  12  

TRUE  

47  FALSE  FALSE  0  

Model  of  PLC  Program  Execu9on  

PLC  program  

var1=7,  var2=10  

Inputs   Outputs  

in   out  var  

0  0  12  

TRUE  

47  FALSE  FALSE  0  

“State”:  

Model  of  PLC  Program  Execu9on  

in   out  var  

Model  of  PLC  Program  Execu9on  

in  

in’   in’’  

out  

out’’  out’  

var  

var’   var’’  

Model  of  PLC  Program  Execu9on  

in  

in’   in’’  

out  

out’’  out’  

var  

var’   var’’  

...   ...   ...   ...  

Model  of  PLC  Program  Execu9on  

in  

in’   in’’  

out  

out’’  out’  

var  

var’   var’’  

...   ...   ...   ...  

Searching  the  “State  Space”  

input0,  input1   INPUT  

output0   OUTPUT  

var0   GLOBAL  

Type  BYTE   0..255  

input0  =   0   3  

255  

2 255  1  

…   …  

input1  =  

0  

1  0   0   0  0  

…   …  

…  …  

IF  input0+50  =<  100  THEN    output0  :=  var0;  

ELSE    var0  :=  input1;  

ENDIF;  

Searching  the  “State  Space”:  Abstrac9on  

25  

input0,  input1   INPUT  

output0   OUTPUT  

var0   GLOBAL  

Type  BYTE   0..255  

input0  =  

…  

input1  =  

…  

…  [0,  49]    [0,  255]    

[50,  255]    [0,  0]    

[50,  255]    [50,  255]    [1,  1]     [255,  255]    

IF  input0+50  =<  100  THEN    output0  :=  var0;  

ELSE    var0  :=  input1;  

ENDIF;  

Example:  Value  Set  Analysis    in  ARCADE.PLC  

26  

©Prof.  Dr-­‐Ing.  Stefan  Kowalewski  

Three examples

Real-time capable

mobile devices Run-time validation Architecture

DPL

M1 M2 M3

V1 V2 V3 V6V4 V5

Wrapper

Operating System

Hardware Abstraction Layer

©Prof.  Dr-­‐Ing.  Stefan  Kowalewski  

Example: Extra-corporal membrane oxygenation (ECMO)

2.0 l/min 2.0 l/min 2.0 l/min 2.0 l/min 2.0 l/min 2.0 l/min

©Prof.  Dr-­‐Ing.  Stefan  Kowalewski  

ECMO: State of the art

•  Completely manual operation

•  Permanent supervision

©Prof.  Dr-­‐Ing.  Stefan  Kowalewski  

Automated ECMO à SmartECLA (extra-corporal lung assistance)

©Prof.  Dr-­‐Ing.  Stefan  Kowalewski  

Measurement Validation - Blood Gas Sensor

©Prof.  Dr-­‐Ing.  Stefan  Kowalewski  

According Simulink Model

©Prof.  Dr-­‐Ing.  Stefan  Kowalewski  

Software System Architecture

Operating System

Hardware Abstraction Layer

Data Provisioning Layer

Model

Wrapping Layer

©Prof.  Dr-­‐Ing.  Stefan  Kowalewski  

Wrapping Layer in Detail

DPL

M1 M2 M3

V1 V2 V3 V6V4 V5

Wrapper

Operating System

Hardware Abstraction Layer

©Prof.  Dr-­‐Ing.  Stefan  Kowalewski  

Workflow Generation(exhaustive)

Model development

Translation (RTW)

Preprocessor

Compiler

S-Functions

Simulink Model

C-Code

universal DPL

Customised Code (specialized DPL)

Binary (ELF)

©Prof.  Dr-­‐Ing.  Stefan  Kowalewski  

©Prof.  Dr-­‐Ing.  Stefan  Kowalewski  

Thank you!