FIRE - Final Report

iFIRE FINAL REPORT FOR PUBLICATION

)LQDO�5HSRUW�IRU�3XEOLFDWLRQ

),5(&RQWUDFW�1R�5$��6&��

3URMHFW�&RRUGLQDWRU��)6

3DUWQHUV��'%

��g%%

��0$5&21,

��6(0$

��7,07(&

��$/&$7(/

��$7*

��55(

��6$,0$

��,//

3URMHFW�'XUDWLRQ�

��WR��

'DWH��

��352-(&7�)81'('�%<�7+(�(8523($1

��&200,66,21�81'(5�7+(�75$163257

��57'�352*5$00(�2)�7+(

��WK�)5$0(:25.�352*5$00(

iFIRE FINAL REPORT FOR PUBLICATION

&217(176

�� 3$571(56+,3 ��

�� (;(&87,9(�6800$5<��

�� 2%-(&7,9(6�2)�7+(�352-(&7��

3.1 THE SCENARIO ........................................................................................... 1

3.2 FIRE’S OBJECTIVES.................................................................................... 2

�� 0($16�86('�72�$&+,(9(�7+(�2%-(&7,9(6 ��

4.1 ASSESSING THE INFORMATION NEEDS........................................................... 3

4.2 CHOOSING NEW TECHNOLOGIES .................................................................. 64.2.1 GPS (Global Positioning System) ................................................. 64.2.2 GSM (Global System for Mobile communications) ....................... 64.2.3 Internet.......................................................................................... 6

�� 6&,(17,),&�$1'�7(&+1,&$/�'(6&5,37,21�2)�7+(�352-(&7 ��

5.1 INFORMATION FLOWS.................................................................................. 75.1.1 Information Sources...................................................................... 95.1.2 Information Processing ................................................................. 95.1.3 Information Delivery ...................................................................... 9

5.2 USER ACCESS............................................................................................ 10

5.3 DATA COLLECTION...................................................................................... 105.3.1 Manual Data Entry ........................................................................ 105.3.2 GPS/GSM Data............................................................................. 105.3.3 SBB’s AVI and Other AVI services................................................ 105.3.4 Hermes ......................................................................................... 10

5.4 DATA OUTPUT (INTERNET BASED ENQUIRIES)............................................... 11

5.5 FIRE AS A PRODUCT .................................................................................. 11

5.6 QUALITY CRITERIA ...................................................................................... 11

5.7 WEB SERVER ACCESS................................................................................ 12

5.8 USER FACILITIES ........................................................................................ 135.8.1 End Customer Facilities ................................................................ 146SHFLILF�:DJRQ ........................................................................................ 14:DJRQ�7UDFH ........................................................................................... 15&RQVLJQPHQW�7UDFH.................................................................................. 152XWVWDQGLQJ�&RQVLJQPHQWV...................................................................... 155.8.2 OBT Manufacturers Facilities........................................................ 17/DVW��9DOLG�5HSRUWV�IRU�D�9HKLFOH.......................................................... 17

iiFIRE FINAL REPORT FOR PUBLICATION

/DVW��5HMHFWHG�5HSRUWV�IRU�D�9HKLFOH.................................................... 17/DVW��5HSRUWV�IRU�D�9HKLFOH................................................................... 18:DJRQ�7UDFH ........................................................................................... 185.8.3 Cargo Companies Facilities .......................................................... 20&UHDWH�D�6FKHGXOH ................................................................................... 21&UHDWH�D�&RQVLJQPHQW ............................................................................. 26'HOHWH�D�6FKHGXOH.................................................................................... 33&DQFHO�D�&RQVLJQPHQW............................................................................. 338SGDWH�D�6FKHGXOH .................................................................................. 338SGDWH�D�&RQVLJQPHQWV�7UDLQ ................................................................. 335HPRYH�D�9HKLFOH�IURP�D�&RQVLJQPHQW................................................... 33/LVW�7UDLQ�6FKHGXOHV ................................................................................ 34/LVW�2XWVWDQGLQJ�&RQVLJQPHQWV ............................................................... 34/LVW�9HKLFOH�,QIRUPDWLRQ............................................................................ 34/LVW�7UDLQ�,QIRUPDWLRQ ............................................................................... 36/LVW�$OO�,QIRUPDWLRQ ................................................................................... 36:DJRQ�7UDFH ........................................................................................... 367UDLQ�7UDFH............................................................................................... 36&RQVLJQPHQW�7UDFH.................................................................................. 376KRZ�9HKLFOH�3RVLWLRQ�RQ�0DS ................................................................ 376KRZ�7UDLQ�3RVLWLRQ�RQ�0DS .................................................................... 376KRZ�&RQVLJQPHQW�3RVLWLRQ�RQ�0DS ....................................................... 37

5.9 MAP FUNCTIONALITY................................................................................... 38

5.10 ON BOARD TERMINAL ................................................................................. 405.10.1 Functional Requirements .............................................................. 405.10.2 Access Security............................................................................. 405.10.3 Environmental Requirements........................................................ 415.10.4 Power Requirements..................................................................... 415.10.5 Installation Requirements.............................................................. 41

5.11 OBT OPERATIONAL MODES, FUNCTIONS AND DATA STRUCTURES ................. 425.11.1 OBT Operations Modes ................................................................ 425.11.2 OBT Data Storage ........................................................................ 46

5.12 OBT DESIGN ............................................................................................. 475.12.1 Hardware components.................................................................. 475.12.2 Case.............................................................................................. 475.12.3 Internal Electronic Boards............................................................. 485.12.4 GSM Module & antenna................................................................ 485.12.5 Battery........................................................................................... 485.12.6 Energy Generation Module ........................................................... 485.12.7 Operational profile......................................................................... 49

5.13 INSTALLATION PROCEDURES........................................................................ 49

5.14 CONFIGURATION AND TESTING PROCEDURES ................................................ 49

5.15 OPERATIONS PROCEDURES ......................................................................... 50

5.16 MAINTENANCE PROCEDURES ....................................................................... 505.16.1 Battery replacement...................................................................... 50

iiiFIRE FINAL REPORT FOR PUBLICATION

5.16.2 OBT servicing................................................................................ 50

5.17 KTT’S OBT IMPLEMENTATION ..................................................................... 515.17.1 HW-Components .......................................................................... 515.17.2 Software........................................................................................ 535.17.3 Application .................................................................................... 57

5.18 MARCONI’S OBT IMPLEMENTATION .............................................................. 625.18.1 Hardware Architecture .................................................................. 625.18.2 OBT’s Technical Characteristics ................................................... 625.18.3 Software Architecture.................................................................... 635.18.4 OBT’s INSTALLATION ................................................................. 65

5.19 PILOT OPERATION SCENARIO ...................................................................... 695.19.1 Transportation Characteristics ...................................................... 705.19.2 Logistic.......................................................................................... 72

5.20 ASSESSMENT FORM.................................................................................... 72

5.21 FIRE ACCESS............................................................................................ 745.21.1 Technical Problems ...................................................................... 745.21.2 Usability ........................................................................................ 745.21.3 Availability ..................................................................................... 74

5.22 FIRE INFORMATION .................................................................................... 745.22.1 Presentation.................................................................................. 745.22.2 Usefulness .................................................................................... 745.22.3 Suggestions .................................................................................. 745.22.4 Security ......................................................................................... 75

�� &21&/86,216 ��

�� $11(;(6 ��

�� 5()(5(1&(6 ��

1FIRE FINAL REPORT FOR PUBLICATION

��3DUWQHUVKLS

),5( is an Europe-wide service aimed to deliver )reight ,nformationin the 5ailway (nvironment to Transport Service Providers (TSP) orLogistic Service Providers (LSP).

Partners in the project (which has been approved and funded by theEuropean Commission under the Transport RTD programme of the4th Framework Programme), are

5DLOZD\� &RPSDQLHV, such as: FS (Italy), DB (Germany), OeBB(Austria), SBB (Switzerland)

7UDQVSRUW� 6HUYLFH� 3URYLGHUV, such as: ATG (Germany), Roadrailer(Germany), SAIMA Avandero (Italy), ILL (Austria)

0DQXIDFWXULQJ� ,QGXVWULHV, such as: Marconi Communications (Italy),Krupp Timtec (Germany), SEMA Group (Great Britain), Alcatel(Austria)

�� ([HFXWLYH�VXPPDU\

The third chapter of this Final Report describes the objectives of theproject, giving details on the scenario wherein the project has beendeveloped .

The fourth chapter illustrates the means used to achieve theobjectives, highlighting the assessment of information needs, whichimplied a deep investigation on the matter among the partners.

The fifth chapter comprehends a detailed description of the project, interms of information flows, user facilities, On Board Terminal (OBT)requirements, and KTT’s OBT implementation as well as Marconi’sOBT implementation. A description of the Pilot Operation scenarioand the relevant assessment are also included.

The sixth chapter gathers the conclusions and the seventh chapterlists the publications, conferences, presentations related to theproject.

The eighth chapter gives some reference documents.

�� 2EMHFWLYHV�RI�WKH�SURMHFW

��7KH�VFHQDULR

Transportation in the European Union is a sector in expansion, with ademand for freight transportation services that has been growingsteadily during the last 20 years.

However, freight transportation has not been expanding evenly for allthe transportation modes. The market share for the road mode hasdoubled between 1970 and 1995, while rail has experienced a strong


decrease.

This decrease is in contrast with the prominent role that rail transportcould have, and should have, within the integrated vision set out inthe TEN (Trans-European Networks) concept defined at the EU level.In fact, the railway should act as an improved, customer-orientedbackbone network performing time-critical transportation tasks in co-ordination with other transportation modes (e.g. road, waterborne,etc.) in a door-to-door delivery service view.

In further detail, rail-based freight transportation is to be consideredas a fundamental component within the supply chain, as largevolumes of goods are to be delivered from one site to another,crossing international borders, in times which are to be compatiblewith the just-in-time and lean production concepts, and fulfilling thestringent logistic requirements of the industry. Thus, suitableperformances have to be provided by the railway transportationsystem, in order not to affect negatively the production flow.

In this scenario, a key concept in the confrontation between rail androad is information.

Today, one reason for which the parties carrying out pan-Europeanfreight transportation tasks (i.e. the transportation / logistic serviceproviders) use the road mode on a wide scale is that the roadenvironment makes available a large amount of information on tariffs,procedures, and on-going task data (e.g. freight current location,status, arrival forecast, etc.) to these parties.

On the contrary, rail transport does not provide an easy access pointto commercial and task-related information. It can be hard for thetransportation / logistic service providers to acquire a clear vision ofrail operators’ tariffs, service offers, and procedures; furthermore,information on current location and conditions of the freight beingtransported is not always available, as it cannot be easily retrievedfrom the owners of this kind of data, the rail network companies.

��),5(¶V�REMHFWLYHV

The FIRE (Freight Information in the Railway Environment) project isaimed at building up a prototype of an information service concerningrail-based international freight transportation. The service is designedto answer to the needs of the users of the European rail-based freighttransportation system: the Transportation / Logistic Service Providersusing the rail infrastructure - through the Rail Cargo Companies - fortransporting goods from one place to another throughout Europe.

The service is based on a FIRE Service Provider acquiring andconcentrating on a FIRE Information Gateway relevant data on freightwagons from a number of different data sources, including UICinternational applications, GPS/GSM equipment installed on boardfreight wagons, AVI equipment, the network computer systems and


other rail relevant computer systems. The information is madeavalaible to the Rail Cargo Companies’ CISs (FIRE CommercialInformation Servers). The CISs can be accessed in turn by authorisedTransportation/Logistic Service Providers (through FIRE AccessPoints) which can retrieve commercial data on the Rail CargoCompany’s offer (e.g. services, tariffs, procedures, etc.), as well asinformation about specific on-going, cross-border transportationtasks, both on a wagon and train basis.

The main actions performed within the project are:

1) To define a general FIRE architecture and function set

2) To define a subset architecture and functions to be implementedduring the FIRE project’s two-year timescale

3) To set up an on-field testing of a prototype information service(Pilot Service) based on the subset architecture and functions definedabove

�� 0HDQV�XVHG�WR�DFKLHYH�WKH�REMHFWLYHV

��$VVHVVLQJ�WKH�LQIRUPDWLRQ�QHHGV

FIRE is essentially a commercially-oriented project, analysing marketneeds and providing some kind of answer. Market needs oninformation are the main input to the whole project process.Information needs determine the largest part of the initial projectdecisions and the subsequent project evolutionary paths, with animpact propagating through the project and beyond.

Thus, the first logical, mandatory step to be performed is an effectiveneeds assessment phase: the project’s fundamental starting point.

The interviews carried out within the initial phase of the FIRE project -together with selected TSPs and RCCs - have lead to a number ofstrong statements that are summarised in this section.

75$163257$7,21�6(59,&(�3529,'(56

��6$,0$��$7*��52$'5$,/(5��,//�

7KH�ZRUOG�RI�WKH�7UDQVSRUWDWLRQ�6HUYLFH�3URYLGHUV operating withrail and intermodal schemes is made up by a number of companieswith different missions, strategies and operations.

6RPH�763V�FRXOG�VKLIW�SDUW�RI�WKHLU�DFWLYLWLHV�IURP�URDG�WR�UDLO, ifrail provide a less rigid, more effective response to the changingmarket conditions, in terms of:

- Competitive pricing with respect to road

- Flexible commercial offer and procedures (payment terms, price


negotiation, etc.)

- Improved service quality in terms of information, at least at thelevel already provided by road.

Despite the differences existing among the TSP environment,FRPPRQ��JHQHUDO�LQIRUPDWLRQ�QHHGV�FDQ�EH�SRLQWHG�RXW:

- To know the FRPPHUFLDO� RIIHU provided by the Rail cargoCompanies on a European scale

- To monitor the RQ�JRLQJ� WUDQVSRUWDWLRQ� WDVNV on the railportion of the shipments

The information on the FRPPHUFLDO� RIIHU should mainly includeservice provided, wagons available, freight station status and servicedescription, scheduled tariff information.

The information on the RQ�JRLQJ� WUDQVSRUWDWLRQ� WDVNV shouldinclude wagon timing information (actual vs. planned) on a realtimebasis, realtime alarm notification, and positioning (the latter only forTSPs managing wagon fleets).

$W� SUHVHQW� WKHVH� QHHGV� DUH� QRW� VDWLVILHG by the Rail CargoCompany. Available information is scarce, provided only in request,difficult to retrieve and not supported by computerised deliverysystems.

)DLOXUH� LQ�DQVZHULQJ� WKHVH�QHHGV� LV� UHVXOWLQJ� LQ� WKH� ORVV�RI� UDLOPDUNHW�VKDUHV, caused by customers disappointed by the rail, and byTSPs forced to give up the rail mode and to use the road mode everincreasingly.

Furthermore, if the Rail Cargo Companies do not provide a suitableanswer, some third party will do so (by only providing, for instance, aGPS-based positioning service).

6XFFHVV� LQ� DQVZHULQJ� WKHVH� QHHGV may result in the retaining ofthe actual rail customers and TSPs, the increase of TSP railoperations, and an increased appeal to use the rail mode for presentroad-only TSPs.

5$,/�&$5*2�&203$1,(6

��)6�/RJLVWLFD�,QWHJUDWD��g%%�5DLO�&DUJR�

Despite the constant decrease of the rail market share with respect toroad, WKH� 5DLO� &DUJR� &RPSDQLHV� IRUHVHH� IRU� WKH� QH[W� \HDUV� DQLQFUHDVH� LQ� WKH� WRWDO� YROXPH� RI� JRRGV� WUDQVSRUWHG� E\� UDLO,especially in intermodal, block-train schemes. This push is driven bythe increasing development of the European industry needing totransfer large volume of goods from one place to other across Europeat limited costs.

At the same time, the RCCs are aware that WKH�PDUNHW�LV�DVNLQJ�WKH


UDLO�PRGH�WR�SURYLGH�LQFUHDVHG�SHUIRUPDQFHV, at least compatiblewith the ones provided by the road mode: mainly, LQFUHDVHGUHOLDELOLW\ and LQFUHDVHG�LQIRUPDWLRQ�WR�WKH�FXVWRPHUV.

The information requested by the customers to the RCCs includes:FRPPHUFLDO�LQIRUPDWLRQ (i.e. service offer, tariffs, wagons available,etc.) and LQIRUPDWLRQ�RQ�WKH�RQ�JRLQJ�WUDQVSRUWDWLRQ�WDVNV (timing,delays, arrival forecasts, positioning).

7KH� FXUUHQW� LQIRUPDWLRQ� VXSSO\� LV� QRW� VDWLVIDFWRU\� IRU� WKHFXVWRPHUV, as no computerised provision is present, commercialinformation is not available but on the phone and current informationon the on-going transportation tasks is not always suitably updated, oravailable at all.

All RCCs thinks that LI� WKHVH� LQIRUPDWLRQ� QHHGV� ZHUH� VDWLVILHG�SRVLWLYH�HIIHFWV�ZRXOG�UHVXOW�RQ�WKH�UDLO�PRGH�VKDUH, owing to theattraction of new customers towards this mode.

$OO�5&&V�DUH�LQWHUHVWHG�LQ�WKH�LPSOHPHQWDWLRQ�RI�DQ�LQIRUPDWLRQVHUYLFH�DQVZHULQJ�FXVWRPHU�QHHGV, to be tailored according to thespecific customer requests.

By comparing the summaries for TSPs and RCCs, it is evident thatWKH�5&&V�DUH�QRZ�DZDUH�RI�WKH�PDUNHW�QHHGV�H[SUHVVHG�E\�WKH763V.

$Q�DQVZHU�WR�WKHVH�PDUNHW�QHHGV�FDQ�EH�IRXQG�ZLWKLQ�WKH�),5(SURMHFW, specifically established to provide a solution to the problemsstated in this scenario.


��&KRRVLQJ�QHZ�WHFKQRORJLHV

In the current railway environment the information about train, wagon andfreight position, cumulated delay, expected time of arrival may be obtained bythe interested parties mainly by phone.

FIRE Project uses the newest technologies, such as

• GPS, for localization

• GSM, for communication between the wagons and the InformationGateway

• Internet, for access to FIRE service

�� *36��*OREDO�3RVLWLRQLQJ�6\VWHP�

The GPS (Global Positioning System) provides positioning functionalities forfixed and mobile applications with suitable precision all over the world. Small,compact terminals and antennas are used, suitable for installation on railvehicles.

The system is owned by the U.S.A. Government, which decided in May 2000to stop the intentional degradation of the signals available to the public (SA,Selective Availability), so that the civilian users may now pinpoint locations upto then times more accurately than they did before.

�� *60��*OREDO�6\VWHP�IRU�0RELOH�FRPPXQLFDWLRQV�

The GSM (Global System for Mobile communications) is the european digitalcommunications standard selected by the european railways and the EU asthe basis for the new integrated radio system to be used in the europeanrailway environment (GSM/R).

FIRE uses the Short Message Service (SMS) offered by this network, which isa “store and forward” packet transmission through the service channel, withbetter quality characteristics than the data transmission through the trafficchannel.

�� ,QWHUQHW

Internet is the well known World Wide Web, by which a Service Provider maybe reached from every user through its PC.


�� 6FLHQWLILF�DQG�WHFKQLFDO�GHVFULSWLRQ�RI�WKH�SURMHFW

The FIRE Service is designed to provide a reliable and consistent source ofinformation pertaining to freight wagons as they cross Europe, specifically:

• 3ODQQHG� VFKHGXOHV� RI� WUDQVSRUWDWLRQ� WDVNV� LQYROYLQJ� ZDJRQV�� TheService provides to authorised parties the relationship between the trainschedules and the wagon plan information for scheduled rail-based freighttransportation tasks.

• :DJRQ�DQG�7UDLQ�0RQLWRULQJ��The Service monitors the progress on thetransportation tasks across the railway network; information on positioning,delays and arrival forecasts are available for each wagon in atransportation task as well as the current train allocation; wagon and/orgoods status will be also provided if requested.

• &RPPHUFLDO� ,QIRUPDWLRQ�� The Service provides the Transport ServiceProviders with commercial information on the Rail Cargo Company’sservice offer, in standard format, including available transportationservices, available wagons, served freight stations, etc.

The goals of the Service are the following:

A. 7R�SURYLGH�D�),5(�7UDFN�DQG�7UDFH�6HUYLFH� WR� WKH�PDUNHW�QHHGV� , interms of effectiveness of the information provided, roles assigned to thevarious market parties, framework issues,

B. 7R�SURYLGH�D�IOH[LEOH�DUFKLWHFWXUH�HIIHFWLYHO\�OLQNV�WR�XVHUV��in terms ofworld-wide internet access and easy start up costs

��,QIRUPDWLRQ�)ORZV

The main information flows within the FIRE Service are shown inFigure 5.1-1.


$'',7,21$/�:$*21�'$7$(Captured at Origin)

Wagon OriginWagon DestinationConsigneeWeight

:$*21�'$7$OBT Fitted or notTrain No.Latest PositionWagon History(History of OBT reportsreceived, journeys made etc)

75$,1�,1)2Train NoReporting/Calling PointsTimetable DataDays runTrain History (Planned vsActual)Estimated time of Arrival

),5( INFORMATION GATEWAY

/2&$7,21�'$7$ENEE Location DataLatitude/Longtitude

Wagon/ConsignmentData(own vehicles only)

Replay Trains History(Trains conveyingtheir wagons)

Estimated Time ofArrival

)UHLJKW�6KLSSHUV

Current Wagon Data(Wagons on trainsoperated by RCC)

Wagon History(When on a trainoperated by RCC)

Train Information(RCC’s trains only)


5DLO�&DUJR�&RPSDQLHV

Generated Arrival,Departure and BorderCrossing Messages inHERMES format

Comparison of FIREdata with HERMESmessages


Replay Train History

5DLO�1HWZRUN�&RPSDQLHV

)LJ��


�� ,QIRUPDWLRQ�6RXUFHV

Basic data to be used within the FIRE Service are acquired from avariety of data sources. They include RNC sources (trafficmanagement data on trains), RCC sources (commercial andoperations data on tasks, commercial offers) and OBT (On-BoardTechnology) specific sources (for instance, wagon-mountedGPS/GSM terminals).

Future sources, which will form part of the Full stage 2 service, willalso include international systems integrating data from different RNCand/or RCC companies (for instance, HERMES applications,European project servers ERTMS etc.)

�� ,QIRUPDWLRQ�3URFHVVLQJ

Basic data acquired from the different sources are processed at theFire Service level. Suitable correlation among different information isperformed, further processing is carried out and a standard dataformat is achieved. All transactions are stored at this level for historicpurposes.

�� ,QIRUPDWLRQ�'HOLYHU\

After processing, the information is delivered to the relevant,authorised parties over the Internet where it can be accessed viaclient computers running Microsoft’s Internet Explorer.

Processed data on the on-going tasks are delivered to the relevantRCCs and, where apropriate, their relevant customers (theTSP/LSPs).

All information delivery is carried out with standard format andprocedures.


��8VHU�$FFHVV

Some access will be via e-mail (e.g. bulk data take on, support calls),though it is our intention to minimise this. [The e-mail address will beof the form [email protected], the account being monitored bythe FIRE support team.]

��'DWD�&ROOHFWLRQ

The following short-term data sources are used within the PilotService:

• 0DQXDO� GDWD� HQWU\� DW� &DUJR� &RPSDQ\ (mainly used for entering taskconfiguration data)

• $XWRPDWHG� GDWD� HQWU\� IURP� *36�*60� 2%7V (for acquiring wagonpositioning and alarm data)

• $XWRPDWHG�GDWD�HQWU\� IURP�6%%¶V�DQG�RWKHU� �$9,� FRPSXWHU� V\VWHPV (foracquiring wagon positioning)

• $XWRPDWHG�GDWD�HQWU\�IURP�OLQNV�WR�+HUPHV�( stage 2 )

�� 0DQXDO�'DWD�(QWU\

This is carried out via the Internet using predefined data entryscreens.

�� *36�*60�'DWD

Data are collected in real time from GPS/GSM units fitted to wagons.The receipt of this data is via Sema’s “P2 Radio Interface” softwaremodule using a Siemens M20 unit. This feeds a “P2 Radio Gateway”,to translate phone numbers into wagon numbers and thence to asubsystem that records the information in a log.

�� 6%%¶V�$9,�DQG�2WKHU�$9,�VHUYLFHV

The AVI system provides train information. This will be interfaced viaa POP3 service.

�� +HUPHV

Hermes messages will be monitored and compared with outputavailable from FIRE from Stage 2 of the production service.


��'DWD�2XWSXW��,QWHUQHW�%DVHG�(QTXLULHV�

Master enquiry of whereabouts of all GPS/AVI fitted vehicles.

User’s enquiry about the status of the wagons he owns.

Customers’ enquiry about the whereabouts of wagons hired to them.

Commercial information on the Cargo Companies’ service offers, instandard format; available information will include a general Companypresentation, offered transportation services and wagon types.

��),5(�DV�D�3URGXFW

Input by the client

� Wagon No./type of consignment

� Train info

� Time table

),5(�*DWHZD\��ZDJRQ�LQIR�

� position

� delay

� type of consignment

� sensors: shocks etc.

��4XDOLW\�FULWHULD

� future expandability

� data security (fire walls)

� modular structure (to fit/in wagon management systems)

� internet access

� low complexity

� standard interface (for multiple suppliers)


��:HE�6HUYHU�$FFHVV

The FIRE web server is programmed to be available from 10:00to 14:00 GMT, Monday to Friday. Anyone can access it during thattime. All accesses are logged. To access it, one needs an Internetconnected PC, with Microsoft Internet Explorer version 4.x or 5.xinstalled and working correctly. One must also have a Java VMinstalled, and allow applications to write cookies. The displays workbest with the browser maximized, at a resolution of at least 1024x768with 256 colours.

At the URL window, type:

HTTP://212.70.131.24/

which will bring up the FIRE logon screen. Enter the userid andpassword as supplied, and click the validate button.

There are 3 classes of users:

1) End customers

2) OBT equipment suppliers

3) Cargo companies

The userid will have been assigned to one of these categories,depending on what kind of FIRE user one is. Access to data is limitedby that user type and, within that, which vehicles one has control over(for cargo companies), uses of or owns (end customers) or has fittedOBTs to (for OBT manufacturers).


��8VHU�)DFLOLWLHV

In this chapter will be described all the facilities which FIRE Pilotoffers to its users. The following glossary explains some FIRE specificterms .

*/266$5<

• Consignment: An end to end transportation task as viewed by thecustomer. May involve wagons travelling on more than one train to reachtheir destination. Each FIRE consignment is given a unique number whichis used to refer to it by

• Destination: The place where an activity finishes.

• Location code: A 7-digit UIC code (country code and location code withinthat country).

• Origin: The place wherefrom an activity starts

• Schedule: The planned timetable for a train (origin, destination, andintermediate points) with expected times/days.

• Train number: a 5-digits UIC number for train identification.


�� (QG�&XVWRPHU�)DFLOLWLHV

These facilities are primarily intended to allow a customer of therail service provider to enquire about the progress of shipments. Anend customer is not, generally, concerned with operator-specific data,such as train number. Thus, a transportation task within FIRE istermed a consignment, and the unique number given to them by thecargo company is the access key for data.

6SHFLILF�&RQVLJQPHQW

This enquiry lists data about a consignment in the FIRE system.Enquiry may be made before departure, during the running, or afterthe task has been completed.

The output lists the current status, and, if in progress, the delay.It gives the origin and destination time and place, as well as the trainnumber(s) involved in the task, and the wagon numbers assigned toit.

6SHFLILF�7UDLQ

This enquiry lists data about a train within FIRE. Enquiry may bemade after departure, or at any time after it has terminated. The trainnumber itself is unique in FIRE, and the start date is added to makethis unique. Thus, to enquire about a train, one must supply the trainnumber and the date of departure from the originating point.

The output lists the current status, and the schedule for thetrain. It adds (up to) the last 20 reports for the train, giving the dateand time, position, speed and heading, the delay at that time, and thenumber of the wagon which made the report.

6SHFLILF�:DJRQ

This enquiry lists data about the specific wagon number entered.This enquiry may be made at any time.


The output gives the train and consignment number (if any), andlists the last 20 position reports for the wagon. These list the date andtime received, the position, the train (if any) it was on and the delay.

:DJRQ�7UDFH

This enquiry shows, on a map of Europe, the last few reportsreceived for a wagon. See section 4 for details of map functionality.

&RQVLJQPHQW�7UDFH

This enquiry shows, on a map of Europe, the last few reportsreceived for a consignment. See section 4 for details of mapfunctionality

2XWVWDQGLQJ�&RQVLJQPHQWV

This enquiry gives data about all current, not yet completed,consignments. It lists the origin and destination place and date, andthe current and estimated destination delay.

An example follows.


�� 2%7�0DQXIDFWXUHUV�)DFLOLWLHV

The facilities for OBT manufacturers are intended to assist themin the task of monitoring OBTs during the trail. Thus, they are notinterested in train or consignment information (in fact, this is private).The enquiries are detailed below.

/DVW��9DOLG�5HSRUWV�IRU�D�9HKLFOH

This enquiry lists the last 20 valid reports received for the givenvehicle. It gives the date and time, speed and heading, train number,delay, and position.

/DVW��5HMHFWHG�5HSRUWV�IRU�D�9HKLFOH

This enquiry lists the last 20 rejected reports for a vehicle. Itgives the date and time, speed, heading and position (if the reportallows this). Then it lists the rejection reason and the input messagewhich was rejected.

Rejection reasons are:

• GPS mode not N - the GPS mode field in the message must be N for thedata to be valid

• Bad heading - the heading can only have a value between 0 and 360.

• Speed to high - each vehicle has a designed maximum speed. This isentered into the FIRE database, and, should a reading come in whosespeed exceeds this by 10%, it is rejected.

• Time of day too high - the date/time fields are too far in the future to bereasonable

• Time of day too low - the date/time fields are too old for the reading to beof use

• Record same as the last received - a duplicate transmission has takenplace.


/DVW��5HSRUWV�IRU�D�9HKLFOH

This intermixes both the previous categories.

An example follows.

:DJRQ�7UDFH

This enquiry shows, on a map of Europe, the last few reportsreceived for a wagon. See section 4 for details of map functionality


�� &DUJR�&RPSDQLHV�)DFLOLWLHV

Correct functioning of FIRE, from an customers perspective,relies on correct and timely data entry by the cargo company. In thisphase of the project, the data input is manual. Each function will bedescribed in detail later, but, first, some detail will be presented aboutthe way FIRE operates.

The unit of work from the customers perspective is aFRQVLJQPHQW. This represents a single transportation task of a goodson a wagon (or wagons) from one place to another. The cargocompany may run a single train between these two points, or it mayuse more than one train to accomplish the task. Thus, a FRQVLJQPHQWis made up of one or more WUDLQV.

A WUDLQ� is identified by a single train number. This is in thestandard 5 digit UIC format. Every train has a VFKHGXOH�which detailsthe days that train runs (e.g Mondays only), the dates it runs (e.g.from 01/01/2000 until 01/07/2000), and the origin and destinationlocations. Also, to aid FIRE in determining delay to a train, thefollowing classes of intermediate locations should also be timed:

a) Calling points

b) Intermediate passing points where the running time between twoexisting points exceeds about 30 minutes.

Additionally, there is little benefit in having timing points closerthan about 5 minutes. A schedule may contain up to 20 timing points.FIRE wagons may use only an intermediate part of a train’s journey.

Inter-train time gaps require special attention. If the outboundtrain waits, should the inbound train be late, then this is requiredinformation, as is the time required to perform shunting from one trainto another. These two pieces of information are used thus inestimating destination arrival time:

If a train is so late such that it would miss the outbound leg, the ‘will itwait’ flag is examined. If it is set on, we assume that the outbound legwill wait, and depart at (estimated inbound arrival time + declared


shunting time), with delay (estimated depart time - scheduled departtime). If it is not set on, and an e-mail address has been declared forthe customer, an e-mail is sent to him asking him to contact the cargocompany for information. If it would not potentially miss the outboundleg, the delay is set to zero (i.e. Time it would have stood idle in theyard is used to offset the delay). This process is continued up to thedestination point, and the calculated delay there is used.

Schedule input should only need to be done once for theservices to be used, but consignment data will need to be input as themake up of each consignment is known

Schedule input is based upon locations being available in thegeographic database. In order to do this, the latitude and longitude ofthe location must be known to enable the system to calculate delayfrom the information presented. Thus, schedules can ONLY be madeup of places for which latitude and longitude data have beenprovided. There is a ‘place list’ button on the bottom of the scheduleinput screen which lists all valid location codes and their names.

Cargo companies can only enter and enquire about data aboutwagons which are shown as being their responsibility in FIRE - that is,they own and hire out to customers, or they operate on a customersbehalf.

&UHDWH�D�6FKHGXOH

This item is used to create a permanent train schedule. For theheader section you need to know:

a) Train number - 5 digits

b) Days run (i.e. days the train is scheduled to start its journey). On theinput form, this has 7 digits, the first of which represents Monday,the second Tuesday, etc. A ‘1’ means ‘runs’ and a ‘0’ means ‘doesnot run’

c) Dates run - the UK format (DD/MM/YYYY) including the slashesand using leading zeroes as appropriate.

For the detail lines, the following is required:


a) Location code - as mentioned above, must be in the FIRE database(which implies a latitude and longitude pair have been supplied)

b) Type of event:

• O - Origin of train, only departure time required

• P - Passing point, only departure time required

• C - Calling point, arrival and departure time required

• T - Termination point, only arrival time required

c) Time of event, and day number from origin (if not the same day).This only applies to trains which run overnight. Day 0 is the day ofdeparture from origin, day 1 the next day, and so forth. Times areexpected to be 4 digits, HHMM format, with leading zeroes asrequired.

The first detail line must be type O, and occur on day 0.Subsequent times/days must be after the previously entered ones,and the last line of entry must be type T. There may be no blank linesin the middle of a schedule.

An example follows.


&UHDWH�D�&RQVLJQPHQW

Before a consignment is created, the relevant train schedulesmust have been created. Then, enter the following data:

a) Customer code - 4 character code

b) Depart from origin date - in UK format, DD/MM/YYYY, with leadingzeroes as required.

c) The start location of the consignment

d) The end location of the consignment

e) The destination delay at which the customer is e-mailed to informhim of late arrival of the consignment.

f) The type of goods to be carried.

Next, for each train to be used on the consignment:

a) Train number

b) (For all but the first train) the day number with relation to the originday (0 = same day, 1 = next day, etc.)

c) The location (on the train’s schedule) at which these wagons join thetrain

d) The location (on the train’s schedule) at which these wagons leavethe train

e) The minimum transshipment time to the next train (i.e. shuntingtime, etc.)

f) Whether the outbound train waits for the wagons if the inbound trainis late (see explanation in the introduction to this section for moredetails)

Then, the list of wagon numbers on this consignment. These willbe checked to ensure that they are not already on a consignment atthis time/these times.

An example follows.


'HOHWH�D�6FKHGXOH

Enter the train number and the start date for the consignment,and it will be deleted from the system.

&DQFHO�D�&RQVLJQPHQW

Enter the consignmnent number to delete.

8SGDWH�D�6FKHGXOH

This allows for a train schedule to be updated, in the event of anerror being detected in it, or a change of operations. Enter the trainnumber and the start date, and the schedule will be displayed in aformat similar to that in 3.1, from where it may be changed asrequired. To save the change, press the ‘input schedule’ button at theend of the form.

8SGDWH�D�&RQVLJQPHQWV�7UDLQ

In the event of a consignment running very late, and thusmissing a connection en-route, it will be necessary to update it toshow the new train number(s) to be used. This facility allows such achange to be made. Data appears in a format similar to the middlesection of 3.2 (above) from where it may be amended as required.

5HPRYH�D�9HKLFOH�IURP�D�&RQVLJQPHQW

In the event of a vehicle becoming defective en-route, and itbeing removed from the train, it will be necessary to enter thisinformation into FIRE. Enter the consignment number and the vehiclenumber to remove.


/LVW�7UDLQ�6FKHGXOHV

This enquiry lists all the schedules which are in the FIREdatabase. It lists:

• Train number

• Origin time

• Origin place

• Destination place

• Days run

• Start date

• End date

/LVW�2XWVWDQGLQJ�&RQVLJQPHQWV

This enquiry lists all consignments which have not yetterminated, and are owned by this cargo company.

/LVW�9HKLFOH�,QIRUPDWLRQ

This enquiry lists data about the specific wagon number entered.This enquiry may be made at any time.

The output gives the train and consignment number (if any), andlists the last 20 position reports for the wagon. These list the date andtime received, the position, the train (if any) it was on and the delay.

An example follows.


/LVW�7UDLQ�,QIRUPDWLRQ

This enquiry lists data about a train within FIRE. Enquiry may bemade after departure, or at any time after it has terminated. The trainnumber itself is unique in FIRE, and the start date is added to makethis unique. Thus, to enquire about a train, one must supply the trainnumber and the date of departure from the originating point.

The output lists the current status, and the schedule for the train.It adds (up to) the last 20 reports for the train, giving the date andtime, position, speed and heading, the delay at that time, and thenumber of the wagon which made the report.

/LVW�$OO�,QIRUPDWLRQ

This enquiry is a summary of all on-going work. It lists all trainscurrently running, all consignments not currently terminated, and shortdetails about all wagons. For the wagons, the ‘Time of last rep’ fieldgives the time a report was last received from ANY wagon on the trainthat this wagon is on. The ‘time of loc’ is the time a report was lastreceived from this wagon itself.

