CAN and CANopen communication protocol

The standardized communication protocol CANopen is a higher-layer protocol  based on the CAN protocol, used for industrial embedded networking. Before going into the basics of CANopen, an overview of the CAN protocol is helpful in order to have a better understanding of the CANopen communication protocol.

CAN bus

CAN is a serial communication bus protocol that uses a unique bus access control method called ‘Nondestructive Bitwise Arbitration’. “It supports distributed real-time control with a very high level of security” as mentioned by Sunit K . Sen (2014a). CAN was officially introduced by Bosch in 1986 and was intended to satisfy the high demand for electronic control systems in the automotive industry (Sunit K . Sen, 2014a).

CAN only implements the two lower levels of the Open System Interconnection (OSI) sevenlayer model, the ‘Data link layer’ and the ‘Physical Layer ‘out of 7 layers . The ‘data link layer’ is responsible for packaging the received data (from the physical layer) in ‘frames’. The physical layer provide the connection of the data link layer (the CAN controller) to the physical medium (transmission medium), as it contains the CAN transceiver. The CAN transceiver has a double role, as it also converts the received signals (from the CAN controller) to a differential signal between the two wires of the network cable, are refereed as CAN_L and CAN_H (Ayre et Keydel, 2003).

A typical CAN bus consists of a twisted pair cabling with termination resistors (120 Ohm) on each side, and nodes that are connected through CAN_H and CAN_L signals(Ayre et Keydel, 2003). The use of differential signal bus makes the CAN bus very robust to external noise, thus any electromagnetic interference (EMI) is avoided. CAN bus speed can achieve 1 Mbit/s for a bus length less than 45 meters, however the bit rate decreases with the bus length(Ayre et Keydel, 2003).

A variety of higher layer protocols were developed based on CAN, such as CANopen and DeviceNet. The basics of the CANopen application layer are presented next.

CANopen communication protocol 

CANopen is a standardized communication higher-layer protocol, implemented through the higher layers of the OSI seven-layer model. Many communication/networking technologies lack a dominant higher layer protocol standard; they only offer data transmission and reception functionalities without any specification regarding the data type or the number of messages streaming over the network (a sort of layer 2 (Data link layer) interface) (Ayre et Keydel, 2003).

In the CANopen protocol, the following parts of the higher layers (Figure 1.5) are implemented (Ayre et Keydel, 2003):
• network layer: destination addressing and routing via Service Data Object (SDO) channels, interaction functionality between a host and the network (configuration via SDO objects, etc.);
• transport layer: provides communication reliability between source and destination (provided by Network Management (NMT) services);
• session layer: defines functions, such as ‘write access’ to a shared database record (SDO channel management) and synchronization; and
• Presentation layer: involves data representations in a standardized way (Object dictionary, etc.).

A typical CANopen device model . The device has three function units (CAN in automation, 2011):
• Communication function unit : provides the link between the object dictionary and the data transportation support, which is the network;
• Object dictionary; and
• Application function unit: ”the application comprises the functionality of the device with respect to the interaction with the process environment” (CAN in automation, 2011). The terms SDO, NMT, and Object Dictionary are related to the CANopen protocol and will be defined in the following subsections.

Object Dictionary

The object dictionary is the core of any CANopen device. It is a table of objects with a 16- bit index and an 8-bit sub-index. Node information and configuration is stored in the object dictionary. All the processes and data used by the application will also be stored as entries ith predefined addresses. Within the object dictionary it is possible to define the data types for each assigned variable, and to configure a node and modify its parameters by writing to the object dictionary related to that node (CAN in automation, 2011).

Service Data Object (SDO) 

Since each node can implement its own object dictionary (OD), it can also implement a server for reading and writing access to that object dictionary. SDO is a direct method to access an OD using the ‘Client and server’ communication type (Ayre et Keydel, 2003). This method is especially useful during the initialization phase of a CANopen-based communication session, as it allows the network master to initializeand configure other nodes. There are two types of SDO objects, ‘SDO read’ which implement a read access and ‘SDO write’ which implements a write access. While it is possible to build an entire communication system by only using SDOs, for real-world real time implementation, the Process Data Object (PDO) method is preferable.

Table des matières

INTRODUCTION
CHAPTER 1 LITERATURE REVIEW
1.1 Morphing wing
1.1.1 Morphing concept
1.1.2 Benefits of ‘morphing’
1.1.3 Morphing skins
1.2 CRIAQ 7.1 Project
1.2.1 Morphing mechanism
1.2.2 Control system architecture used with wing morphing
1.2.3 Control method used for morphing wing
1.3 CRIAQ MDO 505 Project
1.4 Fieldbus
1.5 CAN and CANopen communication protocol
1.5.1 CAN bus
1.5.2 CANopen communication protocol
1.5.2.1 Object Dictionary
1.5.2.2 Service Data Object (SDO)
1.5.2.3 Process Data Object (PDO)
1.6 MODBUS communication protocol
1.6.1 Overview
1.6.2 MODBUS protocol variants
1.6.3 MODBUS TCP/IP
1.7 Aerospace Communication protocols
1.8 Digital PID control
CHAPTER 2 MORPHING WING SYSTEM: OVERVIEW
AND ARCHITECTURE
2.1 Morphing wing model description
2.1.1 Wing description
2.1.2 Model Morphing Mechanism
2.2 Wing control system setup
2.2.1 Real time controller NI PXI-e 8135
2.2.2 Fieldbus communications
2.2.3 EPOS2 24/5 drives
2.3 System Software Setup
2.4 CANopen communication protocol implementation: Application
to the EPOS2 24/5 drives
2.5 Modbus TCP/IP communication protocol implementation: Application to the
Kollmorgen® drive
2.5.1 Overview
2.5.2 Modbus TCP implementation
CHAPTER 3 WING SHAPE MORPHING
3.1 Wing morphing in open loop
3.1.1 Skin shape open loop control
3.2 Skin shape closed loop control
3.2.1 Principle of the closed loop
3.2.2 Closed loop implementation:
3.2.3 Closed loop model structure and execution
3.2.4 Adjustment of the closed loop parameters
3.3 Skin shape morphing using lookup tables
3.3.1 Principle of ‘lookup tables’
3.3.2 Open loop measurements
3.3.3 Measurements analysis
3.4 Skin shape morphing using feedback on DDI
3.4.1 Principle of the closed loop on DDI
3.4.2 Retrieving displacement values from DDI
3.4.3 DDI closed loop implementation
3.4.4 Optimization of the wing shape for one flight condition
3.5 Flight case calibration procedure
3.5.1 Principles of flight case calibration
3.5.2 Models’ mutual interaction during flight cases calibration
3.5.3 Automating the calibration procedure:
3.6 Skin shape morphing using system identification
3.6.1 Principle
3.6.2 Data collection
3.6.3 Model integration and implementation
CHAPTER 4 Wind Tunnel Tests and Results
4.1 Wind Tunnel Tests
4.1.1 NRC-CNRC wind tunnel description
4.1.2 Preparation and performance of the tests
4.2 Results
4.2.1 Wing shape morphing using lookup table results
4.2.2 Wing shape morphing using calibration results
4.2.3 Overview of aerodynamic results
CONCLUSION 

Cours gratuitTélécharger le document complet

 

Télécharger aussi :

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *