CAN-based Higher Layer Protocols and Profiles

liuxianglong

CAN-based Higher Layer Protocols and Profiles


1. Introduction


The CAN protocol has gained worldwide acceptance as a very versatile, efficient, reliable and economic platform for almost any type of data communication in mobile systems, machines, technical equipment and industrial automation. Based on sophisticated standardised higher layer protocols and profiles, CAN-based open automation technology successfully competes on the market of distributed automation systems. One of the main reasons for the enormous success of CAN-based systems obviously are the special features of the CAN-protocol, especially its producer-consumer- oriented principle of data transmission and its multimaster capability. With these properties, the CAN-protocol also from the technical point of view is very attractive for the usage in distributed systems applications.



When referring to the "CAN standard" or "CAN protocol" we understand the functionality which is standardised in ISO 11898 [1] respectively [2]. This standard comprises the Physical (Layer 1) and Data Link Layer (Layer 2) according to the OSI-reference model. Whereas Layer 1 is responsible for functions like physical signalling, encoding, bit timing and bit synchronisation, Layer 2 performs functions like bus arbitration, message framing and data security, message validation, error detection and signalling and fault confinement. The CAN standard does not specify the medium attachment unit and the medium upon which it resides, nor an Application Layer.



The Layer 2 of the CAN protocol offers two types of connectionless transmission services to the user:



Unacknowledged transfer of a CAN-message and
Unacknowledged remote request of a CAN-message
Connectionless transmission means that no data link connection has to be established before performing a message transfer or request. Reception of messages is supported by the CAN chips in form of different type object filtering and object buffering methods. A Layer 2 CAN data message according to the CAN Specification V 2.0 is determined by the message identifier, standard/ extended format indication, data length and the data to be transmitted.



Since the CAN-Protocol specifies no rules for the assignment of message-identifiers, a variety of different, application-specific usages is possible. Assignment of the CAN message identifiers therefore is one of the most important decisions when designing a CAN-based communication system. Assignment and allocation of message identifiers also is one of the main items of a higher Layer approach.



The Requirement of Higher Layers

In practice the implementation even of very simple distributed CAN-based systems shows, that beside of the basic Layer 2 services further functionality is required or desirable e.g. for the transmission of data blocks longer than 8 bytes, acknowledged or confirmed data transfer, identifier distribution, network start-up or the supervision of nodes. Since this additional functionality directly supports the application process, it is understood as "Application Layer". If implemented properly, the introduction of an Application Layer in addition with an appropriate Application Layer Inte***ce provides a clearly defined separation of communication and application processes.




Since the CAN protocol provides very unique features, most of the known higher layer protocols conserve this features for the user of the Application Layer by providing direct access to the services of the Data Link Layer (no additional protocol overhead for basic functions).



Especially for industrial automation applications, the need for open, standardised higher layer protocols was raised which support interoperability and exchangeability of devices of different manufacturers. Supplementary to a standardised Application Layer therefore the specification of standard device models, "standard devices" and "standard applications" of basic functionality is required.



In the following at first a short overview of the main higher layer protocol solutions will be given. Then the main items of the different solutions will be presented. Within the scope of this ***** it is only possible to evaluate some of the main aspects. The main focus will be given to higher layer protocols for industrial automation.
2. Survey of CAN-based Higher Layer protocols


According to the widespread usage of CAN networks with different objectives and requirements beside of many special solutions several main standards of CAN-based Higher Layer protocols are available today. According to the different requirements these solutions differ significantly with respect to their scope and performance.



Representatives of widely accepted Application Layer standards for direct usage by the application are CAL[3] and OSEK [4]. Whereas CAL may be considered as application-independent application layer applicable in any kind of CAN-based application which directly uses the services of the application layer, the OSEK-Com/Net specification represents an application layer and network management functionality whose application is primarily intended for networking in cars.



CAL (CAN Application Layer) was specified as one of the first work items of CAN-in-Automation (CiA) and was published in 1993. CAL offers an application-independent, object-oriented environment for the implementation of CAN-based distributed systems [6]. It provides objects and services for communication, identifier distribution, network and layer management. Main application areas of CAL are CAN-based distributed systems which do not require configurability and standardised device modelling. A subset of CAL is used as Application Layer of CANopen. Therefore CANopen devices may be used within application-specific CAL systems.



OSEK/VDX is a joint project of the automotive industry with the objective to provide an industry standard for an open architecture for distributed control in vehicles. This standard comprises the definition of a real-time operating system, software inte***ces as well as a communication and network management system. The OSEK operating system provides services for management and synchronisation of tasks, interrupt management, alarms and error handling. One major goal of the approach was the provision of a common platform to integrate software modules from various manufacturers. As the operating system is intended for use in any type of control units, it must support time-critical applications on a wide range of hardware. The OSEK communication specification [6] defines a hardware and bus system independent application inte***ce. Communication between local and remote tasks is performed by the operation system via "Message Objects". Two types of messages are distinguished: "State Messages" and "Event Messages". State Messages always represent the most actual state of a system variable (not buffered), by means of Event Messages events are reported. Thereby each message has to be processed by the consumer. Both types of messages can be used in a peer-to-peer and multicast fashion with transfer modes periodically, event-driven and periodically/eventdriven. Transport Layer services provide acknowledged and fragmented transfer of data in addition to the unacknowledged and unfragmented services of the Data Link Layer.



Based on the very high requirements of in-vehicle communication a sophisticated Network Management System is specified [7] which has to ensure the safety and reliability of the communication network. By means of "Node Monitoring" every node is actively monitored by every other node in the network (Direct Monitoring). For this purpose the monitored node sends a NM message according to a dedicated and uniform algorithm. Direct node monitoring requires a network-wide synchronisation of NM messages. For this purpose a logical ring is used. Any node must be able to send NM messages to all other nodes and receive messages from them.



If direct monitoring is too complex for a device the principle of "Indirect Monitoring" may be applied. It is based on the observation of application messages and limited to nodes which periodically send messages. A node of that type may be monitored by one or more other nodes.



A quite different kind of an open system solution is provided with the SAE J1939 [11] standard. This standard was defined by the Society of Automotive Engineers Heavy Truck and Bus Division to provide an open interconnect system for electronic systems. Main applications are light, medium and heavy duty vehicles used on or off roads as well as appropriate stationary applications which use vehicle derived components. Vehicles include highway trucks and their trailers, construction equipment, agricultural equipment and ship instrumentation. J1939 is based on the usage of a 29 bit message identifier. The standardised usage of the message identifier results in the distinction of 8 priority classes, predefined message types, destination specific communication and broadcasting. In the J1939/7x standard in-vehicle and diagnostic messages are defined. Hereby data type, range, repetition rate etc. together with the corresponding Parameter Group Number determine the respective message identifier. Also the mapping of the messages into CAN data field of a parameter group is defined.