Scope

Scope

Scope

This document specifies facilities and services of a Power Management Layer protocol entity on the CAN bus allowing significant reduction of power consumption in CAN networks by the introduction of the so-called network standby capability. The power reduction facilities of current CAN controller hardware designs by using the sleep mode, which can be recognized as a de-facto standard; are supported for usage under all higher layer protocols during an internal Power Management Layer IDLE state.

Scope

This specification specifies the CANopen application layer. This includes the data types, encoding rules and object dictionary objects as well as the CANopen communication services and protocols. In addition, this specification specifies the CANopen network management services and protocols. This specification specifies the CANopen communication profile, e.g. the physical layer, the pre- defined communication object identifier connection set, and the content of the Emergency, Time- stamp, and Sync communication objects.

Scope

In a network programmable CANopen devices can be characterized as a process having input variables and output variables. The set of variables will be arguments of the program and hence will be only known in a final state when the program is written. The arguments are handled as variables located in the object dictionary. The marking of such parameters depends on the programming system (e.g. /IEC61131–3/) and does not fall into the scope of this document. But it can be assumed that there is a set of network variables with the logic attribute EXTERN. Compiling/Linking (or interpreting) a program including EXTERN variables requires relocation information. Within CANopen devices this information is the index (and sub-index) of the variable. Most of the programming systems know the mechanism of a resource definition. This can be used to assign the CANopen attributes (index, sub-index, R/W, assignment of CANopen data type to local data type etc.) to the corresponding symbolic names (variable name in the program). The resource definition may be created with a simple editor by the user or with much more comfort by a configuration tool. Systems with a disk-based file system may exchange the information directly, e.g. via a device configuration file. The names of variables may meet the rules of the underlying programming system. The definition does not fall into the scope of this document. This is the responsibility of the programmer/manufacturer. Defining EXTERN variables requires a rule for distributing the indices. It is called "dynamic index assignment".

Scope

This specification describes the interface for bi-directional CANopen-to-CANopen communication in multi-level networks. It supports multiple CANopen networks implementing hierarchical and non-hierarchical architectures.

Scope

This recommendation describes the communication-related indicators. Additional application- related indicators are either described in the appropriate device profile or are manufacturer-specific.

Scope

The usage of devices in a communication network requires configuration of the device parameters and communication facilities. CANopen defines a standardised way to access these parameters via the object dictionary. For handling of the complexity of CANopen systems software tools are required. This reduces the complexity of the planning, configuration and analysis process and significantly increases the security of the system. For this purpose software tools need an electronic description of the CANopen devices. To allow the usage of manufacturer independent tools, this document defines a standardised file format – called Electronic Data Sheet. Furthermore some derived file formats are specified. The Device Configuration File describes a concrete incarnation of a device configuration. The Module Data Sheet describes modules of devices with a modular structure

Scope

This set of documents specifies the electronic description of CANopen devices in standardized file formats. These electronic descriptions are used to configure CANopen device parameters or for testing and diagnostic purposes. This set of documents consists of the three parts: ⎯ Part 1: Electronic data sheet and device configuration file; ⎯ Part 2: Profile database; ⎯ Part 3: Network variable handling and tool integration. This part specifies mechanisms with regard to the handling of network variables, which are specified in CiA 302-4. In addition recommendations for tool integration are provided. NOTE This document contains parts of the withdrawn document CiA 405.

Scope

CANopen is a field-bus protocol used in many diverse application: CANopen networks can be found not only in various industrial applications ranging from printing machines and robots to process controls, but also in ships, building automation, trains, trucks and even in coffee machines. CANopen is used for high accuracy drive synchronisation and for flight data recording. It is also in use in medical applications and has been chosen as the standard communication protocol for passenger information systems in public transport. This variety of applications leads to totally different requirements in regard to CANopen performance. The critical real-time requirement of one application may be a short response time to synchronisation messages relating to a single process data object, where as a different application may expect a node with many event driven process data obj ects to send these objects immediately after a certain input signal has changed. With drive synchronisation for instance, some applications need long time accuracy of the sync cycle and tolerate almost any jitter of a single sync message, and others require minimal jitter and tolerate long term drift. Regarding most other bus systems it is fairly straightforward to measure and publish communication performance figures for most node types. With CANopen this is not the case: the capability of CANopen to tailor the communication to the application needs makes it very difficult to determine valuable performance figures that are independent of the specific network set-up. For example, figures relating to reaction times not only depend on the processor used, but on the actual bus load, on the type of CAN controller being used, on the actual number and types of I/Os or drives connected, on the number and transmission types of the process data objects, on the guard or heartbeat cycle, and on many other settings and parameters in the object dictionary. Developing a CANopen node always involves a certain trade-off between performance and functionality. Therefore performance is a multi - dimensional value. The goal of this performance specification is to name and define a set of CANopen communication performance figures that may be used to compare devices and implementations within a specific application environment. It is not the aim of this paper to define a standard performance-measuring environment, as this would lead to implementations that perform fine in exactly this environment but disappoint under most other conditions. However, in order to establish some comparable conditions, this specification defines a number of standard busloads that may be used to simulate or enhance application environments. This performance test specification is aimed both at CANopen device developers and at CANopen system integrators. It may help developers determine relative performance figures regarding two implementation variants, thus leading to better devices and it may help system integrators to ask the right questions, thus leading to better CANopen networks.

