Model-based development of CANopen systems

Alexios Lekidis, Marius Bozga, Saddek Bensalem
Univ. Grenoble Alpes, VERIMAG, F-38000 Grenoble, France
CNRS, VERIMAG, F-38000 Grenoble, France
10th IEEE International Workshop
on Factory Communication Systems
Paul Sabatier University, Toulouse (France)
May 5-8,2014
Model-based validation of CANopen
systems
Lekidis A., Bozga M., Bensalem S. Model-based validation of CANopen systems 1/32

1) CANopen: An increasingly popular though fairly
complex Fieldbus protocol
2) Formal models of CANopen’s communication
mechanisms in BIP
• CANopen overview
• BIP overview
• CANopen protocol model
3) Case study: Pixel Detector Control System
4) Conclusion and ongoing work
Outline

Networked embedded systems (1)
Fieldbus
protocols
• Manageable system complexity
• Reduced communication cost and energy
consumption
• Guarantee for functional and real-time requirements
Device
7
Device
5
Device
3
Device
1
Device
6
Device
4
Device
2

Device
7
Device
5
Device
3
Device
1
Device
6
Device
4
Device
2
CANopen
• Network management
• Time synchronization
• Flexibility in the device
configuration
• Cyclic, time-driven or
event-driven
(asynchronous
communication)

Device
7
Device
5
Device
3
Device
1
Device
6
Device
4
Device
2
CANopen
Subtle interactions
between
the different types of
communication
mechanisms
configuration
event-driven
(asynchronous
communication)

Device
7
Device
5
Device
3
Device
1
Device
6
Device
4
Device
2
CANopen
configuration
event-driven
(asynchronous
communication)
Subtle interactions
between
the different types of
communication
mechanisms
Functional
system
construction
is complex and
requires
validation

Validation through conformance testing
 Verifies the network
integrity
 Ensures the error-free
functionality of a
communication protocol
Observation of
functional errors
Early-stage
performance analysis
 Previous work is based on the analysis and validation of the
CANopen communication profile through a number of test
sections, related to:
 Object Dictionaries of the devices
 Conformance to the CANopen protocol
 Correct behavior in different network states as well as state transitions

Alternative: Model-based design
Formal approach expressing the behavior and
functionality of embedded systems
• Simulation, validation and verification enabled in every
stage of the development
• Modularity, reusability of artifacts in complex
heterogeneous systems
• Systematic development of models for CANopen systems
• Construction based on a structural representation of the
protocol’s primitives and communication mechanisms

mechanisms in BIP
• BIP overview
Outline

CANopen overview (1)
• Usage in a wide range of applications including:
• Distributed control systems, building automation systems,
medical devices, photovoltaic systems, maritime electronics
e.t.c.
• Fieldbus protocol based on a vast variety of standards:
1) Defining the communication mechanisms
2) Facilitating the configuration of:
• Applications, network devices, interfaces
• Relying on different communication models, each one
corresponding to a specific protocol service:
• Master/slave for management services
• Client/server for configuration services
• Producer/consumer for real-time communication services

CANopen overview (2)
• Communication mechanisms defined by standard
Communication Objects (COBs), such as:
• All the objects are stored in a centralized repository,
unique for every device, the Object Dictionary (OD)
• Initialization of network states and monitoring
Network Management
objects (NMT)
• Event-driven (asynchronous), time-driven, synchronous
Process Data Objects
(PDO), used for real-time
communication
• Expedited, segmented and block transfer
Service Data Objects (SDO),
used for configuration data
exchange
• Synchronization object (SYNC)
• Timestamp object (TIME)
• Emergency object (EMCY)
Predefined objects

CANopen communication
(6000h-9FFFh)
(1000h-1FFFh)
(6000h-9FFFh) (6000h-9FFFh)
(1000h-1FFFh) (1000h-1FFFh)
(2000h-5FFFh) (2000h-5FFFh) (2000h-5FFFh)

(6000h-9FFFh)
(2000h-5FFFh)
(1000h-1FFFh)
(6000h-9FFFh) (6000h-9FFFh)
(2000h-5FFFh)
(1000h-1FFFh)
(2000h-5FFFh)
(1000h-1FFFh)
1st TPDO communication
parameter
TPDO1

