Automating Hardware and Software integration testing based on CAN open protocol

Shreeram P Hungund & Senior Test Engineer

Raghavendra S & Test Lead

Larson and Toubro Technology Services ltd

AbstractIn today’s world, automation for embedded systems network increases rapidly. Hardware and Software integration testing is one important phase on PDLC. CAN protocol is widely used in several industries like automotive, avionics and medical devices. It is the broadcast based communication protocol between devices. On the other hand, CAN Open is the multi master CAN based communication protocol and profile based device specification. CAN Open uses the CAN Hardware for application layer in OSI/ISO model, the task includes are Configuring, accessing, messaging between various kinds of devices.

This paper describes the automation testing of CAN open protocol applications is used in Embedded network as a hardware and software integration testing by using CAN open protocol tools and scripting language. Here, we are using CAN open protocol in embedded network and automating the CAN open application using PCAN view tool and Unit test framework for the result of automation testing.

Keywords: CAN open protocol, Automation, Hardware and software integration testing, PCAN view tool, Python scripting

Introduction:

1. CAN Open:CANopen is a standardized application for distributed automation systems based on CAN (Controller Area Network) offering the following performance features:

Transmission of time-critical process data according to the producer consumer principle

Standardized device description (data, parameters, functions, programs) in the form of the so-called "object dictionary". Access to all "objects" of a device with standardized transmission protocol according to the client-server principle

Standardized services for device monitoring (node guarding/heartbeat), error signalization (emergency messages) and network coordination ("network management")

Standardized system services for synchronous operations (synchronization message), central time stamp message

Standardized help functions for configuring baud rate and device identification number via the bus

Standardized assignment pattern for message identifiers for simple system configurations in the form of the so-called "predefined connection set"

Application

Device profile for generic I /O

modules (CiA 401, V3.0)

Device profile drives and motion control (CiA 402,

V2.0)

...

Interface and device profile for IEC 61131-3

programmable devices (CiA 405, V2.0)

...

CANopen application layer and communication profile (CiA 301, V4.1, also EN 50325-4) and CANopen framework for CANopen managers and programmable

CANopen devices (CiA 302, V3.4)

CAN data link layer (ISO 11898:2003)

CAN physical layer (ISO 11898:2003)CANopen Bus

CANopen is a "Layer 7" CAN protocol that defines communication and device functions for CAN-based systems. CANopen is a standardized, highly flexible, and highly configurable embedded network architecture used in industries such as Railway, Medical, Industrial, Agriculture, Heavy Truck & Bus, Marine, Off-Highway, Factory Automation, Aerospace, and many others. CANopen is also becoming a popular choice for closed, company-specific embedded networks. The CAN open profile family specifies standardized communication mechanisms and device functionalities

CAN Open Structure:

Compared to the ISO/OSI Stack, CANopen is a "Layer 7" communication profile based on CAN, which is standardized in ISO 11898. It is supplemented by a set of device profiles.

The ISO OSI Stack

The Device Model:

he device model consists of three main components:

Communication Object Dictionary Application

CANopen Device Model

The Object Dictionary:

CANopen is built around the central concept of an Object Dictionary (OD), the interface between the application and communication within each device. Every function, variable and data type seen via the network must be described in the OD.

The Communication channels:

The basic communication mechanisms are categorized as one of the following relationships: Client / Server - Point-to-point connection. The client always takes the initiative (N Clients, n Servers) Master / Slave - Point-to-point connection. The Master always takes the initiative (1 master, 1...127 Client Servers) Producer / Consumer - This broadcast connection is exactly like the CAN protocol’s broadcast capability. The Producer takes the initiative during the unconfirmed relationship. The Consumer takes the Initiative during the confirmed relationship (N Producers, M Consumers) The two most important communication types are the Process Data Object (PDO) and Service Data Object (SDO)

PDO (Process Data Object):The PDO is used for normal process data communication, the primary purpose of the CANopen network. And broadcast based non acknowledged protocol

SDO (Service Data Object):The SDO is used for configuration and diagnostic access to a device. It is not as fast as PDO, but provides the most flexible means to read/write any amount of data. SDO can access the object dictionary and acknowledged protocol

Network Management A CAN open network requires a Network Management (NMT) Master and all NMT Slave devices to implement a state machine. The NMT Master controls the status of all the NMT Slaves on the network. After "power-on" and internal initialization, the NMT Master automatically brings every Slave device into

the "Pre-operational" state. Each Slave device may be configured and parameterized via SDO (e.g., Master or configuration tool), but no PDO communication is allowed at this state. Now the NMT Master may switch all nodes (or a single node) to their "Operational" state. In the "Operational" state, all communication objects are active. Switching a node into a "Stopped" state terminates all PDO and SDO communication.

NMT State Machine

