|WP2 - Architecture Specification: Deliverable D2.1 - Architecture and Components Integration|
|Prev||Chapter 8. Communications Components||Next|
List of abbreviations used in the document
Controller Area network
Communication object (CAN message). A unit of transportation in a CAN network. Data must be sent across a network inside a COB.
Unique ID of the COB. The identifier determines the priority of the COB in the MAC sub-layer too.
Electronic Data Sheet
Finite State Machine
CANopen FSM in this article means a state automat processing CAN messages.
Handlers Definition Sheet
COBs designated for network management ie. initialize, start, stop nodes etc.; this service is implemented according to master-slave concept.
Common representation of device parameters, process variables, configuration, communication settings and device data types. Accesible as SDO objects from CANopen network. The textual description of OD is called EDS file.
Process Data Object
CANopen objects designed for real-time process data exchange.
PDO received by device in order to set appropriate PDO mapped objects value.
Remote Transmission Request
CAN message to initiate RPDO object sending.
Service Data Object
CANopen service objects designated for manipulation with slaves object dictionaries.
Special Function Object
Special purpose messages ie. SYNC, time stamp, emergency, node/life guarding, boot-up objects.
PDO transmitted by device when device specific event occurs (ie. timer or object value is changed) or as a response to the RTR or after SYNC object.
Virtual RT-CAN API
* - this abreviations are not standardised yet and they are valid only in OCERA project
The goal of our team work is to develop set of software tools and real-time modules/applications necessary for building of CANopen network solutions. We also want to make tools to facilitate the CANopen slaves and master configuration using the textual EDS files and the bus monitoring. By developing the CANopen real-time driver, software slave and master we will get basic blocks to connect to working CANopen network. Any industrial CANopen device can be plugged to this network.
To reach that goal, the next points have to be fulfilled.
to develop CAN API called the virtual CAN API (VCA), usable for user space threads and also for the RT-Linux ones.
to develop a RT-Linux CAN driver providing VCA interface to the application RT-Linux threads and also to the user space ones.
to develop software CANopen slave.
to develop software CANopen master.
to develop EDS parser tool for setting software CANopen master and slave parameters in the convenient way.
The virtual CAN API is the interface to connect application thread either with the CAN hardware card or with other software layers substituting CAN bus. The application thread can be in RT_Linux/kernel space or in the user space.
RT-CAN driver resides in the RT-Linux address space as the real-time thread. It means, that any CAN message can be handled in a deterministic time horizon.
Two interfaces are exported. First one is the set of handlers needed for device /dev/canxx. The second one is the Virtual CAN API (VCA) designed for driver communication with POSIX threads.
As you can see in the following figures, RT-CAN driver contains the table of buffers for transmitted and received CAN messages. This buffers can be considered, from the CANopen point of view, to serve as the RPDO and TPDO buffers. The COB-ID mask can be registered to each buffer. Driver also contains the FIFO for receiving and transmitting the CAN messages. This FIFO will be used for the SDO communication.
Next figures show possible usage of the VCA.
Real-time application thread uses directly VCA of RT-CAN driver for the communication with a CAN bus.
In Figure 8-9 the application thread and CAN driver reside in different address spaces. To connect kernel space and user space, we use device /dev/can xx. The applications which will not use VCA can use directly /dev/can and the standard set of I/O operations (read, write, ioctl). A libCAN is needed to grant the same API to user space and kernel space threads. This approach supports portability of application threads between the kernel and user spaces on the source code level.
On Figure 8-10 we can see option, that gives us an opportunity to exploit the VCA even if no real CAN hardware is used. This solution is designed mainly for development purposes and testing. The dashed line in the figure means that CAN substitution layer can optionally operate on some other device than /dev/can (ie. Ethernet). CAN substitution layer can be also a kind of user space application providing the VCA. This can be very useful during development or for educational purposes.
RT-CANopen slave (only slave or CANopen slave will be used instead in rest of this section) is the software solution based on the hardware, RT-CANopen FSM threads, EDS file and HDS file (see Figure 8-11).
CANopen slave components description
Slave FSM: Slave FSM means set of RT-Linux threads providing PDO and SDO communication via CAN driver VCA. Slave FSM also calls appropriate handler PDO communication and looks into the slave's object dictionary in case of SDO request.
PDO handlers: User written module containing handlers for reading/writing PDO mapped object data from/to hardware.
EDS: EDS means the Electronic Data Sheet, text file describing all objects in the slave object dictionary. EDS is parsed in order to create the slave OD.
HDS: HDS means the Handler Definition Sheet, text file describing the linking PDO's COB-ID with required handler in order to grant correspondence between the CANopen object value and technological process data from the hardware. For example a thermometer with the analog output connected to PC A/D convertor card needs handler which reads temperature from the card output port and gives it to the FSM. The slave designer have to write this handler code while the FSM source code remains always the same, OCERA written.
As can be seen on figure above CAN driver sends the CAN messages to CANopen FSM via VCA. FSM handles messages of two main categories, process data (PDO) and service data (SDO, NMT, SFO).
The process data (PDO objects) are handled separately of the service ones. Slave FSM exploits CAN driver message buffers as the buffers for the slave PDOs. This approach is necessary because some CAN chips have such buffers integrated. On the other hand this can speed up PDO object handling. Slave FSM role lies in updating this buffers after device specific event such is timer event or process object value change. The CAN driver sends objects from its buffers when needed (after SYNC object or as a response to RTR object). Consequently slave FSM has to read this buffers after WPDO object arrival.
The PDO handler module is used to synchronize PDO mapped objects values and real world data examined or set by computer hardware. Every PDO mapped object has assigned its reading and writing routine called PDO handler. These handlers are written by control system developer in order to fit general FSM concept to specific hardware and real world process.
Some of SFO are handled directly by CAN driver. Such objects are the SYNC or RTR frames
Other objects (SDO, NMT) are sent through the SDO API to OD driver. OD driver is responsible for all object dictionary manipulations, that means getting and setting object values. If the PDO mapping change occurs due to SDO object processing, OD driver informs slave FSM (via SDO API) to correct PDO handlers table to reflect PDO mapping status in OD properly.
OD driver communicates with OD daemon, which resides in the user space, through RT FIFOs. OD daemon offers set of primitives to provide basic manipulations with OD like get/set object value, add object, delete object etc. OD daemon also owns slave OD in its memory space.
Slave OD can be loaded onto OD daemon memory by EDS parser. EDS parser is the graphical front end to the OD daemon connected with it via Unix socket. This gives us the opportunity to control the daemon and slave OD remotely using TCP/IP. EDS parser is also responsible to read HDS and make appropriate changes in daemon OD and also (via daemon SDO API) in slave FSM PDO handler table. This ensures that the proper handlers will be called for certain PDO objects.
For diagnostic and visualization purposes the diagnostic couple of pipes exists. This pipes can be connected to the diagnostic and monitoring application.
This architecture is very similar to the previous one. The main difference lies in OD position which is a part of OD driver module now. Every other part of slave remain the same. OD driver module is compiled from source code generated by EDS parser from the slave EDS, HDS and the empty OD driver template.
Benefits of the kernel space solution
Faster SDO object processing.
Slave does not need user space applications to work properly.
Slave can be implemented to other POSIX compliant real-time OS like RTEMS.
Suitable for CANopen slave realization in embedded systems.
Disadvantages of the kernel space solution
OD is static, no objects can be added or removed.
EDS parser can not explore OD any more. The diagnostic pipe has to be used for that purpose and all the information must be communicated through SDO API and slave FSM.
RT-CANopen master architecture is very similar to the user space slave one. CAN driver, FSM, OD driver and OD daemon are the same. New blocks, PDO processor and PDO object table are introduced and OD daemon contains OD of all slaves connected till now.
PDO objects table is a memory mirror for transmitted and received PDOs. When a new RPDO comes, it is written into the table and PDO processor is notified by master FSM about this event. On the contrary, when PDO processor updates some object in the write part of PDO table, the FSM should be notified to allow it to transmit object change across the network.
PDO processor is an user written set of functions designated for processing objects from read part of PDO table and generating new value of objects in write part of PDO table. New generated write objects can be sent across the CAN, if the processor notifies master FSM. This way the RPDO-TPDO mapping rules or control algorithms can be realized.
We expect to design PDO processor as a special PDO handler (from slave FSM point of view). This approach gives us the opportunity to have the same FSM for slave and master.
The master OD daemon holds one or more slave EDS. That means, that the slave OD daemon is a special case of the master one. Thanks to this generalization we can have also one code for the master and slave OD daemon.
When we look at the paragraphs above, we can see, that the User space CANopen slave and the CANopen master share the same code, which can be any time configured to run as a master or as a slave.
The RT-CANopen architecture design is based upon 4 basic elements.
The Virtual CAN API introduces either real CAN network or any substitution of that sublayer to the application threads. Application threads can reside in user space or in kernel/RT-Linux space.
The CANopen FSM is an kernel space state machine connected to VCA, which can handle the process data (PDOs) and service data (SDO, NMT, SFO). The PDOs are handled by PDO handler functions. The service data objects are resent through a SDO API to OD driver for other processing and its response is sent back if necessary.
The OD driver manages a device OD. It is also able to communicate with FSM via EDS API to provide it information about every particular object. The OD driver can be realized either whole in the kernel space or partially in the user space (OD daemon).
The EDS parser serves for processing EDS and configuration files. Processed data are loaded into OD daemon (master, user space slave). EDS parser can also generate OD driver module source code in C (kernel slave concept).
This philosophy gives us the opportunity to reuse common elements to build the CANopen master or slave even to define it in process of configuration.
[CANOpen] CiA CANopen - Application Layer and Communication Profile, CiA Draft Standard 301 CAN in Automation e. V. 1 June 2000
[[EDS]] CiA, CANopen: Electronic Data Sheet Specification for CANopen, CiA Draft Standard Proposal 306, CAN in Automation e. V., 31 May 2000.