Explains vocabulary and abbreviations used in CAN technology
Alphabetic selection:
Definitions:
See electronic data sheet.
Software tool that checks the conformity of electronic data sheets. The CANopen EDS checker is integrated into CiA's CANopen conformance test tool.
Software tool that generates electronic data sheets (available for CANopen and DeviceNet).
See error frame.
The electronic data sheet describes the functionality of a device in a standardized manner. CANopen and DeviceNet use different EDS formats. It is specified in CiA 306-1 for CANopen devices.
Pre-defined communication service in CANopen mapped into a single 8-byte data frame containing a 2-byte standardized error code, the 1-byte error register, and 5-byte manufacturer-specific information. It is used to communicate device and application failures.
Set of CENELEC standards defining a CANopen application profile for passenger information systems, which was developed in cooperation with the German VDV. It specifies interfaces for a range of devices including displays, ticket printers, passenger counting units, main onboard computers, etc.
CENELEC standard defining the CANopen application layer and communication profile, which is further developed in the CiA 301 specification.
CENELEC standard defining the CAN open Safety protocol. The CANopen framework for safety-relevant communication is an add-on to the CANopen application layer and communication profile. The CANopen Safety protocol is designed to allow safety-related communication based on CAN according to IEC/EN 61508. It is approved by German authorities and fulfils the requirements to build systems requiring SIL 3 (safety integrity level) according to IEC 61508.
Seven recessive bits make the EOF field of CAN data and remote frames (only in Classical CAN).
An object attribute in CANopen defining this object as mandatory, conditional (mandatory for certain conditions) or optional.
In error active state the CAN controller is allowed to transmit active error frames containing active error flags. If all CAN nodes are in this state, then a network wide data consistency is guaranteed.
CANopen specifies error codes transmitted in emergency messages.
The CANopen error control messages are mapped to a single 1-byte CAN data frame assigned with a fixed identifier that is derived from the device's CAN open node-ID. It is transmitted as boot-up message before entering the NMT pre operational state after initialization. It is also transmitted periodically by the device (heartbeat) or, if remotely requested (only in Classical CAN implementations) by the NMT master (node guarding).
Each CAN controller implements two error counters, one for received messages and one for transmitted messages. They are increased and decreased user-transparently by implemented rules as specified in ISO 11898-1. They are used to determine the current state of the CAN module (error active, error passive, and bus-off).
Last segment in error frames made up of 8 recessive bits.
There are five different failure detection mechanisms in the CAN protocol, which allow the detection of nearly any error in a CAN message. The probability of nondetected failures depends on error rate, bit rate, busload, number of nodes and error detection capability factor.
First segment in error frames made up of 6 bits of the same polarity. A second error flag transmitted by another node may overlap the first error flag.
Frame to indicate the detection of an error. It is made up of the error flag and the error delimiter.
Local failures cause the transmission of an error flag, which will be regarded as a stuff error forcing the other nodes to transmit error flags. This means the local failure is globalized, so that network-wide data consistency is guaranteed for nodes in error active state.
In this state, CAN controller is only allowed to transmit passive error frames containing passive error flags. Additionally the CAN controller has to wait a certain time after a previous transmission before its own transmission takes place (suspend transmission).
The error signaling is provided by means of transmitting error frames.
The error state indicator bit in the CAN FD data frame indicates whether the transmitting CAN node is in CAN error active (dominant) or passive (recessive) state.
See error state indicator.
The event timer is assigned in CANopen to one PDO. It defines the frequency of PDO transmission.
Event-driven messages are transmitted when a defined event occurs in the device. This may be a change of input states, elapsing of a local timer, or any other local event.
An event-driven PDO (process data object) is transmitted whenever a device internal event (e.g. elapsing of PDO's event timer) occurs. If an event-driven PDO is received the protocol software immediately updates the mapped objects in the object dictionary.
This is a confirmed communication service in CANopen (peer-to-peer). It is defined in CiA 301 v. 4.2.0 and former versions. It is made up by one SDO (service data object) initiate message of the client node and the corresponding confirmation message of the server node. Expedited SDOs are used if not more than 4 byte of data has to be transmitted.
The explicit message is a confirmed communication service in DeviceNet used for configuration purposes. It supports segmented transfer in order to transmit information longer than 8 byte.
Also called CAN 2.0B – a protocol variation where the identifiers are 29 bits long. Commonly used in automotive CAN networks. Also see Standard CAN.
Data Job S.r.l. is the Italian sales representative of the KVASER products
We are available for any information about the hardware and software products.
Contact us