23
Supporting evolving requirements in CPS by abstraction layers in the architecture Stefan Kowalewski, Andre Stollenwerk April 11 th 2011, ACPS, Chicago, IL

Supporting evolving requirements in CPS by …able/acps2011/presentations/1_Stollenwer...Supporting evolving requirements in CPS by abstraction layers in the architecture Stefan Kowalewski,

  • Upload
    others

  • View
    2

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Supporting evolving requirements in CPS by …able/acps2011/presentations/1_Stollenwer...Supporting evolving requirements in CPS by abstraction layers in the architecture Stefan Kowalewski,

Supporting evolving requirements in CPS by abstraction layers in the architecture

Stefan Kowalewski, Andre StollenwerkApril 11th 2011, ACPS, Chicago, IL

Page 2: Supporting evolving requirements in CPS by …able/acps2011/presentations/1_Stollenwer...Supporting evolving requirements in CPS by abstraction layers in the architecture Stefan Kowalewski,

2

Outline

Motivation: Lifelong evolving constraints

Abstraction Layers in rapid control prototyping

Model based generated code in medical engineering

Page 3: Supporting evolving requirements in CPS by …able/acps2011/presentations/1_Stollenwer...Supporting evolving requirements in CPS by abstraction layers in the architecture Stefan Kowalewski,

3

Lifetime Adaption

Fastened development process of embedded systems- Smart phones- Automotive assist systems- Biomedical engineering- Rapid prototyping (Fabbing @ home)

Result in continuous adaption to variations of constraints Requirement changes during runtime may throw back to

falling branch of V-model Changes can also result of usage of agile methods Moving boundary between design, development and

operation

Page 4: Supporting evolving requirements in CPS by …able/acps2011/presentations/1_Stollenwer...Supporting evolving requirements in CPS by abstraction layers in the architecture Stefan Kowalewski,

4

Design Constraints

Small adoptions during design process enable fast adoptions during life-time

Impossible aspects to predict during design time- All possible interactions- Use cases of a system’s life

Lifelong evolving requirements

Page 5: Supporting evolving requirements in CPS by …able/acps2011/presentations/1_Stollenwer...Supporting evolving requirements in CPS by abstraction layers in the architecture Stefan Kowalewski,

5

Approach: introduction of abstraction layers

Well defined interfaces between different modules

Increased interoperability

Lower effort in maintaining and lifetime development

Automated data management

Predictable code modules

Page 6: Supporting evolving requirements in CPS by …able/acps2011/presentations/1_Stollenwer...Supporting evolving requirements in CPS by abstraction layers in the architecture Stefan Kowalewski,

6

Outline

Motivation: Lifelong evolving constraints

Abstraction Layers in rapid control prototyping

Model based generated code in medical engineering

Page 7: Supporting evolving requirements in CPS by …able/acps2011/presentations/1_Stollenwer...Supporting evolving requirements in CPS by abstraction layers in the architecture Stefan Kowalewski,

7

Requirements

Software Engineering: reusability support of different

modeling environments maintainability configurable sensors

Control Engineering: modeling environment

e.g. Matlab / Simulink ability to simulate ability to change sensors

and actuators without reimplementing the model

Page 8: Supporting evolving requirements in CPS by …able/acps2011/presentations/1_Stollenwer...Supporting evolving requirements in CPS by abstraction layers in the architecture Stefan Kowalewski,

8

Simulation and code generation

Page 9: Supporting evolving requirements in CPS by …able/acps2011/presentations/1_Stollenwer...Supporting evolving requirements in CPS by abstraction layers in the architecture Stefan Kowalewski,

9

Architecture 1/2

Library

Velocity

.

.

.

Modeling Tool

Sensor-ModelC

all

… …

Abstraction Layer

Page 10: Supporting evolving requirements in CPS by …able/acps2011/presentations/1_Stollenwer...Supporting evolving requirements in CPS by abstraction layers in the architecture Stefan Kowalewski,

10

Architecture 2/2

Sensor 1

Sensor-Model Driver

Simulation RCP-System

Features:

• managed variability sensors / actuators

• change of Modeling Environment

• easy switch form simulation to RCP-System

Configuration-tool for Sensorand Actuators

Sensor 2

Abstraction Layer

Sensor-Model Driver

Basic Layer

ADC_Driver.o DIO_Driver.o PWM_Driver.o CAN_Driver.o SPI_Driver.o …

HIS ADC HIS DI HIS DO HIS PWM CAN SPI

Page 11: Supporting evolving requirements in CPS by …able/acps2011/presentations/1_Stollenwer...Supporting evolving requirements in CPS by abstraction layers in the architecture Stefan Kowalewski,

11

Variability

sensors or actuators:

model documentation

Page 12: Supporting evolving requirements in CPS by …able/acps2011/presentations/1_Stollenwer...Supporting evolving requirements in CPS by abstraction layers in the architecture Stefan Kowalewski,

12

Feature Tree – Parking Assistant

Parking Assistant

