This document summarizes Venkata Kalyan Ram's masters thesis on model checking the AUTOSAR Basic Software Component. It introduces model checking as a formal verification technique, describes modelling a system as finite state machines and specifying properties with temporal logic. It then discusses the AUTOSAR architecture and CAN network management. A case study is presented where properties of the CAN network management model are verified using model checking. The results found all properties were satisfied, demonstrating model checking's ability to detect non-determinism and help build a verification model.

1. Model-checking
AUTOSAR Basic
Software Component
Masters thesis by
Venkata Kalyan Ram
Software Engineering and Management
Department of Computer Science and Engineering

2. Agenda
• Introduction
– Problem statement
• Model-Checking
– Modelling
– Specification
• AUTOSAR
– CAN Network Management
• Case-Study: Verification
• Results & Reflections

3. Introduction
• Electronic Control Units (ECUs) are the basic blocks of
many features of an automobile
3

4. Introduction
• Example: Parking
assistance
4

5. Introduction
5

6. Introduction
• ECUs are connected as a network of nodes
• Networked ECUs forms a distributed and networked system
6

7. Introduction
Different bus types
and/or networks like
CAN, LIN, FlexRay,
etc.
• Each node may be a
processor, a DSP, an FPGA,
etc
• Depending on the type of
application, nodes may be
units of individual chips, or
small embedded computers
7

8. Problem statement
• Verifying the design of the software early during the
development life cycle is considered highly essential
• Testing can only show that a system is working as
intended, whereas verification can show the correctness
proof of a system
• Thus it is the aim of this thesis to perform such verification
on a model of a software module which is part of a
broader framework called AUTOSAR
8

9. • Introduction
– Problem statement
• Model-Checking
– Modelling
– Specification
• AUTOSAR
– CAN Network Management
• Case-Study: Verification
• Results & Reflections

10. Model-checking
• A Formal Verification technique
• Formal Verification
“Mathematically proving the correctness of a design with
respect to mathematical formal specification”
• Introduced by Edmund M. Clarke & Joseph Sifakis
• Given a model M and a specification P of a
system, determine whether the specification P is satisfied
on the model M.
• This is written as
?
M P
10

11. Model-checking
• Modeling
– Finite state machines
• Specification
– Expressed with temporal aspects of the property
– Temporal Aspects
• Linear time
• Discrete time
• Branching time
• Verification
– Process of searching the state space of a model
exhaustively to determine whether a specified property
fails.
11

12. Model-checking
Model
(Abstract of a system)
Answer
Yes  If Model satisfies
Model the specification
checker Counter Example  If
Model doesn’t satisfy the
specification
Specification
(System property)
12

13. Model-checking
PROMELA
(PROcess MEta LAnguage)
Answer
Yes  If Model satisfies
the specification
SPIN
Counter Example  If
Model doesn’t satisfy the
specification
LTL
(Linear Temporal Language)
• SPIN – Simple PROMELA INterpreter
• Developed in 1980 at Bell Labs by Gerard J. Holzmann
13

14. Modeling
• An example of an audio player
– A finite state model of the audio player
Stop
Idle Playing
Play
Pause
Stop Play
Paused
14

15. Modeling
• PROMELA code of the model of the audio player
15

16. Modeling
• PROMELA code of the model of the audio player
16

17. Modeling
• PROMELA code of the model of the audio player
17

18. Modeling
• PROMELA code of the model of the audio player
18

19. Specification
• Common operators of Linear Temporal Logic
G or □ – Globally or Always p
F or ◊ – Finally or Eventually p
19

20. Specification
• Property to be verified –
“Whenever the play button is pressed, it is guaranteed that the
song will be played”
• Expressed in LTL
((input == play) -> (CURRENT_STATE == PLAYING))
20

21. • Introduction
– Problem statement
• Model-Checking
– Modelling
– Specification
• AUTOSAR
– CAN Network Management
• Case-Study: Verification
• Results & Reflections

22. AUTOSAR
• AUtomotive Open Software ARchitecture
• Layered architecture
Application layer
AUTOSAR Runtime Environment (RTE)
System services Memory Communication I/O Hardware Compl
ex
services services Abstraction drivers
Onboard device Memory Communication
hardware hardware
abstraction abstraction
abstraction
Microcontroller Memory drivers Communication I/O Drivers
devices drivers
Microcontroller
22

23. AUTOSAR
• The communication services are the group of modules for
vehicle network communication (CAN, LIN and FlexRay)
• They are interfacing with communication drivers via the
communication hardware abstraction
23

24. AUTOSAR
24

25. CAN Network Management
• Decentralized network
management strategy
• Periodic NM-Message
transmission via broadcast
transmission
• Two key-requirements are:
– Every node shall transmit
messages
– If no messages are
transmitted, every node shall
make a transition to Sleep
Mode
25

26. CAN Network Management
26

27. CAN Network Management
Network mode
Ready
Sleep
State
Repeat
Message
State
Normal
Operation
Bus-
Sleep
Mode
Prepare Bus-
Sleep Mode
27

28. Tx or Rx Network mode
CAN Network
Management NM_Timer NetRel & Ready
Sleep
Repeat_Message_Timer
State NM_Timer
Following are called by expiry
expiry /
Generic NM Wait_Bus
Repeat RepeatReq _Sleep_Ti
CanNm_NetworkRequest() Message mer
State
CanNm_NetworkRelease() start
CanNm_RepeatMessageReq NetReq NetRel
RepeatReq
uest()
NetReq &
Following are called by Repeat_Message_Timer
expiry NM_Timer
CAN_IF
CanNm_TxConfirmation() Normal
Operation
CanNm_RxIndication() Bus-
Sleep
Mode NetReq || Rx /
The timers are NM_Timer start
NM_Timer Wait_Bus_Sleep_Timer
Rx Prepare Bus-
Repeat_Message_Timer Sleep Mode
Wait_Bus_Sleep_Timer
28

29. • Introduction
– Problem statement
• Model-Checking
– Modelling
– Specification
• AUTOSAR
– CAN Network Management
• Case-Study: Verification
• Results & Reflections

30. Case-Study: Verification
• Properties are drawn from the key requirements
• 3 properties were verified
– 2 are temporal in nature
– 1 is an assertion
• The temporal properties are
– P1 – “CAN NM should enter Normal Operation state whenever
network is requested”
□(NetReq -> ◊ Normal_Operation)
– P2 – “If the network is released, CAN NM shall be put to sleep mode”
□(NetRel -> ◊ Bus_Sleep_Mode)
• The assertion property is
– P3 – “All the states specified for CAN NM are reachable”
e.g. – assert(CURRENT_STATE == NORMAL_OPERATION)
30

31. • Introduction
– Problem statement
• Model-Checking
– Modelling
– Specification
• AUTOSAR
– CAN Network Management
• Case-Study: Verification
• Results & Reflections

32. Results & Reflections
• All the properties were satisfied on the model
• By this study the characteristic non-determinism
of CAN NM, has been made explicit
• Abstraction played a key role while modeling
CAN NM
• Model-checking showed to be a good technique
for detecting non-determinism and also building
a good verification model
32

33. References
• AUTOSAR illustrations from www.autosar.org
• Clarke, Edmund M. “Model Checking.” Foundations of
Software Technology and Theoretical Computer
Science, Lecture Notes in Computer Science. Vol. 1346.
Springer Berlin/ Heidelberg, 1997. 54-56.
• Temporal Logic Formulas Illustrations by Alessandro
Artale, Free University of Bolzano
• Parking assistance illustration from Valeo Service, The
Netherlands
33

34. Thank you