Scope

Conformance testing is the process of verifying that an implementation performs in accordance with a particular standard, specification or environment. A CiA 310 conforming implementation is one that satisfies both static and dynamic conformance requirements. Conformance testing is not intended to be exhaustive, but it does ensure with a reasonable degree of confidence that implementation is consistent with its specification and it increases probability that implementations will interoperate. The test specification includes a lower test comprising the test description and specification for CANopen devices with NMT slave functionality compliant to the CANopen application layer and communication profile. The test specification of dynamic and upper tests does not fall in the scope of this document as well as the definition of additional tests for checking conformance of a CANopen device to a certain CANopen device profile.

Scope

The document contains additional lower-, dynamic- and upper tests for CANopen devices that shall be tested according to a certain device profile. The definitions of the generic lower -, dynamic- and upper tests do not fall in the scope of this document.

Scope

This part of the test plan specifies the additional tests for contrast media injectors, which shall be tested for conformity according to CANopen application profile for medical diagnostic add-on modules (CiA 425-1 version 2.0. and CiA 425-2 version 2.0.2). The additional tests verify entries in EDS and object dictionary, which are defined in CANopen application profile for medical diagnostic add-on modules. Furthermore additional test steps verify the implementation of the device finite state automata and further object coherences, which are defined in application profile for medical diagnostic add-on modules. To achieve a certain level of conformity the DUT shall pass the corresponding tests defined in CANopen conformance test plan, CiA 312-1, plus those defined in this test plan.

Scope

This document specifies the mapping of the Robotic technology component (RTC) finite state automaton to the CANopen network management (NMT) finite state automaton as well as the mapping of the RTC data types to CANopen data types. In addition, it describes the RTC - CANopen manager and the ProxyRTCs system integration.

Scope

This series of profile specifies the CANopen interface of power drive systems. It is suitable for drive and motion controllers. It specifies several operating modes for frequency inverters, servo-controllers, and stepper motors. The series of profile is split in several parts: • Part 1: General definitions; • (Part 2: Operation modes and application data); • (Part 3: PDO mapping); • Part 4: Safety functionality; • Part 5: PDO mapping superset. Part 2 and part 3 are substituted by the international standards IEC 61800-7-201 respectively IEC 61800-7-301. This part specifies the safety functionality for electrical drives and motion controllers compliant with the CiA 402 profile. It specifies the safety-related process data, the safety-related configuration parameters, and the safety-related diagnostic information as well as the SRDO communication and mapping parameters. Safety devices compliant with this part consume SRDOs containing commands from a control device and produce SRDOs containing status information to be received by the control device. Safety devices compliant with this document provide typically local safety functions as well as safety inputs and outputs. The safety outputs can be used to assign safety status information or can be set by the command information of the safety logic. The document is based on the ETG.6100.2 Generic Safety Drive Profile by the Ethercat Technology Group (ETG), and it specifies the mapping to CANopen. NOTE The naming and the assigned indices and sub-indices of the parameters are far as possible the same as in the ETG documents. But some ETG parameters are represented in CANopen by two parameters, consequently two names are used.

Scope

TThis document represents the device profile for measuring devices and for universal controller devices for measuring or controlling physical quantities like temperature or pressure. These devices use communication techniques which are conform to those described in /2/. This document should be consulted in parallel to this profile.

Scope

This specification represents the device profile for measuring devices and for universal controller devices for measuring or controlling physical quantities like temperature or pressure. These devices use communication techniques which are conform to those described in /CiA301/. The CANopen device profile for measuring devices and closed-loop controllers consists of several parts: • Part 1 defines the generic objects and the generic PDO mapping; • Part 2 defines the EUROMAP specific parameters. This part specifies the additional objects needed for EUROMAP 75 measuring amplifiers parameters and EUROMAP 66 heating/cooling device parameters.

Scope

This document represents the CANopen device profile for generic X-ray collimators, and as such describes the generic subset of collimator functionality. A prerequisite for the conformity to this CANopen device profile is conformity with the CANopen communication profile (CiA Draft Standard DS 301). Additionally, in the case that the module is programmable it must conform to the Framework for programmable CANopen devices (CiA Draft Standard Proposal DSP 302). These specifications should be consulted in parallel to this device profile specification.

