CiA® 437: CANopen application profile for grid-based photovoltaic systems

The CiA 437 application profile defines the CANopen interfaces for photovoltaic (PV) control systems. This includes interfaces to PV controllers, PV inverters, wind direction sensors, temperature sensors, radiation sensors, energy sensors, power sensors, solar panel tracking systems, etc. The three-part specification comprises general definitions, pre-defined communication objects, and process data specification. When implementing the profile, device manufacturers may supply diverse applications using the same electronic CANopen interface implementation and simply adapting the required functionality. A system designer may combine CANopen devices from different manufacturers implementing the required profile-compliant functionality. The according spare parts are then also available from different sources. For development, analysis, and maintenance of the devices, off-the-shelf CANopen tools may be used.

Virtual network architecture for PV systems

The profile defines several virtual devices (non-divisible functions) supporting a set of mandatory and optional application objects. A physical CANopen device implements one or more virtual devices. But a virtual device may not be distributed to several physical devices. A virtual device supports one or more functional elements (device numbers, e.g. inverter 1, inverter 2, inverter 3) distinguished by the index and sub-index number of the implemented objects. A mechanism for automatic device number assignment is proposed (not mandatory) in CiA 437-1. The PV controller is a virtual device with NMT manager functionality and the capability of automatic device number assignment. It also provides the SDO client functionality to the SDO servers of other devices. A PV system may consist of much more networked devices than 127 (node-ID limit in one CANopen network), requiring interconnection via several CANopen networks. To transfer data between the networks is possible using remote emergency and remote SDO functional elements (see CiA 302-7). Hereby, the PV controller acts as the system manager. It also optionally provides an interface to other distributed electrical power generation systems (e.g. wind-craft, diesel, biogas, etc.) and optionally links the PV system to the electrical power distribution control system. Part 1 also defines which application objects have to be implemented by a certain virtual device including the access direction (e.g. ro, rw, wo) and the category (mandatory, conditional, or optional).

Each PV inverter (up to 254 possible) implements a TPDO providing the 64-bit inverter’s total output energy value. The PV controller as well as the data monitoring or data logger device collects these values. Each physical device implements one MPDO (multiplexed PDO) to be transmitted in broadcast and up to 127 MPDOs to be received. Thus, the CANopen devices may exchange all application objects (beside inverter’s total output energy) via MPDOs. To be transmittable via MPDO, the application parameters were defined as values smaller or equal to 32 bits.

The application objects (part 3) for inverters include all required electrical parameters (current, voltage, power, frequency, energy), temperatures, statuses and commands, test types, as well as diverse limits for failure-free inverter functioning (e.g. operating, disconnection, reconnection). For sun tracking system devices the geometry, technology, location longitude and latitude, as well as statuses and commands (also for drives and motors) are specified. Parameters for control (actual and target values, offsets, intervals), the azimuth and elevation, as well as for special conditions (storm, snow drop, maintenance, night) are given as well. In addition, the application parameters for a string diagnostic device and a grid diagnostic device are specified in detail. For each “complex” device the operating time and number of start-ups are defined. The “simple” devices with less application data include temperature sensors, radiation sensor, energy sensor, wind sensor, as well as generic digital/analog inputs/outputs.

Profile compliant devices support a bit-rate of 125 kbit/s (and optionally others) and one of the four connectors (RJ45, 5-pin micro-style, 9-pin sub-D, open style connector) with the pinning from CiA 106. The physical layer definitions follow those in CiA 301. For node-ID assignment and bit-rate reconfiguration it is recommended to use the CANopen layer setting services (see CiA 305). Support of the emergency message and the heartbeat functionality is mandatory.

Title Details
CiA 437-3 version 2.0.0CANopen application profile for grid-based photovoltaic systems - Part 3: Profile data objects
DescriptionThis application profile defines the CANopen interfaces for photovoltaic control systems. This includes interfaces to photovoltaic controller, photovoltaic inverter, wind direction sensor, temperature sensor, radiation sensor, energy (Wh) sensor, power (W) sensor, solar panel tracking system, etc. The application profile specification consists of several parts: Part 1: General definitions, Part 2: Pre-defined communication objects, Part 3: Detailed process data specification. This part of the application profile specifies in detail the process data and parameters of the virtual devices.
DSP4.0 MiB2012-06-15Login
CiA 437-1 version 1.1.0CANopen application profile for grid-based photovoltaic systems - Part 1: General definitions
DescriptionThis document specifies the CAN-related physical layer, the general system architecture, and some common CiA 301 communication parameter objects. It also defines, which process data and parameters are used by the virtual devices specified for grid-based photovoltaic systems
DSP784 KiB2024-01-09Login
CiA 437-2 version 1.1.0CANopen application profile for grid-based photovoltaic systems - Part 2: Pre-defined communication objects
DescriptionThis document specifies default communication objects and general communication parameters for CANopen devices in grid-based photovoltaic systems.
DSP305 KiB2024-01-09Login
CiA 301 version 4.2.0CANopen application layer and communication profile
DescriptionThis 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 predefined communication object identifier connection set, and the content of the Emergency, Timestamp, and Sync communication objects.
PAS3.0 MiB2011-02-21Login
CiA 305 version 3.0.0CANopen layer setting services (LSS) and protocols
DescriptionThis document specifies the layer setting services (LSS) and protocols for CANopen. These services and protocols are used to inquire or to change the settings of three parameters of the physical layer, data link layer, and application layer on a CANopen device with LSS server capability by a CANopen device with LSS manager capability via the CAN network.
DSP1.9 MiB2013-05-08Login
CiA 106 version 1.1.0Connector pin-assignment recommendations
DescriptionThis document recommends the connector pin-assignment for CAN interfaces. This includes the CAN_H and CAN_L pins, the ground pin, and the power supply pins.
TR0.9 MiB2023-07-11Login