lecture 4 component behavioral modeling with remes
DESCRIPTION
Lecture 4 Component Behavioral Modeling with REMES. Agenda. Background and Motivation REMES Connecting REMES and ProCom REMES Editor Lab2. Background and Motivation. Embedded systems “Computer that does not look like computer” Part of a larger system or machine Typical requirements - PowerPoint PPT PresentationTRANSCRIPT
Lecture 4
Component Behavioral Modeling
with REMES
Advanced Component-Based Software Engineering
Agenda
Background and Motivation REMES Connecting REMES and ProCom REMES Editor
Lab2
Advanced Component-Based Software Engineering
Embedded systems “Computer that does not look like computer” Part of a larger system or machine
Typical requirements Low cost Constantly react to changes in the environment Dependability Compute certain results in real-time without delay Limited available resources Manage the growing complexity of software
Need for solutions that Alleviate software complexity Ensure predictable system behavior
Background and Motivation
Advanced Component-Based Software Engineering
C2
{RC2}
C3
{RC3}
Cn
{RCn}
{RB} > {RC1}
C1
{RC1}B{RB
RepositoryRepository
Background and Motivation
Advanced Component-Based Software Engineering
Challenge construct component model for ES design enriched with
behavioral information support predictable system development and as such
guarantee absence or presence of certain properties prediction methods should be available already at early design
stage bottom-up resource analysis can guide the selection of components top-down resource analysis could help in correct decomposition of
system’s specification
Background and Motivation
Advanced Component-Based Software Engineering
REMES behavioural language
Advanced Component-Based Software Engineering
Resource Class Characteristics
A(memory)
discrete c´=0 or c’=inf referable
B(CPU, bandwidth)
discrete c’=0 or c´=inf non-referable
C(CPU, energy)
continuous c´=n, n in Z - {-inf,+inf} non-referable
Resource consumption- annotated with c;
accumulated resource usage up to some time point c’ - rate of consumption over time Classification of resources:
discrete or continuous nature referable or non-referable
Classification of resources
Advanced Component-Based Software Engineering
REMES – REsource Model for Embedded Systems
Behavioral model intended to describe the resource-wise behavior of interacting embedded components
Behavior of a component is a mode
Modes atomic composite
Advanced Component-Based Software Engineering
REMES - modes Mode M (SM, V, In, Out, E, RC, Inv, CC)
Control points In: (Init point, Entry point), Out: (Write point, Exit point) Variables (V) (boolean, natural, integer, array, clock, history variables) Actions over edges (E)
discrete A (guard, body) delay/timed
Constraints set of invariants (Inv) set of res. diff equations (RC)
Conditional connectors (CC) Nested submodes (SM)
Entry Point
Init Point
C
M
submode1 submode2
submode3
Exit Point
Write Point
(guard, body)
Inv1RC1
C
Control
Init
Entry
Exit
login=userdata
cpu’=2
t<=30,
Credentials
Air_conditioning
Example1- internal behaviour of Control component in REMES
logged==true
logged==false
cpu’=10eng’=2
mem+=30, t:=0
Initializationresource mem:TA; resource cpu:TC; resource eng:TC; t:clock
turnoff==tru
e
Analysing REMES based ES
REMES modes have access to R1,…, Rn
Goal analyze various scenarios of system’s resource usage
Analysis model for REMES
rtot total accumulated resource consumption for R1,…, Rn
r1,…, rn accumulated consumption of R1,…, Rn
w1,…, wn relative importance of r1,…, rn
nndeftot rwrwrwr 2211
Advanced Component-Based Software Engineering
12
Analysing REMES based ES
Translating REMES into Priced timed automata or Multi PTA TA + costs on locations and edges
REMES atomic submode PTA location(s) REMES discrete edge PTA edge REMES discrete step PTA transition REMES conditional connectors are removed
Automated translation Types of analysis
Feasibility Optimal/ worst-case resource consumption Trade-off analysis
• PTA waits in location Start for system startup
• Init, Entry, Write and Exit locations created
• Transformation of Submode2
• Internal execution rounds - PTA edge connecting locations Write and Submode1
• Synchronization with other components
Analysing REMES based ES
Model Checker(Uppaal Cora)
PTA / MPTA
resource-aware property
error trace
yes
Assumptions from hardware abstraction:
Memory budget, Bandwidth, Cost model
vEF ntcos
Analysing REMES based ES
Advanced Component-Based Software Engineering
ProCom component REMES model of component behavior
Attribute Framework Managing and integrating properties
Each ProCom component has an attribute with a complex value: Reference to a REMES model file Reference to a mapping file between ProCom and REMES interfaces
Analysing REMES based ES
Advanced Component-Based Software Engineering
ProSave level trigger port REMES interface boolean variable data port REMES interface data variable
ProSys level input message port REMES read boolean variable
and REMES read data variable of the same type as the port type
output message port REMES write boolean variable and REMES write data variable
Connecting ProCom and REMES
Advanced Component-Based Software Engineering
Example2- Temperature control system
core is heated at some given rate
core temperature should be maintained
between a minimum and a maximum
when max temp. is reached, designed to be cooled down by inserting one of two existing rods , which cool at different rates R1 or R2
a rod is available again after T time units
Advanced Component-Based Software Engineering
Model of the architecture and behaviour System modeled with 3 ProSave components Each component has a behavior depicted by a REMES mode Assume memory and cpu usage Formal analysis
ProCom + REMES PTA
Example2- Temperature control system
Advanced Component-Based Software Engineering
Example2- Temperature control system
Advanced Component-Based Software Engineering
Example2- Temperature control system
Advanced Component-Based Software Engineering
Example2- Temperature control system – Analysis in Uppaal
Just for illustration!
QUESTIONS ???
Advanced Component-Based Software Engineering
REMES tool-chain
Advanced Component-Based Software Engineering
The REMES tool-chain consists of
REMES model editor REMES simulator to test timing and resource
behavior prior to formal analysis Automated transformation from REMES to PTA
for formal analysis and UppaalLite editor
Integrated in PRIDE
REMES tool-chain
Advanced Component-Based Software Engineering
REMES tool-chain
Page 26, CBSE graduate course
REMES editor
Advanced Component-Based Software Engineering
Page 28, CBSE graduate course
REMES language elements
Composite mode Compartments for declaration variables, resources, constants
Advanced Component-Based Software Engineering
REMES language elements
Submodes Invariant – time is allowed to pass until invariant is violated Non-lazy – does not contain any.invariant, Time is allowed to pass in a non-lazy mode until at
least one of the guards of the outgoing discrete actions evaluates to true Urgent – time is not allowed to pass (invariant is false)
Advanced Component-Based Software Engineering
REMES language elements
Input and output Init-, entry-, exit-, write – points (local exit points not presented here)
Advanced Component-Based Software Engineering
REMES language elements
Control flow
Edges with guards and actions Conditional connectors
Advanced Component-Based Software Engineering
Introduction to Lab2
Advanced Component-Based Software Engineering
Objectives Learn how to model behaviors of component-based
embedded systems
Model internal behavior of components Think about modes, actions, resources, invariants etc. Get familiar with the REMES editor
Advanced Component-Based Software Engineering
Expected Output
Same system as for Lab1 Archive files only (no folder) named ”Lab2_X.zip” where
X is student name1 report explaining your design choices
The Project folder for your system
Submission to [email protected]
Individual work And nothing else!
Do not copy solutions from others !
Advanced Component-Based Software Engineering
Deadline
Thursday 21 February 2014 23:59 (FIRM Deadline!)
If you submit your work late, you fail one submission opportunity
Remember Lab2 needs to be aproved for passing the course
The assignment
In 2 exercices Modelling behavior of simple Touch-Lamp system Modeling behavior of an abstracted version of a
Baking Conveyor System
Advanced Component-Based Software Engineering
Exercise 1- Touch Lamp System
Lamp has two modes of light operation
• Dim – 1 touch
• Bright – 2 successive touches within 15 sec
Advanced Component-Based Software Engineering
Exercise 2- Industrial Baking Conveyor System
Main parts• Oven• Conveyor Belt• Orchestrator
Advanced Component-Based Software Engineering
Usage Scenario
Orchestrator
OvenConveyor Belt
Oven monitors the temperature and humidity and determines 1. if the heat should be increased or decreased and 2. displays the status of the cookies
Carries the cookies from point A to point B in passing by the oven
Ensure that the conveyor belt and the oven are working together
Advanced Component-Based Software Engineering
Exercise 1 and 2- What do you need to do?
To model the behaviour of the system components Lamp component for Exercise 1 Orchestrator, Oven and Conveyor Belt component for
Exercise 2 Tips
Start by understanding REMES think about different types of modes that exist in REMES
Use pen and paper before using REMES editor Once you are sure of your solution. Model it in
the REMES editor
Advanced Component-Based Software Engineering
Questions ???Advanced Component-Based Software Engineering