Scope

This set of profile specifications describes CANopen gateways to CAN-based in-vehicle networks using the SAE J1939-71 application profile, ISO 11992-2, -3, and -4 truck/trailer networks or other J1939-based networks, e.g. ISO 11783-based (ISOBUS) networks, NMEA2000 networks, or RV-CAN network systems. The CANopen device profile for truck gateways consists of several parts: • Part 1 describes general definitions; • Part 2 defines the application objects for braking and running gear; • Part 3 defines the application objects for equipment other than brakes and running gear; • Part 5 defines the application objects for superstructures; • Part 6 defines the interface profile for J1939-to-CANopen gateways; • Part 8 defines the framework for HMI control. This part specifies the physical layer including connectors, and some general communication parameters. There are no PDOs pre-defined

Scope

This set of profile specifications describes CANopen gateways to CAN-based in-vehicle networks using the SAE J1939-71 application profile, ISO 11992-2, -3, and -4 truck/trailer networks or other J1939-based networks, e.g. ISO 11783-based (ISOBUS) networks, or NMEA2000 networks, or RV-CAN network systems.The CANopen device profile for truck gateways consists of several parts: • Part 1 describes general definitions; • Part 2 defines the application objects for braking and running gear; • Part 3 defines the application objects for equipment other than brakes and running gear; • Part 5 defines the application objects for superstructures; • Part 6 defines the interface profile for J1939-to-CANopen gateways; • Part 8 defines the framework for HMI control. This part specifies the application objects for other than brake and running gear equipment. These objects are equivalent to signals and parameters in /ISO11992-3/. This allows a directly forwarding of messages received from the in-vehicle network and a directly forwarding of CANopen application objects to the in-vehicle network

Scope

Part 6 of the CANopen device profile for truck gateways defines a framework for J1939-based networks. The normative references, definitions, acronyms, and abbreviations given in part 1 applies to this part, too. The object value definitions shall be as given in SAE J1939-71. The gateway is usable in static systems, where ECU address changes do not apply. Using other protocols based on J1939, such as ISO 11783 or NMEA 2000 will require some extensions, that may be subject to later versions.

Scope

The device profile defines the CANopen interfaces for weaving machines. The specification comprises the following two parts: Part 1 : General definitions; Part 2 : Feeders. Part 1 defines the operating principles for the feeder sub-systems, the error handling and the general communication parameters.

Scope

The CANopen sensor system application profile for road construction and earth moving machines specifies the communication interface for sensors as well as the sensor control unit. The profile is suitable for a broad range of machine types (e.g. paver, compactor, grader, dozer, mill, heater and truck). NOTE The first version of this profile has been jointly developed with the OSYRIS (Open System for Road Information Support) consortium (www.osyris.org) and the European Asphalt Pa vement Association (EAPA).

Scope

This part of the application profile gives an overview of the virtual devices.

Scope

This set of CANopen application profile specifications describes the CANopen Lift control network system. It specifies the CANopen communication interfaces and the application functionality of several functional elements (virtual devices). This application profile specification consists of several parts: • Part 1 provides general definitions; • Part 2 specifies the functionality of the virtual devices; • Part 3 specifies the pre-defined PDOs; • Part 4 specifies the application objects. Besides some general definitions such as general virtual device descriptions, this part specifies the CAN physical layer as well as the error handling. Additionally some network architecture examples are given.

Scope

This set of CANopen application profile specifications describes the CANopen Lift control network system. It specifies the CANopen communication interfaces and the application functionality of several functional elements (virtual devices). This application profile specification consists of several parts: • Part 1 provides general definitions; • Part 2 specifies the functionality of the virtual devices; • Part 3 specifies the pre-defined PDOs; • Part 4 specifies the application objects. This part specifies for a single lift application (lift 1) the general communication parameter. It specifies also for each virtual device the supported application objects including the category, access, and default value attributes. It describes the supported Process Data Objects (PDO). In addition, the PDOs for the other lift application 2 to 8 are assigned correspondingly.

Scope

This set of CANopen application profile specifications describes the CANopen Lift control network system. It specifies the CANopen communication interfaces and the application functionality of several functional elements (virtual devices). This application profile specification consists of several parts: • Part 1 provides general definitions; • Part 2 specifies the functionality of the virtual devices; • Part 3 specifies the pre-defined PDOs; • Part 4 specifies the application objects. This part of the application profile specifies pre-definitions for communication objects. This subpart specifies in detail the communication and mapping behavior of the PDOs for the lift 1 application.

Scope

This set of CANopen application profile specifications describes the CANopen Lift control network system. It specifies the CANopen communication interfaces and the applicationfunctionality of several functional elements (virtual devices). This application profile specification consists of several parts: • Part 1 provides general definitions; • Part 2 specifies the functionality of the virtual devices • Part 3 specifies the pre-defined PDOs; • Part 4 specifies the application objects. This part specifies in detail the used process data, configuration parameter, and diagnostic information represented in the object dictionary for the lift 1 application.

Scope

This device profile specifies a recommended practice for the communication link between a battery module and a battery charger. The required data messages are intended to be sufficient to allow a battery charge to be carried out. Optional data is a selection of data commonly used in the industry to provide enhanced features. Battery modules compliant to this standard shall use communication techniques, which conforms to those described in the CANopen application layer and communication profile.

Scope

The CANopen application profile for extruder downstream devices includes several parts: Part 1 specifies general definitions; Part 2 specifies the device profile for the puller downstream device; Part 3 specifies the device profile for the corrugator downstream device; Part 4 specifies the device profile for the saw downstream device; Part 5 specifies the device profile for the co-extruder device; Part 6 specifies the device profile for the calibration-table downstream device. NOTE All parts of this specification have been developed jointly with the European Committee of Machinery Manufacturers for the Plastics and Rubber Industries (Euromap) and is documented there as Euromap 27. This part specifies the physical layer and the common CANopen functions and common communication objects. It also specifies the CANopen functions of the extruder-master.

Scope

The CANopen application profile for extruder downstream devices include several parts: Part 1 specifies general definitions; Part 2 specifies the device profile for the puller downstream device; Part 3 specifies the device profile for the corrugator downstream device; Part 4 specifies the device profile for the saw downstream device; Part 5 specifies the device profile for the co-extruder device; Part 6 specifies the device profile for the calibration-table downstream device. NOTE All parts of this specification have been developed jointly with the European Committee of Machinery Manufacturers for the Plastics and Rubber Industries (Euromap) and is documented there as Euromap 27 . This part specifies the CANopen interface for the corrugator downstream device.

Scope

The CANopen application profile for extruder downstream devices includes several parts: Part 1 specifies general definitions Part 2 specifies the device profile for the puller downstream device Part 3 specifies the device profile for the corrugator downstream device Part 4 specifies the device profile for the saw downstream device Part 5 specifies the device profile for the co-extruder device Part 6 specifies the device profile for the calibration-table downstream device NOTE All parts of this specification have been developed jointly with the European Committee of Machinery Manufacturers for the Plastics and Rubber Industries (Euromap) and is documented there as Euromap 27. This part specifies the CANopen interface for simple and advanced co-extruder.

Scope

This application profile defines the communication between virtual devices within locomotives, power cars as well as coaches. It is intended to use the application profile for urban and regional rail vehicle transportation system as well as long-distance rail vehicle transportation systems including high-speed trains. But it is not limited to these railway applications, e.g. it is also used in cargo train locomotives and cargo train wagons as well as other railway transportation systems, such as commuter trains, subway trains, etc. The set of specifications is organized as follows: • Part 1: General definitions; • Part 2: Train operating system (TOS); • Part 3: Monitoring and safety system (MSS); • Part 4: Auxiliary operating system (AUX): • Part 5: Power (drive) system (PDS); • Part 6: Running gear system (RGS); • Part 7: Brake control system (BCS); • Part 8: Ancillary operating system (ANC); • Part 9: Vehicle linkage system (VLS); • Part 10: Exterior lighting system (ELS); • Part 11: Interior lighting system (ILS); • Part 12: Door control system (DCS); • Part 13: HVAC system (HS); • Part 14: Passenger information system (PIS); • Part 15: Cargo superstructure system (CSS); • Part 16: Diagnostic system (DS); • Part 17: Train-to-ground communication system (TCS); • Part 18: Slip/slide control system (SCS). CANopen devices compliant to this application profile use communication techniques, which conform to those described in the CiA Draft Standard 301.

Scope

This part of the CANopen application profile describes the CANopen interface of the virtual power drive system to the rail vehicle in-vehicle network.

Scope

This part of the CANopen application profile for rail vehicles describes the CANopen interface of the virtual exterior lighting system.

Scope

This part of the CANopen application profile for rail vehicles describes the CANopen interface of the virtual door control system.

Scope

This set of CANopen application profile specifications 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 consists of several parts: • Part 1 provides the general definitions; • Part 2 specifies the functionality of the virtual devices; • Part 3 specifies the pre-defined PDOs and SDOs; • Part 4 specifies the application objects; This part specifies the general communication parameter. It specifies for each virtual device the supported application objects including the category, access, and default value attributes. It describes the supported Process Data Objects (PDO) and additional Service Data Objects (SDO).

Scope

This set of CANopen application profile specifications 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 consists of several parts: • Part 1 provides the general definitions; • Part 2 specifies the functionality of the virtual devices: • Part 3 specifies the pre-defined PDOs and SDOs; • Part 4 specifies the application objects. This sub-part of part 3 specifies the communication and mapping parameter sets of the pre-defined RPDOs.

Scope

This CANopen application profile defines the communication between virtual devices within a rail vehicle power drive system. The power drive system shall be connected via a gateway device to the logical CANopen-based train vehicle control network as defined in CiA 421. The set of specifications is organized as follows: • Part 1: General definitions; • Part 2: Traction controller; • Part 3: Diesel engine control unit; • Part 4: Transmission control unit; • Part 5: Speed sensor unit; • Part 6: Diesel engine safety control unit; • Part 7: Diesel engine signal control unit; • Part 8: Clutch control unit; • Part 9: Gear control unit; • Part 10: Particle filter control unit; • Part 11: Starter unit; • Part 12: Oil refill tank unit. Devices compliant to this application profile uses communication techniques, which conform to those described in the CiA Draft Standard 301.

Scope

This part of the CANopen application profile for rail vehicle power drive systems describes the diesel engine control unit.

Scope

This part of the CANopen application profile for rail vehicle power drive systems describes the diesel engine safety control unit.

Scope

This part of the CANopen application profile for rail vehicle power drive systems describes the diesel engine signal unit. The diesel engine signal unit is the measuring unit, required for diesel engine control and monitoring.

Scope

This part of the CANopen application profile for rail vehicle power drive systems describes the starter unit.

Scope

This CANopen application profile defines the communication between virtual devices within a rail vehicle door control system. The rail vehicle door control system may be connected via a gateway device to the logical CANopen-based rail vehicle in-vehicle network. The set of specifications is organized as follows: • Part 1: General definitions; • Part 2: Door controller; • Part 3: Door unit. Devices compliant to this application profile shall use communication techniques, which conform to those described in the CiA Draft Standard 301.

Scope

This application note recommends and suggests how to implement and handle devices, which are compliant to CiA 434 profile family. The application note discusses the different modes of operation for laboratory automation slaves (LAS), the transfer of the commands to the LAS as well as the handling of the command parameter RAM (CPRAM). The purpose of this application note is to explain the major issues of specification CiA 434 standard part 1. This document is not normative but informative. In case of doubts always the specifications given in CiA 434 apply.

Scope

This set of documents specifies and recommends the usage of CAN FD hardware implementations. It consists of the following parts: Part 1: Physical interface implementation, Part 2: Controller interface specification, Part 3: System design recommendation, Part 4: Signal improvement, Part 6: CAN FD cable. This part specifies the requirements and test methods of the mechanical and electrical parameters for cables to be used in CAN FD networks.

Scope

This set of documents specifies and recommends the usage of CAN FD hardware implementations. It consists of the following parts: Part 1: Physical interface implementation, Part 2: Controller interface specification, Part 3: System design recommendation, Part 4: Ringing suppression. This part provides specifications and guidelines on the physical layer interface design for automotive electronic control units and non-automotive devices supporting the CAN FD data link layer as defined in ISO 11898-1 and the CAN high-speed physical layer as defined in the harmonized ISO 11898-2 standard, which includes the specification of high-speed transceivers with low-power mode (formerly known as ISO 11898-5) and/or with selective wake-up functionality (formerly known as ISO 11898-6).

Scope

This specification describes the control application for drilling machines with special regard on positioning and tool control.

Scope

This document specifies application objects provided by the drive control unit, as typically utilized in light electric vehicles.

Scope

The CANopen application profile for EMSs specifies the communication interface for all virtual devices that may take part in energy management control application. Such energy management control applications may be implemented in e.g. light electric vehicles, robots, offshore parks, isolated farms, etc. The CANopen application profile for EMSs consists of the following parts: Part 1: General definitions, Part 2: Pre-defined communication parameters and general application objects, Part 3: Pre-defined PDO communication, Part 4: EMS controller, Part 5: Voltage converter unit, Part 6: Battery pack, Part 7: Motor control unit (under development), Part 8: Load monitoring unit (under development), Part 9: HMI unit (under development), Part 10: Security unit (under development), Part 11: Sensor unit (under development), Part 12: Gateway unit (under development), Part 13: Generator unit, Part 14: Load unit. This document represents the part 13 of the CANopen application profile for EMSs. Part 13 of the document specifies generator units such as a diesel engine, photovoltaic generator, winds turbine, etc. Generators shall be divided into two classes: Controllable and stochastic generator.

Scope

This CANopen application profile specifies the physical layer as well as application, configuration and diagnostic parameters for the add -on devices used in special-purpose passenger cars such as taximeter, roof bar, etc. The specification comprises the following parts: • Part 1: General definitions; • Part 2: Virtual device definition; • Part 3: Detailed process data specification; • Part 4: Pre-defined CAN-IDs and communication objects. This part specifies in detail the process data and parameters of the virtual devices.

Scope

