CANopen: A Field-Level Protocol Formal Specification and Validation Conformance Testing Manuel Bernardo Barbosa July 3, 2003
Manuel Bernardo Barbosa -
[email protected]
1
Contents 1. Overview of CANopen 2. Motivation 3. Specification and validation of CANopen using PROMELA and Spin 4. Analysis of the Conformance Testing approach 5. An alternative approach 6. Results
Manuel Bernardo Barbosa -
[email protected]
CANopen - Formal Specification and Validation - Conformance Testing
2
CANopen: A Field-Level Protocol • CANopen is a communication protocol designed for distributed control in industrial environments: system integration. • Typical CANopen applications perform the connection of controllers (e.g. PLCs) to intelligent sensors and actuators such as I/O modules and motion controllers: it is a field-level protocol. • Other areas of application: medical applications, railways, maritime electronics, etc. • Competitiveness: low cost, reliability, flexibility, diversity of CANopencompatible products, made in Europe, European Standard EN 50325-4.
Manuel Bernardo Barbosa -
[email protected]
CANopen - Formal Specification and Validation - Conformance Testing
3
CAN: Controller Area Network • Originally developed for passenger car applications: – most European cars use CAN networks for engine management – many use it also for connecting body electronics e.g. lighting control. – others use it for diagnostic interfacing and entertainment equipment. • CAN features make it a good solution for industrial real-time applications: – Producer/Consumer broadcast model: message identifiers instead of station addresses. It is content-oriented. – Message identifiers determine bus access priorities: transmission requests are handled in the order of the importance of the messages. – High reliability based on multi-master capabilities and data integrity preservation features. – Low cost and guaranteed availability. Manuel Bernardo Barbosa -
[email protected]
CANopen - Formal Specification and Validation - Conformance Testing
4
CAN: Higher Layer Protocols • CAN hardware implementations provide OSI layers #1 and #2 services: – transmission of frames carrying up to 8 data bytes. – remote data frame request. – complex error handling mechanisms. • CAN functionality is too low-level to be employed directly in industrial system integration. Problems such as network management, data segmentation and synchronisation must (always) be addressed. • Higher-layer protocols are software-based communication frameworks that provide this type of functionality using CAN as a communication link. • Examples: CANopen, Devicenet, CAN Kingdom. Manuel Bernardo Barbosa -
[email protected]
CANopen - Formal Specification and Validation - Conformance Testing
5
CANopen: A Three-And-A-Half Layer Protocol Device Profiles Application
Data Link Physical OSI
Communication Profile Controller Area Network (CAN) CANopen
• The User Application implementation is constrained by Device Profiles. This is sometimes called a User Layer. Manuel Bernardo Barbosa -
[email protected]
CANopen - Formal Specification and Validation - Conformance Testing
6
CANopen Services • Network configuration (potentially automatic) and network management (monitoring and control) • OO access to parameters and data block transfer (segmentation) • Device synchronisation: synchronous reading or setting of inputs, outputs or parameters • Cyclic and event-driven data transfer • Emergency signalling • Device profiles: generic I/O modules, drives and motion controllers, measuring devices and closed-loop controllers, encoders, proportional hydraulic valves, etc. Manuel Bernardo Barbosa -
[email protected]
CANopen - Formal Specification and Validation - Conformance Testing
7
CANopen: Device Model
APP OBJ
APP OBJ
APP OBJ
APP OBJ
APP OBJ
Inputs / Outputs
User
Object Dictionary Application SDO PDO NMT EMG CAN Electronics
Data Link Physical
CAN Network Manuel Bernardo Barbosa -
[email protected]
CANopen - Formal Specification and Validation - Conformance Testing
8
CANopen Conformance Testing • CANopen is steered by the CAN in Automation (CiA) users group. CANopen became an European standard in 2002. • Important developments leading to this standardisation were: – the restructuring of the CANopen specifications (DS301 V4), and – the creation of a CANopen-compliance certification system. • The CANopen certification system was important because: – It implies a stabilised specification whose integrity is protected by conformance testing implementations. – It associates the CANopen brand with a culture of rigour. – It is great publicity for complying manufacturers: offer conformance. – It is a quality seal for users to look for: look for interoperability. Manuel Bernardo Barbosa -
[email protected]
CANopen - Formal Specification and Validation - Conformance Testing
9
Motivation • This work was carried out while the CANopen Conformance Testing procedures were being developed. • The contribution was to find answers to the following questions: – How does CANopen Conformance Testing relate to the concepts defined in the International Standard for OSI Conformance Testing ? – Can a global change in its strategy lead to an increase in its error detection effectiveness? – How does CANopen Conformance Testing rate when it is formally analysed in light of Conformance Testing theory? – Can a formal analysis and validation of the CANopen specification and associated Test Cases lead to possible enhancements?
Manuel Bernardo Barbosa -
[email protected]
CANopen - Formal Specification and Validation - Conformance Testing
10
Conformance Testing Communication Protocols Formal Methods Test Suite Test Case design Specification
Dynamic Testing Test Tool
Static Testing Test Selection
Manuel Bernardo Barbosa -
[email protected]
Abstraction Instance
Implementation Under Test
Conformance Statement
CANopen - Formal Specification and Validation - Conformance Testing
11
CANopen Conformance Testing: Remote Testing
Device Profiles (unreliable)
Not Accessible
Upper PCO Application Layer
Lower Tester
Lower PCO CAN (reliable)
Manuel Bernardo Barbosa -
[email protected]
CANopen - Formal Specification and Validation - Conformance Testing
12
Formal Specification of CANopen using PROMELA • PROMELA is a notation for specifying the procedural rules in Communication Protocols, in order to study their structure and to verify their completeness and logical consistency [Holtzmann]. – Basic objects: processes, message channels and state variables. – Syntax similar to C but no distinction between conditions and statements (executability). – Data types: bit, bool, byte, short and int; arrays and structs. – Processes represent entities executing concurrently. They can also model procedures, including recursive ones. – Communication using channels can be asynchronous or synchronous. – Statements: if, do, break, skip, timeout. • Correctness requirements: assertions, valid end statements (deadlocks), valid cycles (livelocks), progress statements (non-progress cycles), temporal claims. Manuel Bernardo Barbosa -
[email protected]
CANopen - Formal Specification and Validation - Conformance Testing
13
CANopen PROMELA Specification Stimulator Process
Stimulator Process
CANopen Protocol Entity
CANopen Protocol Entity
CAN Emulation Model
Manuel Bernardo Barbosa -
[email protected]
User Layer
Application Layer
Physical & Data Link Layers
CANopen - Formal Specification and Validation - Conformance Testing
14
PROMELA specification: Example proctype NMT_Slave_Err() { ... end_S_Err: do :: ((timeout)&&(NMT_Err==1)) -> NMT_SAP_out_Err[1]!NMT_out; :: DLL_to_AL[1]?[RECEIVE_A] -> DLL_to_AL[1]?message_in -> message_out.identifier=RECEIVE_A; ... NMT_Err=1; AL_to_DLL[1]!message_out; od; }; Manuel Bernardo Barbosa -
[email protected]
CANopen - Formal Specification and Validation - Conformance Testing
15
Validation of the CANopen Specification using Spin PROMELA Validation Model
Specification (Formal)
Spin
Validator
Random Simulation
Validation
Trace
Spin
Guided Simulation
• Main results: – Identification of ambiguities and inconsistencies in the specification. – Identification of problems introduced by message loss and message duplication. – Clarification of the use of timeout mechanisms. Manuel Bernardo Barbosa -
[email protected]
CANopen - Formal Specification and Validation - Conformance Testing
16
Conformance Testing Theory • Objective: to establish that the control structure in an implementation complies with the control structure defined in the specification. • Using suitable abstract models, conformance is an implementation relation between the set of implementations and the set of specifications. • Specifications and implementations can be modeled as Finite State Machines (FSM). Implementarion relation: FSM equivalence. • Conformance Testing is the problem of establishing whether F SMIU T is equivalent to F SMspec, given that: – there is complete knowledge of F SMspec, – and that F SMIU T is a black-box of which only the input and output signals are known → testing through I/O sequences Manuel Bernardo Barbosa -
[email protected]
CANopen - Formal Specification and Validation - Conformance Testing
17
Test Case generation vs Test Case evaluation • Ideally it should be possible to automatically generate Test Cases from models of specifications. • Several methods have been proposed, but they all suffer from severe practical limitations (explosion). • An expert in the technology that is to be tested (seldom an expert in testing) must be involved in the Test Case generation process. • Formal methods can be useful in assessing Test Case quality. • One of the ways in which this can be achieved is applying reachability analysis techniques to models of Test Case execution. Manuel Bernardo Barbosa -
[email protected]
CANopen - Formal Specification and Validation - Conformance Testing
18
Test Case Evaluation Through Reachability Analysis • Set of transitions/states not reached in F SMspec, when it is stimulated according to a given Test Case: Tuncovered ⊂ T /Suncovered ⊂ S • Clearly, a Test Case does not cover all of the implementation’s functionality Suncovered 6= ∅ ∨ Tuncovered 6= ∅ and the verification performed by the Test Case is not complete.. • Defining the sets Ttarget ⊂ T and Starget ⊂ S as the set of transitions and states that the designer of the Test Case identifies as relevant in the verification of an IUT, a good Test Case implies: Smissed = Starget ∩ Suncovered = ∅ ∧ Tmissed = Ttarget ∩ Tuncovered = ∅ Manuel Bernardo Barbosa -
[email protected]
CANopen - Formal Specification and Validation - Conformance Testing
19
Evaluation of CANopen Test Cases Tester
Lower Tester Model
User Layer Model Model (Formal Specification) of the IUT
Simplified model of the Lower PCO System Under Test
Manuel Bernardo Barbosa -
[email protected]
CANopen - Formal Specification and Validation - Conformance Testing
20
Example: NMT Test Case Model inline NodeGuard() { message_out.identifier=RECEIVE_A; AL_to_DLL[0]!message_out; if :: DLL_to_AL[0]?message_in -> if :: ((M_slave_state != message_in.AL_msg.state)||(toggle != message_in.AL_msg.toggle)) -> printf("Conformance Error: State"); :: else -> toggle = 1-toggle; fi; :: timeout -> printf("Conformance Error: Timeout"); fi; } proctype LowerTester() { ... M_slave_state=STT_PREOPERATIONAL; command=CMD_RESETAPP; SendCommand(); NodeGuard(); command=CMD_OPERATIONAL; ... };
Manuel Bernardo Barbosa -
[email protected]
CANopen - Formal Specification and Validation - Conformance Testing
21
Results • Identification of points of execution left uncovered by Test Cases. • Test Case coverage enhancement. • Test Case simplification maintaining Test Case quality. • Experimental trials on commercial devices demonstrate benefits. Device Test Case Version SDO PDO NMT State Transitions
A Old 0 0 0
New 6 0 0
Manuel Bernardo Barbosa -
[email protected]
B Old 0 0 0
New 6 1 0
C Old 0 0 0
New 5 0 1
D Old 0 0 1
New 4 0 1
E Old 0 0 0
New 5 0 1
CANopen - Formal Specification and Validation - Conformance Testing
