CEN/TR 16815:2015

SLOVENSKI STANDARD
01-januar-2016
CleANopen - Aplikacijski profil za uporabo na komunalnih vozilih (za zbiranje
odpadkov)
CleANopen - Application profile for municipal vehicles
CleANopen - Anwendungsprofil für Kommunalfahrzeuge
CANopen - Profil d’application aux véhicules municipaux
Ta slovenski standard je istoveten z: CEN/TR 16815:2015
ICS:
35.240.60 Uporabniške rešitve IT v IT applications in transport
transportu in trgovini and trade
43.160 Vozila za posebne namene Special purpose vehicles
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

CEN/TR 16815
TECHNICAL REPORT
RAPPORT TECHNIQUE
November 2015
TECHNISCHER BERICHT
ICS 35.240.60; 43.040.15; 43.160
English Version
CleANopen - Application profile for municipal vehicles
CleANopen - Profil d'application aux véhicules CleANopen - Anwendungsprofil für
municipaux Kommunalfahrzeuge
This Technical Report was approved by CEN on 23 February 2015. It has been drawn up by the Technical Committee CEN/TC
183.
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, 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: Avenue Marnix 17, B-1000 Brussels
© 2015 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TR 16815:2015 E
worldwide for CEN national Members.

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 . 52
12 Manufacturer-specific TPDOs . 493
13 Pre-defined RPDO communication . 494
14 Manufacturer-specific RPDOs . 902
15 Pre-defined additional SDO communication. 902
16 Object dictionary . 951
Annex A (normative) Manufacturer-specific TPDOs for unit-specific use . 1094
Annex B (normative) Manufacturer-specific RPDOs for unit-specific use . 1100
Annex C (informative) Measurement process . 1106
Bibliography . 1109

European foreword
This document (CEN/TR 16815:2015) has been prepared by Technical Committee CEN/TC 183 “Waste
management”, the secretariat of which is held by DIN.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN [and/or CENELEC] 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.
1 Scope
This Technical Report 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, in whole or in part, are normatively referenced in this document and are
indispensable for its application. 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.
3.1
CleANopen unit
virtual device that provides functional elements specified in this application profile
3.2
functional element
atomic application function
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
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
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
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.
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.
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
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.
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
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.
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.
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.
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.
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 11 — Byte number 3 of the EMCY message
Table 2 — Virtual device numbers
Virtual device name Number
BC
h
CCU
h
CU
h
LU
h
IDU
h
MU-A
h
BCU
h
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
bit , bit , bit ,
1 2 3
DEFTYPE BOOLEAN4
h
bit
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.
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 12 — Object structure
Table 4 — Virtual device code values
Code Function
Body controller (BC)
h
reserved for compatibility reason
h
Change container unit (CCU)
h
Compaction unit (CU)
h
Lifter unit (LU)
h
Identification unit (IDU)
h
Measuring unit A (MU-A)
h
Bin classification unit (BCU)
h
Washing unit (WU)
h
Code Function
0A
reserved for compatibility reason
h
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 implemented the CANopen device shall behave
as the default values define.
Table 5 defines the values.
Table 5 — Value definition
Value Definition
Change to NMT state Pre-operational
h
(only if currently in NMT state Operational)
No change of the NMT state
h
Change to NMT state Stopped
h
The object description and the entry description for sub-index 00 and 01 are given in [CiA301].
h h
Table 6 specifies the entry description for sub-index 02 .
h
Table 6 — Entry description for sub index 02h
Attribute Value
Sub-index
h
Description Internal device error
Access rw
Entry category Optional
PDO mapping No
00 to 02
Value range
h h
Default value
h
10.2.8 Object 1F80 : NMT startup
h
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 04 ) need to be implemented. If several
h
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 02 and 04 ) need to be implemented.
h h
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, TPDO 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-BC status) need to be supported (see Table 25).
10.3.2 General application objects
Every CANopen device compliant with this application profile can implement the application objects
shown in Table 7. The category, access, and default value attributes shall be used.
Table 7 — General application objects
Index Name Cat. Acc. Default value
Manufacturer-specifi
Supported virtual device types (NOTE) C const
h
c
Manufacturer-specifi
Supported profile version O const
h
c
Absolute work hours O ro No
h
NOTE Mandatory for CANopen devices supporting more than one virtual device.

10.3.3 Body controller (BC)
All applications objects used by the BC virtual device are listed in Table 8. The category, access, and
default value attributes shall be used.
Table 8 — BC specific application objects
Index Name Cat. Acc. Default value
Body controller status M ro No
h
6100 3FFF
Lifter unit status O rw
h h
6130 FF
Lifter unit body controller request M rw
h h
Lifter unit body controller status M ro No
h
6140 3FFF
Identification unit status O rw
h h
6161 1FFF FFFF
Measuring unit A extended status O rw
h h
6171 1FFF FFFF
Measuring unit B extended status O rw
h h
6180 3FFF
Bin classification unit status O rw
h h
61A0 3FFF
Washing unit status O rw
h h
61B0 FF
Washing unit body controller request O rw
h h
61B1
Washing unit body controller status O ro No
h
61C1 3FFF FFFF
Measuring ident controller extended status O rw
h h
6300 3FFF
Compaction unit status O rw
h h
6310 FF
Compaction unit body controller request O rw
h h
Compaction unit body controller status O ro No
h
Index Name Cat. Acc. Default value
6320 3FFF
Change container unit status O rw
h h
6330 FF
Change container unit body controller request O rw
h h
Change container unit body controller status M ro No
h
6406 FFFF
Vehicle speed O rw
h h
6408 FFFF
Engine speed O rw
h h
640A FF
Maximum vehicle speed limit O rw
h h
First clutch dependent PTO feedback O rw TRUE TRUE
h
Second clutch dependent PTO feedback O rw TRUE TRUE
h
Clutch independent PTO feedback O rw TRUE TRUE
h
First engine mounted PTO feedback O rw TRUE TRUE
h
Second engine mounted PTO feedback O rw TRUE TRUE
h
Parking brake device active O rw TRUE TRUE
h
Stopping brake device active O rw TRUE TRUE
h
First clutch dependent PTO engagement consent O rw TRUE TRUE
h
Second clutch dependent PTO engagement
641A
O rw TRUE TRUE
h
consent
641B
Clutch independent PTO engagement consent O rw TRUE TRUE
h
641C
First engine mounted PTO engagement consent O rw TRUE TRUE
h
641D
Second engine mounted PTO engagement consent O rw TRUE TRUE
h
641E
Transmission neutral switch active O rw TRUE TRUE
h
641F
Transmission reverse direction switch active O rw TRUE TRUE
h
Clutch closed state active O rw TRUE TRUE
h
Engine speed control upper limit allowed O rw TRUE TRUE
h
Engine speed control lower limit allowed O rw TRUE TRUE
h
Engine speed control allowed O rw TRUE TRUE
h
Engine stop allowed O rw TRUE TRUE
h
Vehicle speed limit control allowed O rw TRUE TRUE
h
642D
First clutch dependent PTO switch O ro No
h
642E
Second clutch dependent PTO switch O ro No
h
642F
Clutch independent PTO switch O ro No
h
Index Name Cat. Acc. Default value
First engine mounted PTO switch O ro No
h
Second engine mounted PTO switch O ro No
h
Engine stop switch O ro No
h
Requested engine speed lower limit O ro No
h
643C
Request engine speed O ro No
h
643D
Remote emergency light request O ro No
h
643E
Stopping brake device request O ro No
h
TRUE TRUE TRUE
67F0
Boolean 4 O const
h
TRUE
In Table 9 it is specified, which PDOs the BC virtual device shall (category = M) and can (category = O)
support. The PDO numbers and mapped application objects for virtual device entities are given for the
entity 1 without brackets, the PDO number and mapped application objects (sub-index corresponds to
the entity no.) for the entities 2 to 8 are given in brackets.
If the CANopen device implements the corresponding TPDO and RPDO, the PDO is normally
communicated device-internally and not via CAN. The PDO communication and mapping parameter
sets are specified in detail in Clauses 11 to 15.
Table 9 — PDOs supported by the BC virtual device
PDO no. Cat. Mapped application objects
6020 00 , 6331 00
TPDO 7 M
h h
6311 00
TPDO 10 O
h
TPDO 32 O 6131 01 , 61B1 01
h h
(TPDO 48)
(6131 02 , 61B1 02 )
h h
(TPDO 64)
(6131 03 , 61B1 03 )
h h
(TPDO 80)
(6131 04 , 61B1 04 )
h h
(TPDO 96)
(6131 05 , 61B1 05 )
h h
(TPDO 112)
(6131 06 , 61B1 06 )
(TPDO 128)
h h
(TPDO 144)
(6131 07 , 61B1 07 )
h h
(6131 08 , 61B1 08 )
h h
TPDO 260 O 643C 01 , 6435 01 , 642D 00 , 642E 00 , 642F
h h h h
00 , 6430 00 , 6431 00 , 643D 00 643E 00 ,
h h h , h
6432 00 , 67F0 00
h h
RPDO 5 O 6320 00 , 6330 00
h h
RPDO 9 O 6300 00 , 6310 00
h h
PDO no. Cat. Mapped application objects
RPDO 18 O 6100 01 , 6130 01
h h
(RPDO 34)
(6100 02 , 6130 02 )
h h
(RPDO 50)
(6100 03 , 6130 03 )
h h
(RPDO 66)
(6100 04 , 6130 04 )
h h
(RPDO 82)
(6100 05 , 6130 05 )
h h
(RPDO 98)
(6100 06 , 6130 06 )
(RPDO 114)
h h
(RPDO 130)
(6100 07 , 6130 07 )
h h
(6100 08 , 6130 08 )
h h
RPDO 20 O 6140 01
h
(RPDO 36)
(6140 02 )
h
(RPDO 52)
(6140 03 )
h
(RPDO 68)
(6140 04 )
h
(RPDO 84)
(6140 05 )
h
(RPDO 100)
(6140 06 )
(RPDO 116)
h
(RPDO 132)
(6140 07 )
h
(6140 08 )
h
6161 01 , 0004 00
RPDO 11 O
h h
(RPDO 14)
(6161 02 , 0004 00 )
h h
(RPDO 31)
(6161 03 , 0004 00 )
h h
(RPDO 79)
(6161 04 , 0004 00 )
h h
(RPDO 127)
(6161 05 , 0004 00 )
h h
(RPDO 262)
(6161 06 , 0004 00 )
(RPDO 265)
h h
(RPDO 268)
(6161 07 , 0004 00 )
h h
(6161 08 , 0004 00 )
h h
RPDO 27 O 6180 01 , 0006 00
h h
(RPDO 43)
(6180 02 , 0006 00 )
h h
(RPDO 59)
(6180 03 , 0006 00 )
h h
(RPDO 75)
(6180 04 , 0006 00 )
h h
(RPDO 91)
(6180 05 , 0006 00 )
h h
(RPDO 107)
(6180 06 , 0006 00 )
(RPDO 123)
h h
(RPDO 139) (6180 07 , 0006 00 )
h h
(6180 08 , 0006 00 )
h h
RPDO 28 O 61A0 01 , 61B0 01
h h
(RPDO 44)
(61A0 02 , 61B0 02 )
h h
(RPDO 60)
(61A0 03 , 61B0 03 )
h h
(RPDO 76)
(61A0 04 , 61B0 04 )
h h
(RPDO 92)
(61A0 05 , 61B0 05 )
(RPDO 108) h h
(61A0 06 , 61B0 06 )
(RPDO 124)
h h
(RPDO 140)
(61A0 07 , 61B0 07 )
h h
(61A0 08 , 61B0 08 )
h h
PDO no. Cat. Mapped application objects
RPDO 30 O 61C1 01
h
(RPDO 46)
(61C1 02 )
h
(RPDO 62)
(61C1 03 )
h
(RPDO 78)
(61C1 04 )
h
(RPDO 94)
(61C1 05 )
h
(RPDO 110)
(61C1 06 )
(RPDO 126)
h
(RPDO 142)
(61C1 07 )
h
(61C1 08 )
h
RPDO 257 O 6410 00 , 6411 00 , 6412 00 , 6413 00 , 6414
h h h h
00 , 6418 00 , 6419 00 , 641A 00 , 641B 00 ,
h h h h h
641C 00 , 641D 00 , 641E 00 , 641F 00 , 6420
h h h h
00 , 0062 00
h h
RPDO 258 O 6416 00 , 6422 00 , 6423 00 , 6424 00 , 6426
h h h h
00 , 6427 00
h h
RPDO 259 O 6406 01 , 6408 01 , 640A 01 , 6428 00
h h h h
RPDO 391 O 6171 01 , 0004 00
h h
(RPDO 407)
(6171 02 , 0004 00 )
h h
(RPDO 423)
(6171 03 , 0004 00 )
h h
(RPDO 439)
(6171 04 , 0004 00 )
h h
(RPDO 455)
(6171 05 , 0004 00 )
(RPDO 471) h h
(6171 06 , 0004 00 )
(RPDO 487)
h h
(RPDO 503)
(6171 07 , 0004 00 )
h h
(6171 08 , 0004 00 )
h h
10.3.4 Change container unit
All applications objects used by the CCU virtual device are listed in Table 10. The category, access, and
default value attributes shall be used.
Table 10 — CCU specific application objects
Index Name Cat. Acc. Default value
6020 3FFF
Body controller status M rw
h h
6100 3FFF
Lifter unit status O rw
h h
6140 3FFF
Identification unit status O rw
h h
6161 1FFF FFFF
Measuring unit A extended status O rw
h h
6171 1FFF FFFF
Measuring unit B extended status O rw
h h
6180 3FFF
Bin classification status O rw
h h
Index Name Cat. Acc. Default value
61A0 3FFF
Washing unit status O rw
h h
61C1 3FFF FFFF
Measuring ident controller extended status O rw
h h
6300 3FFF
Compaction unit status O rw
h h
Change container unit status M ro No
h
Change container unit position M ro No
h
Change container unit body controller request M ro No
h
6331 FF
Change container unit body controller status M rw
h h
In Table 11, it is specified which PDOs the CCU virtual device shall (category = M) and can (category =
O) support. The PDO numbers and mapped application objects for virtual device entities are given for
the entity 1 without brackets, the PDO number and mapped application objects (sub-index corresponds
to the entity no.) for the entities 2 to 8 are given in brackets.
If the CANopen device implements the corresponding TPDO and RPDO, the PDO is normally
communicated device-internally and not via CAN. The PDO communication and mapping parameter
sets are specified in detail in Clause 11 to 15.
Table 11 — PDOs supported by the CCU virtual device
PDO no. Cat. Mapped application objects
6320 00 , 6330 00
TPDO 5 M
h h
6320 00 , 6322 00
TPDO 6 M
h h
6020 00 , 6331 00
RPDO 7 M
h h
6300 00 , 0005 00
RPDO 9 O
h h
6100 01 , 0005 00
RPDO 18 O
h h
(RPDO 34)
(6100 02 , 0005 00 )
h h
(RPDO 50)
(6100 03 , 0005 00 )
h h
(RPDO 66)
(6100 04 , 0005 00 )
h h
(RPDO 82)
(6100 05 , 0005 00 )
h h
(RPDO 98)
(6100 06 , 0005 00 )
(RPDO 114)
h h
(RPDO 130)
(6100 07 , 0005 00 )
h h
(6100 08 , 0005 00 )
h h
PDO no. Cat. Mapped application objects
RPDO 20 O 6140 01
h
(RPDO 36)
(6140 02 )
h
(RPDO 52)
(6140 03 )
h
(RPDO 68)
(6140 04 )
h
(RPDO 84)
(6140 05 )
h
(RPDO 100)
(6140 06 )
(RPDO 116)
h
(RPDO 132)
(6140 07 )
h
(6140 08 )
h
RPDO 11 O 6161 01 , 0004 00
h h
(RPDO 14)
(6161 02 , 0004 00 )
h h
(RPDO 31)
(6161 03 , 0004 00 )
h h
(RPDO 79)
(6161 04 , 0004 00 )
h h
(RPDO 127)
(6161 05 , 0004 00 )
h h
(RPDO 262)
(6161 06 , 0004 00 )
(RPDO 265)
h h
(RPDO 268)
(6161 07 , 0004 00 )
h h
(6161 08 , 0004 00 )
h h
6180 01 , 0006 00
RPDO 27 O
h h
(RPDO 43)
(6180 02 , 0006 00 )
h h
(RPDO 59)
(6180 03 , 0006 00 )
h h
(RPDO 75)
(6180 04 , 0006 00 )
h h
(RPDO 91)
(6180 05 , 0006 00 )
h h
(RPDO 107)
(6180 06 , 0006 00 )
(RPDO 123)
h h
(RPDO 139)
(6180 07 , 0006 00 )
h h
(6180 08 , 0006 00 )
h h
RPDO 28 O 61A0 01 , 0005 00
h h
(RPDO 44)
(61A0 02 , 0005 00 )
h h
(RPDO 60)
(61A0 03 , 0005 00 )
h h
(RPDO 76)
(61A0 04 , 0005 00 )
h h
(RPDO 92)
(61A0 05 , 0005 00 )
h h
(RPDO 108)
(61A0 06 , 0005 00 )
(RPDO 124)
h h
(RPDO 140) (61A0 07 , 0005 00 )
h h
(61A0 08 , 0005 00 )
h h
RPDO 30 O 61C1 01
h
(RPDO 46)
(61C1 02 )
h
(RPDO 62)
(61C1 03 )
h
(RPDO 78)
(61C1 04 )
h
(RPDO 94)
(61C1 05 )
(RPDO 110) h
(61C1 06 )
(RPDO 126)
h
(RPDO 142)
(61C1 07 )
h
(61C1 08 )
h
PDO no. Cat. Mapped application objects
RPDO 391 O 6171 01 , 0004 00
h h
(RPDO 407)
(6171 02 , 0004 00 )
h h
(RPDO 423)
(6171 03 , 0004 00 )
h h
(RPDO 439)
(6171 04 , 0004 00 )
h h
(RPDO 455)
(6171 05 , 0004 00 )
h h
(RPDO 471)
(6171 06 , 0004 00 )
(RPDO 487)
h h
(RPDO 503)
(6171 07 , 0004 00 )
h h
(6171 08 , 0004 00 )
h h
10.3.5 Compaction unit
All applications objects used by the CU virtual device are listed in Table 12. The category, access, and
default value attributes shall be used.
Table 12 — CU specific application objects
Index Name Cat. Acc. Default value
6020 3FFF
Body controller status O rw
h h
6100 3FFF
Lifter unit status O rw
h h
6102 FFFF
Lifter unit position O rw
h h
6140 3FFF
Identification unit status O rw
h h
6161 1FFF FFFF
Measuring unit A extended status O rw
h h
6171 1FFF FFFF
Measuring unit B extended status O rw
h h
6180 3FFF
Bin classification status O rw
h h
61A0 3FFF
Washing unit status O rw
h h
61C1 3FFF FFFF
Measuring ident controller extended status O rw
h h
Compaction unit status M ro No
h
Compaction unit body controller request M ro No
h
6311 FF
Compaction unit body controller status M rw
h h
6320 3FFF
Change container unit status O rw
h h
6322 FFFF
Change container unit position O rw
h h
In Table 13, it is specified, which PDOs the CU virtual device shall (category = M) and can (category = O)
support. The PDO numbers and mapped application objects for virtual device entities are given for the
entity 1 without brackets, the PDO number and mapped application objects (sub-index corresponds to
the entity no.) for the entities 2 to 8 are given in brackets.
If the CANopen device implements the corresponding TPDO and RPDO, the PDO is normally
communicated device-internally and not via CAN. The PDO communication and mapping parameter
sets are specified in detail in Clause 11 to 15.
Table 13 — PDOs supported by the CU virtual device
PDO no. Cat. Mapped application objects
6300 00 , 6310 00
TPDO 9 M
h h
6320 00 , 0005 00
RPDO 5 O
h h
6320 00 , 6322 00
RPDO 6 O
h h
6020 00 , 0005 00
RPDO 7 O
h h
6311 00
RPDO 10 O
h
6100 01 , 0005 00
RPDO 18 O
h h
(RPDO 34)
(6100 02 , 0005 00 )
h h
(RPDO 50)
(6100 03 , 0005 00 )
h h
(RPDO 66)
(6100 04 , 0005 00 )
h h
(RPDO 82)
(6100 05 , 0005 00 )
h h
(RPDO 98)
(6100 06 , 0005 00 )
(RPDO 114)
h h
(RPDO 130)
(6100 07 , 0005 00 )
h h
(6100 08 , 0005 00 )
h h
RPDO 19 O 6100 01 , 6102 01
h h
(RPDO 35)
(6100 02 , 6102 02 )
h h
(RPDO 51)
(6100 03 , 6102 03 )
h h
(RPDO
...