CEN/TR 16815:2015

CleANopen - Application profile for municipal vehicles

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.

CleANopen - Anwendungsprofil für Kommunalfahrzeuge

CleANopen - Profil d’application aux véhicules municipaux

CleANopen - Aplikacijski profil za uporabo na komunalnih vozilih (za zbiranje odpadkov)

To tehnično poročilo vsebuje sklop 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 PDO in SDO;
– aplikacijski objekti.

General Information

• Status: Withdrawn
• Publication Date: 10-Nov-2015
• Withdrawal Date: 26-Mar-2019
• ICS: 35.240.60 - IT applications in transport
• ICS: 43.040.15 - Car informatics. On board computer systems
• ICS: 43.160 - Special purpose vehicles
• Technical Committee: CEN/TC 183 - Waste management
• Drafting Committee: CEN/TC 183/WG 3 - Identification and/or determination of waste
• Current Stage: 9960 - Withdrawal effective - Withdrawal
• Completion Date: 27-Mar-2019
• Ref Project: SIST-TP CEN/TR 16815:2016 - CleANopen - Application profile for municipal vehicles

Relations

• Replaced By: EN 16815:2019 - CleANopen - Application profile for municipal vehicles
• Effective Date: 03-Apr-2019

Standards Content (Sample)

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 loa
...