Contract 015286 (INCO) - CRESMED Document: Deliverable 18 WP 4 Task 4.3 Final use Description: Prototype of communication device Language English Responsible: Stefano Quaranta Revised by:<br/><br/>Date:16.06.08<br/><br/>Version:01 Level: WD Nš pages:11<br/><br/>Author: Stefano Quaranta Date Comments<br/><br/>WORK PACKAGE 4 DELIVERABLE 18: Prototype of interface for Energy Management System<br/><br/>I1 Project:<br/><br/>Internal document : Prototype of communication device CRESMED<br/><br/>Date: 16.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  CANbus communication ............................................................................................... 5  1.1  CANopen ........................................................................................................ 6  Components ............................................................................................................... 7  1.2  RS232/CANopen Gateway ................................................................................ 7  1.3  CANopen/TApS ............................................................................................... 7  1.4  Internet gateway.............................................................................................8  Conclusions .............................................................................................................. 10  Literature ................................................................................................................. 11 <br/><br/>I1 Project:<br/><br/>Internal document : Prototype of communication device CRESMED<br/><br/>Date: 16.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/>One of the areas the CRESMED project focus on is the need for integration of state-of-theart technologies into systems and processes able the exploit them at their most and tailor the added-value of such integration. Based on this criteria particular attention has been paid to those parts of the hybrid system for rural electrification allowing for the communication of data and information of great importance to the system and to its users. The communication device described in this document represent the outcome of studies and developments done in order to provide the technical solution to the requirements of reliability and efficiency of the Energy Management System. Starting from a system able to communicate over short path and by mean of basic communication standards, the prototypes built have brought major modification to reach an higher level of performance. This document gives an overlook of the communication system set up and highlights its main features.<br/><br/><br/>Introduction<br/>The original idea of this project was the following: giving the possibility to a Energy System to communicate could be very useful in order to have a more reliable, flexible, expandable and diagnosticable system. This means that communication capabilities could be the key point for lowering the overall cost of the Energy System and increase the Energy Management efficiency. From the first analysis of the system it was clear that more than one communication system has to be developed. In fact, three different functions are needed: · · · give the EMS Centralita the possibility to control remote I/O devices give the EMS Centralita the possibility to manage existing HMI remote device, like energy dispenser and display give the EMS Centralita the possibility of sending data on the internet network<br/><br/>The EMS Centralita device is able to communicate in two different ways: a custom 48Vdc bus, called TApS bus, an RS232 standard port. Both of these communication technologies are not suitable for solving the above mentioned functions. In fact, a serial RS232 communication line is not able to manage more than one device (it is not a network solution). On the other hand, the TApS bus is not able to cover with high distances or be very efficient in timings. To solve the three problem above described were developed three gateways: · · · RS232 to CANbus gateway TapS bus to CANbus gateway RS232 to Internet gateway<br/><br/>Thanks to this new devices, the centralita is able to communicate in the actual standard mode. On the other side, the complete system is able to communicate with the newest and best technologies for I/O management, remote existing devices control and internet connectivity.<br/><br/><br/>CANbus communication<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 1 Km. 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, in a very efficient way data from one place of the network to another place. In the Energy Management System something more is needed: to develop a complete I/O solution together with the possibility of driving old TapS devices. To cover the gap, over the CANbus technology was placed the CANopen technology, described in the next chapter Basically, all the work done was aimed to develop electronics gateway board fully compliant with CANbus and CANopen specifications on one side and compliant with the RS232 and TApS bus specification on the other side. After that, the application software was just a logic translator from one protocol to the other and vice versa for bidirectional communications. Several hypothesis were done, in order to better configure the communications systems. The result of this study are the following: CANbus was configured to a standard baud rate of 50Kbps with optically isolated transceivers and galvanically isolated external network power supply. This configuration ensures that the bus length could be more that 1Km, 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. Thanks to the multi master capability of the CANopen network, more than one gateway could be connected to the same CANbus network. This was very advantageous for the complete communication system: one CANbus network was able to completely satisfy all the requested functionality: I/O management, TApS control, HMI remote management, RS232 data communication at high distances. To calculate the maximum response time of a so configured network system, it is important to remember that a CANbus system is able to hardware manage the priority of messages. This means that if more than one devices has to send data on the network, the device with the highest priority will send data first, than the other devices with just one frame delay for each device. To calculate the response time of the highest priority devices, we have to calculate how long does last a CANbus frame of 8 bytes of data (the longer frame we can send on a<br/><br/><br/>CANbus network). As a CANbus frame, complete of services fields like CER, ACK, SOF, EOF, etc. is around 125 bit 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 lasts for 2.5 milliseconds. With the choices just described, we can say that for 1 CANbus device network we get a maximum delay of 2.5 millisecond, for 10 devices 25 millisecond. As the cyclic time of the Taps bus is 5 second, we can conclude that CANbus is a transparent solution also in case of the maximum capability of the bus: 128 CANbus nodes.<br/><br/>1.1<br/><br/>CANopen<br/><br/>The CANbus technology described in the previous chapter is a way of moving data in a communication network. In the Energy Management System something more is needed: we have to define application data in order to be able to put them in CANbus frames. Instead of defining a proprietary coding of data, the decision of using the CANopen protocol coding strategies were taken. Thank to this decision, the CANopen official specifications were adopted: DS301, DS4xx. The CANopen protocol services were used in order to maximize the efficiency of te system in response time. Thank 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 take care of recover from the error and restart the system. All the gateway are nodes of the standard CANopen network, so, from the CANbus point of view, every information is contained in the Dsxxx specifications.<br/><br/><br/>Components<br/>The components developed for the Energy Management System were three: a RS232 to CANopen gateway, a CANopen to TapS Bus gateway, a RS232/CANopen to Internet gateway. As prototypes has to be developed, the choice of using standard CPU devices with standard operating system on board was done. This means that standard hardware from the marked was purchased and it was completed with the needed software. Only one special piece of hardware was developed: the power driver for the 48Vdc TAPs bus. In the following chapters details of the features of each gateway will be described.<br/><br/>1.2<br/><br/>RS232/CANopen Gateway<br/><br/>The RS232/CANopen gateway was developed using a commercial CPU in the PC/104 format with an expansion board with a CANbus interface. To be able to use the very high performances of the communication system, a real time operating system was used. The basic function of this gateway is to receive data from the EMS Centralita and send this information over the CANopen network. The EMS Centralita is programmed to send over the RS232 port all the information needed to drive remote HMI devices, like energy dispenser and display. As the EMS Centralita is the control system, the RS232/CANopen gateways has to act as a server for what is coming out of the EMS Centralita and as a Master of the CANopen network. This is the reason why, referring to the CANopen protocol, all the following functionalities were implemented under the real time operating system: · · · · CANopen CANopen CANopen CANopen NMT Manager SYNC Master TIME Master SDO Client<br/><br/>Concerning the PDO functionality of the gateway, the software remaps inside the first PDO of the CANopen node all the process information coming out of the EMS Centralita. This information will be remapped, thanks to the other remote gateway, to the other standard communication technologies.<br/><br/>1.3<br/><br/>CANopen/TApS<br/><br/>The CANopen/TAps gateway has to reconstruct a TApS bus communication getting data from the CANopen network.<br/><br/><br/>To build this device, a standard CPU from the market was chosen with a CANbus and some I/O onboard. As for the RS232/CANopen gateway, a standard operating system was chosen in order to speed up the software developing activity. From the CANopen network point of view, this gateway is a Slave node that receives commands from the EMS Centralita (through the RS232/CANopen gateway) and sends command to the HMI devices connected over the TAPS bus. In other words, the CANopen/TAPS gateway has to cover the CANopen Slave functionalities plus the TApS bus Master functionalities. For what is concerning CANopen slave, all the implemented functionalities are: · · · · CANopen CANopen CANopen CANopen NMT slave SYNC slave TIME slave SDO server<br/><br/>Focusing on the PDO protocol, the CANopen/TApS gateways receives PDOs from the EMS Centralita and sends the contained information over the TApS bus. Respect to the TApS bus master functionalities, we have to say that this is a very simple technology of communication in which only a basic service of data sending (PDO like) is available. Two main difficulties are present in the TAPS technology: timing of the 48Vdc signals and bus connection. Timing of the line were implemented in software and, thanks to the powerful CPU, the specification was respected. On the 48Vdc bus connection side, a special hardware transceiver was designed and build. To be sure that the transceiver was fully compliant with the TApS specification, direct driving of TApS slave devices was tested for several days demonstrating the correct functionality of the system<br/><br/>1.4<br/><br/>Internet gateway<br/><br/>The EMS Centralita can be connected, through a standard RS232 port, to a PC. With this connection and with a program running over the PC itself it is possible to configure and manage the complete control system. The idea of building an internet gateway was the following: we want to give a remote technician the possibility to make the same operation that it does when he is connected, in local way, to the RS232 port of the EMS Centralita. In the same time, the Internet gateway has to be able to move data from the standard operation of the EMS Centralita to an Internet web site. From the hardware point of view, the gateway has to connect to the EMS Centralita, to the CANbus, to the TApS bus and to a modem. Then, a software is needed able to do different functions: · gateway from the modem to the RS232 control port of the EMS Centralita<br/><br/><br/>·<br/><br/>gateway from the modem to the resident data of the system<br/><br/>A GSM/GPRS modem was chosen and a special program was developed. This program is able to be remotely configured for talking 'in transparent mode' with the RS232 port of the EMS Centralita or for getting data from the communication lines. Choosing the right function, a remote operator could `talk' directly with the EMS Centralita or get data. No special configuration software was developed for the EMS Centralita configuration function, as this software exits and could be easily remapped for talking through the Internet. On the other side, a special software able to get data from the system and publishing data to the web was developed. To achieve this result a classic client-server architecture was implemented, were the Internet gateway installed inside the EMS Centralita is configured as a network data server. It is very important to remember that the EMS Centalita could not be on line at every time. This means that the server present inside the Internet gateway could not be a web server. So, a master web server, always on line has to be installed in some other place of the world.<br/><br/><br/>Conclusions<br/>The development of hardware devices and software functionalities give the EMS Centralita the possibility to communicate with both field devices and with the Internet network. This solution is very powerful for it permits remote data acquisition, diagnostic and configuration of the complete energy system. Two advantages of this architecture are remarkable: · · the EMS Centralita could control a very big area of Power Devices the EMS Centralita could be configured or analyzed from a remote place<br/><br/>In terms of costs, this means more capability of optimizing Energy Flows and keep under control the complete Energy System. A lot of savings are permitted with this architectures: · · · · Reduction of the energy waste Optimization based on data acquisition Reduction of on-site technical intervention Continuous reconfiguration and optimization of process<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