:DJRQ�7UDFH

This enquiry shows, on a map of Europe, the last few reportsreceived for a wagon. See section 4 for details of map functionality.

7UDLQ�7UDFH

This enquiry shows, on a map of Europe, the last few reportsreceived for a train. See section 4 for details of map functionality


&RQVLJQPHQW�7UDFH

This enquiry shows, on a map of Europe, the last few reportsreceived for a consignment. See section 4 for details of mapfunctionality

6KRZ�9HKLFOH�3RVLWLRQ�RQ�0DS

This enquiry shows, on a map of Europe, the last reportedposition of the wagon.

6KRZ�7UDLQ�3RVLWLRQ�RQ�0DS

This enquiry shows, on a map of Europe, the last reportedposition of the train.

6KRZ�&RQVLJQPHQW�3RVLWLRQ�RQ�0DS

This enquiry shows, on a map of Europe, the last reportedposition of the consignment.


��0DS�)XQFWLRQDOLW\

This section details functionality built into the mapping displays used by FIRE.

• F4 and F5 zoom the map in and out

• Page up and Page down keys work as expected, as do the arrow keys.

• By pressing the left mouse button, and dragging it to make a rectangle,the screen display will be rescaled to fit that rectangle into the window i.e.zoom in to a specific place.

• Clicking the left mouse button will bring up a dialogue box. Contents willvary depending on the type of display, but will include:

- Wagon number that generated the report

- Its speed and heading at the time

- The time of the report

- The position of the report

From the display menu, one can select what is displayed againstthe points. This will depend on the type of map display, but cangenerally be the wagon number which generated the report, the dateand time of the report, or the speed or heading of the report.

An example follows.


�� 2Q�%RDUG�7HUPLQDO

�� )XQFWLRQDO�5HTXLUHPHQWV

• Capability to calculate its own positioning, in latitude and longitude terms,with a precision better than 100 m by using the Global Positioning System(GPS).

• Capability to recognise its own distance from specific Reference Points,recorded as latitude and longitude items.

