The current edition of the standard for Train Communication Networks (TCN) describes in a two-level approach the communication based on WTB (Wire Train Bus) for the train level and MVB (Multifunction Vehicle Bus) on consist level. Due to certain, manufacturer-specific boundary conditions (e.g. demands on network topology, utilized control units, availability of devices and tools, price, etc.) manufactures of rail vehicles deviate from the standard and equip their rail vehicles with a bus system that meets their requirements better. Therefore bus systems such as e.g. LON, ProfiNet, FIP, or CAN-based networks are used on consist level as well. To allow this development the new edition of IEC 61375 TCN will standardize further bus systems for the consist level. The CANopen network is one of them and will be added to the new TCN standard.
Specialized for embedded control systems
CANopen is a CAN-based higher layer protocol, standardized in EN 50325-4 comprising the application layer and communication profile. In the application field of rail vehicles CAN-based systems are used to connect control devices, sensors and drives within subsystems as well as to enable the data exchange between subsystems on consist level. CANopen provides standardized communication objects for the transmission of real-time data and configuration data. To achieve synchronous communication, CANopen provides the SYNC object. All network participants receive it at the very same time. Therefore they all perform actions connected with the reception of the SYNC object synchronously. Additional CANopen communication objects are the time stamp for creating a single system time, the emergency message to publish local errors, the boot-up message to signal that a new network participant is ready to “work” and the error control message to guard the network participants. The network management services are used to switch a CANopen device through the NMT slave state machine. They may be very helpful for system integrators during system development and for diagnosis. All communication and application objects belonging to a CANopen device are managed in a standardized listing. In this listing, the object dictionary, each object owns its unique 24-bit address, which is divided in a 16-bit index and an 8-bit sub-index. Therefore the object dictionary describes the complete functionality of a CANopen device. It represents the interface between the protocol stack and the application software. The object dictionary contains a standardized set of attributes for every object. This set of attributed specifies, among others, the object type (e.g. variable, array or record) and how a certain object can be accessed via the CANopen network (e.g. read-only, read-and-write, etc.).
CANopen profiles for rail vehicles
In order to minimize the effort of system integration, the non-profit users’ and manufacturers’ group CAN in Automation (CiA) has established the CANopen Special Interest Group (SIG) rail vehicles (including Deuta, Knorr-Bremse, Luetze, MTU, Selectron/Schneider Electric, Siemens, Voith, Vossloh Kiepe, etc.), which develops CANopen application profiles specifically for rail vehicles. On the one hand the working group develops a CANopen application profile for the in-vehicle integration network (consist network). On the other hand the group develops several application profiles that describe the communication within the different subsystems such as e.g. diesel engine control, door control or interior/exterior lighting control. This profile can be considered as an integration platform, which describes the application data to be provided on consist level by a certain subsystem. In case e.g. all doors shall be closed, the train operating system needs to know where to hand over the command to the door control system. From a CANopen point of view this means to which object in the object dictionary of the door controller the train operating system has to write the “close all door command”. In addition, the door controller needs to know the structure of the command (e.g. which bit covers the demanded action). This information is standardized in the specification CiA 421 specification. The diesel engine control unit operates the diesel engine according to the commands received by the traction controller. The CANopen application profile offers the possibility to control the diesel engine by means of a speed-, power-, or torque-demand-value. The diesel engine sensor unit provides the sensor values, which are required for a safe and correct engine operation. All measured analog values such as engine oil pressure, charge air temperature, coolant level, etc. are represented in the data format signed Integer 32. This offers the possibility to represent all analog values with the same SI-unit in the same resolution without further offset-calculation. In addition the CANopen application profile defines virtual devices for transmission control, for particle filter control, oil refill unit control as well as vehicle speed control. Furthermore the closely coupled auxiliary operating system (CiA 430) is specified, which enables the standardized control of the engine cooling equipment or the generator unit. Moreover the working group described the communication interfaces of these two systems to the consist network. This allows the diesel engine control unit to demand the appropriate engine cooling in a standardized way. The documents defining the power (drive) system (CiA 423) and the auxiliary operating system (CiA 430) are published CiA-internally. Together with these specifications, the CANopen application profiles for door control as well as for interior/exterior lighting control will be published CiA internally as well.
Automation system for rail diesel engines
MTU has introduced an automation system for its Series 4000 rail engines. The CANopen-based Powerline management system is specially adapted to rail traction with MTU diesel engines. The system monitors, controls and regulates all the functions of the propulsion system. The interplay between the vehicle devices, the engine and the electronics is fully automatic, an advantage for train drivers because they can then concentrate fully on their work. The modular electronics system guarantees the optimal adjustment of the propulsion system to the various operating conditions in regular use. With the basic components of the Power Automation Unit (PAU), Power Output Module (POM) and Advanced Diesel Engine Control (ADEC), the Powerline propulsion automation system allows the simple integration of the engine in the locomotive. The PAU is a system that integrates many individual devices such as switching elements and aggregates in just one piece of equipment. The PAU has a redundant CANopen interface and controls not only the engine, but also other devices of a rail vehicle such as the cooling system, air conditioning, voltage transformer and fuel preparation. The significant market advantages of the CANopen interface integrated in the PAU are the easy installation and the secure transfer of processing data from the engine to the train’s computer. The engine and diagnosis data that are transferred are available in a clear form on the train driver’s display. Via this interface, service personnel and the rail operator’s fleet management have access to all relevant operating data such as engine revolutions, temperatures and alarm messages. The POM starter system and the ADEC controller are also electronic modules that are permanently installed on the engine. The devices are simply to integrate in new direct-current locomotives, but also re-motorization, that is, the changeover of existing vehicle controls is possible. The Capacity Power Starter Unit (Capos) supplies the POM with electricity. The starter unit serves as a spare battery and consists of concentrated capacitor units. Electricity can be temporarily stored in these units with practically no maintenance. The capacitors’ lifetime of approximately 15 years is longer than that of conventional locomotive battery packs. Due to the integrated safety system, the system also automatically adapts the engine’s power output to current driving conditions and stops the engine in an emergency. Furthermore, the automation system already offers an optional interface for the subsequent integration of exhaust-gas after-treatment systems.
One of the system advantages is its compact shape and size tailored to rail applications and that the integration effort is reduced by half. Service tools for simplified and rapid repair and maintenance round off the application profile for locomotive manufacturers, whose complex locomotive approval applications are simplified by a safety expertise for MTU’s automation system issued by the German Federal
Railways Authority.
by Holger Zeltwanger, Managing Director CAN in Automation (CiA) GmbH
Share on:
