SIST EN 16815:2019

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