• Capability to monitor specific alarm sensors. Required sensors areShock/motion, Removal, and a battery voltage sensor. Additional sensorsmay be ones such as temperature and pressure. Additional sensors areapplication defined but may be included with an OBT even if they are notused.

• Capability to internally store a history of events. This history must includethe time, position, alarms, and some OBT status information at each event.A history will be primarily maintained through maintaining a messagehistory.

• Capability to communicate the listed events to a remote supervising centre,the FIRE Information Gateway in three different ways:

1. On a cyclic basis, at preconfigred times

2. On operator request, at known time periods during the day

3. On specific events detection, such as alarms, border crossing, etc.

• Capability to receive configurations data and commands from the FIREInformation Gateway.

• Capability to receive new software releases from the FIRE InformationGateway.

• The main medium for communications is GSM SMS, using GSM forsoftware downloads. Alternative methods of communications, for exampleOrbcom, are possible and can be used instead of GSM. A manufacturer orcustomer wishing an alternative to GSM should discuss the possibility withthe FIRE service provider/s.

The OBT is not required to calculate paths or routings.

�� $FFHVV�6HFXULW\

In order to warrant access security, the OBT accepts only short messages fromauthorised numbers.


�� (QYLURQPHQWDO�5HTXLUHPHQWV

As the OBT is to be installed on freight wagons, minimum environmentalrequirements are according to EN50155 with additional requirements accordingto the intended application of the OBT and these specifications.

• Dimensions: self-contained box not larger than 21 x 29.7 cm x 10 cm.Larger dimensions may be taken into consideration provided they arecompatible with the internationally approved gauge for rolling stock

• Temperature: -20°C to +55°C

• Sustained vibrations: according to EN50155 for equipment directly mountedon vehicle body with mass<2000 Kg. See EN50155, paragraph. 10.2.11.2.

• Shocks: according to EN50155 for shunting shocks

up to 5g for longitudinal movement

up to 2g for transverse movement

up to 1g for vertical movement

• Humidity: water resistance to falling rain

�� 3RZHU�5HTXLUHPHQWV

• Self powered unit with an energy storage device. A battery is consideredstandard.

• For “normal” operations, at least 6 months of operations without any batteryre-charging, or transmission of up to 1000 Short Messages.

• An on board battery recharging device is at the discretion of the OBTmanufacturer, however the OBT may not exceed the size limits.

�� ,QVWDOODWLRQ�5HTXLUHPHQWV

• Mounting: Mounting is application dependent. The main method ofmounting will be mounted fixed in a sleeve that is soldered or welded to thewagon’s frame. A secure, antitheft lock allowing authorised deinstallationfor maintenance purposes must be included. Other methods are permitted.

• Battery servicing: The OBT must have locked access to the battery forauthorised replacement with no need for OBT deinstallation.


�� 2%7�2SHUDWLRQDO�0RGHV��)XQFWLRQV�DQG�'DWD�6WUXFWXUHV

�� 2%7�2SHUDWLRQV�0RGHV

Because freight wagons are normally not provided with a power supply, theOBT must carefully use the energy stored in its own battery.

This is achieved through the use of three different Operations Modes, enablingthe OBT to select different power consumption levels depending on thebattery’s available energy and on the needs of the specific application.

The three available Operations Modes are Stand By Mode, Normal Mode, andBoot Mode. The System Configuration defines additional operationalparameters of the OBT.

6WDQG�%\�0RGH

The OBT is in a low power consumption state. No positioning is calculated, normessages received and transmitted.

An internal clock is monitored.

Three digital sensors (on/off type) are also monitored. These are the “OBTremoval” antitheft sensor, the “motion/shock” sensor, and the remaining sensoris application dependent.

At configured time intervals or specific configured times, the OBT entersNormal Mode.

On OBT removal, the OBT enters the Normal Mode to produce an alarm.

On shock the OBT enters the Normal Mode to produce an alarm. Optionally,on motion detected after a predefined amount of time without motion, the OBTmay also enter Normal Mode to produce an alarm.

On alarm by an application dependent sensor, the OBT enters Normal Mode toproduce an alarm.

1RUPDO��0RGH

This Mode is entered at configured time intervals or at specific configured timesduring the day, on detection of an Alarm situation if Alarms are active, or after areboot caused by a power shortage. The configurable time interval may rangefrom 30 minutes to 24 hours, or at one or more configurable times during each24 hour period. The OBT must wake at least once every 24 hours to maintainreasonable accessibility.

In special applications this Mode may also be operated continuously with notriggering from Stand By Mode.

After entering Normal Mode, the OBT determines if Normal Mode has beenentered through a normal timed wake up, or as a result of an Alarm detection.If Normal Mode has been entered through a normal timed wake up, the OBTcarries out its Standard Operations as described in the Standard Operationssection below. If Normal Mode has been entered on a detected Alarm, theOBT carries out its functions according to the Alarm Generation function.


Normal Mode is operated for a period of time as stored in the OBT’sconfiguration table. This time may not be less than one minute. OBTmanufacturers may define a maximum length of operations in Normal Mode.This maximum may not be less than 10 minutes. The maximum definablelength of operations of Normal Mode is 21:25 minutes.

In Normal Mode, the GSM module is always on. Switching of the GPS moduleis at the discretion of the OBT manufacturer.

During Normal Mode, the OBT must be able to receive and respond to ShortMessages it receives. These messages are described in the relevant functionsbelow.

At the end of the period of operations of Normal Mode, the OBT enters StandBy Mode.

If Normal Mode is operated continuously, defined as “Normal ContinuousMode”, the OBT carries out Standard Operations repeatedly until newconfiguration information is received.

Standard Operations

In Standard Operations, the OBT calculates its position using GPS. Thiscalculation is completed either by obtaining a position fix, or by expiration of amanufacturer definable time for obtaining a fix in which case no fix waspossible. This manufacturer definable time may also be at the expiration of theperiod of operations of Normal Mode. The other sensors are checked for theirstatuses. The OBT then generates a Timed Data Message and sends thatmessage to the configured recipient/s.

After the Timed Data message is generated, the OBT checks if the ReferencePoints are active. If so, the GPS position is checked against the storedReference Points and the OBT establishes which is the closest ReferencePoint. If the OBT detects it within the “Tolerated Radius” of the nearestReference Point, it generates a Reference Point Reached message containingthis information and sends it to the configured recipient/s.

If Normal Continuous Mode is configured, the OBT carries out StandardOperations at regular time intervals. The interval is configurable and may befrom 1 to 30 minutes.

If it is not possible to send a particular Short Message, that message should bemarked and its transmission retried in the subsequent times the OBT entersNormal Mode until it is successfully sent. This retrying should occur for at leastthe following five times the OBT enters Normal Mode. After this, it is at theOBT manufacturers discretion if to continue retrying, or to store the message inthe OBT’s message history as unsendable and discontinue trying to send it.

Alarm Generation

Alarms are generated if the System State defines that Alarms are active. AnAlarm is generated when one or more of the monitored sensors detects it isoutside normal operational parameters. This can be as a result of shock, OBTremoval, low battery voltage, or from an application dependent sensor. TheOBT will follow the same procedure described for Standard Operations except


that instead of generating a Timed Data message, an Alarm Message will begenerated.

If the OBT was already in Normal Mode when the Alarm situation arose and aReference Point Reached message has already been generated, an additionalReference Point Reached message should not be generated.

Command Handling

When the OBT receives a Short Message, it processes the contents of thatmessage and acts according to those contents. As a general rule, if acommand contains a request for information, only the originator of the messageis responded to. If the command changes the recorded configuration in anyway, the recorded recipient/s and the originator of the message, if different, areresponded to.

If the message contains a Request or command, and no significant alarm wasbeing handled at the time of message reception, the OBT processes that,sends an appropriate response and continues with normal operations. If analarm was being handled at the time, the alarm is first processed, then themessage handled.

If the message contains a new configuration, the OBT first checks if thecontained parameters are legal and within defined limits. If all parameters arelegal, the OBT stores those new operating parameters and sends a response ofConfiguration OK to the previously configured recipient/s and the originator ofthe message. If one or more parameters are not legal, the OBT should rejectthe configuration and send a Configuration Not OK message with the rejectedconfiguration to the originator of the message. It then continues normaloperations according to the stored configuration.

If the message contains a Data Request, the OBT calculates its position usingGPS and sends a response including overall OBT status to the originator of therequest.

If the message contains a Configuration Request, the OBT returns its currentlystored configuration to the originator of the message.

If the message contains new Reference Points, the OBT checks that all pointsare legal. If all Reference Points are legal, each new point is then checkedagainst the existing Reference Points in memory. If a Reference Point alreadyexists in memory, that point is overwritten by the new point, otherwise the newpoint is added to the stored list. The OBT should then respond to theconfigured recipient/s and the originator of the message which points havebeen stored with a Reference Points OK message. If any of the new ReferencePoints were illegal, the OBT should reject the entire list and respond to theoriginator of the message with a Reference Points Not OK message.

If the message contains a Reference Points Request, the OBT returns allReference Points currently stored over as many messages as are necessary tothe originator of the request using Reference Points Stored messages.

If the message contains a command to clear all reference points, the OBTremoves all reference points stored and sends a response of Reference PointsStored with no points listed to the configured recipient/s and the originator ofthe message.


If the message contains a request to download new software, the OBT stops alloperations, sends a message to the originator of the message that it is ready toreceive new software and waits for a GSM connection to receive the newsoftware. New software is then downloaded to the OBT. When the downloadis complete, the OBT restarts operations using the Boot Mode.

Local Check Function

Local Check Function is activated locally by pressing a button located inside thebattery compartment. The same checks are performed as in the Boot Mode,except the OBT’s software is not restarted. The function of the OBT may bemonitored through the LED’s or their equivalent in the battery compartment.After booting is complete, the OBT enters Normal Mode.

%RRW�0RGH

Boot Mode is entered after a power shortage caused by battery first installationor replacement, or on request by other Operations.

In this Mode the OBT performs a full boot procedure. After restart it performs aglobal check of all components (CPU, memory, GPS module, GSM module,sensors, battery, and energy generating module if any) and of its configuration.