This CANopen application profile specifies the CAN physical layer as well as application, configuration and diagnostic parameters for the add -on devices used in special-purpose passenger cars such as taximeter, roof bar, etc. The specification comprises the following parts: • Part 1: General definitions; • Part 2: Virtual device definition; • Part 3: Detailed process data specification; • Part 4: Pre-defined CAN-IDs and communication objects. This part defines the physical layer, the general system architecture, and some common communication parameter objects.

Scope

This application profile provides general definition as well as recommendations for using CANopen control networks on construction machineries. In addition, this applicat ion profile introduces the virtual control architecture on construction machineries, integrating the engine control system, the drivers’ desk, the sensor control system, the transmission control system, the fleet management control system as well as the co ntrol system for the superstructure respectively implement.

Scope

This part of the CANopen profiles for laboratory automation systems defines the CANopen interface for dilutor, dispenser and pump units. Based on the definitions given in CiA 434 -1, this CANopen device profile specifies commands as well as parameters relevant for controlling dilutor, dispenser and pump units that are part of an automated laboratory system.

Scope

This part of the CANopen application profile for rail vehicle interior lighting control describes the interior lighting unit

Scope

This virtual device describes the generator unit, which is a part of the rail vehicle auxiliary operating system.

Scope

This part of the CANopen application profile for rail vehicle auxiliary operating systems describes the engine pre-heating unit.

Scope

This part of the CANopen application profile for rail vehicle auxiliary operating systems describes the coolant expansion tank unit.

Scope

This part of the CANopen application profile for rail vehicle auxiliary operating systems describes the auxiliary operating system controller.

Scope

This part of the CANopen application profile for rail vehicle exterior lighting describes the exterior lighting unit.

Scope

Scope

Scope

This document specifies the requirements of the data link layer and the physical coding sub-layer of a responder node. It contains detailed requirements for: — the logical link control sub-layer; — the medium access control sub-layer; and — the physical coding sub-layer.

Scope

This document specifies CANopen interface functionality, general communication parameters and Process Data Objects. It also specifies the lower-layer requirements.

Scope

This document specifies the CANopen interface for scales. This includes process data and configuration parameters as well as PDO communication and mapping parameters.

Scope

This document specifies additional requirements for CAN transceivers compliant with ISO 11898-2:2016 for the purpose to reduce differential and common-mode ringing on the CAN_H and CAN_L wires, namely the CAN SIC transceiver. Furthermore, this document specifies EMC tests for the CAN SIC transceiver.

Scope

This document specifies the CAN XL data link layer (DLL) and the physical coding sub-layer (PCS). The CAN XL DLL features Data Fields of up to 2 KiB (2048 byte). It is backwards compatible with CAN FD and implicitly with Classical CAN. Therefore, this document provides references to ISO 11898 1:2015, where appropriate. This includes references to the attachment unit interface (AUI). The optional PWM encoding is specified in this document, too. This document divides the CAN XL data link layer (DLL) into the logical link control (LLC) and the medium access control (MAC) sub-layers. The DLL’s service data unit (SDU), which interfaces the LLC and the MAC, is implemented by means of the LLC frame. The LLC frame features also the service data unit type (SDT) and the virtual CAN identifier (VCID), which provide higher-layer protocol configuration and identification information.

Scope

This document specifies an intrinsically-safe CAN device interface. It does not list the requirements by which an item of equipment can be certified as intrinsically safe nor does it require equipment to be intrinsically safe. NOTE 1 The document seeks to exclude conditions or situations that would prevent IS certification. Many parameters are selected by the developers to provide a baseline for calculation. NOTE 2 The wire-medium specification provides the option of intrinsically safe power via t he network conductors.

Scope

This part of the additional application layer function documents specifies the project management parameters used for programmable CANopen devices.

Scope

This part specifies the mapping to CANopen communication services to access CANopen networks from the other networks.

Scope

This part specifies the ASCII-based communication syntax for CiA 309 gateway devices. The aim is to provide a lightweight counterpart to solutions with CORBA or OPC.

Scope

This document provides the conformance test specification for devices implemented according to CiA 454, Part 1, 2, 3, 4, 5, and 6 version 2.0. 2 Normative references CiA 301, CANopen application layer and communication profile; CiA 305, CANopen layer setting services (LSS) and protocols; CiA 306, CANopen electronic device description; CiA 310, Conformance test plan – CiA 301 testing; CiA 454, CANopen application profile for energy management systems. NOTE Some parts of CiA 454 were submitted to IEC for international standardization in IEC 61851-3 Electric vehicle conductive charging system

Scope

This document specifies the CANopen mapping for a generic digital and analog I/O device and joystick. Annex B specifies CANopen mapping CiA 401-B for joysticks.

Scope

This document provides general definitions on functional elements of power drive systems. It also defines application modes such as for torque, velocity, and position control.

Scope

This document specifies CANopen PDO communication and mapping parameters power drive devices. In addition, this document specifies the PDO mapping attributes for communication and application parameters.

Scope

This document specifies default communication objects and general communication parameters for CANopen devices in grid-based photovoltaic systems.

Scope

This document specifies the CANopen profile for a sub-section of low-voltage switchgear devices: motor starters, soft starters, and motor management starters. The specification is functional compatible with the international standard IEC 61915-2.

Scope

This document specifies the physical layer, and some general CANopen communication parameter objects.

Scope

This document specifies the device profile for straddle carrier spreaders including process data and process data objects.

Scope

This document specifies the CANopen interfaces for pump devices of the following types, based on VDMA 24223 series: - Generic pump; - Rotodynamic (liquid) pump. It specifies the object dictionary entries and the PDO mapping for both pump types.

Scope

This document specifies the CANopen communication and application parameters as well as the PDO mapping for power supplies and power converters.

Scope

This document specifies the CANopen interface for energy measuring devices. This includes energy consumption as well as energy production, in particular for energy recovering.

Scope

This document specifies the mandatory and recommended communication parameters, as well as the parameter sets for the PDO communication.

Scope

This document specifies the CANopen interface for devices that identify existence, dimension, orientation, or movement of items in their environment (e.g. optical camera (2D or 3D), laser device). Often those devices are called vision sensors or object detection devices.

Scope

This document specifies the mapping of the IO-Link gateways to CANopen. This includes the specifications of the Classic CAN physical layer, data link layer, and the Classic CANopen communication parameters.

Scope

This document specifies the mapping of CANopen application layer protocols to J1939 parameter groups. This includes, in particular, the mapping of SDO (service data object) client and SDO server protocols. Additionally, this document specifies the mapping of the EMCY (emergency) protocol. The mapping of CANopen profile-specific PDOs is not in the scope of this document.

Scope

This document provides recommendations for avoiding CAN Remote Frames when using CANopen communication services.

Scope

This document provides implementation hints for CiA 417’s bootloader (CiA 417 version 2.2.0 and higher).

Scope

This document recommends how to implement the CANopen interface for operator environments with human-machine interface functionality. It is based on the CiA 401 CANopen profile for generic I/O modules. It recommends how to use the digital and analog process data parameters specified in CiA 401. It also recommends a mapping of these parameters into PDOs.

Scope

This document specifies the layer setting services (LSS) and the layer setting protocols for CANopen FD devices.

Scope

This document specifies the XML Schema Definition for the CANopen FD profiles. It is based on ISO 15745-1:2003/Amd 1:2007.

Scope

This series of profile specifies the CANopen interface of power drive systems. It is suitable for drive and motion controllers. It specifies several operating modes for frequency inverters, servo - controllers, and stepper motors. The series of profile is split in several parts: • Part 1: General definitions; • Part 2: Operation modes and application data; • Part 3: PDO mapping; • Part 4: Safety functionality; • Part 5: PDO mapping superset; • Part 6: CANopen FD PDO mapping. This part specifies the CANopen FD mapping for frequency converters, servo drives and stepper motors as well as for multiple-axes systems.

Scope

Scope

This part provides specifications and guidelines on the physical layer interface design for automotive electronic control units and non-automotive devices supporting the CAN FD data link layer standardized in ISO 11898-1:2024 and the CAN FD physical layer standardized in ISO 11898-2:2024.

Scope

This document specifies the CANopen interface of an IVN gateway providing process data for other than brake and running gear equipment compliant with suspect parameters specified in ISO 11992-3. The CANopen interface is configurable by means of parameters specified in this document, in order to optimize the communication with the CANopen-connectable body application units (BAU). This allows forwarding of parameter groups received from the J1939-based IVN network and forwarding of CANopen application objects to the IVN network.

Scope

This document specifies the functional behavior as well as application parameters for different types of linear and rotary encoders such as incremental and absolute, normal, and high-resolution, single and multi-sensor (linear only) encoders. This includes encoder output process values such as position, speed, acceleration and jerk, and encoder CAM parameters. Additionally, safety-related parameters such as safety position and safety speed for encoders are specified. The mapping into Process Data Objects (PDO), Safety-related Data Objects (SRDO), and Parameter Groups (PG) is not in the scope of this document.

Scope

This document part specifies the CANopen FD communication and mapping parameters for encoders compliant with the CiA 406-B specification. This includes the PDO mapping.

Scope

This document specifies the functional behavior as well as application parameters for inclinometers. The mapping into Process Data Objects (PDO), Safety-related Data Objects (SRDO), and Parameter Groups (PG) is not in the scope of this document.

Scope

This document specifies the CANopen FD communication and mapping parameters for inclinometers compliant with the CiA 410-B specification. This includes the PDO mapping.

