Contract 015286 (INCO) - CRESMED Document: Deliverable 17 WP 4 Task 4.3 Final use Description: Prototype of load/generator management device Language English Responsible: Stefano Quaranta Revised by:<br/><br/>Date:10.06.08<br/><br/>Version:01 Level: WD Nº pages:11<br/><br/>Author: Stefano Quaranta Date Comments<br/><br/>WORK PACKAGE 4 DELIVERABLE 17: Prototype of load/generator management device<br/><br/>I1 Project:<br/><br/>Internal document : Prototype of load/generator management device CRESMED<br/><br/>Date: 10.06.08 Responsible: Stefano Quaranta Page 1/11<br/><br/>Work Package : 4 - Communication, monitoring and remote control system<br/><br/><br/>Content<br/>Executive summary ..................................................................................................... 3  Introduction ............................................................................................................... 4  Field-bus CAN.............................................................................................................5  1.1  Digital I/O.......................................................................................................6  Components ............................................................................................................... 7  1.2  Communication module ................................................................................... 7  1.3  Power module.................................................................................................8  Advanced features ...................................................................................................... 9  Conclusions .............................................................................................................. 10  Literature ................................................................................................................. 11 <br/><br/>I1 Project:<br/><br/>Internal document : Prototype of load/generator management device CRESMED<br/><br/>Date: 10.06.08 Responsible: Stefano Quaranta Page 2/11<br/><br/>Work Package : 4 - Communication, monitoring and remote control system<br/><br/><br/>Executive summary<br/>The load/generator management devices are part of the technical developments carried out by the project in the search for an integrated and cost-effective system for energy production and control. The prototypes listen to the signals on the bus and take corresponding actions (ex. a device installed on a fuel generator starts and stops the generator, a device installed with a water pump can be used to pump water on a tank during daytime only). The devices turn loads and generators into intelligent devices directly controlled by the Energy Management System. This deliverable describes processes and components that have been selected and integrated to reach the targeted functional level.<br/><br/><br/>Introduction<br/>The load/generator management devices are basically an innovative I/O system that enables the Energy Management System to drive external loads and generators. The basic problem to solve is to connect the I/O system with the main intelligent unit of the system, the 'centralita'. The 'centralita' has the capability to drive loads and generators only through phisycally wired connections, and this is not compatible with the distance between the centralita and the loads and generators devices. The load/generator management devices is a sort of mirroring system that enables, thanks to the use of a powerful communication network, to reproduce the I/O system present on centralita in every place where I/O is needed. To better understand the adopted solution, here an example of scheme:<br/><br/>EMS<br/><br/>Input Module<br/><br/>Output Module<br/><br/>Communication Network<br/><br/>The outputs signals coming out from the EMS Centralita are physically wired to the Input Module. This module converts the input signals in requests and send the request over the communication network. If an Output module is present in the network with the same address of the Input Module, it will take the input information from the network and will generate as outputs the same signal present on the EMS Centralita. This simple mechanism enables to reproduce the same outputs signal present on the EMS Centralita in different places. This places can be very far from the centralita, up to 4 kilometers. The result is that the EMS Centralita could drive remote I/O also without having on-board communication capabilities. In the following paragraph we will show that the delay introduced by the communication system has no effect on the Energy Management System timings, thank to the very high performances of the selected communication network.<br/><br/><br/>Field-bus CAN<br/>To select a suitable communication system for the proposed application, several consideration were done. First of all, the communication system has to be very reliable in harsh environments. Second, the communication system must be able to cover long distances, more than one kilometer. Third, the communication system has to be fast enough to be 'transparent' to the application: that means the delay introduced by the network for activating physical signals must be very small if compared to the application timings. Only one standard and largely diffused technology is able to cover all this features: the CANbus. As is well known, the CANbus technology is just a communication data-link layer system: that means that CANbus technology is able to move data, in a very efficient way, from one place to another place on the network. In the Energy Management System something more is needed: to develop a complete I/O solution. To cover the gap, over the CANbus technology was placed the CANopen technology: an application layer solution largely diffused in industrial automation and transports application. The load/generator management devices were developed to be fully compliant with the CANopen specification. This means that all the very advanced functions of the CANopen protocol were used to build a very reliable, efficient and accurate system. Basically, all the work done was aimed to develop electronic I/O boards fully compliant with CANbus and CANopen specifications. After that, all application software was developed in order to configure and optimize the CANopen protocol services needed for the load/generator control system. To summarize the choices: CANbus was configured to a standard baud rate of 50 Kbps with optically isolated transceivers and galvanically isolated external network power supply. This configuration ensures that the bus length could fulfill the distance range targeted, and will be very robust against external EMC noise. As the system has to comply with a high voltage power system, the galvanic isolation ensures also that there is enough isolation between the communication signals and the I/O signals. The CANopen protocol services were used in order to maximize the efficiency of the system in response time. Thanks to the very high quality definition of the services, also reliability and diagnostic were important features introduced in the application software. Basically, the NMT master of the CANopen network takes care of activating all the modules present in the network. If something wrong happens, the NMT master will start a process to recover from the error and restart the system. For what concerns the I/O mirroring application, a very advanced feature of the CANopen protocol was used: the PDO mapping and relinking procedure. Thanks to the multi-master capability of the network, the I/O devices are configured in such a way they can talk each other without the need of an external master.<br/><br/><br/>This means that an input module can talk with an output module as fast as a single CANbus frame could go from a module to another. To calculate the maximum response time of such an I/O mirroring system, we just need to calculate how long does last a CANbus frame of 8 bytes of data (the longer frame we can send on a CANbus network). As a CANbus frame, complete of services fields like CER, ACK, SOF, EOF, is about 125 bits long, to know the timing we have just to multiply 125 by the bit duration. At 50Kbit baud rate, one bit last for 20 microseconds. This means that a complete frame takes only for 2.5 milliseconds to be brought from one module to another. With the choices just described, with a CANbus/CANopen solution we were able to develop an I/O mirroring system going from the EMS Centralita to more than 1 Km of distance, and this remoting application has just a 2.5 milliseconds of delay: fantastic.<br/><br/>1.1<br/><br/>Digital I/O<br/><br/>As described above, the I/O system is basically a mirroring system for the centralita I/O. In order to be very flexible, the features of the I/O signal are the standard features of an industrial I/O. That means that every input channel is based on 24Vcc industrial standard, that means 18-36Vdc input means a logic 1, under 9 Vdc means a logic 0. As every input channel has a pull-down resistor to 0Vdc, an open input is always at a logic 0 value. To detect the open contact (relays) status of the EMS Centralita outputs, it is needed to connect a 24Vdc on one side of the relay contact and to connect a wire between the other side of the contact and the input connector of the Input device. Concerning the Output channels, the industrial standard requires high side silicon switches able to drive up to 0,5A of current. If more current or a galvanic isolation open contact is needed, just insert a standard 24Vdc relay. In this case, adding to the Output system the required external relay, it is possible to drive virtually any kind of load or generator.<br/><br/><br/>Components<br/>The development activities of the CANbus modules follow an hardware/software partitioning: hardware development and software/firmware development. Referring to hardware development, here a brief list:<br/>· · · ·<br/><br/>definition definition definition definition<br/><br/>of of of of<br/><br/>the hardware driver/detector for the I/O signals a CANbus CPU able to manage I/O galvanic isolation strategies power supply strategies (both for the CPU and I/O)<br/><br/>Referring to the software development, here is the corresponding list:<br/>· · · · ·<br/><br/>development development development development development<br/><br/>of of of of of<br/><br/>base firmware operating system scheduler CANbus drivers CANopen protocol application<br/><br/>The first three points of the firmware development activities are standard activities. This part of work is needed for every microprocessor a technician has to use. The important part of the development is the CANopen protocol personalization for the requested Energy Management Application. A fully compliant CANopen protocol was developed, in order to have a complete support of all the services: NMT, SYNC, TIME, EMCY, PDO, SDO, NG. A very important part of the development was the configuration of the CANopen object dictionary in order to implement both the communication and profile object described by the protocol. The most innovative and interesting part of the development was the integration of the auto-configuration and auto-recognition of modules that have to be mirrored. As a CANopen network is able to manage up to 128 network devices, the mirroring procedure was implemented in order to cover the maximum number of nodes: 64 inputs plus 64 outputs on the same network.<br/><br/>1.2<br/><br/>Communication module<br/><br/>As stated by the CANopen specification, a CANopen network requires the presence of a CANopen manager node. This node must implement the NMT master, the SYNC master, the TIME master, the SDO client for each node and the Node Guarding and Emergency managers in case of errors. All the CANopen communication system depends on a CPU module that manages the complete network. As the Energy Manager System is a system composed by different parts, some important consideration were done concerning this subject: if something in the network is going wrong, what we have to do?<br/><br/><br/>Basically there are two different philosophy of behavior in case of an error: stop everything or stop only the node where the error is present. We adopted the second philosophy: that means that in case of an error, all the system still work correctly except the damaged part. The CANopen Manager software is installed in a special node, based on a powerful CPU running the Windows CE operating system. The reason of having such kind of powerful system is due to the fact that this module will also run other important functionalities not related with the simple I/O system: the communication gateway between EMS Centralita and the Energy Dispenser, the communication gateway between the EMS Centralita and Internet.<br/><br/>1.3<br/><br/>Power module<br/><br/>The whole I/O system is based on the industrial standard +24Vdc power supply. This standard requires a nominal power supply of +24 Vdc but tolerates a minimum supply of 18Vdc and a maximum of 36Vdc. Every CANopen I/O module requires just 2W of power for its functions, while the CANopen Manager module requires less than 15W. As the complete Energy System complies with different Power standard, it is recommended to use AC-DC or DC-DC converters to generate all the required power supply. The use of galvanically isolated AC-CD or DC-DC converter, with short circuit and over voltage protection is recommended. In fact, the galvanic isolation will ensure the needed robustness to EMC noise in the communication system and also a correct high voltage isolation between the 'intelligent part' of the system (control and communication units) and the power lines, loads and generators. No development efforts were done about the power supply solution for the Energy Manager System, as on the market are available a large number of suitable commercial products. It is responsibility of the installer to choose where to get the power (from the electrical power network or from the 48V battery that supplies the EMS Centralita).<br/><br/><br/>Advanced features<br/>The load/generator management devices was designed in order to be very reliable, fast, efficient respect to both performance and robustness. Special care was used in order to comply with harsh environment features. The CANbus I/O modules were designed in order to work from -40 up to 85 °C of temperature range. It is well know that the CANbus technology it is very reliable, with millions of installations mainly in the industrial and automotive field. To be very robust also for long cable length, as recommended by the international consortium of the CANbus (CiA), it is recommended a cable composed by a double twisted pair with double shield. The first twisted pair has to be 120 ohm impedance and has to be used for the CANbus signals. The second twisted pair will supply all the network transceivers through a 24Vdc galvanically isolated power supply. This solution will enhance the network performance and robustness keeping all the transceivers network ground to the same voltage potential. As described in a previous chapter, the use of the most advanced services of the CANopen protocol ensures the maximum performances of the CANopen network. This means that a very short delay (2.5 milliseconds) will be introduced by the communication network. Thanks to this very efficient way of communicating, the control system inside the EMS Centralita will be able to drive all the peripheral device up to 1km of distances without any impact of the actual performances without communication system. At the end this is the most important result of the development: the EMS Centralita can act in a very large area (more than 1 square kilometer) in the same way it would do without a communication system in area definitely more restricted area of few tenths of meters.<br/><br/><br/>Conclusions<br/>The use of the 'state of the art' new communication technologies integrated with control devices has permitted to expand the control capability of the system, the EMS Centralita, to cover a very large area. Giving more control capability to the Energy Control System means be more efficient. Basically, the positive result of this development activity are two: expand the area were the power can be controlled and improve the overall efficiency of the energy system.<br/><br/><br/>Literature<br/>IEC 61158 Digital data communications for measurement and control - Fieldbus for use in industrial control systems IEC 61784 Digital data communications for measurement and control CiA 301 DS V4.0.2: CANopen application layer and communication profile CiA 400 DSP V1.0: CANopen interface profile - Multi-level networking CiA 401 DS V2.1: CANopen device profile generic I/O modules CiA 404 DS V1.2: CANopen device profile measuring devices and closed-loop controllers CiA 418 DS V1.0.1: CANopen device profile for battery modules CiA 419 DS V1.0.1: CANopen device profile for battery charger TCP/IP Tutorial and Technical Overview - IBM Corporation, International Technical Support Organization