Testing CANopen system

Testing CANopen system
Bari 15 june 2015 CAN in Space Workshop Testing CANopen system Bruno Storni

CAN in Space Workshop Testing CANopen Systems
Topics Introduction on CANopen systems How to test CANopen systems COTS Tools Example on CANoe ADELSY CAN in Space Workshop Testing CANopen Systems

Introduction on CANopen Systems
CANopen standard for Higher level layer protocol CAN in Automation Advanced distributed intelligent system General system specs CiA 301 CANopen Specification Specific system CiA 302 Additional application Layer functions CiA 305 layer setting services LSS CiA 306 Electronic Data Sheet CiA 310 conformance test plan CiA 311 XML specifications CiA 302 The definition of the network management includes the definition of the network startup behavior as well as definitions that are related to networks that operate without NMT master, networks with one CANopen device capable of the NMT master mode, and networks with more than one CANopen device capable of the NMT master mode (NMT flying master for higher availability). These definitions are intended to be an add-on to the CANopen application layer and communication profile (see /CiA301/). CANOpen systems implent ha higher layer level protocol Basically based on a SW interface between applications and a protocol stack Communication object as Object Dictionnary Some services are mandatory Configurable Not simple to test Large number of test cases ADELSY CAN in Space Workshop Testing CANopen Systems

Introduction on CANopen Systems
Specific for devices or Device Profile Spec CiA 401 Generic I/O Modules CiA 402 drive and motion controllers CiA 404 measuring devices and closed loop controllers CiA 406 incremental absolute linear and rotary encoders … …. CiA 460 service robot controller CiA 302 The definition of the network management includes the definition of the network startup behavior as well as definitions that are related to networks that operate without NMT master, networks with one CANopen device capable of the NMT master mode, and networks with more than one CANopen device capable of the NMT master mode (NMT flying master for higher availability). These definitions are intended to be an add-on to the CANopen application layer and communication profile (see /CiA301/). CANOpen systems implent ha higher layer level protocol Basically based on a SW interface between applications and a protocol stack Communication object as Object Dictionnary Some services are mandatory Configurable Not simple to test Large number of test cases ADELSY CAN in Space Workshop Testing CANopen Systems

CAN in Space ECSS E50-15 Selected Higher Layer protocol CANopen CiA Draft Standard 301 V4.02 Added a Redundancy Management Protocol Defined Time Distribution data formats Defined Physical layer ISO and 2 or RS485 ADELSY CAN in Space Workshop Testing CANopen Systems

Can in Automation CiA Organisation for promoting CAN 500 companies user’s and manufactures Developed CANopen Long time Draft Standard Now EN standard ADELSY CAN in Space Workshop Testing CANopen Systems

CANopen (cont) CAN based Higher Layer protocol for embedded control systems Machine control Medical devices Off-road and rail vehicles Maritime electronics Building automation Power generation ... ADELSY CAN in Space Workshop Testing CANopen Systems

CANopen (cont) CANopen profiles CiA defined specific Object dictionary for different types of devices e.g.: DS 401 Generic I/O modules DS 402 Drive and Motion Control etc Standardised profile area index 6000 ADELSY CAN in Space Workshop Testing CANopen Systems

CANopen (cont) ADELSY CAN in Space Workshop Testing CANopen Systems

CANopen (cont) MultiProtocols in one Master slave ( NMT) Client server ( SDO) Produced consumer (PDO) Distributed database ADELSY CAN in Space Workshop Testing CANopen Systems

CANopen (cont) Application Layer Implements CAN application layer elements defined by CiA CMS CAN-based Message Specification NMT Network ManagemenT DBT DistriBuTor LMT Layer ManagemenT Communication by objects Object dictionary ADELSY CAN in Space Workshop Testing CANopen Systems

CANopen (cont) ADELSY CAN in Space Workshop Testing CANopen Systems

CANopen (cont) Object dictionnary Grouping of objects accessible via network Adressed by index and subindex ADELSY CAN in Space Workshop Testing CANopen Systems

CANopen (cont) State diagram of a device Master slave ADELSY CAN in Space Workshop Testing CANopen Systems