Scope

This document provides recommendation how to represent the international system of units and prefixes in parameter specifications. It recommends also the structure of configuration parameters for SI units and prefixes.

Scope

The CANopen application profile for EMSs specifies the communication interface for all virtual devices that may take part in energy management control application. Such energy management control applications may be implemented in e.g. light electric vehicles, robots, offshore parks, isolated farms, etc. The CANopen application profile for EMSs consists of the following parts: Part 1: General definitions, Part 2: Pre-defined communication parameters and general application objects, Part 3: Pre-defined PDO communication, Part 4: EMS controller, Part 5: Voltage converter unit, Part 6: Battery pack, Part 7: Motor control unit (under development), Part 8: Load monitoring unit (under development), Part 9: HMI unit (under development), Part 10: Security unit (under development), Part 11: Sensor unit (under development), Part 12: Gateway unit (under development), Part 13: Generator unit, Part 14: Load unit. This document represents the part 2 of the CANopen application profile for EMSs. Part 2 provides additional specifications with regard to the pre-defined communication objects as well as the general communication objects. KeywordsCANopen application profile for energy management systems - Part 2: Pre-defined communication parameters and general application objects.

Scope

The CANopen application profile for EMSs specifies the communication interface for all virtual devices that may take part in energy management control application. Such energy management control applications may be implemented in e.g. light electric vehicles, robots, offshore parks, isolated farms, etc. The CANopen application profile for EMSs consists of the following parts: Part 1: General definitions, Part 2: Pre-defined communication parameters and general application objects, Part 3: Pre-defined PDO communication, Part 4: EMS controller, Part 5: Voltage converter unit, Part 6: Battery pack, Part 7: Motor control unit (under development), Part 8: Load monitoring unit (under development), Part 9: HMI unit (under development), Part 10: Security unit (under development), Part 11: Sensor unit (under development), Part 12: Gateway unit (under development), Part 13: Generator unit, Part 14: Load unit. This document represents the part 3 of the CANopen application profile for EMSs. Part 3 specifies the application objects provided by the virtual device Energy management system controller (EBC).

Scope

The CANopen application profile for EMSs specifies the communication interface for all virtual devices that may take part in energy management control application. Such energy management control applications may be implemented in e.g. light electric vehicles, robots, offshore parks, isolated farms, etc. The CANopen application profile for EMSs consists of the following parts: Part 1: General definitions, Part 2: Pre-defined communication parameters and general application objects, Part 3: Pre-defined PDO communication, Part 4: EMS controller, Part 5: Voltage converter unit, Part 6: Battery pack, Part 7: Motor control unit (under development), Part 8: Load monitoring unit (under development), Part 9: HMI unit (under development), Part 10: Security unit (under development), Part 11: Sensor unit (under development), Part 12: Gateway unit (under development), Part 13: Generator unit, Part 14: Load unit. This document represents the part 6 of the CANopen application profile for EMSs. Part 6 of the document specifies application objects provided by the battery pack.

Scope

This document specifies the communication and application parameters for different types of linear and rotary encoders such as incremental and absolute, normal, and high resolution, single and multi-sensor (linear only) encoders. The document provides also operating principles of the encoders and specifies encoder output process values such as position, speed, acceleration and jerk. The document specifies also encoder CAM parameters. This document also specifies CANopen Safety parameters such as Safety position and Safety speed for encoders with CANopen Safety functionality (see EN 50325-5).

Scope

Scope

This document specifies the mapping of data objects specified in CiA 408-B to CANopen CC communication objects, especially PDO communication and mapping parameters. Additionally, this document provides requirements and recommendations for the implementation of the lower CAN layers. This specification is based on the profile “Fluid Power Technology”, version 1.7.0, designed by Verband Deutscher Maschinen- und Anlagenbau e.V. Frankfurt/Main, Germany (VDMA).

Scope

This document specifies functional principles and application parameters for hydraulic proportional valves, hydrostatic pumps, and hydrostatic transmissions. They can be applied on pneumatic, as well. This specification is based on the profile “Fluid Power Technology”, version 1.7.0, designed by Verband Deutscher Maschinen- und Anlagenbau e.V. Frankfurt/Main, Germany (VDMA).

Scope

Scope

This CiA device profile describes the functionality of interconnectable proportional valves, hydrostatic pumps and hydrostatic transmissions. The specification is based on the profile “Fluid Power Technology”, version 1.6.3 designed by Verband Deutscher Maschinen- und Anlagenbau e.V. Frankfurt/Main, Germany (VDMA). The device profile specifies CANopen interface for hydraulic proportional valves, hydrostatic pumps and hydrostatic transmissions. This profile may as well be applied on pneumatic devices.

Scope

This document specifies the physical layer including connectors, and some general communication parameters. There are no PDOs pre-defined