(6000h-9FFFh)
(1000h-1FFFh)
(6000h-9FFFh) (6000h-9FFFh)
(1000h-1FFFh) (1000h-1FFFh)
RPDO1
(2000h-5FFFh) (2000h-5FFFh) (2000h-5FFFh)
1st RPDO communication
parameter

• BIP (Behavior-Interaction-Priority) is a formal
language for the hierarchical construction of
heterogeneous real-time systems
• Provides a rich set of tools for analysis and
performance evaluation
B E H A V I O R
Interactions (collaboration)
Priorities (conflict resolution)
BIP component framework
Composition
glue
Atomic
components

s:=0
t:=0
BIP: Atomic components
 Finite state automata (Petri nets) extended with data and
functions described in C/C++
TICK
SEND
s:=s+1
t:=0
COM
[s<100]
TICK
[t<100]
t:=t+1
sSEND
idle
COM TICK
EXERECV
print(r)
TICK
t:=t+1
rRECV
idle
EXE
TICK
t:=t+1

BIP: Interactions
 Communication between components involving data
exchange
s:=0
t:=0
TICK
SEND
s:=s+1
t:=0
COM
[s<100]
TICK
[t<100]
t:=t+1
sSEND
idle
COM TICK
EXERECV
print(r)
TICK
t:=t+1
rRECV
idle
EXE
TICK
t:=t+1
r:=r+s

BIP: Priorities
 Used among competing interactions
π1 : TICK<EXE
s:=0
t:=0
TICK
SEND
s:=s+1
t:=0
COM
[s<100]
TICK
[t<100]
t:=t+1
sSEND
idle
COM TICK
EXERECV
print(r)
TICK
t:=t+1
rRECV
idle
EXE
TICK
t:=t+1
r:=r+s

The BIP toolset
Offers:
 Translators from
various languages
and models into
BIP
 Source-to-source
transformers
 Code generation
by dedicated
compilers
More information and
related material at:
http://bip-components.com

CAN/CANopen Modeling Principle
Temperature
Control
Motion
Detector
Pressure
Control
Regulator
CAN Bus
OD OD OD OD

CAN/CANopen Modeling Principle
Temperature
Control
Motion
Detector
Pressure
Control
Regulator
CAN Bus
OD OD OD OD
Existing BIP
library for the
CAN protocol
Structural preserving
model in BIP

Modeling CANopen in BIP
• Consisting of several CANopen devices responsible for frame
transmission/reception
• Each Device component:
• Consists of sub-components corresponding to their COBs

• Composed by three parts: TRANSMIT, T/R and RECEIVE

Lower communication layer

OD
Async
Timer
Event
Generator
User layer

Async
Timer
Event
Generator
User layer
Lower communication layer
OD

• Divided in two categories the transmit PDO (T-PDO) and the receive PDO
(R-PDO) component
• Supporting the following scheduling policies:
• SYNC-triggered
• Time-triggered
• Event-triggered
PDO communication
SYNC-triggered
T-PDO component
R-PDO component
idle
trig
REQUEST frame
SYNC_TRIG
REQUEST
SYNC_TRIG
id:=TPDO2
idle
rec
OD_WRITE
RECV frame
OD_WRITE
[id:=TPDO2]
internal
[id≠TPDO2]
RECV

Predefined object communication
• Focus on the SYNC object, since it is mandatory in CANopen systems
• Divided in two categories the transmit PDO (T-SYNC) and the receive
PDO (R-SYNC) component
• R-SYNC component interacting with the SYNC-triggered T-PDO
component
T-SYNC component R-SYNC component
REQUEST frame
TICK
[t≠period]
t:=t+1
REQUEST
internal
[t=period]
t:=0
id:=SYNC
length:=1
idle
trans
SYNC_TRIG
idle
rec
RECVSYNC_TRIG
[id=SYNC]
RECV frame
TICK