CANopen (cont) Service Data Objects SDO Access object dictionary Parameters of nodes Configuration of node Client server model Server is Object dictionary of a node Download / upload Different modes of SDO Expedited, segmented , block transfer Acknowledged exchange ADELSY CAN in Space Workshop Testing CANopen Systems

CANopen (cont) Electronic data sheet EDS Description of device for networks design Communication objects Service data objects SDO Process data objects PDO Synchronisation object SYNC Emergency object EMCY Network management objects NMT ADELSY CAN in Space Workshop Testing CANopen Systems

CANopen (cont) Process Data Objects PDO Up to 8 octets Unconfirmed service Producer consumer Synchronous Cyclic, acyclic, after RTR Asynchronous After RTR, Event driven ADELSY CAN in Space Workshop Testing CANopen Systems

CANopen (cont) Syncronisation object SYNC Syncronise devices of the network Synch Producer Emercency object EMCY Information about status of device Content of an error register ADELSY CAN in Space Workshop Testing CANopen Systems

CANopen (cont) Network management objects NMT Master slave Module (device) control protocol Start, stop, Enter operational,.. Bootup protocol Error control protocol Heartbeat or Nodeguard ADELSY CAN in Space Workshop Testing CANopen Systems

CANopen complexity CANopen is quite complex Many services are configurable Sets of Mandatory and optional services and objects Complex option Plug and Play Highly dynamic Systems Complex testing tools and time !! Obvioulsy CANopen is known as quaite a complex standard Services and objects are configurables Tailor each node and intercommunication Mandatory for node guard either Heart Beat or Node guard Other such as Plug and play for Highly dynamic systems is not a function required everwhere , for instance in space it can be smanaged by adequate Network management system control Therefore also testing of CANopen System is a complex task requiring adequate tools and a an import effort to configure them ADELSY CAN in Space Workshop Testing CANopen Systems

CANopen complexity But also simple Standardized device profiles simplify communication between bus nodes simplify interplay between components (ECUs, sensors and actuators) from different manufacturers Not yet for Space applications Obvioulsy CANopen is known as quaite a complex standard Services and objects are configurables Tailor each node and intercommunication Mandatory for node guard either Heart Beat or Node guard Other such as Plug and play for Highly dynamic systems is not a function required everwhere , for instance in space it can be smanaged by adequate Network management system control Therefore also testing of CANopen System is a complex task requiring adequate tools and a an import effort to configure them ADELSY CAN in Space Workshop Testing CANopen Systems