After booting is complete, the OBT switches to Normal Mode operatingaccording to the recorded configuration. If no configuration has been received,operations will be according to a default, manufacturer defined configuration.

Small LED’s, or their equivalent, only active when the Boot Mode or LocalCheck Function are initiated are inside the OBT battery compartment to providethe following information:

• Green: CPU operating correctly (watchdog)

• Red: battery low

• Yellow: SMS message sent successfully


�� 2%7�'DWD�6WRUDJH

The Data stored in the OBT is the following:• Sensor configuration, if any• Software configuration consisting of the current release and other parameters

considered necessary by the OBT manufacturer• Phone number of one or two FIRE Information Gateway/s in use• Phone numbers of up to five Admitted Users• Operating Mode configuration data• Space for up to 1000 Reference Points, including a “Tolerated Radius” for each

Reference Point• A history of at least the last 50 Short Messages generated. Larger histories are at

the manufacturers discretion.


�� 2%7�'HVLJQ

OBT design relates to defining the following items:

• Hardware components

• Installation procedures

• Configuration and testing procedures

• Operations procedures

• Maintenance procedures

�� +DUGZDUH�FRPSRQHQWV

The OBT will be made up by the following components:

• Construction: self contained metallic case of suitable dimensions. Other matieralsmay be accepted provided the OBT can maintain its reliability.

• Internal electronic boards and components with suitable mounting.

• Antennas may be internally or surface mounted on the case of the OBT. Antennasshould be chosen so they will not be easily damaged, and may not use any externalwiring.

• Internal Battery for energy storage

• Optional Power Generation Module

�� &DVH

The case is in metallic material, able to withstand the harsh environmentalconditions defined for the OBT. Other matierals may be accepted provided theOBT can maintain its reliability and resistance to environmental conditions.

Maximum dimensions for the case should be 21 x 29.7 x 10 cm.

A locked compartment providing access to the battery for replacement withoutdeinstalling the whole OBT. The lock uses a special key common to all OBTs.

The battery compartment also contains the following:

Small button for activating the Local Check Function

3 LED’s:

½ Green: CPU operating correctly (watchdog)

½ Red: battery low

½ Yellow: SMS message sent successfully

The LED’s may be substituted by a seven segment display or other clear visualmethod of indicating at least the three statuses listed. Additional informationmay be provided at the manufacturers discretion but must be clearly identifiableas different to the above listed statuses should the service personnel not knowabout the additional information provided.