SDO communication
• Can be of two types:
• SDO Download (D-SDO)
• SDO Upload (U-SDO)
• Consists of a Client and a Server atomic component supporting:
• Expedited data transfer
• Segmented data transfer
D-SDO component

SDO Client component
D-SDO Client component

SDO Client component
D-SDO Client component
initiate
segment

mechanisms in BIP
• BIP overview
Outline

• Innermost part of the ATLAS experiment at CERN’s LHC (Large Hadron
Collider) particle accelerator
• Test beam used for the calibration and performance evaluation of
pixel detector modules (presented in [1])
• Each pixel detector module is equipped with a temperature sensor,
measuring its operating temperature
• CANopen used for the communication in the front-end system as well as
in the connection between the back-end and front-end equipment
[1] S. Kersten, K. Becks, M. Imhäuser, P. Kind, P. Mättig, and J. Schultes, “Towards a Detector
Control System for the ATLAS Pixel Detector”, 2002
Pixel Detector Control System (DCS) (1)

Detector system: Contains four pixel
detector modules

Interlock Box: Thermal
NFC system detecting
the overheated pixel
detector modules

Cooling Box: Required
in order to cool the
overheated pixel
detector modules

Regulator: Adjusts the
coolant flow inside the
Cooling Box

DCS Station:
 Used for data logging,
 Ensuring synchronized data transmission

125 kbit/s
ELMB: General purpose I/O and
processing units responsible for data
transmission to the CAN interface

• CANopen communication through the ELMB units:
125 kbit/s
TPDO2
TPDO3
TPDO2
TPDO3
TPDO1
SYNC
D-SDO D-SDO

• Requirements ensuring the proper system functionality:
• The physics and performance of the individual subsystems
of the DCS found in: http://cds.cern.ch/record/391176
• The communication through CANopen:
1) If a sensor’s temperature is increased the Logic Unit must
inform the DCS Station rapidly through a TPDO1 frame
2) Following a reset of a pixel detector module, a TPDO3
frame must be send prior to a temperature change
detection
3) The coolant flow inside a Cooling Box must be set at least
once before it is required to cool a pixel detector module

DCS model in BIP
Wrap-up: 52 atomic components, 95 connectors, 427 transitions, 2300 lines of
BIP code

• Use of temperature data stored from a previous
system execution and provided as input to the model
• Each pixel detector module is considered overheated
if the temperature is above a computed threshold
• Asynchronous timer generating event interrupts for
the SDO transmission
• Based on the Poisson distribution
Experiments

Results: Response times
• 4 hours of real
system time were
simulated in 2
minutes and 43
seconds

• The requirements of the DCS are described as probabilistic
properties
• What is the probability for:
1) The maximum response time of a TPDO1 frame to be less
than the shortest time between two consecutive TPDO2 frame
transmissions (inhibit time)?
2) A TPDO3 frame to be sent before a temperature change is
detected (TPDO2 frame generated)?
3) A D-SDO frame to be transmitted before any other frame in
the initialization phase?
• The probability for each property is computed by several
simulations using the statistical model-checking BIP tool
(SBIP)
Evaluation of temporal properties

properties
(SBIP)

Evaluation of temporal properties for the
DCS (1)
max
1.72 sec
1
m
TPDOT =
11
1secTPDOTφ= >
( )1 1P φ =

properties
(SBIP)

Evaluation of temporal properties for the
DCS (3)
23 TPDO D SDOt tφ −
= >
( )3 0.1P φ =
Pixel detector module is overheated

Conclusion
• Systematic construction of formal models for
CANopen systems
• Encapsulates both functional and extra-functional
aspects
• Demonstration of the method on a case study
• Validation of certain communication requirements
using the Statistical Model-Checking BIP tool
• Ongoing work:
• Mapping of CANopen applications to Real-Time
Ethernet networks
• Automatic code generation for Ethernet
Powerlink based on CANopen specifications

Thank you for your attention.
Further details: alexios.lekidis@imag.fr

Model-based development of CANopen systems

Recommended

Recommended

More Related Content

Similar to Model-based development of CANopen systems

Similar to Model-based development of CANopen systems (20)

Recently uploaded

Recently uploaded (20)

Model-based development of CANopen systems