Device Profiles:CANopen uses the concept of device profiles. These profiles define all mandatory functionality for particular device classes and enable standardized access to that functionality.The goals of these device profiles are: Define mandatory functionality and provide access to the basic functionality, for example: "set output" for I/O or "halt" function for drives. Provide pre-defined communication objects and interchangeability of standard functionality, for example: "set filter" for I/O or "feed command value" for drives. Unification of the device's state machine for easier setup of networks. Locate vendor-specific functionality in the Object Dictionary - realization of vendor-specific features such as "edge evaluation" for I/O Define additional error conditions - extension for pre-defined error codes in the DS-301 for device-specific errors such as "short circuit on the output" for I/O

2. PCAN View tool:The PCAN-USB adapter enables simple connection to CAN networks. Its compact plastic casing makes it suitable for mobile applications. The opto-decoupled version guarantees galvanic isolation of up to 500 Volts between the PC and the CAN side.

3. Test Stub:

Test stubs are mainly used in incremental testing's top-down approach. Stubs are computer programs that act as temporary replacement for a called module and give the same output as the actual product or software.

4. Unit Testing Framework:The Python unit testing framework, sometimes referred to as “PyUnit,” is a Python language version of JUnit, by Kent Beck and Erich Gamma. JUnit is, in turn, a Java version of Kent’s Smalltalk testing framework. Each is the de facto standard unit testing framework for its respective language Unit Test supports test automation, sharing of setup and shutdown code for tests, aggregation of tests into collections, and independence of the tests from the reporting framework. The Unit Test module provides classes that make it easy to support these qualities for a set of tests.

Methods and Procedures:

Automation testing of CAN open protocol applications can be achieved using PCAN view tool by using Python unit framework. Python scripts are written in unit framework in order to get the results of can open protocol applications testing.

Connecting the CAN Bus and testing procedure:

A High-speed CAN bus (ISO 11898-2) is connected to the 9-pin D-Sub connector. The pin assignment for CAN corresponds to the specification CiA® 303-1.

Pin assignment High-speed CAN

Simple CAN communication and result:

Simple CAN connection

The one end of PCAb view tool USB is connected to PC and other end is connected to Control devices like micro control boards. Here Pin 2 is CAN low and pin 7 will be the CAN high.

Hardware connection should be proper on order to get the packet transmission as shown below.The Receive/Transmit tab is the main element of PCAN-View. It contains two lists, one for received messages and one for the transmit messages. The CAN data format is hexadecimal by default,

We automated the CAN open protocol applications using PCAN view tool by python unit framework. the transmitting and receiving the CAN packets will be performed using python scripting in unit framework. The final test result captured in the command line argument and record in Test script document for documentation or future use.

Receive/Transmit tab

Test stub testing procedure:

Test stubs are the test code which is used to simulate a specific test condition.Let us take an example of CAN based Medical bed.Scenario:To test a condition with patient present state as true (i.e. patient is on the BED) either weight should be placed on the bed or additional tester should sleep on the BED.But with the Test stub approach same condition can be simulated without placing weight/patient on the BED.

In above case testing can also be carried without mattress and weight sensors. Hence additional hardware can be reduced.

Code snip (in c/c++) is added for reference:Actual code without test stub:void getPatientStatus(bool newPatientDetected){ newPatientDetected = global_flag; }global_flag is 1: Patient is on the BEDglobal_flag is 0: Patient is on the BEDIn real environment 'global_flag' will set only when weight/patient is on the bed.

Modified code with stub:Create a dummy stub function as followsvoid stub_patientState(uint8_t pps_data) { global_flag = pps_data;}Use CAN SDO to call the stub function "stub_patientState" with following arguments.If 'pps_data' is 1 -> Patient is on the SurfaceIf 'pps_data' is 0 -> Patient left the Surface Sample data captured using in PCAN-View tool (is an easy to supervise the data flow on a Controller Area Network (CAN))In Embedded/Medical systems the Firmware code and user added test stubs are flashed to DUT (Device under test).

References & AppendixI. https://vector.com/portal/medien/cmc/application_notes/AN-ION-1-

1100_Introduction_to_the_CANopen_Protocol.pdfII. http://www.peak-system.com/PCAN-View.144.0.html?&L=1 III. https://www.peak-system.com/produktcd/Pdf/English/PCAN-USB_UserMan_eng.pdf IV. https://en.wikipedia.org/wiki/Test_stub V. https://docs.python.org/2/library/unittest.html

Author Biography

1. Shreeram P HungundShreeram is working as senior test engineer V&V departments in Larson and Toubro Technology Services ltd Mysore. He has about 6.5 years of work experience in product testing and verification. He holds MTech in Electronics from PESIT Bangalore.

2. Raghavendra SRaghavendra S is working as Test lead in V&V departments for Larsen and Toubro Technology Services ltd Mysore. He has about 12.8 years of work experience in Software development, Product Validation and Test Automation development in embedded domain

THANK YOU!