Lecture 3 CBSE in Embedded System Development

1
Lecture 3 CBSE in Embedded System Development
2
Agenda

• Embedded and Real-Time Systems
• ProCom
• Extra-Functional Properties
• PRIDE
• Lab2

3
What are Embedded Systems ?
special purpose computer built into a larger
device to perform a specific functionality by
combination of hardware and software
4
Interaction with the environment
An embedded system interacts with the environment
via sensors and actuators

• A sensor transforms physical data (temperature,
  pressure) to digital format
• Examples thermometer, microphone, video camera
• An actuator works the other way round -
  transforming digital data to physical format.
• Example motors, pumps, machines

Environment
Sensor
RT software system
Actuator
5
Does someone know an example of an embedded
system that you can find in a car?
6
An airbag
7
Correct results at the right time
Example An air bag must not be inflated too
late, nor too early!
8
What is a real-time system?
A real-time system is a system that reacts upon
outside events and performs a function based on
these and and gives a response within a certain
time. Correctness of the function does not only
depend on correctness of the result, but also the
timeliness of it.
9
Event driven vs. time driven systems

• Event driven real-time systems
• External events determines when a program is to
  be executed
• Often through interrupts
• Example telephone switches, video-on-demand,
  transaction systems
• Time driven real-time systems
• The system handles external events at predefined
  points in time
• Most often cyclic systems ? repeats a certain
  scenario
• Example ABS, control systems, manufacturing
  systems

10
Predictable vs. fast
A robot arm with good timing catches the passing
boll.
11
Predictable vs. fast
Too fast robot arm misses the passing boll!
12
What do you need to think about when developing
ES?
13
Heterogeneous Development Concerns

• Predictable
• react in well-specified ways and be highly
  dependable
• Real-time demands
• react correctly to events in a given interval in
  time
• Resource limitations
• memory
• bandwidth
• power

14
Current Trend
special purpose computer built into a larger
device to perform a specific functionality by
combination of hardware and software
special purpose computer built into a larger
device to perform a specific functionality by
combination of hardware and software

• Today, the software part increases
• Additional functionality
• HW functionality replaced by SW functionality

15
Problems in current development methods

• Traditional development method does not scale
  anymore (1 functionality/subsystem on 1 ECU)
• Software complexity
• Distribution
• Shared resources
• Need solutions to
• Manage software complexity
• Improve reusability
• Address some fundamental development concerns
• Timing demands
• Resource limitations
• Predictability

16
CBSEThe future of ES development?
17
Questions ???
18
General Requirements

• Cover the whole development process
• From early design up to deployment and synthesis
• Centered around a unified notion of components
• Collection of requirements, documentation, source
  code, analysis models, test results, etc.
• Enable the integration of various analysis
  techniques
• Manage and store the required/produced artefacts
  in a systematic way

19
Coexistence of Different Abstraction Levels

• Example of development process

Deployment
Requirements Specification
Component-Based Design
Reuse of an already existing solution
Partially implemented component
Fully implemented Component(architecture
modelsource codeanalysis model)
Sketch of component
Component repository
20
Different Concerns at Different Granularity Levels
21
(No Transcript)
22
ProCom

• A component model for
• distributed embedded systems

23
ProCom Key aspects (1)

• Rich design-time concepts
• A collection of development artefacts
• (source code, models of timing and resources,
  analysis results, documentation, etc.)
• Reuse all this information.
• Components of different maturity should be
  allowed to co-exist.

24
ProCom Key aspects(2)

• Components abstracted from physical deployment
• Different concerns depending on granularity
• Distribution, communication, analysis, etc.

Architectural model (CBD)
25
ProCom ? a Two-Layered Component Model
ProSys (upper layer)
System
26
ProSys the upper layer

• Components (subsystems)
• Active, possibly distributed.
• Interact through message ports.

27
ProSys communication

• Communication
• Asynchronous messages
• Explicit message channels
• Design entity for data shared between subsystems
• Not a physical message channel like a bus !

speed
28
ProSave the lower level

• Passive components(similar to task or function
  block)
• Interact through input- and output ports.
• Data ports
• Trigger port
• Component semantics
• Initially passive, receivinginput data.
• When triggered, read inputdata and turn active.
• Write output once.
• Return to the passive state.

29
ProSave the lower level

• More complex components can have
• Multiple output groups
• Output can be produced at different points in
  time.
• Each group written once per activation.
• Multiple input groups (services)
• Services can share state.
• Individual control flows

30
ProSave the lower level

• Separated data- and control flow

• Hierarchical nesting
• Primitive components (implemented in C)
• Composite components

31
ProSave the lower level

• Connectors for more elaborate control

• Data fork
• Data or

• Control fork
• Control join
• Control selection
• Control or

32
Modelling a ProSys subsystemin ProSave

• Message ports ? trigger and data
• Clocks and events

33
Electronic Stability Control in ProSys
34
Stability Control System in ProSave Primitive
Subsytems
35
ProCom Summary

• A component model for distributed
  control-intensive embedded systems
• Rich design-time component notion including
  models, properties, realisation, analysis
  results, etc.
