Using Open Hardware in a Harsh Environment: A Case Study Rodrigo Santos∗1 , Leo Ordinez†2 Gabriel Eggly∗3 ∗ Dep.
de Ing. Eléctrica y Computadoras, Instituto de Inv. en Ingeniería Eléctrica, UNS-CONICET, Av. Alem 1253, 8000 Bahia Blanca, Argentina 1
† Laboratorio
[email protected] 3
[email protected]
de Investigación en Informática (LINVI), Departamento de Informática, UNPSJB, Bvd Brown 3050, 9120, Puerto Madryn, Chubut, Argentina 2
[email protected]
Resumen—This paper reports the experience of implementing a data logger for a diesel-electric locomotive using open hardware and software. The proposed system was designed for one of the main railway companies in Argentina under the requirement from the Government office for transport control security. Resumen— En este trabajo se reporta la experiencia de la implementación de un registrador de datos para una locomotora diesel-eléctrica utilizando hardware y software abierto. El sistema propuesto se diseñó para una de las principales compañías ferroviarias en Argentina bajo el requisito de la Oficina del Gobierno para la seguridad de control del transporte. Index Terms—Embedded Systems, Locomotives, OTMR, open hardware.
I.
I NTRODUCTION
The National Transport Control Secretary in Argentina obliges to railway companies to implement On-Train Monitoring Recorders (OTMR). The function of the OTMR is similar to the flight data recorder found on aircraft. The new regulations came out after some severe incidents in which people died, the most relevant occurred on February 22nd, 2012. The purpose of the OTMR is to save all the relevant data about the functioning of the train. In case of an incident, these data can be analyzed for assigning responsibilities. During the decade of 1990, the railway system in Argentina was privatized. Several railway companies took charge basically of the commodities transportation and, in the metropolitan region, of passengers transportation; virtually stopping the transport of people outside that area. Commodities transport (mainly crop) is done with diesel trains. Diesel locomotives are rather old with very low automation systems for their control. In the last years, companies have refurnished the locomotives and are now controlled with a PLC. The diesel engine impulses a DC generator that provides the energy to a DC engine to impulse the locomotive. One of the main railway companies came to the University requiring the design and implementation of the OTMR. In this case, the function of the OTMR is to record all the data produced by the PLC.
The OTMR can be classified as a small embedded system. Based on a simple micro-controller, it has to handle essentially two serial ports one for receiving data and the other for retrieving it when necessary. However there are several constraints and non-functional requirements that should be considered in the modeling and design stages for a successful implementation of the system. Data is produced every second by the PLC and transmitted over an RS-485 serial port without hardware traffic control. Each packet has to be time-stamped and has to be saved for a month in a file so it can be recovered if necessary. This represents over 240 MB of information to be stored. The dc generator and engine produce a very important amount of electromagnetic interference (EMI) that has to be considered in the electronic design of the system. The locomotive is also subject to considerable mechanic vibrations and exposed to extreme temperatures while traversing the countryside. The system should be protected from vandalism in a special box. The main contribution of this paper has to do with reporting the experience the design and implementation of OTMR, following the open source paradigm. Particularly, the core of the embedded hardware is based on an Arduino Leonardo board [1], which was supplied with electrical protections, mass storage, date/time circuitry and isolated communications interfaces. For the embedded software, some libraries provided by Arduino and Teensy [6] were used, whilst others were implemented from scratch. Finally, a desktop application for interacting with the embedded system was built. In this case, Processing [5] environment was chosen. The rest of the paper is organized in the following way. Section II describes the environment in which the OTMR has to work. Section III indicates the system requirements demand by the application. Section IV provides a technical description of the main hardware and software components and the way they interact. In Section V a short discussion on some issues found during the development is provided and finally in Section VI conclusions are drawn. II.
T HE E NVIRONMENT
Locomotives are very difficult environments for electronic devices. The diesel engine actually powers a DC generator
that produces the necessary electrical power to drive the DC motor. The DC motor armature has a set of coils that terminate in plates. DC current flows through brushes in contact with the plates producing an electromagnetic field. The rotor pole tries to align to the stator pole but, when achieving that, the current flowing in the armature coils is reversed because the brushes are in contact with different plates after the armature revolves. In this way the motor shaft keeps moving. The rotation speed and direction are proportional to the voltage applied and polarity respectively. As the rotor revolves the brushes short-circuit two consecutive plates in the commutator wasting energy and producing electrical arcs. Diesel-Electric locomotives have power between 4,500 and 6,700 horsepower that represent between 3,352 and 5,000 KW. The electrical power involve is rather important and the amount of electromagnetic interference produce by the commutators of both DC machines is really important. While traversing the countryside locomotives are exposed to extreme temperatures. They may encounter both very high (over 40 o C) and very low temperatures (under -10o C). Another important aspect is that locomotives are subject to very strong vibrations. In fact the suspension mechanism of the locomotive is almost null. An embedded system design to work in this environment should be prepared to support all these conditions. In the design process, the cancellation of electrical noise is mandatory as the system may work in a random way if not properly eliminated. Mechanical vibrations should be eliminated by a very rigorous soldering of every piece in the board but also by the incorporation of dielectric glue to hold them in place and avoid the vibration. Finally all the system should be closed up in a Faraday cage. III.
S YSTEM R EQUIREMENTS
The system proposed should record every second a frame containing the state variables of the locomotive. The variables are received through a RS-485 communication interface from the controlling PLC. The frame has a length of 81 bytes plus a checksum. Before saving the frame in persistent memory, a time stamp should be incorporated. The whole record has 97 bytes. At any moment, the previous 30 days should be available in the log file. The system should also record any unusual situation in another file again with a time stamp. The events that should be recorded are: whenever the system is reset (re-start is considered a reset), low power-source voltage, wrong frame (invalid number of bytes or bad checksum), low battery in the real-time clock subsystem and watchdog timer out (program flow fault). All these unusual situations are reported in real-time by turning off a witness diode that points out the problem. Also, this signal is sent through the GPRS radio system from the locomotive to the command operation center of the rail-company. The system should provide a unique interface for downloading the log and the events files. This interface should be able to read complete or partially the files and in no way the internal memory should be visible as such from the outside.
This requirement is very important as the data recorded in the memory may be used as legal proofs in case of an incident and thus it should be preserved even in the case of vandalism. It is for this reason, that the OTMR should be shielded in a box specially prepared to support physical damage. The electronics inside should be protected against high voltages and currents by opto-couplers and fuses. The system should count with a desktop software with a very simple interface that communicates with the OTMR through an USB port conveniently protected. The software should count with four basic commands: date and clock set-up, download full or partial log record, download full or partial events record, re-start the OTMR. In Figure 1 a Use Case diagram of the main components of the system is presented. Note that Actors are not taken as users, but as roles played by the system. In the same way, Usecases are considered functionalities required or provided through Actors to the System. IV.
S YSTEM D ESIGN
In this section the main issues for the design of the OTMR are presented and discussed. As it has been mentioned in the previous sections, the system should operate in a harsh environment so there are certain electronic and electrical aspects that should be considered carefully. The whole system has three main components. The PLC and the communication interface (this is not part of the purpose of this paper as it is provided by the railway company), the OTMR data logger with its software, and the serial interface with a personal computer and its software. IV-A.
OTMR Logger
For the design of the logger it was chosen the increasingly used paradigm of open hardware. This approach is the continuation of the components out of the shelf (COTS) paradigm. Basically, a rather generic hardware platform with an open design (schematic and Printed Circuit Board, files) is customized for a particular objective. In the case of this work, the Arduino open hardware platform was selected because it counts with a large developing community, several associated devices like memory modules, communication interfaces (ZigBee, Bluetooth, etc), LCD displays among many others. The system should have as less components as possible to reduce the sources of possible failures. After comparing different possibilities the Arduino Leonardo platform was selected. It is based on the micro-controller Atmel ATMEGA32U4 [2]. With 32 kB Flash memory for the program, 2 kB static RAM and 256 bytes of EEPROM for persistent variables. The micro-controller counts with a native USB port, RS232 type port and SPI and I2C interfaces. When selecting possible platform alternatives the criteria involved in the tradeoffs were: availability in local market, community support, suitability of communication interfaces and maturity of design. The RS-485 interface was adapted to the RS-232 port of the Arduino with the corresponding logical drivers MAX1480 [3], which is also opto-coupled internally. The record memory
Figura 1. OTMR Use Case Diagram
was implemented with an SD memory card for industrial applications. It was connected to the micro-controller through an SPI interface. The real-time clock (RTC) was implemented with the DS1307 [4] connected trough an I2C interface. A back-up battery circuit was designed to keep the RTC alive while the locomotive is turn off and consequently the system not powered. The RTC circuit is critical as it is in charged of keeping the time stamp updated. For this reason, the battery supply circuit is checked with an analog comparator provided in the ATMEGA32U4 micro-controller. If the battery voltage is below a certain threshold an alarm is set and the event is recorded in the events log file. The micro-controller also counts with a Burn-Out protection. If the source voltage is reduced from a certain level, the system generates an alarm, stores it in the event log file and puts the system in a stand-by state. As soon as the source voltage recovers the proper level the system returns to work. The software is also protected with a Watch-Dog timer. This protection is oriented to prevent badfunctioning of the software. If for some reason at any point the watch dog timer is not reset, an alarm is generated, the event is saved in the events log file and the system is reset. Figure 2 shows circuit board implemented. In the top view, they can be distinguished the aforementioned modules: (A) is the SD card module, (B) is the RS-485 module, (C) is the power supply module, (D) is the output module and (E) is the RTC module. On the other hand, the bottom view figure shows the Arduino Leonardo board connected to the shield made.
Figura 2. OTMR Circuit Board
(a) Top view
(b) Bottom view
The software has two operating modes. In the first one the system is recording the data received from the PLC through the RS-485 interface. In the second mode, the system is in communication with the personal computer and is not logging data. Both modes share the same initialization phase. In the programming scheme of Arduino, this phase is identified by the subroutine void setup(). During it, the drivers for the different I/O interfaces are loaded and set-up. After that, an infinite loop begins. Following the Arduino jargon again,
this stage is determined by the subroutine void loop(). In it, the micro-controller checks for activity on both communication ports: RS-485 and USB. If there is activity in the USB port, the system gets into the communication with personal computer mode. In this case, it checks for a set of commands: reset (obviously this means a reboot of the system); date/hour set up, for updating the RTC registers;
data retrieval, it can be the total information registered in the system up to that time or a specific interval; and finally events retrieval. If after one minute in this mode, there is no further commands from the USB ports, the system is automatically reset to restart registering data. The default mode of operation is registering data. In this mode, the system listens to the RS485 communication port. When the first character is received, it keeps storing the successive characters. Once the 82 bytes of the frame have been received, it computes the checksum and verifies it. If the frame is correct, a time stamp is generated from the RTC clock and the whole frame is stored in the SD memory. The file should contain the last 30 days of activity. To implement this, two files are used alternatively. With this simple mechanism, in the last instant, there are two files with almost 60 days of activity. Figure 3 shows a statechart of the general functioning of the system.
Figura 3. OTMR General Description
IV-B.
Personal Computer Software
Data record in the OTMR may eventually be retrieved by a personal computer. To do this, a very simple application was developed in JAVA using the Processing 3.0 IDE. This is a very simple programming environment that eases the building of a self-contained JAVA application and its run-time machine. The software provides the following commands. Date/Hour Set Up: This command programs the RTC in the logger. Data input has the following format: yyyy.mm.dd.hh.mm.ss Data Download. In this case an interval of time can be indicated following the same data structure of the previous command for the initial and final date, or the whole record may be downloaded. As the transfer ratio is close to 1Mb/s, for a complete record, about 70
minutes are needed. This is so because the SD card communication with the Arduino was implemented by and SPI protocol variant, since SD protocol is proprietary. Events Download. It is similar to the previous case but the whole file is downloaded to the PC, as the number of recorded events is substantially lower than the amount of data. Reset. This command is trivial and restarts the logger. V. D ISCUSSION The system was designed following both open software and hardware paradigms. In the implementation phase, several problems arise that have been solved with a dedicated customization. In this section they will be discussed. In the first place, it is worth noting that the Arduino model of stackable shields, for providing additional features, was followed. The design was based on Arduino, but a shield was built on top of it to fulfill the requirements of the OTMR, specially those regarding the harsh environment in which it will be deployed. The electrical protection of the OTMR was one of the main hardware requirements. The system should provide electrical insulation in such a way that even in case of high over voltages applied to the different parts of the circuit the memory holding the data recorded is preserved. For this reason several stages with optical couplers were used. In this way the external power source was conditioned with a switching DC-DC power adapter. All the communication interfaces (SPI, I2C, RS-485) used opto-couplers. Although the ATMEGA32U4 has quite a large program memory available, it was found that it was near the required limit for the developed software. One of the reasons for this was that the boot-loader used by the Arduino platform is generic for all the micro-controllers and provides several services that sometimes are not used. In addition, it was noticed that the access to the SD memory using the Arduino provided library was slow. Based on these two facts, the Arduino Leonardo platform was kept but the boot-loader was changed for the Teensy version and the libraries were modified for optimizing both speed and space. With this two modifications, the ATMEGA32U4 worked perfectly for the OTMR purposes. Last but not least, it is important to make a note about the development cost. The bill of materials of the OTMR implemented was around U$S 100. This was obvious advantage of the chosen hardware. VI. C ONCLUSION In this paper, the design and implementation of an OTMR based on the open software and hardware paradigms was presented. Although the system should work in a very harsh environment as it is the diesel-electric locomotive, the use of open hardware elements show that conveniently customized they can work properly even under the hardest conditions. ACKNOWLEDGMENT The authors would like to thank FerroExpreso
R EFERENCIAS [1] Arduino leonardo. [Online]. Available: https://www.arduino.cc/en/Main/ArduinoBoardLeonardo [2] ATMEL, ATmega16U4/ATmega32U4 Datasheet. [Online]. Available: http://www.atmel.com/images/atmel77668bitavratmega16u432u4_datasheet.pdf [3] Maxim, Complete, Isolated RS485/RS422 Data Interface. [Online]. Available: https://datasheets.maximintegrated.com/en/ds/MAX1480AMAX1490B.pdf
[4] ——. Ds1307 64 x 8, serial, i2c real-time clock. [Online]. Available: https://www.maximintegrated.com/en/products/digital/realtimeclocks/DS1307.html [5] B. Fry and C. Reas. https://processing.org/
Processing
[6] Teensy usb development https://www.pjrc.com/teensy/
board.
3.0.
[Online].
[Online].
Available:
Available:
