CiA® 416 series: CANopen application profile for building door control

1st TPDO is transmitted to all other (here two) connected devices and accepted/rejected according to object mask

The profile specifies the CANopen interaction of automatic building door control sub-systems e.g. door locking status, key cylinder, handle, alarms, system parameters, keypads etc. Each of those properties is realized as a virtual device (VD).

The application profile specification includes three parts:

  • Part 1: General definitions, start-up procedures and system security
  • Part 2: Virtual devices overview
  • Part 3: Pre-defined communication objects and application object specification

A physical CANopen device consists of one or more free-combinable VDs. Each VD supports a set of mandatory objects and may implement a set of optional objects. Each physical CANopen device implements the 1st pre-defined TPDO (transmit process data object) with a specified mapping structure. Among others, the 1st TPDO contains the VD basic index indicating which VD sent the data. All networked devices receive the 1st TPDO from each other device. An object mask is used to decide if the data contents have to be processed or not. The relevant data is stored in the VDs collection object array.

Each VD covers an index range of eight objects, with the same structure of the first four objects. The first object contains the application data sent via TPDO. The index of the first object (VD basic index) identifies the virtual device. The second object is a collection array for storing the received relevant data from other devices. The third object is a mask array indicating whether the received data is relevant for the application. The fourth object contains configuration data of the VD.

The application profile specifies two start-up behaviors: with ACP (address claiming procedure) active or with ACP not active. In the first case the device receives its node-ID using the address claiming procedure. In the second case the device uses a pre-configured node-ID. At system start-up, all devices have normally the same setting (ACP active or not).

Each device may be assigned to a group (group 1, group 2, no group or both). During the ACP each device claims its node-ID and informs other nodes about it’s group belonging. The claiming message receivers use this information to set up their object masks. A device only “listens” to data sent by a device of the same group.

Activation of the specified data encryption and decryption increases the system security level. A new device cannot be added to a network valid as “configured”. In order to avoid an unauthorized object data change, the access to the object dictionary is password protected. In order to avoid an eavesdropping and manipulation of PDO data in the system, the PDO communication can be encrypted.

The used physical layer complies with ISO 11898-2. The default bit-rate is 125 kbit/s with bit-timing as specified in CiA 301 v. 4.2.0. It is recommended to use CiA 303-1 connectors. Besides the standard bus topology, the network may be implemented in a combined star and tree topology. Each compliant device should use a 24-V power supply.

The currently valid CiA 416 version 2.0.0 was released in August 2007.

Title Details
Status
Size
Published
Action
CiA 301 version 4.2.0CANopen application layer and communication profile
DescriptionThis specification specifies the CANopen application layer. This includes the data types, encoding rules and object dictionary objects as well as the CANopen communication services and protocols. In addition, this specification specifies the CANopen network management services and protocols. This specification specifies the CANopen communication profile, e.g. the physical layer, the predefined communication object identifier connection set, and the content of the Emergency, Timestamp, and Sync communication objects.
Keywordsn/a
PAS3.0 MiB2011-02-21Login
CiA 416-1 version 2.0.0CANopen application profile for building door control – Part 1: General definitions, start-up procedures and system security
DescriptionThe CANopen application profile for building door control consists of several parts: Part 1: General definitions, start-up procedures and system security, Part 2: Virtual devices overview, Part 3: Pre-defined communication objects and application object specification. These specifications represent the CANopen application profile for building door control. It describes the interaction of e.g. door locking status, key cylinder, handle, alarms, system parameters, keypads and many more. Each of those properties is realized as a single virtual device.
Keywordsn/a
DSP670 KiB2007-08-28Login
CiA 416-2 version 2.0.0CANopen application profile for building door control - Part 2: Virtual devices overview
DescriptionThis part of the application profile gives an overview of the virtual devices.
Keywordsn/a
DSP361 KiB2007-08-28Login
CiA 416-3 version 2.0.0CANopen application profile for building door control - Part 3: Pre-defined communication objects and application data objects
DescriptionThis part of the application profile pre-defines the application objects of the physical and virtual devices in detail
Keywordsn/a
DSP3.6 MiB2007-08-28Login