CleANopen - Application profile for municipal vehicles

This European Standard provides a set of CANopen application profile specifications that describes the CleANopen embedded body control network of municipal vehicles, e.g. refuse collecting trucks. It specifies the CANopen communication interfaces and the application functionality of several functional elements (virtual devices).
It does not specify CANopen devices. The CleANopen application profile specifications consist of several parts dealing with the following:
- general definitions;
- functionality of the virtual devices;
- pre defined PDOs and SDOs;
- application objects.

CleANopen - Anwendungsprofil für Kommunalfahrzeuge

CleANopen - Profil d’application aux véhicules municipaux

Le présent document fournit un ensemble de spécifications des profils d’application CANopen qui
décrivent le réseau de contrôle de caisse embarqué CleANopen des véhicules municipaux, par exemple les camions de collecte des déchets. Il spécifie les interfaces de communication CANopen et les fonctionnalités de l’application de plusieurs
éléments fonctionnels (dispositifs virtuels). Il ne spécifie pas les dispositifs CANopen.
Les spécifications des profils d’application CleANopen sont composées de plusieurs parties traitant des points suivants :
— définitions générales ;
— fonctionnalités des dispositifs virtuels ;
— objets PDO et objets SDO prédéfinis ;
— objets d’application.

CleANopen - Aplikacijski profil za komunalna vozila

Ta evropski standard podaja nabor specifikacij za aplikacijski profil CANopen, ki opisuje vgrajeno mrežo CleANopen za nadzor komunalnih vozil, npr. vozil za zbiranje odpadkov. Določa komunikacijske vmesnike CANopen in aplikacijsko funkcionalnost več funkcijskih elementov (virtualne naprave).
Ne določa naprav CANopen. Specifikacije aplikacijskega profila CleANopen zajemajo več delov, v katerih je obravnavano naslednje:
– osnovne definicije;
– funkcionalnost virtualnih naprav;
– vnaprej določeni objekti PDO in SDO;
– aplikacijski objekti.

General Information

Status
Published
Public Enquiry End Date
14-Nov-2018
Publication Date
04-Apr-2019
Technical Committee
Current Stage
6060 - National Implementation/Publication (Adopted Project)
Start Date
05-Apr-2019
Due Date
10-Jun-2019
Completion Date
05-Apr-2019

Relations

Buy Standard

Standard
EN 16815:2019
English language
979 pages
sale 10% off
Preview
sale 10% off
Preview
e-Library read for
1 day
Draft
prEN 16815:2018
English language
979 pages
sale 10% off
Preview
sale 10% off
Preview
e-Library read for
1 day

Standards Content (Sample)

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.CleANopen - Aplikacijski profil za komunalna vozilaCleANopen - Anwendungsprofil für KommunalfahrzeugeCleANopen - Profil d’application aux véhicules municipauxCleANopen - Application profile for municipal vehicles43.160Vozila za posebne nameneSpecial purpose vehicles35.240.60Uporabniške rešitve IT v prometuIT applications in transportICS:Ta slovenski standard je istoveten z:EN 16815:2019SIST EN 16815:2019en,fr,de01-junij-2019SIST EN 16815:2019SLOVENSKI
STANDARDSIST-TP CEN/TR 16815:20161DGRPHãþD



SIST EN 16815:2019



EUROPEAN STANDARD NORME EUROPÉENNE EUROPÄISCHE NORM
EN 16815
March
t r s { English Version
CleANopen æ Application profile for municipal vehicles CleANopen æ Profil d 5application aux véhicules municipaux
CleANopen æ Anwendungsprofil für Kommunalfahrzeuge This European Standard was approved by CEN on
u r December
t r s zä
egulations which stipulate the conditions for giving this European Standard the status of a national standard without any alterationä Upætoædate lists and bibliographical references concerning such national standards may be obtained on application to the CENæCENELEC Management Centre or to any CEN memberä
translation under the responsibility of a CEN member into its own language and notified to the CENæCENELEC Management Centre has the same status as the official versionsä
CEN members are the national standards bodies of Austriaá Belgiumá Bulgariaá Croatiaá Cyprusá Czech Republicá Denmarká Estoniaá Finlandá Former Yugoslav Republic of Macedoniaá Franceá Germanyá Greeceá Hungaryá Icelandá Irelandá Italyá Latviaá Lithuaniaá Luxembourgá Maltaá Netherlandsá Norwayá Polandá Portugalá Romaniaá Serbiaá Slovakiaá Sloveniaá Spainá Swedená Switzerlandá Turkey and United Kingdomä
EUROPEAN COMMITTEE FOR STANDARDIZATION COMITÉ EUROPÉEN DE NORMALISATION EUROPÄISCHES KOMITEE FÜR NORMUNG
CEN-CENELEC Management Centre:
Rue de la Science 23,
B-1040 Brussels
9
t r s { CEN All rights of exploitation in any form and by any means reserved worldwide for CEN national Membersä Refä Noä EN
s x z s wã t r s { ESIST EN 16815:2019



EN 16815:2019 (E) 2 Contents Page European foreword . 3 1 Scope . 4 2 Normative references . 4 3 Terms and definitions . 4 4 Acronyms . 5 5 Abbreviations . 6 6 General architecture . 6 7 Physical layer specification . 13 8 Error handling . 14 9 Data type specification . 15 10 Object dictionary entries . 15 11 Pre-defined TPDO communication . 50 12 Manufacturer-specific TPDOs . 446 13 Pre-defined RPDO communication . 447 14 Manufacturer-specific RPDOs . 784 15 Pre-defined additional SDO communication. 785 16 Object dictionary . 830 Annex A (normative)
Manufacturer-specific TPDOs for unit-specific use . 966 Annex B (normative)
Manufacturer-specific RPDOs for unit-specific use . 971 Annex C (informative)
Measurement process . 976 Bibliography . 979
SIST EN 16815:2019



EN 16815:2019 (E) 3 European foreword This document (EN 16815:2019) has been prepared by Technical Committee CEN/TC 183 òWaste managementóá the secretariat of which is held by DIN. This European Standard shall be given the status of a national standard, either by publication of an identical text or by endorsement, at the latest by September 2019, and conflicting national standards shall be withdrawn at the latest by September 2019. Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. CEN shall not be held responsible for identifying any or all such patent rights. This document is based on the version 2.0 of the CiA 422 specification series describes the embedded body control network of refuse collecting vehicles (RCV). It specifies the CANopen (EN 50325-4) communication interfaces and the application functionality of several functional elements (virtual devices). It does not specify CANopen devices. This document is structured as follows:
the 1st part (Clauses 3 to 9) contains general definitions and describes the functionality of the virtual devices as well as the CANopen physical layer requirements and recommendations.
the 2nd part (Clause 10) provides a detailed overview of communication and application parameters supported by the different virtual devices. Virtual devices include the body controller, and the change container, compaction, lifter, identification, measuring A and B, bin classification, washing, truck gateway as well as GPS units. Also a monitoring device is described
the 3rd part (Clauses 11 to 15) and its sub-parts specify the pre-defined Process Data Objects (PDO) and the additional pre-defined SDOs. The pre-defined Transmit-PDOs for all virtual devices ares specified in Clause 11. This includes the PDO communication parameter set as well as the PDO mapping parameter set. The corresponding Receive-PDOs are specified in Clause 13. The SDO communication between bin classification units and measuring units is specified in Clause 15.
the 4th part (Clause 16) specifies the application parameters. This covers the process data (mainly mapped into PDOs), configuration data, and diagnostic information (both mainly transmitted by SDO communication services). In this clause are defined parameter pools for the measuring units, and the data read as well as write for identification units. Other introduced parameters include support profile version, extended status for measuring units and measuring ident controllers. According to the CEN-CENELEC Internal Regulations, the national standards organisations of the following countries are bound to implement this European Standard: Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United Kingdom. SIST EN 16815:2019



EN 16815:2019 (E) 4 1 Scope This document provides a set of CANopen application profile specifications that describes the CleANopen embedded body control network of municipal vehicles, e.g. refuse collecting trucks. It specifies the CANopen communication interfaces and the application functionality of several functional elements (virtual devices). It does not specify CANopen devices. The CleANopen application profile specifications consist of several parts dealing with the following:
general definitions;
functionality of the virtual devices;
pre-defined PDOs and SDOs;
application objects. 2 Normative references The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies. ISO 639-1, Codes for the representation of names of languages
Part 1: Alpha-2 code ISO/IEC 646, Information technology
ISO 7-bit coded character set for information interchange ISO 11898-2, Road vehicles
Controller area network (CAN)
High-speed medium access unit SAE J1939-71, Recommended practice for a serial control and communication network
Vehicle application layer 3 Terms and definitions For the purposes of this document, the following terms and definitions apply. ISO and IEC maintain terminological databases for use in standardization at the following addresses:
IEC Electropedia: available at http://www.electropedia.org/
ISO Online browsing platform: available at http://www.iso.org/obp 3.1 CleANopen unit virtual device that provides functional elements specified in this application profile 3.2 functional element atomic application function SIST EN 16815:2019



EN 16815:2019 (E) 5 3.3 virtual device part of the logical device as defined in [CiA301] 3.4 left side when viewing forward, the left side 3.5 pitch angle from the front to the back of the vehicle (see Figure 1)
Figure 1
Pitch example 3.6 right side when viewing forward, the right side 3.7 roll angle from the left to the right side of the vehicle (see Figure 2)
Figure 2
Roll example 4 Acronyms The acronyms given in documents CiA301, CiA413 series and SAEJ1939 apply for this standard, too. BCU Bin classification unit BC Body controller MIC Measuring ident controller CAN Controller area network CCU Change container unit COB Communication object SIST EN 16815:2019



EN 16815:2019 (E) 6 COB-ID COB identifier CSDO Client SDO CU Compaction unit GPS Global positioning system GPSU GPS unit IDU Identification unit IVN In-vehicle network LSB Least significant bit LU Lifter unit MSB Most significant bit MU Measuring unit SSDO Server SDO TGU Truck gateway unit WU Washing unit 5 Abbreviations Acc. Access Cat. Category const constant ro read-only rw read/write 6 General architecture 6.1 General This application profile specification describes the virtual devices of municipal vehicle bodies (CleANopen units). Figure shows a simple example: The BC virtual device controls the overall system, however the other virtual devices communicate directly by means of PDOs. The virtual interfaces are implemented as CANopen interfaces or as CANopen device internal interfaces if the virtual devices reside in the same CANopen device. If the virtual interfaces between virtual devices are implemented as CANopen interfaces they use SDO or PDO services to read or write application objects. SIST EN 16815:2019



EN 16815:2019 (E) 7
Figure 3
Virtual devices interconnection (example) Most of the application objects are mapped into pre-defined PDOs. If an implemented application object is not mapped into one of the pre-defined PDOs, other CANopen devices can access them by means of SDO. The CSDOs, which corresponds to the Default SSDO, shall be implemented always in the BC virtual device. CANopen devices compliant to this application profile without BC functionality shall not implement any CSDO that relates to Default SSDO. For systems not comprising a BC, additional SDO channels are needed. This application profile pre-defines some SDO channels for dedicated functionality. For some virtual devices up to eight instances are specified. The instances with the very same number belong to one sub-system, e.g. LU 1, MU-A 1, and WU 1 belong to sub-system 1; LU 2, MU-B 2, and WU 2 belong to sub-system 2. When the BC is implemented, it is connected to all sub-systems. 6.2 Communication to the in-vehicle networks The communication to the truckïs in-vehicle networks is possible by means of truck gateways provided by the truck manufacturer. There are different implementations on the market as shown in the examples given in Figure 4. In the past, most truck manufacturers provided digital and analog inputs and outputs (a). In this implementation example, the TGU only transmits and receives those objects that are not used by the BC. It is also possible to implement the TGU in a generic I/O module compliant to [CiA 401 (b)]; it provides than TGU-compliant PDOs. Nowadays, some truck manufacturers provide a [CiA 413] or [CiA 422] compliant truck gateway (c). In this implementation example, the truck gateway provides TPDOs and RPDOs that correspond to those provided by the TGU. SIST EN 16815:2019



EN 16815:2019 (E) 8
Figure 4
Truck gateway implementation examples If the TGU is implement in the very same CANopen device as the BC, the communication can be done device-internally without transmitting COBs on the CAN network. 6.3 Numbering of the lifter units (LUs) The LUs can be positioned on the vehicle in different ways. The numbering of the LUs as given in this clause shall be used for the vehicles implementing this specification. The lifter units shall be enumerated from left to right while standing in front of the lifter. One compartment consists of four LUs in maximum. The 1st compartment consists of LUs 1 to 4. If there is a second compartment on the truck (e.g. for organic waste) it consists of the LUs 5 to 8. For other configurations it is up to the system integrator to provide the LU numbering. Figure 5 specifies the LU numbering for the single compartment front loader. Figure 6 specifies the LU numbering for the single compartment rear loader. Figure 7 specifies the LU numbering for the single compartment left side loader. Figure 8 specifies the LU numbering for the single compartment right side loader. Figure 9 specifies the LU numbering for the two-compartment rear loader. Figure 10 specifies the LU numbering for the two-compartment combined rear and side loader. SIST EN 16815:2019



EN 16815:2019 (E) 9
Figure 5
LU numbering for the single compartment front loader
Figure 6
LU numbering for the single compartment rear loader
Figure 7
LU numbering for the single compartment left side loader SIST EN 16815:2019



EN 16815:2019 (E) 10
Figure 8
LU numbering for the single compartment right side loader
Figure 9
LU numbering for the two compartment rear loader
Figure 10
LU numbering for the two compartment combined rear and side loader 6.4 Virtual device description 6.4.1 General Every virtual device represents a specific functional unit. Some of them can be installed multiply in one application. The following brief descriptions give an overview on the functionality of the different virtual devices. SIST EN 16815:2019



EN 16815:2019 (E) 11 The supported application objects are summarized in the clause on functionality of the virtual devices of this application profile. The detailed PDO interfaces are specified in the appropriate clause on pre-defined Process Data Objects (PDO) of this application profile. The detailed application objects are specified in the appropriate clause of this application profile. 6.4.2 Body controller (BC) The BC is the interface to the hydraulic and the pneumatic power supply of the disposal vehicle. Related to its operating mode some other units request optionally the supply of pressure from the BC. Other units need optionally the BC status information (e.g. to estimate the intervals of maintenance) for their operations. 6.4.3 Bin classification unit (BCU) The BCU classifies a waste bin attached to the lifter. Other units
virtual devices
use this classification for sequence control purposes:
LU lifts and empties or does not lift and does not empty the bin.
WU washes or does not wash the bin. The BCU implements optionally the measuring ident controller (MIC) functional element. The MIC combines the results of identification (through the IDU) and a measuring (through the MU). The MIC coordinates the correct matching of measured values and the waste bin using information from IDU and LU. The MIC can detect (using the LU) the emptying of a waste bin with or without transponder. There are up to eight BCU (1 to 8) instances possible in one logical CleANopen network. 6.4.4 Change container unit (CCU) The CCU is used for changing the collecting reservoir (container) of a disposal vehicle. It is also used for providing information about the mounted container (fixed or changeable). 6.4.5 Compaction unit (CU) The CU is used for compacting the waste and for providing information about the compaction process. It is used for synchronizing and for coordinating its activities with the LU. Other units use optionally the CU status information (e.g. to estimate the intervals of maintenance). 6.4.6 GPS unit (GPSU) The GPSU is used for providing geographical positioning as well as date and time information, which is recorded by other units. 6.4.7 Identification unit (IDU) The IDU is used for identifying waste bins by identifying a transponder attached to the waste bin. It can also write information to the transponder. The identification process is started by means of an explicit start command received from the MIC or automatically, when the IDU is supporting continuous identification. SIST EN 16815:2019



EN 16815:2019 (E) 12 6.4.8 Lifter unit (LU) The LU is used for controlling the emptying procedure of a single waste bin. It is also used for informing additionally other units:
about the state of a lifter,
if a waste bin is attached or not,
about the position of the lifter and whether the lifter is in the measuring window or not. It is possible to configure the LU. For example, that the lifter adjust its speed in the emptying process. This is needed to consider the particular features of some other units (e.g. MU). The LU is used for communicating with the CU to inform it whether the CU is or not in operation. The LU is used for communicating with the BC to demand power supply (e.g. hydraulic). There are up to eight LU (1 to 8) instances possible in one logical CleANopen network. 6.4.9 Measuring unit (MU) The MU is used for issuing measurement results acquired while treating the bin or the container. The MU is used for abstracting particularly the functionality of scales or devices to measure the volume. As scale the MU is used for measuring the weight of waste in the waste bin. As volume measurement device the MU provides the volume of the disposed waste. In some cases, it is necessary to measure up to two physical values on one lifter (e.g. weight and volume). For this case, the Measuring Unit A and Measuring Unit B are provided. Especially for scales, modes for manual and automatic measuring are implemented. While automatic measurement the scale controls the entire weighing process. While manual measuring the user is responsible for control of the measuring process. There are up to eight MU-A (1 to 8) and up to eight MU-B (1 to 8) instances possible in one logical CleANopen network. 6.4.10 Truck gateway unit (TGU) The TGU is used for providing the access to the in-vehicle networks of the truck. 6.4.11 Washing unit (WU) The WU is used for cleaning the waste bins. The LU provides the waste; it allows and starts the washing process. The WU informs about the state of the washing process and the washing equipment. While washing, no movement of the lifter is allowed. There are up to eight WU (1 to 8) instances possible in one logical CleANopen network. SIST EN 16815:2019



EN 16815:2019 (E) 13 7 Physical layer specification 7.1 General The CAN interface shall be compliant to the definitions and recommendations given in ISO 11898-2 and [CiA 301] and [CiA 303-1]. 7.2 Bit rate The physical CANopen device compliant to this application profile shall provide a default bit rate of 250 kbit/s and shall use the bit timing as specified in [CiA 301]. Other bit rates defined in [CiA 301] can be supported. 7.3 Bus topology The bus topology shall be compliant to the definitions and recommendations given in ISO 11898-2, [CiA 301] and [CiA 303-1]. 7.4 Bus cable The bus cable used shall be compliant to the definitions and recommendations given in ISO 11898-2 and [CiA 303-1]. 7.5 Bus connector The bus connector used shall be compliant to the definitions and recommendations given in ISO 11898-2 and [CiA 303-1]. 7.6 Node-ID assignment The assignment of a node-ID is required for every physical CANopen device. The assignment of node-IDs is manufacturer specific. For a better plug and play behaviour the assignment of the node-IDs is recommended as shown in Table 1. Table 1
Recommended node ID assignment Device Node-ID Body controller (BC) 10 Compaction unit (CU) 11 Container change unit (CCU) 12 Lifter unit (LU) 1 to 8 20 to 27 Bin classification unit (BCU) 1 to 8 30 to 37 Identification unit (IDU) 1 to 8
50 to 57 Measuring unit A (MU-A) 1 to 8 60 to 67 Measuring unit B (MU-B) 1 to 8 70 to 77 Washing unit (WU) 1 to 8 80 to 87 Truck gateway unit (TGU) 89 GPS unit (GPSU) 90 Monitoring device 1 to 8 91 to 98
If more than one virtual device is integrated to one CANopen device, the lowest node-ID shall be used. SIST EN 16815:2019



EN 16815:2019 (E) 14 8 Error handling 8.1 Principle Emergency messages shall be triggered by internal errors in the physical device and they are assigned to high priority to ensure that they get access to the bus without latency. By default, the Emergency messages shall contain the error field with pre-defined error numbers and additional information. 8.2 Error behaviour If a serious device failure is detected the physical device shall enter by default autonomously the pre-operational state. If object 1029h is implemented, the physical device can be configured to enter alternatively the stopped state or remain in the current state in case of a device failure. Device failures shall include the following communication errors:
Bus-off conditions of the CANopen interface;
Life guarding event with the state îoccurredïâ
Heartbeat event with state îoccurredïä Severe device errors also can be caused by device internal failures. 8.3 Additional error code specification Devices compliant to this application profile specification can use the error codes as defined in [CiA 301]. The third byte of the Emergency message (first byte of) described in the EMCY protocol in [CiA 301] shall be used as defined in Figure 11. 7 4 3 0 Virtual device number (see Table 2) Number of virtual device (1 to 8) MSB LSB Figure 11
Byte number 3 of the EMCY message SIST EN 16815:2019



EN 16815:2019 (E) 15 Table 1
Virtual device numbers Virtual device name Number BC 01h CCU 03h CU 04h LU 05h IDU 06h MU-A 07h BCU 08h WU 09h MU-B 0Bh GPSU 0Ch TGU 0Dh
9 Data type specification The application objects specified in this application profile use the data types defined in [CiA 301]. The BOOLEANn data type is specified in this part of the application profile. Data of basic data type BOOLEANn is represented as bit sequences of length n bit. The value attains a combination of TRUE and FALSE. The value TRUE (res. FALSE) is represented by the bit value 1 (res. 0). The profile-specific basic data types are specified in Table 3. Table 2
Profile specific basic data type definitions Index Object Name Examples 0060h DEFTYPE BOOLEAN2 bit1, bit2 0061h DEFTYPE BOOLEAN3 bit1, bit2, bit3 0062h DEFTYPE BOOLEAN4 bit1, bit2, bit3, bit4
10 Object dictionary entries 10.1 General Every CANopen device compliant with this application profile supports some general communication and application objects as well as virtual device specific application objects. It consists of one or more virtual devices as defined in [CiA301]. A virtual device shall not be distributed to several CANopen devices. Each virtual device supports a set of mandatory function-depending application objects and can implement additionally a variable set of optional application objects. SIST EN 16815:2019



EN 16815:2019 (E) 16 All objects are specified by means of object and entry description as defined in [CiA301]. The description attributes are defined in [CiA301]. The category attribute indicates, if an object shall be supported (Mandatory) or can be supported (Optional). The access attribute indicates, if an object is constant (const), read only (ro), read/write (rw) or write only (wo). Read only indicates that this object shall not be written via the bus; read/write allows to read and to write this object; and write only means that this object shall be not read via the bus. The default value attribute defines the behavior of objects after power-on or NMT application reset. The information given in 10.3 about application objects mapped into PDOs is informative, except the mapped dummy objects, they shall be mapped. 10.2 General communication objects 10.2.1 General CANopen devices compliant with this application profile use default values for some communication objects (1000h to 1FFFh), which are not specified in all details in [CiA301]. In the following sub-clauses these default values are specified in details. 10.2.2 Object 1000h: Device type This object describes the type of device and its functionality. The object and entry description are given in [CiA301]. Figure 12 shows the object structure and Table 4 defines the values for the virtual device code field. 31 24 23 16 15 0 Virtual device code reserved (0) Device profile number: 422d MSB LSB Figure 1
Object structure Table 3
Virtual device code values Code Function 01h Body controller (BC) 02h reserved for compatibility reason 03h Change container unit (CCU) 04h Compaction unit (CU) 05h Lifter unit (LU) 06h Identification unit (IDU) 07h Measuring unit A (MU-A) 08h Bin classification unit (BCU) 09h Washing unit (WU) 0Ah reserved for compatibility reason SIST EN 16815:2019



EN 16815:2019 (E) 17 Code Function 0Bh Measuring unit B (MU-B) 0Ch GPS unit (GPSU) 0Dh Truck gateway unit (TGU) 0Eh reserved for future use by CiA ::::: ::::: FDh reserved for future use by CiA FEh Monitoring device FFh reserved
10.2.3 Object 1001h: Error register The device profile specific bit in the error register is reserved for future use. The object and entry description are given in [CiA301]. 10.2.4 Object 1016h: Consumer heartbeat times This object shall be implemented, if the CANopen device receives event-triggered PDOs. The consumer heartbeat times are manufacturer-specific. The object and entry description are given in [CiA301]. 10.2.5 Object 1017h: Producer heartbeat time This object shall be implemented. The heartbeat producer time shall be set to > 0 by default; the value is manufacturer-specific. The object and entry description are given in [CiA301]. 10.2.6 Object 1018h: Identity This object is mandatory and contains in sub-index 01h the unique vendor-ID assigned by CiA. Sub-index 02h to 04h are optional. The object and entry description are given in [CiA301]. 10.2.7 Object 1029h: Error behavior This object specifies to which state the physical device shall be set, when a communication error or a device internal error is detected. Besides the specification given in [CiA301] the following sub-indexes can be implemented optionally. If the entire object is not implemented the CANopen device shall behave as the default values define. Table 5 defines the values. Table 4
Value definition Value Definition 00h Change to NMT state Pre-operational (only if currently in NMT state Operational) 01h No change of the NMT state 02h Change to NMT state Stopped
SIST EN 16815:2019



EN 16815:2019 (E) 18 The object description and the entry description for sub-index 00h and 01h are given in [CiA301]. Table 6 specifies the entry description for sub-index 02h. Table 5
Entry description for sub index 02h Attribute Value Sub-index 02h Description Internal device error Access rw Entry category Optional PDO mapping No Value range 00h to 02h Default value 00h
10.2.8 Object 1F80h: NMT startup This object shall be implemented. The object entry description is given in [CiA302-2]. The default value shall be the value for self-starting devices (see [CiA303-2]). 10.3 Supported application objects, PDOs, and SDOs 10.3.1 General If a specific entity of a virtual device is implemented in the CANopen device (e.g. IDU 4), in all relevant application objects the related sub-indexes (in this example 04h) need to be implemented. If several entities of a virtual device are implemented in the CANopen device (e.g. LU 2 and LU 6), in all relevant application objects the two related sub-indexes (in this example 02h and 04h) need to be implemented. The CANopen device, which implements one or more entities of a virtual device, needs to support the related TPDOs and RPDOs. For example: If WU 3 and WU 5 are implemented, TPD 60 and TPDO 92 (containing the WU status and WU-to-BC request) as well as RPDO 64 and RPDO 96 (containing the WU-to
...

SLOVENSKI STANDARD
oSIST prEN 16815:2018
01-november-2018
CleANopen - Aplikacijski profil za komunalna vozila
CleANopen - Application profile for municipal vehicles
CleANopen - Anwendungsprofil für Kommunalfahrzeuge
CleANopen - Profil d’application aux véhicules municipaux
Ta slovenski standard je istoveten z: prEN 16815
ICS:
35.240.60 Uporabniške rešitve IT v IT applications in transport
prometu
43.160 Vozila za posebne namene Special purpose vehicles
oSIST prEN 16815:2018 en,fr,de
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

---------------------- Page: 1 ----------------------
oSIST prEN 16815:2018

---------------------- Page: 2 ----------------------
oSIST prEN 16815:2018


DRAFT
EUROPEAN STANDARD
prEN 16815
NORME EUROPÉENNE

EUROPÄISCHE NORM

August 2018
ICS 35.240.60; 43.160 Will supersede CEN/TR 16815:2015
English Version

CleANopen - Application profile for municipal vehicles
CleANopen - Profil d'application aux véhicules CleANopen - Anwendungsprofil für
municipaux Kommunalfahrzeuge
This draft European Standard is submitted to CEN members for enquiry. It has been drawn up by the Technical Committee
CEN/TC 183.

If this draft becomes a European Standard, CEN members are bound to comply with the CEN/CENELEC Internal Regulations
which stipulate the conditions for giving this European Standard the status of a national standard without any alteration.

This draft European Standard was established by CEN in three official versions (English, French, German). A version in any other
language made by translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC
Management Centre has the same status as the official versions.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania,
Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland,
Turkey and United Kingdom.

Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are
aware and to provide supporting documentation.

Warning : This document is not a European Standard. It is distributed for review and comments. It is subject to change without
notice and shall not be referred to as a European Standard.


EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2018 CEN All rights of exploitation in any form and by any means reserved Ref. No. prEN 16815:2018 E
worldwide for CEN national Members.

---------------------- Page: 3 ----------------------
oSIST prEN 16815:2018
prEN 16815:2018 (E)
Contents Page
European foreword . 3
1 Scope . 4
2 Normative references . 4
3 Terms and definitions . 4
4 Acronyms . 5
5 Abbreviations . 6
6 General architecture . 6
7 Physical layer specification . 13
8 Error handling . 14
9 Data type specification . 15
10 Object dictionary entries . 15
11 Pre-defined TPDO communication . 50
12 Manufacturer-specific TPDOs . 446
13 Pre-defined RPDO communication . 447
14 Manufacturer-specific RPDOs . 784
15 Pre-defined additional SDO communication. 785
16 Object dictionary . 830
(normative) Manufacturer-specific TPDOs for unit-specific use . 966
(normative) Manufacturer-specific RPDOs for unit-specific use . 971
(informative) Measurement process . 976
Bibliography . 979



2

---------------------- Page: 4 ----------------------
oSIST prEN 16815:2018
prEN 16815:2018 (E)
European foreword
This document (prEN 16815:2018) has been prepared by Technical Committee CEN/TC 183 “Waste
management”, the secretariat of which is held by DIN.
This document is currently submitted to the CEN Enquiry.
This document will supersede CEN/TR 16815:2015.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
This document is based on the version 2.0 of the CiA 422 specification series describes the embedded
body control network of refuse collecting vehicles (RCV). It specifies the CANopen (EN 50325-4)
communication interfaces and the application functionality of several functional elements (virtual
devices). It does not specify CANopen devices.
This document is structured as follows:
st
— the 1 part (Clauses 3 to 9) contains general definitions and describes the functionality of the
virtual devices as well as the CANopen physical layer requirements and recommendations.
nd
— the 2 part (Clause 10) provides a detailed overview of communication and application
parameters supported by the different virtual devices. Virtual devices include the body controller,
and the change container, compaction, lifter, identification, measuring A and B, bin classification,
washing, truck gateway as well as GPS units. Also a monitoring device is described
rd
— the 3 part (Clauses 11 to 15) and its sub-parts specify the pre-defined Process Data Objects (PDO)
and the additional pre-defined SDOs. The pre-defined Transmit-PDOs for all virtual devices ares
specified in Clause 11. This includes the PDO communication parameter set as well as the PDO
mapping parameter set. The corresponding Receive-PDOs are specified in Clause 13. The SDO
communication between bin classification units and measuring units is specified in Clause 15.
th
— the 4 part (Clause 16) specifies the application parameters. This covers the process data (mainly
mapped into PDOs), configuration data, and diagnostic information (both mainly transmitted by
SDO communication services). In this clause are defined parameter pools for the measuring units,
and the data read as well as write for identification units. Other introduced parameters include
support profile version, extended status for measuring units and measuring ident controllers.
3

---------------------- Page: 5 ----------------------
oSIST prEN 16815:2018
prEN 16815:2018 (E)
1 Scope
This document provides a set of CANopen application profile specifications that describes the
CleANopen embedded body control network of municipal vehicles, e.g. refuse collecting trucks.
It specifies the CANopen communication interfaces and the application functionality of several
functional elements (virtual devices).
It does not specify CANopen devices.
The CleANopen application profile specifications consist of several parts dealing with the following:
— general definitions;
— functionality of the virtual devices;
— pre-defined PDOs and SDOs;
— application objects.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO 639-1, Codes for the representation of names of languages — Part 1: Alpha-2 code
ISO/IEC 646, Information technology — ISO 7-bit coded character set for information interchange
ISO 11898-2, Road vehicles — Controller area network (CAN) — High-speed medium access unit
SAE J1939-71, Recommended practice for a serial control and communication network — Vehicle
application layer
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— IEC Electropedia: available at http://www.electropedia.org/
— ISO Online browsing platform: available at http://www.iso.org/obp
3.1
CleANopen unit
virtual device that provides functional elements specified in this application profile
3.2
functional element
atomic application function
4

---------------------- Page: 6 ----------------------
oSIST prEN 16815:2018
prEN 16815:2018 (E)
3.3
virtual device
part of the logical device as defined in [CiA301]
3.4
left side
when viewing forward, the left side
3.5
pitch
angle from the front to the back of the vehicle (see Figure 1)

Figure 1 — Pitch example
3.6
right side
when viewing forward, the right side
3.7
roll
angle from the left to the right side of the vehicle (see Figure 2)

Figure 2 — Roll example
4 Acronyms
The acronyms given in documents CiA301, CiA413 series and SAEJ1939 apply for this standard, too.
BCU Bin classification unit
BC Body controller
MIC Measuring ident controller
CAN Controller area network
CCU Change container unit
COB Communication object
5

---------------------- Page: 7 ----------------------
oSIST prEN 16815:2018
prEN 16815:2018 (E)
COB-ID COB identifier
CSDO Client SDO
CU Compaction unit
GPS Global positioning system
GPSU GPS unit
IDU Identification unit
IVN In-vehicle network
LSB Least significant bit
LU Lifter unit
MSB Most significant bit
MU Measuring unit
SSDO Server SDO
TGU Truck gateway unit
WU Washing unit
5 Abbreviations
Acc. Access
Cat. Category
const constant
ro read-only
rw read/write
6 General architecture
6.1 General
This application profile specification describes the virtual devices of municipal vehicle bodies
(CleANopen units). Figure shows a simple example: The BC virtual device controls the overall system,
however the other virtual devices communicate directly by means of PDOs. The virtual interfaces are
implemented as CANopen interfaces or as CANopen device internal interfaces if the virtual devices
reside in the same CANopen device. If the virtual interfaces between virtual devices are implemented as
CANopen interfaces they use SDO or PDO services to read or write application objects.
6

---------------------- Page: 8 ----------------------
oSIST prEN 16815:2018
prEN 16815:2018 (E)

Figure 1 — Virtual devices interconnection (example)
Most of the application objects are mapped into pre-defined PDOs.
If an implemented application object is not mapped into one of the pre-defined PDOs, other CANopen
devices can access them by means of SDO.
The CSDOs, which corresponds to the Default SSDO, shall be implemented always in the BC virtual
device.
CANopen devices compliant to this application profile without BC functionality shall not implement any
CSDO that relates to Default SSDO.
For systems not comprising a BC, additional SDO channels are needed.
This application profile pre-defines some SDO channels for dedicated functionality.
For some virtual devices up to eight instances are specified. The instances with the very same number
belong to one sub-system, e.g. LU 1, MU-A 1, and WU 1 belong to sub-system 1; LU 2, MU-B 2, and WU 2
belong to sub-system 2.
When the BC is implemented, it is connected to all sub-systems.
6.2 Communication to the in-vehicle networks
The communication to the truck’s in-vehicle networks is possible by means of truck gateways provided
by the truck manufacturer. There are different implementations on the market as shown in the
examples given in Figure 4.
In the past, most truck manufacturers provided digital and analog inputs and outputs (a). In this
implementation example, the TGU only transmits and receives those objects that are not used by the BC.
It is also possible to implement the TGU in a generic I/O module compliant to [CiA 401 (b)]; it provides
than TGU-compliant PDOs.
Nowadays, some truck manufacturers provide a [CiA 413] or [CiA 422] compliant truck gateway (c). In
this implementation example, the truck gateway provides TPDOs and RPDOs that correspond to those
provided by the TGU.
7

---------------------- Page: 9 ----------------------
oSIST prEN 16815:2018
prEN 16815:2018 (E)

Figure 2 — Truck gateway implementation examples
If the TGU is implement in the very same CANopen device as the BC, the communication can be done
device-internally without transmitting COBs on the CAN network.
6.3 Numbering of the lifter units (LUs)
The LUs can be positioned on the vehicle in different ways. The numbering of the LUs as given in this
clause shall be used for the vehicles implementing this specification. The lifter units shall be
enumerated from left to right while standing in front of the lifter. One compartment consists of four LUs
st
in maximum. The 1 compartment consists of LUs 1 to 4. If there is a second compartment on the truck
(e.g. for organic waste) it consists of the LUs 5 to 8. For other configurations it is up to the system
integrator to provide the LU numbering.
Figure 5 specifies the LU numbering for the single compartment front loader.
Figure 6 specifies the LU numbering for the single compartment rear loader.
Figure 7 specifies the LU numbering for the single compartment left side loader.
Figure 8 specifies the LU numbering for the single compartment right side loader.
Figure 9 specifies the LU numbering for the two-compartment rear loader.
Figure 10 specifies the LU numbering for the two-compartment combined rear and side loader.
8

---------------------- Page: 10 ----------------------
oSIST prEN 16815:2018
prEN 16815:2018 (E)

Figure 3 — LU numbering for the single compartment front loader

Figure 4 — LU numbering for the single compartment rear loader

Figure 5 — LU numbering for the single compartment left side loader
9

---------------------- Page: 11 ----------------------
oSIST prEN 16815:2018
prEN 16815:2018 (E)

Figure 6 — LU numbering for the single compartment right side loader

Figure 7 — LU numbering for the two compartment rear loader

Figure 8 — LU numbering for the two compartment combined rear and side loader
6.4 Virtual device description
6.4.1 General
Every virtual device represents a specific functional unit. Some of them can be installed multiply in one
application.
The following brief descriptions give an overview on the functionality of the different virtual devices.
10

---------------------- Page: 12 ----------------------
oSIST prEN 16815:2018
prEN 16815:2018 (E)
The supported application objects are summarized in the clause on functionality of the virtual devices
of this application profile.
The detailed PDO interfaces are specified in the appropriate clause on pre-defined Process Data Objects
(PDO) of this application profile.
The detailed application objects are specified in the appropriate clause of this application profile.
6.4.2 Body controller (BC)
The BC is the interface to the hydraulic and the pneumatic power supply of the disposal vehicle. Related
to its operating mode some other units request optionally the supply of pressure from the BC. Other
units need optionally the BC status information (e.g. to estimate the intervals of maintenance) for their
operations.
6.4.3 Bin classification unit (BCU)
The BCU classifies a waste bin attached to the lifter. Other units — virtual devices — use this
classification for sequence control purposes:
— LU lifts and empties or does not lift and does not empty the bin.
— WU washes or does not wash the bin.
The BCU implements optionally the measuring ident controller (MIC) functional element. The MIC
combines the results of identification (through the IDU) and a measuring (through the MU). The MIC
coordinates the correct matching of measured values and the waste bin using information from IDU and
LU. The MIC can detect (using the LU) the emptying of a waste bin with or without transponder.
There are up to eight BCU (1 to 8) instances possible in one logical CleANopen network.
6.4.4 Change container unit (CCU)
The CCU is used for changing the collecting reservoir (container) of a disposal vehicle. It is also used for
providing information about the mounted container (fixed or changeable).
6.4.5 Compaction unit (CU)
The CU is used for compacting the waste and for providing information about the compaction process. It
is used for synchronizing and for coordinating its activities with the LU. Other units use optionally the
CU status information (e.g. to estimate the intervals of maintenance).
6.4.6 GPS unit (GPSU)
The GPSU is used for providing geographical positioning as well as date and time information, which is
recorded by other units.
6.4.7 Identification unit (IDU)
The IDU is used for identifying waste bins by identifying a transponder attached to the waste bin. It can
also write information to the transponder. The identification process is started by means of an explicit
start command received from the MIC or automatically, when the IDU is supporting continuous
identification.
11

---------------------- Page: 13 ----------------------
oSIST prEN 16815:2018
prEN 16815:2018 (E)
6.4.8 Lifter unit (LU)
The LU is used for controlling the emptying procedure of a single waste bin. It is also used for informing
additionally other units:
— about the state of a lifter,
— if a waste bin is attached or not,
— about the position of the lifter and whether the lifter is in the measuring window or not.
It is possible to configure the LU. For example, that the lifter adjust its speed in the emptying process.
This is needed to consider the particular features of some other units (e.g. MU). The LU is used for
communicating with the CU to inform it whether the CU is or not in operation. The LU is used for
communicating with the BC to demand power supply (e.g. hydraulic).
There are up to eight LU (1 to 8) instances possible in one logical CleANopen network.
6.4.9 Measuring unit (MU)
The MU is used for issuing measurement results acquired while treating the bin or the container. The
MU is used for abstracting particularly the functionality of scales or devices to measure the volume. As
scale the MU is used for measuring the weight of waste in the waste bin. As volume measurement device
the MU provides the volume of the disposed waste.
In some cases, it is necessary to measure up to two physical values on one lifter (e.g. weight and
volume). For this case, the Measuring Unit A and Measuring Unit B are provided.
Especially for scales, modes for manual and automatic measuring are implemented. While automatic
measurement the scale controls the entire weighing process. While manual measuring the user is
responsible for control of the measuring process.
There are up to eight MU-A (1 to 8) and up to eight MU-B (1 to 8) instances possible in one logical
CleANopen network.
6.4.10 Truck gateway unit (TGU)
The TGU is used for providing the access to the in-vehicle networks of the truck.
6.4.11 Washing unit (WU)
The WU is used for cleaning the waste bins. The LU provides the waste; it allows and starts the washing
process. The WU informs about the state of the washing process and the washing equipment. While
washing, no movement of the lifter is allowed.
There are up to eight WU (1 to 8) instances possible in one logical CleANopen network.
12

---------------------- Page: 14 ----------------------
oSIST prEN 16815:2018
prEN 16815:2018 (E)
7 Physical layer specification
7.1 General
The CAN interface shall be compliant to the definitions and recommendations given in ISO 11898-2 and
[CiA 301] and [CiA 303-1].
7.2 Bit rate
The physical CANopen device compliant to this application profile shall provide a default bit rate of 250
kbit/s and shall use the bit timing as specified in [CiA 301]. Other bit rates defined in [CiA 301] can be
supported.
7.3 Bus topology
The bus topology shall be compliant to the definitions and recommendations given in ISO 11898-2,
[CiA 301] and [CiA 303-1].
7.4 Bus cable
The bus cable used shall be compliant to the definitions and recommendations given in ISO 11898-2
and [CiA 303-1].
7.5 Bus connector
The bus connector used shall be compliant to the definitions and recommendations given in
ISO 11898-2 and [CiA 303-1].
7.6 Node-ID assignment
The assignment of a node-ID is required for every physical CANopen device. The assignment of
node-IDs is manufacturer specific. For a better plug and play behaviour the assignment of the node-IDs
is recommended as shown in Table 1.
Table 1 — Recommended node ID assignment
Device Node-ID
Body controller (BC) 10
Compaction unit (CU) 11
Container change unit (CCU) 12
Lifter unit (LU) 1 to 8 20 to 27
Bin classification unit (BCU) 1 to 8 30 to 37
Identification unit (IDU) 1 to 8 50 to 57
Measuring unit A (MU-A) 1 to 8 60 to 67
Measuring unit B (MU-B) 1 to 8 70 to 77
Washing unit (WU) 1 to 8 80 to 87
Truck gateway unit (TGU) 89
GPS unit (GPSU) 90
Monitoring device 1 to 8 91 to 98

If more than one virtual device is integrated to one CANopen device, the lowest node-ID shall be used.
13

---------------------- Page: 15 ----------------------
oSIST prEN 16815:2018
prEN 16815:2018 (E)
8 Error handling
8.1 Principle
Emergency messages shall be triggered by internal errors in the physical device and they are assigned
to high priority to ensure that they get access to the bus without latency. By default, the Emergency
messages shall contain the error field with pre-defined error numbers and additional information.
8.2 Error behaviour
If a serious device failure is detected the physical device shall enter by default autonomously the
pre-operational state. If object 1029 is implemented, the physical device can be configured to enter
h
alternatively the stopped state or remain in the current state in case of a device failure. Device failures
shall include the following communication errors:
— Bus-off conditions of the CANopen interface;
— Life guarding event with the state ‘occurred’;
— Heartbeat event with state ‘occurred’.
Severe device errors also can be caused by device internal failures.
8.3 Additional error code specification
Devices compliant to this application profile specification can use the error codes as defined in
[CiA 301].
The third byte of the Emergency message (first byte of) described in the EMCY protocol in [CiA 301]
shall be used as defined in Figure 11.
7 4 3 0
Virtual device number (see Table 2) Number of virtual device (1 to 8)
MSB LSB
Figure 9 — Byte number 3 of the EMCY message
14

---------------------- Page: 16 ----------------------
oSIST prEN 16815:2018
prEN 16815:2018 (E)
Table 2 — Virtual device numbers
Virtual device name Number
01
BC
h
03
CCU
h
04
CU
h
05
LU
h
06
IDU
h
07
MU-A
h
08
BCU
h
09
WU
h
0B
MU-B
h
0C
GPSU
h
0D
TGU
h

9 Data type specification
The application objects specified in this application profile use the data types defined in [CiA 301]. The
BOOLEANn data type is specified in this part of the application profile.
Data of basic data type BOOLEANn is represented as bit sequences of length n bit. The value attains a
combination of TRUE and FALSE. The value TRUE (res. FALSE) is represented by the bit value 1 (res. 0).
The profile-specific basic data types are specified in Table 3.
Table 3 — Profile specific basic data type definitions
Index Object Name Examples
0060 bit , bit
DEFTYPE BOOLEAN2
h 1 2
0061 bit , bit , bit
DEFTYPE BOOLEAN3
h 1 2 3
0062 bit , bit , bit , bit
DEFTYPE BOOLEAN4
h 1 2 3 4

10 Object dictionary entries
10.1 General
Every CANopen device compliant with this application profile supports some general communication
and application objects as well as virtual device specific application objects. It consists of one or more
virtual devices as defined in [CiA301]. A virtual device shall not be distributed to several CANopen
devices. Each virtual device supports a set of mandatory function-depending application objects and
can implement additionally a variable set of optional application objects.
15

---------------------- Page: 17 ----------------------
oSIST prEN 16815:2018
prEN 16815:2018 (E)
All objects are specified by means of object and entry description as defined in [CiA301]. The
description attributes are defined in [CiA301]. The category attribute indicates, if an object shall be
supported (Mandatory) or can be supported (Optional). The access attribute indicates, if an object is
constant (const), read only (ro), read/write (rw) or write only (wo). Read only indicates that this object
shall not be written via the bus; read/write allows to read and to write this object; and write only means
that this object shall be not read via the bus. The default value attribute defines the behavior of objects
after power-on or NMT application reset.
The information given in 10.3 about application objects mapped into PDOs is informative, except the
mapped dummy objects, they shall be mapped.
10.2 General communication objects
10.2.1 General
CANopen devices compliant with this application profile use default values for some communication
objects (1000 to 1FFF ), which are not specified in all details in [CiA301]. In the following sub-clauses
h h
these default values are specified in details.
10.2.2 Object 1000 : Device type
h
This object describes the type of device and its functionality. The object and entry description are given
in [CiA301]. Figure 12 shows the object structure and Table 4 defines the values for the virtual device
code field.
31 24 23 16 15 0
Device profile number: 422
Virtual device code reserved (0)
d
MSB LSB
Figure 10 — Object structure
Table 4 — Virtual device code values
Code Function
01
Body controller (BC)
h
02
reserved for compatibility reason
h
03
Change container unit (CCU)
h
04
Compaction unit (CU)
h
05
Lifter unit (LU)
h
06
Identification unit (IDU)
h
07
Measuring unit A (MU-A)
h
08
Bin classification unit (BCU)
h
09
Washing unit (WU)
h
0A
reserved for compatibility reason
h
16

---------------------- Page: 18 ----------------------
oSIST prEN 16815:2018
prEN 16815:2018 (E)
Code Function
0B
Measuring unit B (MU-B)
h
0C
GPS unit (GPSU)
h
0D
Truck gateway unit (TGU)
h
0E
reserved for future use by CiA
h
::::: :::::
FD
reserved for future use by CiA
h
FE
Monitoring device
h
FF
reserved
h

10.2.3 Object 1001 : Error register
h
The device profile specific bit in the error register is reserved for future use. The object and entry
description are given in [CiA301].
10.2.4 Object 1016 : Consumer heartbeat times
h
This object shall be implemented, if the CANopen device receives event-triggered PDOs. The consumer
heartbeat times are manufacturer-specific. The object and entry description are given in [CiA301].
10.2.5 Object 1017 : Producer heartbeat time
h
This object shall be implemented. The heartbeat producer time shall be set to > 0 by default; the value
is manufacturer-specific. The object and entry description are given in [CiA301].
10.2.6 Object 1018 : Identity
h
This object is mandatory and contains in sub-index 01 the unique vendor-ID assigned by CiA.
h
Sub-index 02 to 04 are optional. The object and entry description are given in [CiA301].
h h
10.2.7 Object 1029 : Error behavior
h
This object specifies to which state the physical device shall be set, when a communication error or a
device internal error is detected. Besides the specification given in [CiA301] the following sub-indexes
can be implemented optionally. If the entire object is not
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.