Services

A telecommunications framework for real-time monitoring of dangerous goods transport

Description
A telecommunications framework for real-time monitoring of dangerous goods transport
Categories
Published
of 7
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
Share
Transcript
  See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/224108371 A telecommunications framework for real-timemonitoring of dangerous goods transport Conference Paper  · November 2009 DOI: 10.1109/ITST.2009.5399390 · Source: IEEE Xplore CITATIONS 10 READS 64 4 authors , including:Fabio ValentePolitecnico di Bari 3   PUBLICATIONS   12   CITATIONS   SEE PROFILE Giammarco ZacheoForschungszentrum Telekommunikation Wien 10   PUBLICATIONS   39   CITATIONS   SEE PROFILE Pietro CamardaPolitecnico di Bari 161   PUBLICATIONS   1,494   CITATIONS   SEE PROFILE All content following this page was uploaded by Giammarco Zacheo on 07 August 2014. The user has requested enhancement of the downloaded file. All in-text references underlined in blue are added to the srcinal documentand are linked to publications on ResearchGate, letting you access and read them immediately.  A Telecommunications Framework for Real-TimeMonitoring of Dangerous Goods Transport Fabio Valente ∗ , Giammarco Zacheo ∗ , Pierfrancesco Losito † and Pietro Camarda ∗∗ Dipartimento di Elettrotecnica ed ElettronicaPolitecnico di Bari - 70125, Bari, Italy † Microlaben S.r.l., Via Orabona, 470125, Bari, ItalyEmail: valente@deemail.poliba.it, g.zacheo@poliba.it, p.losito@microlaben.com, camarda@poliba.it  Abstract   —Monitoring and tracking of    eets can represent agreat improvement in security and safety when transportinghazardous goods by road. In this paper we propose a completemonitoring and tracking solution for truck    eets, which is ableto check at the same time the position and the mechanicalstatus of the vehicle, as well as the conditions in the cargobay. The system exploits battery-powered environmental sensors(temperature, humidity, pressure, gas concentration and ionisingradiation levels), connected by a ZigBee-based Wireless SensorNetwork. This approach guarantees   exibility, ease of deploymentand low power consumption. Collected data is then sent from thevehicle to a remote server via a GPRS link. The GPS positioningsystem is integrated by the use of an Inertial Navigation System,which guarantees a precise estimate of the position also when theGPS signal is weak or temporarily lost. The proposed solutionhas been deployed in a real environment, and some performanceevaluation tests have been carried out.  Index Terms  —Wireless Sensor Networks, Vehicle monitoring,Kalman   ltering, Sensor Fusion, Inertial Navigation Systems,Real-time monitoring, Power Magement in WSNs. I. I  NTRODUCTION When dangerous goods, such as   ammable liquids, ra-dioactive material or chemical waste are transported by road,safety and security are matters of fundamental importance. Themonitoring of vehicles is highly recommended to avoid safetythreats to drivers and other vehicles during the transport. Real-time monitoring of relevant parameters inside the cargo bay(i.e. temperature, gas concentration, ionising radiation level) isrecommended in order to detect and prevent even more danger-ous situations due to the nature of the transported load. On theother hand, vehicle tracking via satellite positioning systems(such as GPS) can also be useful, for instance when traf   c jamsor adverse weather conditions could create potential safetythreats. More, the information provided by inertial sensors can be conveniently exploited to integrate and re  ne the positioninformation coming from a GPS unit and to monitor themechanical status of the vehicle. All these features can be usedto build a complete monitoring and tracking system for trucksand vans carrying hazardous goods. The monitoring systemmust also have peculiar features related to its   exibility andreliability. The units composing the system, indeed, must belocated in different parts of the truck; wireless network and battery-powered components have to be used to avoid issuesrelated to cabling. A suitable choice of the communicationinfrastructure and strategy is required to improve the system  exibility along with the possibility of self-con  guration of the system, keeping in mind the main issue related to limited power consumption.The ZigBee standard [1], which is in turn based on theIEEE 802.15.4 standard [2], has been designed to be used inseveral application environments, such as home and industrialautomation, environmental monitoring, support for healthcaredevices and so on. It offers a complete network architecture for Wireless Sensors Networks. Its design is focused on low datarate and low power consumption, to guarantee maximum lifetime for battery-operated devices. The use of battery-poweredwireless nodes makes possible to easily deploy the sensor unitswithin the cargo bay, without any modi  cations of the vehicleitself.The General Packet Radio Service (GPRS) uses the existingGSM network to transmit and receive TCP/IP based data toand from GPRS mobile devices [3]. It provides almost ubiq-uitous access to the Internet. Hence, it could be successfullyexploited to send information about the vehicle to a remoteserver in real-time.The use of Kalman   ltering to achieve data fusion betweenGPS and inertial sensors has already been thoroughly inves-tigated in the existing literature, as in [4] and [5]. Moreover, the approach of monitoring both the position and the environ-mental parameters has been already validated by other research projects, such as the Tr@in-MD project, funded by the SNCF(Soci´et´e Nationale des Chemins de fer Franc¸ais), aimed atmonitoring the transport of hazarous good by railway [6].In this paper we propose the prototype of a complete moni-toring system for truck    eets; it consists of several sensors for environmental monitoring connected to a central processingunit by means of a ZigBee Wireless Sensor Network. Thenavigation unit, which exploits both a GPS receiver and anInertial Navigation System (INS), is integrated as a node of the ZigBee network. Finally, a GPRS link is able to guaranteealmost ubiquitous radio coverage, thus establishing a reliablecommunication channel towards a remote server. A prototypeof the system has been deployed on a test vehicle; some of the obtained results are presented in this article. 978-1-4244-5347-4/09/$26.00 ©2009 IEEE 13  The paper is organized as follows: an overview of thesystem from a hardware point of view is presented in SectionII; each device is described in a different subsection. Thecommunication protocol is then explained in Section III,discussing both the communication within the ZigBee network and across the Internet. Section IV describes some of theexperimental results we have obtained and,   nally, Section Vsketches some conclusions and future developments.II. S YSTEM  O VERVIEW The system is made of several devices belonging to threedifferent types, namely: one Central Node (CN), one or moreSensor Nodes (SN) and one Inertial Navigation System Node(INSN). These devices communicate with each other by meansof wireless ZigBee links. A fourth element, named DataCollection Module (DCM), is a software module hosted ona remote machine which communicates with the CN via theGPRS data link. A simple overview of the whole system issketched in Fig. 1. ZigBee network  GPS Signal Internet (GPRS) Central NodeData Collection Module CN DCM Sensor NodeInertial Navigation System Node INSN SN Fig. 1. Architectural Overview of the System. The CN acts also as ZigBee Coordinator (ZC) of the localnetwork. The SN and the INSN have been con  gured as Zig-Bee End Devices (ZED), with limited capabilities. This featurelimits the current implementation to a single-hop wirelessnetwork. Although a star topology may appear more suitablefor our approach, the ZigBee network has been con  gured asa mesh network, which allows to exploit multi-hop routingtechniques to improve the range of the ZigBee network (i.e.,transport using road trains) in future developments.  A. Central Node (CN) The CN is made of several custom hardware componentsembedded in a single device. The main unit is a MicrochipPIC24 Microcontroller [7], which manages the connected peripherals and stores the data on a Secure Digital massstorage device. The main unit is also able to process thedata coming from the sensors and to communicate potentialdangerous situations to the central server. The CN connects toseveral devices by means of different interfaces, namely: •  ZigBee Interface : the ZigBee interface is a Texas In-struments CC2430 System on Chip [8]. It incorporates both a transceiver and an 8-bit microcontroller, the latter implementing the ZigBee stack. As already stated, the CNacts as the only ZigBee Coordinator (ZC) of the network. •  GPRS and GPS Unit : The GPRS and GPS Unit is aTelit GM862-GPS Module [9]. The GPRS interface isused to connect to the remote machine hosting the DCM.The Inertial Navigation System exploits the longitude,latitude, altitude information and the parameters relatedto the GPS signal quality and strength. •  Bluetooth Interface : the CN features a Bluetooth adapter that can be used to send information coming from the SNsand the INSN to the driver via a mobile device, such asa PDA. •  Ethernet Interface : The CN con  guration can be mod-i  ed locally with a simple web interface accessiblethrough an Ethernet connector. The web interface makes possible to set the main con  guration parameters of thesystem, such as the IP address of the DCM, and the sensor  parameters (i.e. threshold values). It is also possible tomonitor the associated nodes and the GPS/INS.The block diagram of the CN is depicted in Fig. 2.  B. Sensor Node (SN) The SNs are simpler devices with respect to the CNs. TheSNs are battery powered and small sized, and can commu-nicate with the CN by means of the ZigBee Network. Thus,they can be deployed in different places within the cargo bay,hence allowing thorough and   exible monitoring capabilities.To improve battery life, power consumption has been limited,trying to achieve maximum ef   ciency while retaining all thefeatures of the devices. For this purpose, a dedicated operatingmode has been implemented: the devices are programmed toremain in a Power Down state until the execution of their speci  c functionalities requires them to be activated. In Power Down state the sensors and the transmitter are switched off,while the microcontrollers are put in sleep mode, thus only preserving data in the internal memory and providing timer functionalities. Also, the power saving features of the Zigbee Mi c ro c ontro ll er U nitGPS  / GPRS U nitB l uetoot hU nit E t h ernetInter f  a c eZigBeeInter f  a c e UA R  T (GPRS) UA R  T SPII 2 CI 2 C   (GPS)  T o  L o c a l Network    (SN , INSN)  T o   t h e   Internet   (DCM) Fig. 2. Central Node Block Function Diagram. 14  End Devices are fully exploited: the ZigBee Coordinator caches packets to be sent to the End Devices and sends themonly upon an explicit request by the ZED. This is done ona regular basis by the End Device; the period between twoconsecutive transmissions is de  ned ZigBee Polling Periodand has been set to 1 second (though this parameter can befreely con  gured). This guarantees an effective compromise between power saving and a prompt response of the devicesin receiving data.The Sensor Node supports several types of sensors, such as: •  Temperature and humidity sensors:  To monitor temper-ature and humidity, the Sensirion SHT75 [10] has beenintegrated into the systems. Both sensors are integratedonto the same circuit and coupled to 14bit ADCs, with avery low power consumption (3mW during operation, 5uW in sleep mode). •  Air pressure sensors:  The Freescale MPX4115A [11] isan absolute air pressure sensor. This integrates on-chip, bipolar op amp circuitry and thin   lm resistor networks to provide a high level analog output signal and temperaturecompensation. Also in this case, key characteristics of such device are small size and low power consumption(35 mW during operation). •  Gas detection sensors:  Every Peripheral Node can ac-commodate one or more Silsens MSGS 3000 miniaturizedsemiconductor gas (CO, C 6 H 6 , CH 4 ) sensor [12]. Thesesensors provide a good balance between power consump-tion and measurement accuracy thanks to a platinumresistive heater driven by a high precision DAC. Their  power consumption ranges between 2.5 mW to 39.5 mWfor the CO an CH 4  sensors, and 33.6 mW for the C 6 H 6 sensor. •  Ionising radiation sensors:  The Black Cat SystemGM10 [13] is a ionising radiation sensor based on aGeiger-M¨uller tube, sensitive to the radiations produced by radioactive decays. It is able to detect alpha, beta andgamma particles. The average consumption for the sensor is 36 mW during operation.Each set of sensors   tted on a SN comes with a EEPROMcontaining the con  guration information (i.e., number andtype of sensors, calibration tables for sensors with nonlinear output), which allows a seamless recon  guration for operationwith different sets of sensors, without the need of reprogram-ming the   rmware on the Processing Unit. C. Inertial Navigation System Node (INSN) The Inertial Navigation System Node (INSN) provides the position of the truck to the Central Node. It performs sensor fusion between the data coming from the inertial and headingsensors and the GPS system by means of a tightly coupledExtended Kalman Filter (EKF). With this approach, the pre-cision in position tracking can be improved with respect toGPS-only based systems, also giving the possibility to estimatethe position of the truck in presence of short GPS coveragefailures (i.e., when driving through tunnels or in presence of tall buildings). Pro c essingSu b systemInertia l Su b system UA R  TF rom  /T o   CN UA R  T Communi c ationSu b system Fig. 3. Inertial Navigation System Node Block Function Diagram. Finally, the data coming from the accelerometers and gy-roscopes are used to detect anomalous vibrations and me-chanichal shocks that can be symptoms of structural damageof the vehicle. The INSN is a more complex device thanthe SN, as the GPS/INS integration function requires moreCPU processing power. The GPS receiver is actually hostedon the CN rather than on the INSN itself; this choice has been dictated by the need of positioning the INSN close tothe vehicle center of mass, which could result in problems for the GPS antenna. The processing unit of the INSN is a MIPS4Kc-based System-on-a-Chip clocked at 180Mhz [14]. Thesensors provide acceleration, inclination and heading data tothe processing system; the INSN features an Analog DevicesADIS16355 triaxial gyroscope/accelerometer [15] and a Hon-eywell HMC5843 magnetic compass [16]. Data are collected by the sensors at a 100 Hz sampling rate and compared tothe GPS samples, received at 1 second time-interval each, toestimate the position of the vehicle. The logical block of theINSN are depicted in Fig. 3.  D. Data Collection Module (DCM) The Data Collection Module is a software running on aremote machine connected to the Central Node via a GPRSInternet Connection. It gathers data coming from several CNs,sends it to a central server and dispatches to the CNs themessages generated by the server (i.e. when a change in theitinerary is required or when a potentially dangerous situationoccurs). The DCM can output the processed data in severalformats, and it can be run both as a standalone applicationor as a set of application libraries. It is made of two maincomponents, a multithreaded server and the translation unit,and is able to manage multiple connections towards CNs atonce.When used as a standalone application, it can output data inJSON or XML formats to a local or remote Data Base Man-agement System (DBMS) application. On the other hand it can be used as a building block of more complex applications, pro-viding a rich and   exible Application Programming Interface(API), creating an abstraction layer for data formatting andinterfacing to a Database Management System (DBMS). Toguarantee maximum portability, the DCM has been written inPython [17], a powerful general-purpose interpreted languageavailable on many computing platforms. The DCM has beenintegrated into a remote web service able to monitor multipletruck    eets at once. Currently, three vehicles with two SN eachare used for testing purposes. A screenshot of the web serviceis depicted in Fig. 4. 15  Fig. 4. Web service integrating the DCM. III. C OMMUNICATION  P ROTOCOLS  A. Communication over the ZigBee network  The devices which communicate over the ZigBee network use small datagrams exchanged at the application layer of theZigBee stack. Two different packet formats are used, one for the messages sent by the Sensor Nodes (including the Inertial Navigation System Node), the other for the messages sent bythe Central Node. The packet format is described in Fig. 5.Each packet starts with a  Length   eld (1 byte), which indicatesthe size of the payload, while the  Type  (1 byte)   eld identi  esthe packet type. The  NodeID  (2 bytes) is a unique identi  er for each SN, and the  Payload    eld, whose size depends on the packet type, contains the actual data being sent. The INSN usesa reserved Node ID. The CN can send frames both in unicastand broadcast, while the SNs can only send unicast frames tothe CN. L engt h Node ID TypePayload L engt h  TypePayloada) f  rom Sensor Nodes to Central Node b ) f  rom Central Node to Sensor Nodes Fig. 5. Packet format used within the ZigBee network. When starting up, the SN nodes, con  gured as ZigBee EndDevices (ZED), try to associate to the CN, which is the ZigBeeCoordinator (ZC) of the network. When the wireless link isestablished at network level, each SN announces itself to theCN by means of a Sensor Announcement packet (the  Type   eldis set to  0x01 ). The payload contains information about thenumber of sensors installed in the SN and their con  guration parameters. The CN adds the SN to its association table andacknowledges the reception of this packet sending a Set Rate(type  0x15 ), which sets the rate of data transmission on theSN. This startup phase lasts 5 seconds, then the CN sends anAnnouncement packet to the DCM, as explained later. A SN isallowed to associate to an established network at any time. TheAnnouncement packet is also sent by the CN when a new SNassociates or when a SN deassociates from the network. Thus,the state of the network is automatically updated at runtime.After receiving the Set Rate packet, the SN starts sendingdata sampled from its sensor periodically, using a Data Sensor  packet (type  0x03 ) directed to the CN. The CN can modifythe rate of transmission during operation, sending a new SetRate packet, both in unicast or in broadcast.The CN node can also send a Sensor Announcement Re-quest (type  0x05 ) if the Sensor Announcement has been lostor if it receives data from a SN which is not included into itsassociation table. Finally, the Sensor can send a Battery Low packet (type  0x02 ) when the level of the batteries fall belowa certain threshold.  B. Communication over the Internet  The communication protocol between the Central Node andData Collection Module has been carefully designed takinginto account the characteristics and the limitations of thecommunication network. The GPRS offers almost ubiquitouscoverage, but the data rate is rather low (theoretically up to 114kbit/s, but highly dependent on channel conditions) [3] withhighly variable transmission delays. Moreover, many mobile phone operators offer tariffs based on traf   c volume. Hence,it is important to remove redundancy and compress the datain order to reduce billing costs and to increase reliability andresponsiveness. We have chosen to use a simple compressionmechanisms, with almost zero overhead on the CN and theDCM to encode and decode the information; the details areexplained later in this section. SoPTruck IDPayload L engt h Payload(optional)a) f  rom Central Node to Data Collection Module (Data Connection) b ) f  rom Data Collection Module to Central Node (Control Connection)RSSITimestampTypeString ID Fig. 6. Packet format used on the GPRS channel. The DCM listens for incoming connections from the CNs.During the initialization phase, the CN connects to the GPRSnetwork and contacts the DCM. When the DCM answers, two bidirectional communication TCP sockets are opened for eachconnected CN, one for the data packets and one for the controlmessages. The former is used to deliver information from theCN to the DCM about the state of the system (sensor values,vehicle position, data coming from the inertial subsystem),while the latter is used to interrogate and to send con  guration parameters to the CN. When the connection is established, theDCM acts as a bridge between the CN and a remote server or a custom user interface. The packet format is described in Fig.6. After both communication channels have been established,the CN sends an Announcement Packet (type  0x01 ) messageto the DCM. This message contains detailed information aboutthe number of SNs associated to the CN, and also the type and 16
Search
Similar documents
View more...
Tags
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks