Thesis presentation

Design flow for the rigorous development of networked
embedded systems
Alexios Lekidis
Verimag, Université Grenoble Alpes
10 December 2015
Committee:
Ahmed Lbath Professeur, Université Joseph Fourier Grenoble, President du jury
Roman Obermaisser Professeur, Universität Siegen, Rapporteur
Roberto Passerone Professeur, University of Trento, Rapporteur
Smail Niar Professeur, Université de Valenciennes, Examinateur
Marius Bozga Ingénieur de recherche, CNRS, Directeur de thèse
Saddek Bensalem Professeur, Université Joseph Fourier Grenoble, Co-Directeur de thèse
Alexios Lekidis Design flow for the rigorous development of networked embedded systems 1 / 36

Networked embedded systems
Exponential growth in the current use of
embedded devices due to:
Compact size
Low-cost
Low-power consumption
Portability
Ability of monitoring the physical
environment
Data exchange capabilities through
wired or wireless networks
Application areas include: Health-care,
transportation, agriculture, environmental
monitoring, security systems, industrial
process control, factory and building
automation and control, high-energy
physics

Networked embedded systems: Design challenges
A collection of embedded devices that are interconnected by a wired/wireless network
Network
Embedded Device Embedded Device Embedded Device Embedded Device

A collection of embedded devices that are interconnected by a wired/wireless network
Network
Embedded Device Embedded Device Embedded Device Embedded Device
Considerable complexity during system design
Heterogeneity in:
Device functionalities, sensors/actuators, processing units etc
Operating systems, drivers
Network protocols
Communication mechanisms for data exchange
Limited resources
Functional and extra-functional requirements

Heterogeneity in network protocols
Selection based on system speciﬁcations from:
Wired and wireless
Event- and time-triggered technologies
Aﬀects application perfomance and functionality

Resource constraints
Scarce hardware resources:
Processing power, available memory, network bandwidth, battery lifetime
Resources should not reach a critical state
Functional and extra-functional requirements
1. Functional: Correctness, robustness, deadlock-freedom
2. Extra-functional enforce bounds in:
QoS: Communication and data processing latencies
Energy consumption and maintaining the desired system temperature levels
Both types of requirements are equally important for system development

Existing development methods
Several methods for the development of
embedded systems
Extension to networked embedded
systems requires:
Knowledge of network stack
protocols
Handling more complex
Interactions with the device
drivers
No guarantee of correct functionality
makeSense project
(www.project-makesense.eu)

Thesis contribution
A model-based approach for building functional networked embedded systems
Early-stage simulation and testing, performance evaluation as well as
veriﬁcation of system requirements
Progressive system implementation through novel developed tools that
automate system development
Development of components that describe faithfully the system behavior and
functionality in a higher abstraction level
Experiments on relevant case-studies for several application domains:
Automotive
Industrial automation
Wireless Sensor Network (WSN) systems
Internet of Things (IoT) systems

•Design flow for Networked Embedded Systems
Outline
Motivation
•Background: The BIP Framework
•Overview of the proposed flow
•Insight on the flow phases
Application modeling
Code generation
System modeling
Performance evaluation
•Application and experiments
•Overview
•Case study 1: Clock synchronization in a multimedia WSN Application
•Case study 2: Smart heating IoT application
•Conclusion

•Design ﬂow for Networked Embedded Systems •Background: The BIP Framework
The BIP Framework
A formal framework for the hierarchical construction of heterogeneous real-time systems:

The BIP Framework
A formal framework for the hierarchical construction of heterogeneous real-time systems:
s0

sndPacket

NB:=0

s1

s2

s3

busy

6ck

[t<CCA]

t:=t+1

elapsed

[t=backoff]

t:=0

s5

free

s8

endT

[t=tdata]

startTrans
beginT

[t=CCA
||
eval=1]

t:=0

6ck

[t<backoff]

t:=t+1

6ck

[t<tdata]

t:=t+1

backoff=distVal*aUnitBackoffPeriodL0
beginT

nodeNum:=nodeNum+1

endT

nodeNum=nodeNum-‐1

sending

[nodeNum

1]

L1
busy

nodeNum:=nodeNum+1

beginT

busy
endT
free

nodeNum

L2
free

nodeNum=nodeNum-‐1

newTrans

[nodeNum=0]

beginT
eval

endT
busy
free

6ck
sndPacket
pkt

if
(nodeNum

1)
then
eval:=1
else
eval:=0

busy

[eval=0]

≤
≤
distVal=select(distrib,size)
Behavior: Transition systems enriched with data and functions in C/C++
Interaction: Data transfers between components
Priority: Enforcing scheduling policies amongst possible interactions

The BIP tools
1. Language Factory: Translation from other languages and programming
models
2. Verification of functional properties:
State-space exploration tool for the verification of safety requirements
D-Finder tool for compositional verification
3. Verification of performance properties: Statistical Model Checking tool
4. Code generation for target HW architectures

•Design ﬂow for Networked Embedded Systems •Insight on the ﬂow phases
Outline
Motivation
Code generation
System modeling
•Overview
•Conclusion

Design flow for networked embedded systems
Relies on the BIP framework and the associated tools
Implements a Y-chart approach, having as distinct inputs:
Application software
HW architecture specification
Models for the network protocols
Mapping for the application deployment
Uses BIP for the construction of system-level models at different levels of
abstraction
Applies the BIP tools for verification and performance evaluation
Uses code generation tools for rapid prototyping and application deployment

Design ﬂow for networked embedded systems
Translation Translation
Modeling
Verification
Error
(BIP)
library
Model
(BIP)
packet delivery)
(e.g. timing,
Runtime
Application
Software
HW/
OS−Network
Model
(BIP)
Code
deployment
generation/
Execution
Transformation
(BIP)
System
Model
2
calibration
Model
System
Model
Calibrated
measurements
6
OS/
Network stack
(e.g. standards)
specifications
OS−Network
(BIP)
library
Preliminary phase
(DSL)
software
Application
(XML)
Mapping
specifications
3
1
5
evaluation
Performance
4
7
Architecture
HW
(BIP)

The design ﬂow oﬀers:
1. Description of the
application software
through a novel
programming
framework
2. Automated code
generation for several
hardware architectures
of networked
embedded systems
3. Construction of faithful
system-level models
4. System-level
performance evaluation
Modeling
Verification
Error
(BIP)
library
Model
(BIP)
packet delivery)
(e.g. timing,
Runtime
Application
Software
HW/
OS−Network
Model
(BIP)
Code
deployment
generation/
Execution
Transformation
(BIP)
System
Model
2
calibration
Model
System
Model
Calibrated
measurements
6
OS/
Network stack
(e.g. standards)
specifications
OS−Network
(BIP)
library
Preliminary phase
(DSL)
Application
(XML)
Mapping
specifications
3
1
5
evaluation
Performance
4
7
Architecture
HW
(BIP)
software

Pragmatic Programming Model (PPM)
A unifying computational model adapted to networked embedded systems
Describes application software as a process network, involving
communication between diﬀerent processes
Application software consists of three basic entities:
Processes, shared memories, mutexed locations
Communication performed using shared objects, which are:
FIFOs, shared memories, mutexed locations
Network structure described in XML
Process behavior written in C/C++
Inspired by the DOL (Distributed Operations Layer)
framework in multiprocessor systems
synchro PLL
speaker micro
PLL
micro
SO1
SO2
SO3
SO4

Automated code generation from PPM specifications
Generated code consists of:
1. Functional code:
Includes processes that are implemented
as threads
Includes shared objects tha are
implemented according to the underlying
communication protocols
Substitutes PPM read and write
primitives by read and write API calls on
the respective communication protocol
2. Glue code:
Includes the application deployment, also
used to define configuration parameters
for the communication protocols
Support of UDP, raw socket and Ethernet
Powerlink communication primitives
Generated code deployed in embedded Linux,
Ethernet Powerlink or Contiki OS architectures
(C code)
Deployable
Application Software (PPM)
Code generation
Device 1
Embedded Embedded
Device 2
Embedded
Device N
Mapping (PPM)
Behavior
(C code)
Process Network
(XML)
(C code)
Templates
HW CodeArchitecture
(XML)

Modeling HW architectures
Timed models developed for:
1. Network protocols:
CAN: Synchronous communication, CAN/CAN FD protocol versions, timing
aspects follows the ISO 11898-1 and ISO 11898-2 standards, bit-stuffing
techniques, transmission offsets, (non-)abortable requests
CANopen: CANopen DS-301 communication profile, integration with CAN
and Ethernet Powerlink (EPL), event- and time-driven, synchronous and
asynchronous comommunication
WiFi: Timing aspects following of the IEEE 802.11 standard, DCF channel
access scheme, FHSS modulation technique
Contiki protocol stack: CoAP, 6LoWPAN and the IEEE 802.15.4 standard
models, compression and decompression mechanisms for the IP packet
headers, DSSS modulation technique
2. Operating systems:
Embedded Linux: Scheduling mechanisms, device hardware clocks
Contiki OS: Kernel, scheduling mechanisms, memory allocation
Overall complexity of the developed models for IoT systems approximately 16
components with 426 transitions

Construction of faithful system-level models
1. Construction of an abstract system model by applying composition glue:
BIP models for the application software
BIP model for the hardware architecture
2. System model refinement with timing information obtained from
measurements on the implementation:
Process profiling techniques to instrument the generated code
Distribution fitting when observations are stochastic
Injection of the obtained observations to the system model
Example: Software processes that perform specific computations on input data

System-level performance evaluation
The implemented techniques enable:
Monitoring the evolution of performance characteristics over time
Injecting additional behavior (e.g. packet losses, out-of-order deliveries) to
analyze their impact on performance aspects (i.e memory, timing)
Performance analysis through the evaluation of system requirements using
SMC
Feedback to the system designers

Summary
Design ﬂow based on a
single semantic framework
for networked embedded
systems that supports:
Layered system
composition through
resuable components
Model-based design
Separation of concerns
Tools to automate
every step of the ﬂow
Modeling
Verification
Error
(BIP)
library
Model
(BIP)
packet delivery)
(e.g. timing,
Runtime
Application
Software
HW/
OS−Network
Model
(BIP)
Code
deployment
generation/
Execution
Transformation
(BIP)
System
Model
2
calibration
Model
System
Model
Calibrated
measurements
6
OS/
Network stack
(e.g. standards)
specifications
OS−Network
(BIP)
library
Preliminary phase
(DSL)
software
Application
(XML)
Mapping
specifications
3
1
5
evaluation
Performance
4
7
Architecture
HW
(BIP)

•Application and experiments •Overview
Outline
Motivation
Code generation
System modeling
•Overview
•Conclusion

•Application and experiments •Overview
Design flow applied to several application domains of :
1. Automotive systems
2. Industrial automation systems
3. Wireless Sensor Network (WSN) systems
4. Internet of Things (IoT) systems
The resulting design flow of each domain demonstrated through case-studies in
real-life networked embedded systems
Each domain features different:
Application-specific characteristics
Network stack protocols (e.g. CAN, CANopen, Ethernet Powerlink, WiFi,
6LoWPAN)
Operating systems (e.g. embedded Linux, Contiki OS)
Requirements to be considered (e.g. memory utilization, transmission and
processing delays)

•Application and experiments •Case study 1: Clock synchronization in a multimedia WSN Application
Case study 1: Clock synchronization in a multimedia WSN
Application
Capturing and reproduction of audio data produced by embedded devices in a base station
Advanced Linux Sound Architecture (ALSA) API for audio conﬁguration
Periodic sender-to-receiver synchronization (T=1s)
WIreless network supported by a Snowball SDK Access Point (static ad-hoc server
conﬁguration)
WSN with 3 UDOO platforms connected through the AP
Master Node
Slave Node
Slave Node
Access Point
(AP)

For this case-study we described:
The Application software and the mapping in PPM
Audio capturing and playback technique using the ALSA API
Clock synchronization protocol using the PLL technique
The HW architecture through a WLAN DSL network specification
In our approach we proceeded on:
Modeling the WSN application software and the WLAN hardware architecture
Code generation for WSN systems from the PPM specifications
BIP System Model Calibration using distribution fitting techniques
Validating of functional and extra-functional requirements using SMC
Buffer utilization
Clock synchronization accuracy

WMSN application: PPM Model
synchro PLL
speaker micro
PLL
micro
SO1
SO2
SO3
SO4

WMSN application: Application deployment
synchro PLL
speaker micro
PLL
micro
WMSN Application
SO1
SO2
SO3
SO4
Master
WiFi
card
Sound
card
UDOO node
WLAN HW architecture
Snowball SDK
Access Point
WiFi
WiFi
card
Slave
WiFi
card
Sound
card
UDOO node
Slave
WiFi
card
Sound
card
UDOO node

WMSN application: Experiments
Property 1: What is the probability of avoiding potential audio playback problems
in the WMSN application?
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
0 100 200 300 400 500 600 700 800 900 1000
020406080100
size(Sbuffer)
Probability(%)
Overﬂow avoided for maximum queue
size 400
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
q
q
q
q
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
0 160 320 480 640 800 960 1120 1280 1440 1600
020406080100
Initial playout delay (ms)
Probability(%)
Initial audio playout delay at least 1210 ms
The consumption of audio packets from
the speaker of the Master component
should not start before this time
duration has elapsedAlexios Lekidis Design ﬂow for the rigorous development of networked embedded systems 27 / 36

WMSN application: Experiments
Property 2: What is the probability of maintain a bounded clock synchronization
accuracy for the audio playback?
0 200 400 600 800 1000 1200
20
40
60
80
100
120
140
160
180
Synchronizationerror(usec)
Number of samples
0 200 400 600 800 1000 1200
0
20
40
60
80
100
120
140
160
180
Synchronizationerror(usec)
Number of samples
Observed accuracy in the model and the generated code is the same (equal to
76µs)
Variatibility observed in the model simulation allows better analysis

•Application and experiments •Case study 2: Smart heating IoT application
Case study 2: Smart heating IoT application
Applied to home and building automation areas
of networked embedded systems
Application includes zone-controller receiving
temperature readings from sensors
Requests from a client (zone-controller) to
multiple server devices (containing the sensors)
for temperature data
Particular focus in an apartment with two
rooms, each one having a temperature sensor
Zone-controller periodically accessed by a
smartphone or tablet device to provide control
of the indoor heating to the residents
Tmote Sky platform used as access point
providing a WPAN network
5 embedded devices (4 servers and 1 client)
Use of the Rime Contiki stack for
communication

For this case-study we described:
The application software in a DSL for Contiki OS systems
The HW architecture through a WPAN DSL network specification
In our approach we proceeded on:
Constructing models for the Contiki Kernel and the entire protocol stack
Code generation from a DSL language for IoT systems
BIP System Model Calibration using process profiling techniques
Model verification using state-space exploration
Validation of functional and extra-functional requirements using SMC
Maintaining temperature in user-defined levels inside the building
Proper sizing of the Contiki OS buffers
Achieving low collision rate in the communication medium

Smart heating IoT application: Experiments
Application simulated using:
1. The BIP simulation environment
2. A domain-speciﬁc IoT simulation environment (Cooja/MPSim)
200 250 300 350 400 450 500
11
11.5
12
12.5
13
13.5
14
14.5
Responsetime(ms)
Number of samples
SBIP Model
Cooja
Both experiments provided similar results

Smart heating IoT application: Experiments
Additional experiment on injection of error-prone behavior (e.g. packet losses)
uisng the BIP simulation environment
Cooja only supports the addition of packet losses based on user-provided
simulation values for parameters (not accurately reﬂecting the reality)
0 500 1000 1500
10
12
14
16
18
20
22
24
Responsetime(ms)
Number of samples

•Conclusion
Outline
Code generation
System modeling
•Overview
•Conclusion

•Conclusion
Summary
Model-based design flow for networked embedded systems using the BIP
component framework featuring:
1. Novel languages and computational models for describing the application
software
2. Automated code generation from the application software
3. Construction of faithful and reusable system models using model calibration
techniques
4. Evaluation of the system performance through functional and extra-functional
requirements
5. Feedback for design enchacements
Application of the design flow in various areas: Demonstration through
real-life case-studies and comparison against domain-specific tools and
frameworks

•Conclusion
Perspectives
Existing limitations that should be handled in the design ﬂow relate to:
The simulation performance when compared against other domain-speciﬁc
tools (e.g RTaW-Sim in automotive systems)
Interoperability when deployed in complex architectures, such as Multi-Core
SoC architectures
Complexity of the models, expecially for large-scale networked embedded
systems
Proper stochastic abstractions should be made
Additional extra-functional requirements
Support of power consumption in the constructed models
Analysis of security risks

•Conclusion
Thank you very much for your attention

Thesis presentation

Recomendados

Recomendados

Más contenido relacionado

Similar a Thesis presentation

Similar a Thesis presentation (20)

Último

Último (20)

Thesis presentation