�� ,QWHUQDO�(OHFWURQLF�%RDUGV

Manufacturers are free in their design of the internal electronics of the OBT.The design must however meet the functional and environmental requirementsalready specified. It is recommended that very low energy consumptiontechnology be used. Manufacturers should keep in mind that Analogue and/ordigital inputs may be required in the OBT for some applications.

�� *60�0RGXOH��DQWHQQD

The GSM Module features:

• SMS (Short Message Service) capability, to be used during normal operations

• Data Transmission capability, to be used for software maintenance purposes

• No Voice capability required. Voice capability may be avoided if it reduces powerconsumption.

Note that alternatives to GSM, for example Orbcom, may be used in place ofGSM. Any alternative used must continue to meet the message standards set,detailed later in this document.

�� %DWWHU\

For easy replacement, the battery should weight no more than 1 Kg.Manufacturers should ensure the battery’s capacity allows it to meet theminimum life requirements of the OBT.

�� (QHUJ\�*HQHUDWLRQ�0RGXOH

The Energy Generation Module provides a power source to be used forrecharging the OBT’s battery. Technology may be freely chosen but should befully integrated in the OBT with no external connections. The addition of anenergy generation module is at the discretion of the manufacturer andcustomer.

If the OBT is to be used in a situation where an external power supply is easilyand reliably available, such a power supply may be used. It is not necessaryfor manufacturers to include the possibility to connect an external power supply.Such a connection should generally be avoided where the OBT will runprimarily off its own energy storage.


�� 2SHUDWLRQDO�SURILOH

The OBT is required to operate for a predefined period without any need forbattery replacement. The OBT must meet the following minimal requirements:

2SHUDWLRQDO� 3URILOH� �W\SLFDODSSOLFDWLRQ�2%7�VHW�XS

Basic sensors only (shock/motion,OBT removal); no additionalsensors (temperature, pressure,etc.)No Energy Generation Moduleinstalled

2%7�RSHUDWLRQV Normal Mode: operated twice a day,10 minutes each timeStand By Mode: always operatedwhen not in Normal Mode

7LPH�UHTXLUHPHQW�IRU�WKLV�2SHUDWLRQ�3URILOH��PLQLPXPWLPH�EHWZHHQ�WZR�FRQVHFXWLYH�EDWWHU\�UHSODFHPHQWV��PRQWKV

�� ,QVWDOODWLRQ�SURFHGXUHV

The installation of the OBT depends on the kind of wagon it will be installed on,and where it has to be attached. This is established on a wagon by wagonbasis.

�� &RQILJXUDWLRQ�DQG�WHVWLQJ�SURFHGXUHV

After installation or battery replacement, the OBT automatically enters the BootMode.

In Boot Mode the OBT checks its overall status and sends related informationto the FIRE Information Gateway through the GSM/SMS.

Personnel may monitor the actual status of Boot Mode by observing the LED’sinside the battery compartment.

After completion of Boot Mode or if the lamps indicate any problem, thepersonnel must check for the content of the Short Message sent to the FIREInformation Gateway. This operations will be performed by calling theInformation Gateway’s operator to have the Short Message checked.

Finally, the lid of the battery compartment may be closed and locked.


�� 2SHUDWLRQV�SURFHGXUHV

OBT operations are fully automated, apart from battery replacement and LocalCheck Mode.

�� 0DLQWHQDQFH�SURFHGXUHV

�� %DWWHU\�UHSODFHPHQW

Batteries are serviced at specific sites chosen by the wagon operator or owner.

At these sites exhausted batteries removed from the OBT’s and are replacedwith freshly charged batteries. Exhausted batteries are then recharged. A fewcharged batteries must always be available at each site.

Battery replacement takes place as follows:

1. The OBT advises the Information Gateway that a battery replacement is necessaryby generating a Low Power Alarm.

2. When a Low Power Alarm is received, the Information Gateway advises the wagonowner that a battery replacement is necessary for the OBT.

3. The wagon owner then chooses a suitable location and time to carry out the batteryreplacement.

�� 2%7�VHUYLFLQJ

In case of OBT failure, the OBT is deinstalled and serviced on a case by case basis


�� .77¶V�2%7�,PSOHPHQWDWLRQ

The OBT was developed in compliance with the HW/SW RequirementsSpecification described in D5 with some restrictions towards the pilot service (e.g.removal sensor). Main emphasis during the development has been the urge toreduce the power consumption to an absolute minimum and to withstand therough environmental influences. As well the necessity for a sufficient reliability ofthe unit has to avoid costly and lasting service actions.

battery

µC

communicationnavigation

sensors/interfaces

antennas and solar panel

mainboard

memory

�� +:�&RPSRQHQWV� 0DLQERDUG

• Microcontroller at 12MHz

• 256kB Flash Memory

• 128kB Random Access Memory

• 4kB non volatile memory (Eeprom)

• Interfacecontroller� *36�FKLSVHW

• 12 channel low power GPS receiver

• Patch antenna (active)

• Geo-information (latitude/longitude - WGS84) provided in NMEA-0183 datastrings

• Time to first fix (TTFF) < 60sec typ. (cold)

• Power consumption < 0.9W typ.


• Operating temperature -40°C to +85� *36

The GPS receiver gains its position within a shortest time to save as much poweras possible. This will be obtained best with a 12 channel receiver, which arenowadays widely used. Each channel acquires independently satellite signals,which reduces especially the TTFF.

� 6KRFN

• Micromechanic-electric

• 0 to 10g, solution 0.05g

• 150 µA typ.

• Operation temperature -20°C to 55°C� *60

• Small size OEM board (86,8 x 41,4 x 11,2 mm)

• 900 MHz network

• SMS, GSM-Data

• Operating temperature -40°C to +80°C (-20°C to +55°C full operational)

• Power consumption < 250mA typ., <2A pulsed (at 6V)

Again low power consumption is one of the most important criteria for the widerange of different GSM boards. In this case, Siemens’ M20 showed goodcharacteristics and reliable communication results.

� 'LJLWDO�,�2

• 6 digital inputs (not used in pilot service)

• 6 digital outputs� $QDORJ�,�2

• 8 analog inputs (0-16V)� 3RZHU�6XSSO\

• 12V, rechargeable batteries

• solar panels (optional)� ,QWHUIDFHV

• 2 x RS 232 (TTL)

• 1 x V.24� $SSURYDOV

• EN50121 (EMC)

• EN55022 (EMC)

• EN61000-4-2 (EMD)

• Operation temperature -20°C to +55°C


�� 6RIWZDUH� )XQFWLRQDO�2YHUYLHZ

Communication

Diagnostic

Dataprocessing

HW-Interface

Power-management

Configuration GSM-SMS

GPS

Operating System

�� 2SHUDWLQJ�6\VWHP��26�

The OBT works with an specialised operating system for self driven applications. Itis in charge of acquiring, storing, processing and transmitting data. Besides it hasto take care for the reliable operation in the aspect of power consumption andenergy management. The OS consist of a basic kernel, which connects to thefollowing modules:

• Power management

• Communication

• Data processing

• Diagnostics

• Configuration

The OS controls the modules, (de-)activates certain elements and manages theinformation flow. It constantly tracks the topic system status of the unit andinvokes immediately exception rules in cases were it is necessary (e.g. low poweror reckoned defect).

� 3RZHU�0DQDJHPHQW

Checks constantly the current power state of the unit. In cases where the powersupply is critical it informs the OS to concentrate on the most important functions.The worst case - low power state - leads to a deactivation of the application andany other action. Merely the power will be checked regularly to reactivate the OBT,when the supply is sufficient again (e.g. after replacement of battery).


� &RPPXQLFDWLRQ

Enables the OBT to exchange any data with a host station. It establishesconnection to the GSM network, logs in and enables communication. Receivedmessages are checked towards their integrity and authorisation. Up to five usersare allowed to access the OBT to

• request user data

• request reference point list

• configure reference points

• clear reference point list

• configure system parameters

The authorisation is organised by a „white list“, i.e. the OBT compares eachsender’s phone number of any received message with its predefined list („whitelist“). This list contains up to five different identifications (phone numbers), whichwill be admitted to access the unit.

The evaluated message body will be passed on to the OS for further processing.

Originated messages are formatted corresponding to the GSM specifications andforwarded to the recipient. In cases of bad or no GSM coverage all originatedmessages have to be stored for a later attempt for transmission.

� 'DWD�3URFHVVLQJ

The whole part of data processing is mainly characterised by the application.Information (data) has to be acquired, usually to distinctive times. Some of the datahas to be evaluated and may lead to further actions like an alarm message.

Example: One objective of the OBT is to recognise boarder crossings. So the topicposition will be compared with the previous one and if a boarder crossing tookplace, the OBT acquires all remaining user data and forwards them for directtransmission.

� 'LDJQRVWLFV

The diagnostic module can be considered as an own application by itself.Information are gathered and provided via a serial data link, which may giveimportant hints for an upcoming failure or undeclared behaviour in the past.

Usually it is inactive, but during maintenance the service staff can activate adiagnostic process to get continuously information of the topic actions and states ofthe OBT. This is the base for a quick evaluation of the OBT. Some of theseinformation are battery voltage, power state, state of the GSM network duringcommunication processes, GPS - Fix results, antenna signal strength e.t.c.

� &RQILJXUDWLRQ

The flexibility and dynamic of the OBT has been achieve with a complex structureof different parameters and different configuration opportunities. Many of theseparameters are required by the application and can simply be modified with a singleconfiguration message.


� $SSOLFDWLRQ�SDUDPHWHUV

operation mode disables/enables evaluation of referencepoints, events, peridic transmissionswitches between normal mode and normal continuous mode

activation cycle for normal mode determines in which time scales the user data will be acquired and evaluated

transmission cycle in normal cont.mode

determines the transmission frequency in normal continuous mode

enable/disable border crossingevaluation

controls alarm messages on ‘border crossing’ events

enable/disable shock evaluation controls alarm messages on ‘shock’ events

enable/disable pressure evaluation controls alarm messages on ‘pressure’ events

enable/disable temperature evaluation controls alarm messages on ‘temperature’ events

enable/disable removal evaluation controls alarm messages on ‘removal’ events

enable/disable check of referencepoints

controls evaluation of reference points

reference point list contains several reference points which will be used for a comparison with the topicposition

enable/disable digital inputs masks the digital inputs, i.e. each input can be separately selected

recipients of user data contains identifications (phone numbers) of recipient(s) to whom the user data will besent

� $GPLQLVWUDWLRQ

white list of admitted users list of up to 5 identifications (phone numbers) of users, who are allowed to access the unit


� $GGLWLRQDO�6SHFLDO�3DUDPHWHUV��LPSOHPHQWHG�E\�.77�

power thresholds thresholds for ‘low power detection’

GPS time-out max. allowed time for acquiring a position fix

HW profile enable/disable HW components (e.g. GPS receiver)

GSM activation profile independently of the operation mode the OBT can be configured to activate its GSM device for receivingany SMS-messages (e.g. new configuration data or data requests)


�� $SSOLFDWLRQ

Summery of the OBT operation (the functionality of the FIRE application hasbeen described in OBT HW/SW Requirement Specification -D5 ):

When the OBT powers up, it first checks its power supply. Next are allconnected devices activated and checked for correct operation/configuration.These devices are mainly the GSM and GPS modules and the on boardmemory. The values of the external sensors (if enabled) are acquired andstored. When the internal check has been finished, the state is shown by thegreen LED and afterwards the topic data will be formatted into a standard SMSmessage and sent to its default destination.

The Local Check Mode and Boot Mode were combined, because any relevantdata/parameters are stored in non volatile memory. When no valid configurationdata has been detected on the power up, the OBT will use default values.

According the activation cycle for Normal Mode, the unit ‘wakes up’, activatesit’s communication device and is able to receive any messages. Dependent ofthe configuration, the position and the other sensor data will be acquired andtransmitted to the specific recipients. In this state the possibly configuredreference points are compared with the present position and will immediatelygenerate a ‘reached reference point’ - message. After these actions thesystems switches back to Stand By Mode to save energy.

Only in Normal Continuous Mode the OBT stays active and is constantly able to receiveand transmit messages. With the exception of the power up phase, all enabled sensorinputs are monitored continuously and will immediately start the Alarm Mode, where allstandard user data will be acquired and transmitted


� 3LFWXUH�RI�2%7


�

,QVWDOODWLRQ�RI�2%7


2%7�ILWWLQJ�IUDPH


�� 0DUFRQL¶V�2%7�,PSOHPHQWDWLRQ�� +DUGZDUH�$UFKLWHFWXUH

The On Board Terminal is built up with the following modules :

• Central Processing Unit

• Localisation Unit

• Communication Unit

• I/O Interface

• Power Unit

� �&HQWUDO�3URFHVVLQJ�8QLW

The Central Processing Unit is an Intel 386 microprocessor with a 2 MbytesDRAM and a 8 Mbytes Flash memory, which is its Solid State Disk.

� �/RFDOLVDWLRQ�8QLW

The Localisation Unit is a 6-channels GPS receiver with the relevant antenna(gain 26 dB)

� &RPPXQLFDWLRQ�8QLW

The Communication Unit is a GSM transceiver, with SMS capability

� �,�2�,QWHUIDFH

The I/O Interface allows monitoring of

- shock

- removal

- low battery level

via dedicated sensors.� �3RZHU�8QLW

The Power Unit is a 12 V rechargeable battery, in a separate case.

�� 2%7¶V�7HFKQLFDO�&KDUDFWHULVWLFV

• Dimensions: 292 x 213 x 130 (including the battery case)

• Weigth: 12.5 Kg (including the battery case)

• Operation Temperature: - 20°C t


�� 6RIWZDUH�$UFKLWHFWXUH

The Software Architecture is shown in the following figure

GPS Data

GSM

allar

Sensors Data

'DWD%DVH

5HIHUHQFH3RLQWV

0DQDJHPHQW

3RZHU

0DQDJHPHQW

0HVVDJHV

3URFHVVLQJ

*36

&RPPXQLF�

0DQDJHP�

'DWD3URFHVVLQJ


� 3RZHU�0DQDJHPHQW

This function controls the OBT’s status, switching off and on the GPS and GSMmodules accordingly to the configurated schedule stored in the Data Base.

� *36�'DWD�+DQGOLQJ

This function acquires positioning data from the GPS receiver and convertsthem in the transmission format.

� 5HIHUHQFH�3RLQWV�0DQDJHPHQW

This function verifies whether the positon reached by the wagon is within thetolerance radius of one among the reference points stored in the Data Base: ifyes then the information is sent to the Center, else the distance from thenearest reference point is transmitted.

� &RPPXQLFDWLRQ�0DQDJHPHQW

This function prepares the short messages to be sent via GSM network andcontrols the validity of the received short messages. In the FIRE Pilot Operationphase, positioning data are sent to both the FIRE Center and a MarconiMonitoring Center. Incoming messages are accepted only if sent from anauthorized GSM number.

� 0HVVDJHV�3URFHVVLQJ

This function answers to localization and configuraton enquiries and up-datesthe Data Base accordingly to the received data.

� 'DWD�SURFHVVLQJ

This function checks the values of the sensor controlled parameters, activatingthe Power Management module if the fixed threshold has been trespassed.


�� 2%7¶V�,167$//$7,21

� :DJRQ¶V�VHW�XS

An anchor plate has to be soldered to the rear wall of the wagon, in the upperpart.

The dimensions of this plate are 197 x 391 mm. ; four threaded pins 8 x 20 are atthe four corners of the plate.

� 2%7¶V�$VVHPEO\

The OBT’s assembly is shown in the following picture: the OBT (lower case) andthe battery (upper case) are mounted between two lateral plates. The two holespresent on the lower part of each of these two plates have to match with thethreaded pins on the anchor plate.


� 2%7¶V�$QWHQQDV

The OBT’s antennas are visible in the following picture: the white one is the GPSantenna, the black one is the GSM antenna. The OBT’s installation on the anchorplate has to be made in such a way that the GSM antenna be in the lower part.


� 2%7¶V�$FWLYDWLRQ

In order to activate the installed OBT one has only to connect the battery to theOBT itself, via the dedicated link (see the following picture). The OBT willautomatically wake-up at the programmed time, switch on the GPS and GSMmodules and transmit positioning data and other information (if any) to both theFIRE Center and the Marconi Monitoring Center.


� %DWWHU\�6XEVWLWXWLRQ

The battery life is depending on the transmission profile which has beenprogrammed for the OBT. When the battery level has reached a fixed thresholdan alarm message is sent to the FIRE Center, so that a Marconi Serviceintervention may be planned for the battery substitution.


�� 3LORW�2SHUDWLRQ�6FHQDULR

The FIRE partners, in order to have meaningful results by the FIRE Pilot Service, selectedwagons, routes and consignments with the following criteria:

• Wagons which require simple installation activities and reduce devices damage risks

• Routes in the European area, which is adequately covered by GPS and GSM systems,mainly utilizing railway networks related to the FIRE partners

• Regular consignments, using always the same wagons, in order to have as many dataas possible during the Pilot phase.


�� 7UDQVSRUWDWLRQ�&KDUDFWHULVWLFV

,WDO\

• 7LOHV� FRQVLJQPHQWV� � from Reggio Emilia to Mannheim (Germany) . Thetransportation is by means of FS closed wagons H31 type and DB H29 type. This kindof wagons has particular dimensions and is not easy to find. Due to the high request(tiles are daily delivered and the average need amounts to 20 wagons) the wagons,after unloading, are sent again to the origin station. FS wants to monitor these wagonsbecause in some occasions it has been difficult to localize them, with meaningful wasteof time. The trains to wich the wagons are assigned are the train 40012, together withlotissement and extra-ordinary trains.

• 7LOHV�FRQVLJQPHQWV�from Reggio Emilia to Poland. The transportation is by means ofFS wagons G20 type. The wagons are assigned to the train 4733 POLRAIL in ReggioEmilia, arrive at Bologna and are assigned to train 47032 POLRAIL, in order to reachPoland.

• 7DEDF� FRQVLJQPHQWV� from Caserta to Russia (via Austria, Czech republic, Poland)The transportation, on behalf of Saima Avandero, is by means of FS wagons G20 type.There are 12 consignments per month.

• 6KRHV� FRQVLJQPHQWV� from Verona to Germany. The transportation, on behalf ofSaima Avandero, is by means of either FS wagons G1 type, or FS wagons G19Europe type, or private wagons. These groupage wagons are not daily running.

• &KHPLFDO� SURGXFWV� FRQVLJQPHQWV from Domodossola to London, Birmingham,Manchester (via Switzerland-France). The transportation, on behalf of SaimaAvandero, is by means of FS wagons H21 type. The chemical products are owned byTreibacher firm, Domodossola based, to which Saima Avandero offers customerclearing operations. The cosignments have not an high frequency.

*HUPDQ\

• &DU� FRQVLJQPHQWV� from Opel plant in Bochum Laer (Germany). The wagons aresupposed to run on the following relation:

1. Start: Bochum Laer (Germany)

2. To : Torrile S.Polo (Italy) via Basel/Chiasso (with DB/FS)

3. Further to: Messendorf (Austria) via Tarvisio (with FS/OeBB)

4. Further to: Bremerhaven (Germany) via Passau (with OeBB/DB)

Alternatively to: Saal/Donau (Germany) via Passau (with OeBB/DB)

5. Back to: Bochum Laer (Germany)


Nevertheless it is possible that position 3+4 might be skipped, e.g. the relation isjust:

Bochum Laer (Germany) to Torrile S. Polo (Italy) via Basel/Chiasso and backagain.

$XVWULD

• 6WHHO�FRQVLJQPHQWV�from Linz (Austria) to Germany and Italy. The transportation is bymeans of ILL steel shimmn (private wagon) 358 146 730 710. A sample of the routefollows:

- March 10, 2000 Sindelfingen (D)

- March 16, 2000 Torino (I)

- March 22, 2000 Koeln (D)

- April 7, 2000 Sindelfingen (D)

- April 12, 2000 Dingolfing (D)

• 6WHHO� FRQVLJQPHQWV� from Linz (Austria) to Germany, France and Italy. Thetransportation is by means of ILL steel shimmn (private wagon) 358 146 730 413. Asample of the route follows:

- March 13, 2000 Kaiserslautern (D)

- March 18, 2000 Muenchen (D)

- March 22, 2000 Neckarlsum (D)

- March 28, 2000 Mulhou (F)

- April 6, 2000 Torino (I)

6ZLW]HUODQG