How to test CANopen systems
Tests Modules Modules as Application Communication ( CANopen) Tests whole System Complexity very challenging Testing highly dynamic CANopen system (plug and play ! Layer Setting Services : node ID set through the network HIGHLY DYNAMIC CANOPEN SYSTEMS support plug-and-play and node ID assignment by LSS (Layer Setting Services, node ID gets assigned through the network). As a result, devices may change their node ID, making tests more challenging. One of the test utilities introduced in this paper is now available as free download from ESAcademy’s web pages. It supports the extended concise DCF (Device Configuration File) as introduced in the paper. It allows users to write down configuration or test sequences in a table (save as .csv) and execute them using the free CANopen File Player. The file format, the concise Default Configuration File is part of the basic CANopen definitions and has been in use for quite some time. The extension to it is simply a definition of a set of commands introducing the option to control things like addressing specific devices (identify by CANopen Identity record 1018h) and time delays / timeouts or user interactions. In addition, the utility can re-play previously made CAN trace recordings, supporting a wide variety of formats from Vector, Peak, and others. ADELSY CAN in Space Workshop Testing CANopen Systems

How to proceed? First: Prototyping Components of a system ECU Sensors Actuators Testing starts ad specification and design phase Some components already tested (ESD ) Not yet for Space applications ADELSY CAN in Space Workshop Testing CANopen Systems

How to proceed? Develop a simulated complete system Stepwyse approach Simulate single elements and integrate them ADELSY CAN in Space Workshop Testing CANopen Systems

How to proceed? Create a prototype environment Simulate complete system Simulate single units (nodes) ECUs Sensors Actuators Define communication (layer) CANopen between nodes ( as real system config) Define Application Layer of every node Systematic tests accompanying the development of a total system are indispensible in all development steps. Often it is possible to test, but not until a very late time, when actual system components are available. Then, the system completion date is at risk if problems occur. In practice, tests are not performed on the real system at the customer’s facil ities, rather test setups are used for this purpose. Besides special measurement or diagnostic setups, in testing they also include actuators for simulating system environments as realistically as possible. Depending on the project size, such a test setup could incur much cost and effort. Bottlenecks are built into the process during the test phase, since generally only one test setup is available. A way out of this dilemma might be offered by a software tool that could be used to create a prototype of the future total system in a simple way. Optimally, this tool would also offer extensive test functions. ADELSY CAN in Space Workshop Testing CANopen Systems

How to proceed? CANopen configuration of each node is defined in EDS (first step of design, prototyping phase) Means interrelations between nodes Process data objects e.g. Physical parameters of system, pressure, rotational speed, accelleration The behavior of the CANopen ECUs is defined in description files (EDS – Electronic Data Sheet) that are selected or created beforehand. This next step is to define the interrelationships between calibration data that will later be exchanged over the bus, e.g. the “PressureValve” input of the device with address 5 (pressure transducer) is linked to the “Gas pressure” variable of the device with address 10 (control module). This is how all PDO (Process Data Object) interrelationships are defined in the prototype system. ADELSY CAN in Space Workshop Testing CANopen Systems

How to proceed? Application layer is specific for every node Similar to real unit Simulate it in prototyping phase from simple Ccode to MATLAB/Simulink Not part of CANopen system test Defining application behavior The application behavior of individual ECU nodes cannot be derived directly from the EDS files, since they only map the structure of an object directory. Therefore, formulation of application behavioralways involves additional programming effort. The CAPL programming language integrated in CANoe makes it possible to program ECU behavior quickly. As an alternative it is possible to code ECU behavior in a DLL that is linked in the prototyping environment under CANoe. It is also easy to integrate MATLAB/Simulink models ADELSY CAN in Space Workshop Testing CANopen Systems

How to proceed? Protype implemented (simulated) Test steps Functionalty Tests (bottom up) PROTOCOL LEVEL COMMUNICATION LEVEL APPLICATION LEVEL Test functionality After the prototype system has been completed, the necessary tests for the total project follow. CANoe supports the user here, both in creating tests and in logging and evaluation. The test functionality required for a CANopen system comprises several stages (Figure 4): >> Protocol level: Tests on this level ensure that CANopen-specific communication protocols of the individual devices are implemented within the total system according to specification. >> Communication level: What is important here is not the correctness of the protocol, but the correct logical order of (independent) protocol sequences, e.g. in configuring PDOs. Description of the PDO-relevant entries in the object directory must conform to a specific sequence. >> Application level: Application tests check the relationships between process variables. The following preconditions must be met to even determine such relationships: First, the process variables must be exchanged via PDOs, and the system must be fully configured. This means, for example, that the state of a valve can be checked as a function of a temperature or a pressure. Clearly, the user must have the relevant know-how to formulate the test. ADELSY CAN in Space Workshop Testing CANopen Systems

How to proceed? Create (generate test sequences) Test simulated system Implement nodes Integrate nodes in simulated system Creating and executing test procedures with CANoe Test sequences are formulated under CANoe with the help of the integrated CAPL programming language. Each CAPL test module represents a separate test consisting of individual test cases, which in turn contain a number of test steps. During the test run, CANoe processes the individual test cases sequentially. Suitable test flow control makes it possible to skip or repeat individual tests. Simultaneously, it is possible to monitor conformance to other conditions and restrictions – quasi in background. This might be done, for example, to determine – while waiting for a specific message of interest – whether a specific other message is sent periodically on the bus. Especially in automated tests, it is important to record the results of individual test steps in detail. Other CAPL functions handle writing of test results to an XML file for later post-processing. Test sequences for CANoe can also be specified under XML. This is advantageous when a large number of test flows need to be generated with a single tool. So CANoe utilizes a number of test patterns specified in XML and processes them accordingly ADELSY CAN in Space Workshop Testing CANopen Systems

COTS Tools overview Embedded Academy IXXAT Vector Informatic ADELSY CAN in Space Workshop Testing CANopen Systems

Embedded System Academy (ESAc)
ESAc offers a set of tools HW and SW Testing or Diagnosing Automotive industry Diagnosing Hand Held Tool CiA 447 Searching for defect parts in car After sale testing CiA447 Car Add-On Devices Support When ordered with the CiA 447 add-on, the system offers various additional functions dedicated to CiA 447. The additional SDO channels and the wake-up sleep mechanism is monitored and all traces include CiA 447 symbol interpretation. Enchancements to Existing Functions The status monitor and event history includes CiA 447 specific data and events. The monitored data includes Virtual Device information and statistics about the individual SDO clients. The network scanner scans for CiA 447 specific information such as the Virtual Device information. The CANopen Diag Manager software can interpret traces from the continuous logger with CiA 447 symbolic data representation. Some Concise Device Configuration Files and tests for the Test Machine offer specific CiA 447 support. CiA 447 Tester The CANopen Diag hand held module can be set into a CiA 447 tester mode, as defined by the CiA 447 doucments. Selecting this function starts a CiA 447 tester node running within CANopen Diag. It becomes an active node on the CANopen network and if no default node ID is chosen in the “CANopen Settings”, it waits for the gateway to detect it and assign a node ID to it dynamically. The tester can produce undirected or directed background traffic of different load levels. Wild 13 Mode The wild 13 mode is an extreme stress test for the gateway or another DUT. In this mode, there are multiple tester nodes. Go to the local menu by pressing the dial to activate Wild 13 mode and select 1, 3, 5, 7, 9, 11 or 13 representing the number of additional tester nodes that should run simultaneously. To further increase the stress for the DUT, the tester in wild 13 mode will also duplicate SDO requests sent to the DUT. Where the tester in standard mode uses one SDO client to read from the DUT, in wild 13 mode the DUT will receive read requests from up to 14 nodes – one tester and 13 duplicates. ADELSY CAN in Space Workshop Testing CANopen Systems

ESAc CANopen Diag CANopen Diag functions Network Status and Event History (passive) Show network events Boot up times x nodes First PDO usage Emergencies Show network status Longest HB time Max SDO resp time …. Functionality Provided by CANopen Diag The following is an overview to the specific functions and tests that CANopen Diag provides. Network Status and Event History This set of functions is “passive”, it does not actively produce CAN messages. It should be started before the boot cycle of a network starts, so that the entire boot cycle can be monitored. The event history shows all important network events, such as boot up times of individual nodes, first PDO usage, emergencies and node failures / restarts The network status includes information such as current and longest heartbeat time of each node, maximum SDO response time, as well as current and maximum message rate of each node Network status overview When this function is selcted, a current, overall network overview is diplayed, including: number of nodes found, number of boot-up messages, current bus load, longest message burst, SYNC usage, SDO usage, LSS usage. For ech node found the display can include: NMT status, message load generated by node, node info where available (e.g. names of Virtual Devices implemented by a device) min/max heartbeat, min/max SDO response times, current message rate. One of several display detail modes can be chosen, from a minimal, icon based display for layman users to a detailed mode for experts showing all numbers. Active Network Scanner Here, the device becomes an active node on the network and uses SDO channels to actively scan the network. This allows building a list of currently present nodes and reading detailed information of each node. Information displayed includes the Virtual Device Information, the regular ID Object as well as the extended ID strings (Objects 1008h to 100Ah) and the error history. Write to Node This function allows sending the NMT (Network Management) Master message to individual nodes – for example to send a reset to a selected node. It allows clearing the error history as well as processing Concise Device Configuration Files (CDCF) to send complex configurations to a node. If a device has a CANopen boot loader, then CANopen Diag can activate the bootloader and send a file to it. For CANopen experts a generic write functions is provided, allowing a SDO write request to any node. CANopen aware trace recording In continuous logging mode a trace file of all CAN message is created. Using the included CANopen Diag manager app running on a PC, this file can be converted into a .csv file with all CANopen specific interpretations of the message contents. ADELSY CAN in Space Workshop Testing CANopen Systems

ESAc PC Management Management SW Detect CANopen Diag units Manage test file Represent test results Etc PC Management The user-friendly management software can automatically detect connected CANopen Diag units and provide access to files, logs, trace recording and test files. It allows easy download and synchronization of new firmware and test files. Multiple CANopen Diag units can be managed at once using a single copy of the application. Each Diag is uniquely identified. Adding new tests to the Diag from our online database is as simple as opening the tests window, updating the list then choose which tests to copy to the Diag. For each test the complete test details can be viewed. This shows every state and how the test moves between the different states. The test states can be exported to be used in product testing documentation. Results from executing tests are displayed in the management software. All test results are automatically detected and presented in the user interface. Each test result file contains a checksum generated by the Diag, which can be used to ensure results files have not been tampered with. CAN bus trace logs can be displayed with standard CANopen or CiA447 message interpretation. Timing analysis can be performed to measure times between any messages. Event log recordings are shown in the management software and can be exported to CSV files for documentation or further analysis. ADELSY CAN in Space Workshop Testing CANopen Systems

ESAc test sequences ex PC Management The user-friendly management software can automatically detect connected CANopen Diag units and provide access to files, logs, trace recording and test files. It allows easy download and synchronization of new firmware and test files. Multiple CANopen Diag units can be managed at once using a single copy of the application. Each Diag is uniquely identified. Adding new tests to the Diag from our online database is as simple as opening the tests window, updating the list then choose which tests to copy to the Diag. For each test the complete test details can be viewed. This shows every state and how the test moves between the different states. The test states can be exported to be used in product testing documentation. Results from executing tests are displayed in the management software. All test results are automatically detected and presented in the user interface. Each test result file contains a checksum generated by the Diag, which can be used to ensure results files have not been tampered with. CAN bus trace logs can be displayed with standard CANopen or CiA447 message interpretation. Timing analysis can be performed to measure times between any messages. Event log recordings are shown in the management software and can be exported to CSV files for documentation or further analysis. ADELSY CAN in Space Workshop Testing CANopen Systems

CANoe CANoe development test and analysis environment for CAN Support 3 phase model CANoe.CANopen enables efficient planning, management, simulation, test and startup of CANopen networks. During the system design phase the user has the opportunity to simulate the later behavior of a system, estimate the bus load, and draw conclusions, like the necessary hardware performance, supported with extensive, CANopen-specific functions. ADELSY CAN in Space Workshop Testing CANopen Systems

CANoe ADELSY CAN in Space Workshop Testing CANopen Systems

CANoe Includes CANeds and ProCANopen CANopen simulation models CANopen functionalites of nodes simulated with nodelayer DLL Automatic generation of test sequences Use device description in EDS Full coverage of CiA310 test specification CANopen includes the configuration tool ProCANopen and the EDS editor CANeds. Simulation A significant aspect of CANoe. CANopen is the automatic generation of simulation models. The application oriented C-based language, CAPL (communication access programming language) from Vector is used as the programming language for this purpose. All information necessary for the generation exist in the device descriptions that are set up using ProCANopen. The entire CANopen-specific functionality of an ECU is simulated by a nodelayer-DLL. The user can utilize the functionality of this DLL by means of function calls from a generated CAPL program. This makes it very easy to initiate a SDO access to another device in the network from the CAPL program. Automatic Test Generation It is easy to generate test sequences for CANopen devices. The necessary test functions are identified and assembled into a sequence, based on device descriptions existing in standardized format (EDS files). CANoe.CANopen runs through these sequences. All test results are conveniently logged and documented to a report file. Full coverage of the CiA310 test specification, which forms the basis of the CiA Conformance Test, is thus ensured. ADELSY CAN in Space Workshop Testing CANopen Systems

CANoe Test scenarios NMT status machine and error control SDO protocol Test Send PDO test Test of Object access and object defualt values The following test scenarios can be generated: SDO protocol test Receive PDO test Send PDO test „Hidden Object“ test Test of object access and object default values NMT Status Machine and error control ADELSY CAN in Space Workshop Testing CANopen Systems

CANopen (cont) Configuration nodes EDS Complexity in test ADELSY CAN in Space Workshop Testing CANopen Systems

Standard CANopen test sequences generation ADELSY CAN in Space Workshop Testing CANopen Systems

ADELSY CAN in Space Workshop Testing CANopen Systems

Testing CANopen system

Similar presentations

Presentation on theme: "Testing CANopen system"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Testing CANopen system

Similar presentations

Presentation on theme: "Testing CANopen system"— Presentation transcript:

Similar presentations

About project

Feedback