Distance

Left Distance

Ultrasonic Sensor

Ultrasonic Sensor

Front Distance

Infrared Sensor

Ultrasonic Sensor

Velocity

Impulse Front

Hall Impulse Rear

Sensors

Direction

Compass

User Commands

Remote Control

Simulation Remote Contr.

Debug

Simulation with Direction

Simulation without Direct.

Plant

Front Brake

Brake

Rear Brake

Steering

Actuators

Throttle

Back Distance

Right Dinstance

Algorithm with Direction

Algorithm with-out Direction

Controller

requires requires requires

requires

Page 13: Supporting evolving requirements in CPS by …able/acps2011/presentations/1_Stollenwer...Supporting evolving requirements in CPS by abstraction layers in the architecture Stefan Kowalewski,

13

Development of a Rapid-Control-Prototyping-System

Aspects:

• consistent modelbased Development

• systematic design of the Hardware- and Softwaresystem

• enable early simulation

• support the developer configuration sensors and actuators

• functional and nonfunctional requirements of a small company

Page 14: Supporting evolving requirements in CPS by …able/acps2011/presentations/1_Stollenwer...Supporting evolving requirements in CPS by abstraction layers in the architecture Stefan Kowalewski,

14

Evaluation: Engine Control Unit

integration of all Sensors and Actuators

evaluation with a real engine

Page 15: Supporting evolving requirements in CPS by …able/acps2011/presentations/1_Stollenwer...Supporting evolving requirements in CPS by abstraction layers in the architecture Stefan Kowalewski,

15

Outline

Motivation: Lifelong evolving constraints

Abstraction Layers in rapid control prototyping

Model based generated code in medical engineering

Page 16: Supporting evolving requirements in CPS by …able/acps2011/presentations/1_Stollenwer...Supporting evolving requirements in CPS by abstraction layers in the architecture Stefan Kowalewski,

16

System Setup of the SmartECLA Project

16

Page 17: Supporting evolving requirements in CPS by …able/acps2011/presentations/1_Stollenwer...Supporting evolving requirements in CPS by abstraction layers in the architecture Stefan Kowalewski,

17

Model Based Safety Measures

Page 18: Supporting evolving requirements in CPS by …able/acps2011/presentations/1_Stollenwer...Supporting evolving requirements in CPS by abstraction layers in the architecture Stefan Kowalewski,

18

Model Based Safety Measures - Example

Page 19: Supporting evolving requirements in CPS by …able/acps2011/presentations/1_Stollenwer...Supporting evolving requirements in CPS by abstraction layers in the architecture Stefan Kowalewski,

19

Software System Architecture

Operating System

Hardware Abstraction Layer

Data Provisioning Layer

Model

Wrapping Layer

Page 20: Supporting evolving requirements in CPS by …able/acps2011/presentations/1_Stollenwer...Supporting evolving requirements in CPS by abstraction layers in the architecture Stefan Kowalewski,

20

Wrapping Layer in Detail

DPL

M1 M2 M3

V1 V2 V3 V6V4 V5

Wra

pper

Operating System

Hardware Abstraction Layer

Page 21: Supporting evolving requirements in CPS by …able/acps2011/presentations/1_Stollenwer...Supporting evolving requirements in CPS by abstraction layers in the architecture Stefan Kowalewski,

21

Resulting SW architecture

Integration of model based generated code to existing code framework

Model changes do not cause changes in surrounding SW framework

Dynamic adaptations take place at compile time

Lean and static data management

Fully predictable memory consumption and runtime behavior of the data management

Page 22: Supporting evolving requirements in CPS by …able/acps2011/presentations/1_Stollenwer...Supporting evolving requirements in CPS by abstraction layers in the architecture Stefan Kowalewski,

22

Conclusion

Fuzzy boundary between development and operation

Improvements during development process- Efficient switching between simulation and real environment- Exchangeability of sensors and actuators- Exchangeability of development tools

Tendency to static and thus predictable code

Layered SW architecture enables SW partitioning

Page 23: Supporting evolving requirements in CPS by …able/acps2011/presentations/1_Stollenwer...Supporting evolving requirements in CPS by abstraction layers in the architecture Stefan Kowalewski,

23

Thanks for your attention !

DPL

M1 M2 M3

V1 V2 V3 V6V4 V5

Wra

pper

Operating System

Hardware Abstraction Layer

Questions, Comments, Suggestions… ?Parking Assistant

Distance

Left Distance

Ultrasonic Sensor

Ultrasonic Sensor

Front Distance

Infrared Sensor

Ultrasonic Sensor

Velocity

Impulse Front

Hall Impulse Rear

Sensors

Direction

Compass

User Commands

Remote Control

Simulation Remote Contr.

Debug

Simulation with Direction

Simulation without Direct.

Plant

Front Brake

Brake

Rear Brake

Steering

Actuators

Throttle

Back Distance

Right Dinstance

Algorithm with Direction

Algorithm with-out Direction

Controller

requires requires requires

requires