• Two layers for addressing the different paradigm
  existing at different abstraction level
• ProSys Active subsystems, message passing.
• ProSave Passive components, trigger/data flow.

36
Questions ???
37
ProCom
Extra-functional properties ??? Analysis ???
38
A Huge List of Properties
...
39
Characteristics of Extra-Functional Properties

• Different representations
• numbers, intervals, formula, models, image, ...
• Different techniques to obtain the values
• model checking, measurement, calculation, expert
  estimate, ....
• Relation to different entities
• system, component, interfaces, links, ...
• Validity conditions context
• hardware, specific library, scheduling policy,
  usage Profile, other properties, ...

40
Example
value 10, kB version 1 timestamp
0801201744 source estimation
value 15, kB version 2 timestamp
0802201000 source measurement platform X
value 25, clock cycle version 1 timestamp
0901281100 source analysis platform X
value 30, clock cycle version 2 timestamp
0901051500 source estimation
41
Questions ???
42
PRIDE

• The ProCom
• Integrated Development Environment

43
Main Idea

• Emphasis on component development component
  reuse
• Seamless integration of analysis techniques

44
Components a central concept

• Components are the main units of development
• They follow the rich-desgin component concepts
• a component is the collection of all the
  artefacts produced or required during the
  development process
• Concretely, based on a predefined file structure
• Source code folder,
• Models folder,
• Documentation folder,
• Metadata file

45
The various facets of a component

• Component type
• Defines all the fixed parts of the component
• Characterised by
• a universally unique ID,
• a name (possibly non-unique)
• a architectural description (ports, services,
  etc.)
• a functionality
• Component instances
• Refer to the corresponding component type
• Used during the design and realisation of
  composite components
• Can have additional information, specific to that
  instance
• Ex worst case execution time

46
Overview of the Architecture
47

48
Demo
49
Questions ???
50
Introduction to Lab2
51
Objectives

• Apply component based software engineering
  principles to embedded system development
• Model an embedded system using a component based
  model
• Reuse components between systems
• Calculate its non functional properties
• Learn about composition and interaction semantics
• Uses a dedicated tool suite.

52
Expected Output

• Same system as for Lab1
• Archive files only (no folder) named
  Lab2X_Y.zip where Xyour name (and Yname of
  your teammate if you work in pair).
• 1 report explaining your design choices and
  calculation results
• The Project folder for your system
• Individual work (or in pair)
• But nothing else!
• Both have to submit the archive file
• Do not copy solutions from others !

53
Deadline

• Tuesday 08 February 2011 2359 (FIRM Deadline!)
• If you submit your work late, you fail one
  submission opportunity gt only one chance to
  pass the lab before Exam1!
• Remember.
• Lab2 must also be approved to before Exam 1

54
The assignment

• In 3 parts
• Modelling an industrial Baking Conveyor System
  using ProCom and PRIDE
• Practice reuse of components in adapting the
  system
• Calculate extra-functional properties on simple
  cases

55
The Industrial Baking Conveyor System

• Main parts
• Temperature Sensor
• Humidity Sensor
• Heating Unit
• Orchestrator
• Oven
• Conveyor Belt

56
Usage Scenario
Ensure that the conveyor belt and the oven are
working together
Orchestrator
Oven
Conveyor Belt
Carries the cookies from point A to point B in
passing by the oven
Oven monitors the temperature and humidity
sensor measurements and determines 1. if the heat
should be increased and 2. if the cookies are
cooked correctly
57
Part 1 - What you need to do?

• To model this system with ProCom and PRIDE
• Tip 1
• Start by understanding last year assignment
  (http//www.idt.mdh.se/kurser/cd5490/2010/Assignme
  nt202/index.htm )
• Use pen and paper before PRIDE
• Once you are sure of your solution. Model it in
  PRIDE
• Tip 2
• While designing components, think about reuse
• What would make that component more reusable?
• What would prevent to reuse that components in
  different systems

58
Part 2 - Reuse

• You want to develop software for a second type of
  industrial baking conveyor system

Ok
Waste
59
Part 2 - What you need to do?

• To model this second system with ProCom and PRIDE
• Tip
• Think carefully on the first system with reuse in
  mind
• What are the impacts of this change in the model
  you design for the first system?
• What are the components that you can reuse?
• What need to be added or modified? And Why?

60
Part 3 Calculate Extra-Functional Properties

• First on a simple example, you will need to
• Calculate static memory usage of whole system,
  based on static memory usage of all components
  used in system
• Calculate WCET of the system, based on all
  possible execution paths
• Then on the oven element of your system, you will
  need to
• Calculate static memory usage of element, based
  on static memory usage of all components used in
  system
• Calculate its WCET, based on all possible
  execution paths

61
Static Memory Usage and WCET

• Static memory usage (without considering the glue
  code)
• 10 (A) 8 (B) 6 ( C) 10 (D) 34
• Execution paths
• (I) A ? B ? D , (II) A ? C ? D
• WCET
• Path (I) 5 15 15 35
• Path (II) 5 20 15 40 WCET

62
Questions ?!?
Questions ?!!?