• :DJRQV�UHVWDXUDQW�PRQLWRULQJ�via AVI system.


�� /RJLVWLF

2%7�,QVWDOODWLRQ

OBTs have been installed at the following sites:

• Bologna (Italy) by KTT and Marconi

• Caserta (Italy) by Marconi

• Domodossola (Italy) by KTT and Marconi

• Verona (Italy) by KTT

• Maschen (Germany) by KTT

• Oberhausen i.B. (Germany) by KTT

• Salzgitter (Germany) by KTT

• Linz (Austria) by Marconi

)LUH�6HUYLFH�3URYLGHU

The FIRE Service Provider is in London (United Kingdom).

A Marconi’s Monitoring Center, which communicates with the Marconi’s OBTs, is inGiugliano (Italy).

$FFHVV�3RLQWV

Access Points are scattered at the FIRE partners premises, such as:

• Bologna (Italy)

• Giugliano (Italy)

• Milano (Italy)

• Roma (Italy)

• Eschborn (Germany)

• Gilching (Germany)

• Luenen (Germany)

• Linz (Austria)

• Vienna (Austria)

Further Access Points are available at the premises of the ‘Railway Users Group’ partners.

�� $VVHVVPHQW�)RUP


In order to have a concise and meaningful way for evaluating the FIRE Pilotresults, the following assessment form was prepared.

Name:

Address:

Title:

Telephone Fax

E-Mail

Type of User:

Organisation Type:

Organisation Name:

),5(�$FFHVV�4XHVWLRQV�

Was Access easy?

How often did You access?

Once You knew how to use it,

were there any problems?

Were the problems:

7HFKQLFDO

8VDELOLW\

$YDLODELOLW\

),5(�,QIRUPDWLRQ�4XHVWLRQV

Was the information well presented?

Was the information useful?

$ERXW�ZDJRQV"

$ERXW�WUDLQV"

$ERXW�FRQVLJQPHQWV"

��What improvement would You like to see?

Given wider availability, would

You be interested in a full service?

Experience of the security areas is

limited, but would You consider them?

How would You like to see security extended?


�� ),5(�$FFHVV�� 7HFKQLFDO�3UREOHPV

The reports of the FIRE operators are complaining that the access to the FIRE site wasnot fully satisfactory, due to technical problems: many times the server in the working timeinterval was not reachable. The reasons have been found in problems with the WebService Provider and in a defective modem, which was substituted.

SEMA agreed to prolong the Pilot Service operation until May 31, 2000 in order tocompensate the malfunctioning. In this way, in spite of the initial hard context, the FIREpartners could have material enough for the assessment of the Pilot Service.

�� 8VDELOLW\

Once entered the system, there was no difficulty in the use of its facilities. The menusrelevant to the different users classes were well articulated and the output forms containedall the information one could expect.The level of friendliness was good.

�� $YDLODELOLW\

Data have been available during the whole trial period, with the only exception of the“black hole” in the month of February. The immediate discovery of the InformationGateway anomaly, thanks to the Marconi’s Monitoring Center, and its prompt settling bySEMA helped to maintain the validity and the significance of Pilot Service Operation.

�� ),5(�,QIRUPDWLRQ

�� 3UHVHQWDWLRQ

The presentation quality level was on the average.

Some improvements on the map display have been suggested and could be introduced inthe FIRE Full Service.

�� 8VHIXOQHVV

The information about wagons has been judged useful. The correlation between theposition data and the train schedule gave to the users the possibility of knowing theestimated time of arrival, what is a precious datum for freight transport operators.

�� 6XJJHVWLRQV

FIRE system has been designed to be open to handle positions obtained in whicheverway: in the FIRE Pilot Service there was a connection to the AVI system, which sent every3 hours the position of 10 wagon restaurant (SBB owned).

Some suggestion has been made to adopt AVI system as the main localization system,but its obsolescence and the fact that the investment should be shared betweenInfrastructure and Freight Divisions does not support such a decision. Localization viaGPS seems to be the best choice at the moment, however the GSM localizationdevelopment should be taken care of.


�� 6HFXULW\

The FIRE security system is based on an user classification, which differentiatesthe allowable facilities, and on a password, which circumscribes the wagons onehas control over, uses of or owns

�� &RQFOXVLRQV

The original idea of the EU to fund FIRE, was to provide an information platform(for wagon tracking) for the future One Stop Shops. It was fulfilled: the FIREService Provider (respectively the FIRE Gateway) integrates infrastructure andcargo data. The ways to get there were very complex.The problems could bedescribed as following:

- a general fear of rail operators to pass on information’s to external partners(example: time table transfer for the delay software of FIRE)

- There is a strong technology-oriented thinking in the rail world.

Consequences: railways deny to outsource any information service (like theFIRE Service Provider).

- RCCs think themselves as opponents, not as partners against road

- Railways often are waiting for the UIC to do something, e.g. to define an IT-strategy

- 4 RCCs formed in 1998 the International Service Reliability Group. Theywanted to create a data platform-similar to the FIRE Gateway. Trials to getinto contact with ISR (to not duplicate work) were without success.

Despite all those rather negative background aspects FIRE created severalUSPs (Unique Selling Points):

- consignment orientation (instead of wagon orientation, as present GPS-products)

- integration with train numbers

- delay indication on the basis of the time table of the wagon

- modular architecture of the software

- specifications for the On Board Terminal, FIRE-Gateway and definition ofinterfaces as a basis for future standardisation

- low complexity, stand alone operation

- integration of UIC-data frameworks (like HERMES-information = packages)

- demonstration of data security

The FIRE Service Provider product is now at hand, the hardware (On BoardTerminals) is available on the market. The commercial breakthrough will onlyhappen, if one Rail Cargo operator will define a business case with the FIRE-product as a tool. Through this procedure the FIRE concept could betransferred more believable to possible FIRE "clients".

In the meantime the FIRE consortium will offer to UIC a discussion about theFIRE specs as a basis for a possible UIC-standardization of GPS datatransfers.

�� $QQH[HV

The list of publications, conferences, presentations related to the projectcomprehends:

½ Presentation to the Pushing Group of UIC Infrastructure (Sep. 4th 1998)

½ Presentation at the 5th World Congress on Intelligent Transport Systems (Seoul,Korea, Oct. 12th –16th 1998)

½ Presentation at the Conference “Shaping the Future of Rail II” (Feb.11th1999)

½ Paper at the ’99 World Congress on Railway Research (WCRR99)

½ Presentation to Finnish Railways representatives (May 6th 1999)

½ Presentation at the Conference “Shaping the Future of Rail III”(Jan.28th2000)

½ Presentation to the “Railway Users Group” (Jan. 28th 2000)

�� 5HIHUHQFHV

• Assessment of User Needs Document

• System/Subsystem Specification & System/Subsystem Design

• IG, CIS, AP Hw/Sw Requirements Specifications

• OBT Hw/Sw Requirements Specifications

• System/Subsystem Functional Outline

• KTT’s OBT Hw/Sw Design Description

• Marconi’s OBT Hw/Sw Design Description

• Pilot Set Up Final Report

• Pilot Service Status Report

• FIRE Web page

FIRE - Final Report

Documents

Transcript of FIRE - Final Report