Philips J. Res. 48 (1995) 315-334 R1303

SOCRATES: APPLICATIONS AND ARCHITECTURE

by F. ZIJDERHAND

Philip. Journal of Research Vol. 48 No. 4 1995 315

Philips Research Laboratories, Prof Holstlaan 4, 5656 AA Eindhoven, The Netherlands

Abstract

SOCRATES uses cellular radio systems for duplex communicationbetween vehicles and information centres to provide Road TransportInformaties applications. These applications, such as dynamic routeguidance and driver information but also fleet management, are describedin detail. The corresponding requirements (functions as well as neededtransmission capacities) are given, they formed the basis for theSOCRATES architecture and the corresponding application data andtransport layer protocols. The SOCRATES architecture is designed as apacket-switched network, all information is transmitted in short, indepen-dent datagram messages. The resulted architecture is open and flexibleandwell prepared for future, yet unforeseen extensions.

Keywords: SOCRATES, RTl, architecture, applications, dynamic routeguidance, driver information, fleet management, GSM, opensystem

1. Introduetion

During the last decades electronics has entered homes and officesof peoplesignificantly. Introduetion in vehicles has been lacking behind, however. Whileat a large scale people got used to televisions, video recorders, stereo sets,personal computers, etc., for a long time the car radio remained the mainelectronic component in the vehicles. In the beginning of the 1980s the firstchange was the fast penetration of mobile phones, while in parallel moreand more electronics is used for motor management (e.g. electronicinjection, ABS, etc.). However, during the last years it has become apparentthat electronics will play a strongly increasing role in the vehicles. PRO-METHEUSI) estimated in 1987 that on average the cost of the electrical andelectronic parts of a vehicle will rise to about 25% of the total cost of avehicle in the year 2000.

F. Zijderhand

Since the mid 1980s in Europe, USA and Japan large governmentalprogrammes have been initiated to stimulate the Research and Developmentin the so-called Transport Telematics areas2-4). In the framework of theEuropean DRIVE 1 (1989-1991) and DRIVE 2 (1992-1994) programmes,several consortia of European companies have been working on thedevelopment of the SOCRATES system. SOCRATES stands for System OfCellular Radio for Traffic Efficiency and Safety. It is initiated by PhilipsResearch in Eindhoven in 1987. Right from the start it was clear thatcooperation on a wide scale was required to evolve SOCRATES towards aEuropean system. For this reason cooperation was set up between companieswith specific know-how (e.g. authorities, telecommunication companies, carindustries) and also with potential competitors (Bosch and Siemens). Currentlymore' than 40 European companies are working on and investing inSOCRATES developments with a total effort of more than 250man years dur-ing 1992-1994.

SOCRATES uses Cellular Radio (and in particular the GSM (Global Systemfor Mobile Radios) mobile-telephone system) to provide a duplex com-munication link between vehicles and fixed-side centres. The communicationforms an important, but relatively small part of the total SOCRATESdevelopments. SOCRATES is one of the few initiatives that cover in acomplete system approach many Road Transport Informaties (RTl)applications (such as dynamic route guidance, driver information, emergencyservices, fleet management, parking information and public transportinformation). To provide these applications to the drivers involves develop-ment work in fixed-side centres, in communication systems and in in-carequipment.

The current paper forms part of a series offive papers each describing specifictopics related to SOCRATES6). The current paper focuses on the differentSOCRATES applications and the overall system design as it followed fromthe requirements for these applications. Sec. 2 gives an overview ofthe differentapplications as they are currently under test in the different SOCRATES pilotprojects. Sec. 3 describes the process how the application requirements have ledto the system design, while Sec. 4 describes the SOCRATES architecture as itresults from the application requirements.

Integration of different applications as well as being open to future, newapplications, is of vital importance for SOCRATES. Among others, a flex-ible, well structured application data protocol is required to enable this inte-gration and to facilitate for future extensions. Sec. 5 gives a shortintroduetion to the SOCRATES application data protocol and its correspond-ing message control protocol.

316 PhlUps Journal of Research Vol.48 No.4 1995

SOCRATES: applications and architecture

2. The socrates applications

2.1. Overview of the applications

SOCRATES is a full travel support system. It provides support to thetraveller (driver or passenger) during the complete trip. It gives pre-trip infor-mation, guidance during the trip on how to drive or how to use public trans-port, it gives warnings, it gives support during incidents and supports fleetmanagement.

SOCRATES provides six main RTl applications, while it is designed toinclude also other, possibly yet unknown applications. The applications cur-rently included are:

Dynamic route guidance (DRG),Driver information (DI),Emergency services (ES),Parking information (PI),Public transport information (PI'I) andFleet management (FM).

Table 1 gives an overview of these applications together with some of theirmain functions. All the functions mentioned in Table 1 are currently imple-mented and they will be evaluated during July-Dec. 1994 in the threeSOCRATES Pilot projects: RHAPIT, TANGO and APPLE6).

All functions mentioned in Table 1 are accessible when the car stands still.For safety reasons only a part ofthe functions are available to the driver whiledriving.The main functions from Table 1 are described in more detail in the next

sections.The third column of this table indicates the network requirements of the

functions. DL, UL, BC, GA, PP, Emer. and Ano mean downlink, uplink,broadcast, general address, point to point, emergency priority and anonym-ity, respectively. They are further explained in Sec. 3.

Philips Journalof Research Vol. 48 No. 4 1995 317

2.2. Dynamic route guidance

Route Guidance is the major application of SOCRATES. In fact,SOCRATES is initiated in 1987 with the aim to provide autonomousin-car navigation computers such as the PHILlPS CARiN and theBOSCH TRAVELPILOT systems with real-time traffic information.Dynamic route guidance systems have in principle the following fourfunctions:

F. Zijderhand

TABLE 1Functions and main network requirements.

Applications Main functions Networkrequirements

ES

Determine vehicle positionPlan optimal route (with dynamic traffic data)Provide guidance to driverSend floating car data to traffic centreDisplay ALERT-C messages and free textDisplay map with traffic informationGive information about speciallocationsSend emergency call to emergency centreSend free text notification to vehicleLocate the vehicle after theft

PI Provide information about parking

DLBCDRG

DIULGAAno.DLBCDLBCDLBCULGAEmer.DL PP Emer.DL ULPP

occupancies DL BCInform drivers about parking features DL BC

PTI Inform drivers about public station features DL BCInform drivers about public transp. time tables DL BCProvide park + ride information DL BCProvide park + ride advises DL BC

FM Send position/status reports to fleet centre UL DL PPPoll for a report by the fleet centre DL UL PPSend free text to a vehicle's mail-box DL PP

318 Phllips Journal of Research Vol.48 No.4 1995

2.2.1. Determine vehicleposition

Using a compass, odometers (or ABS pulses), a GPS (Global PositionSystem) receiver and/or map matching, the navigation computer continuouslykeeps track ofthe vehicle's position. The position accuracy with e.g. the PHI-LIPS CARiN system is about 10 to 20 m. The map-matching algorithm relatesthe measured positions to the digital map and reduces in this way the cumulativeposition errors.

2.2.2. Plan optimal route (with dynamic traffic data)

The navigation computer calculates the optimal route using the digital mapwhich is available in the car on e.g. CD-ROM; typically the time needed for

PbJlIps Journal of Research Vol. 48 No. 4 1995 319

SOCRATES: applications and architecture

this calculation is about 5-10 s. The driver can specify criteria for an 'optimal'planning; depending on the situation this can be e.g. the fastest or the shortestroute, but also a tourist route, avoiding highways (or not), avoiding toll-roads,etc. Tests during the CARiN product development phase have shown that acombination of time and distance optimisation provides routes which cor-respond best to the choices a human being would make. SOCRATES addsreal-time traffic information to these autonomous systems. The route planneruses the information available on the CD-ROM in the car and in addition takesinto account the information received dynamically from the traffic centre(s).These dynamic data consist of three groups of data:

1)Detailed traffic data about current and predicted travel times (in seconds)for every road element of the network.2) ALERT-C messages") describing qualitatively the traffic and weather

situations in areas and on stretches of road between major crossings.SOCRATES is fully compatible with the ALERT-C protocol.3) As 1), but with traffic control parameters instead of the real-time para-

meters to provide traffic centres a means to manage the traffic.

After reception of new traffic data (but also when the driver deviates from hisroute) the route planner automatically recalculates a new route.

2.2.3. Provide guidance to the driver

Before each crossing the driver is provided with information how to continuehis route. This information is givenvia speech (e.g. 'Take first turning left') andbacked up with a simple display (seeFig 1).An accurate car position is requiredto provide the guidance at exactly the right moment. Before the start of the tripthe driver can ask the system to display a map with the planned route and theroad elements for which dynamic traffic data is received. This pre-trip infor-mation can be regarded as a simple, but useful form of guidance.

2.2.4. Sendfloating car data to traffic centre

Traffic centres have significant amounts of traffic data, but these are mostlylimited to only a part ofthe network (e.g. mainly highways) and are not alwaysas detailed as can be used by SOCRATES. The vehicles equipped withSOCRATES can determine their own travel times from crossing to crossingat any road element. This information, called floating car data, is sent anony-mously to the traffic centre where it is used to improve the available trafficdata. Studies have shown") that when 1-2% of the vehicles on the road are

F. Zijderhand

Fig. 1. A guidance pictogram.

sending their information to the traffic centre(s) a good overview of the trafficflows can be obtained.

2.2.5. Driver information

Traffic information can be used by navigation systems to provide betterroutes as described in Sec. 2.2. It can also be used to inform and (if necessary)warn the driver directly about traffic and weather conditions. Provision ofinformation directly to the driver via speech and a display is covered in thefollowing sections.

320 Phllips Journalof Research Vol. 48 No. 4 1995

2.2.6. Display ALERT-C messages andfree text

ALERT-C messages") provide information about traffic and weather con-ditions. While driving they are displayed on the in-car screen in an easy-to-understand graphical form (see Fig. 2). While standing still the driver canscan through the message list, locate the problem area on the map and setsome preferences (e.g. to display only messages related to his current plannedroute).

RDS- TMC (Radio Data System-Traffic Message Channel) terminals") areunder development which generate spoken messages. This technology williaterbe integrated in SOCRATES.

In addition to the ALERT-C messages also free text messages can be sentfrom the traffic centre to the vehicles. They are treated in the cars in an identical

Philips Journalof Research Vol. 48 No. 4 1995 321

SOCRATES: applications and architecture

knooppunthintham

Fig. 2. An ALERT-C warning displayed by SOCRATES.

way as the ALERT-C messages. This allows traffic managers to provide alsoinformation about incidents which are not covered in the ALERT-C messagelist.

2.2.7. Display map with traffic information

While standing still, the driver can display the map with, among others, theplanned route and indications where traffic problems occur. This provides

present this message in text ...

Fig. 3. An example of map display.

F. Zijderhand

him with pre-trip information on how to drive and where to expect traffic prob-lems (see Fig. 3).

2.2.8. Give information about speciallocations

Speciallocations are e.g. restaurants, petrol stations, hotels, parking areas,etc. The database in the vehicle contains standard for each special locationsome general information such as type of location, the name and the address.SOeRA TES allows to add more information in additional data bases. Thisinformation can be displayed on request of the driver. It is foreseen for futureextensions that this information can be updated via the air also.

2.3. Emergency services

Emergency services provide help to the driver in cases where support fromothers is urgently needed. The cause for this can vary. Examples are accidentsand car breakdowns.

2.3.1. Send emergency call to emergency centre

Initiated by e.g a crash detector or (when still able to) by the driver, an emer-gency call, in the form of a digital datagram, can be sent to the nearest emer-gency centre. This call among others contains the cause of the incident:accident, driver attack, person unwell or car breakdown and additional detailscan be entered ifthe situation allows for it. In future extensions the list of causesmight be updated. The call also contains the position of the vehicle, togetherwith model and colour etc. to make it easier for the rescue people to find thevehicle.

322 Phlllps Journal of Research Vol.48 No.4 1995

2.3.2. Sendfree text notification to vehicle

In response to an emergency call the operator in the emergency centre cansend a free text message to the vehicle that requested support notifying thedriver about the reception of his message and giving the driver an estimatedtime of arrival of the rescue people. Several messages can be sent by theoperator, they are stored in a mail-box in the car.

2.3.3. Locate the vehicle after theft

When a car is stolen, its position can be retrieved on request of the car ownerby e.g. a police centre. The centre can transmit a polling message to the vehicle toreports its position. This is only possible when the car owner authorises the

Philips Journal of Research Vol.48 No.4 1995 323

SOCRATES: applications and architecture

centre for this action by disclaiming a security code of the in-car system.Connected to a burglar alarm the in-car system can generate and send auto-matically a message to the nearest equipped police centre.

2.4. Parking information

2.4.1. Provide information about parking occupancies

For as far as the information is available in parking guidance systems, theoccupancies (i.e. the total number of parking places and the number of freeparking places) can be transmitted to the vehicles. These include real-timeoccupancies as well as prediction values. This information is provided to thedriver and is used by the navigation system to determine the free parking closestto the destination.

2.4.2. Inform the driver about parking features

Besides the occupancies, there is more information about parking areas relevantto decide to use a parking or not. Examples are: costs, opening hours, type ofparking, connections to public transport, etc. All this kind of information canbe provided to the driver. In principle this information is stored in the in-cardatabase, but SOCRATES allows to broadcast dynamic updates of these para-meters as well.

2.5. Public transport information

2.5.1. Inform drivers about public station features

An important barrier for drivers to use public transport is a lack ofinforma-tion. Providing the necessary information willstimulate the use of public trans-port. As in the case of parking areas, the systemcan provide information aboutall kind of features of public transport stations, such as locations, names,addresses, opening times, connection to public transport lines, available park-ing areas, etc. This information can be static in the in-car database, but alsoupdated via broadcast of information.

2.5.2. Inform drivers about public transport time tables

A special form of providing information about public transport to the driveris the display ofthe time tables ofthe departures. Currently this is to provide thedriver with information on which he can base his choices to use public transport

F. Zijderhand

Fig. 4. Park + Ride Information.

or not. In future extensions these time tables can be used by the navigation com-puter for multi-modal route calculations.

324 Philips Journalof Research Vol.48 No.4 1995

2.5.3. Provide park + ride information

A special function using both parking and public transport information ispark + ride. SOCRATES informs the driver about the features of thepark + ride stations, which is a combination of the parking information andthe public transport information. In addition, the system informs him abouttravel time and costs via public transport, about the latest time of return inthe evening, about which line to take to his destination and even shows himhow to walk to his final destination from the station where he should leavethe public transport (see Fig. 4).

2.5.4. Provide park+ ride advice

Besides informing the driver about parking and public transport, theSOCRA TES system also advises the driver to use park + ride when that seemsappropriate. This is based on a number of criteria, which are currently: a) thevehicle must be in a certain area around the P + R station, b) the final desti-nation must be within a certain crow-fly distance from a public transportstation and c) this station is directly (without interchanges) reachable fromthe P + R station.

PhiUps Journalof Research Vol. 48 No. 4 1995 325

SOCRATES: applications and architecture

2.6. Fleet management

Fleet management is a SOCRATES application which will mainly be used inprofessional systems. Currently the basic functions such as position reports tothe fleet centre and free text to the drivers are included. But this can easily beextended to mature fleet management systems. Moreover, SOCRATESprovides this fleet management functions fully integrated with the five otherapplications mentioned above.

2.6.1. Send position/status reports to fleet centre

At regular intervals the vehicle sends amessage containing information aboutits position and about the status ofthe driver and cargo to the fleet centre. Thiscentre is able to control this transmission by sending control parameters to thevehicle, such as 'reporting on/off' or the time interval between two reports.Intelligent algorithms minimise the number of required transmissions asmuch as possible.

2.6.2. Pollfor a report by thefleet centre

The fleet centre can poll at any time a vehicle to initiate it to respond with aposition and status report. The current function together with the one fromSec. 2.7.1 provides the fleet operator with a means to continuously monitorthe position and the status of his vehicle fleet.

2.6.3. Sendfree text to a vehicle's mail-box

The fleet operator can at any moment generate a free text message and trans-mit that to a specificvehicle. In the vehicle the message is stored in a mail-boxwhich can be read by the driver. The driver is notified when a new messagehas been received.

2.7. Other applicationsfor future extensions

In the current phase of SOCRATES all the functions mentioned above havebeen implemented and are under evaluation in several pilot projects. The mostimportant functions have been selected in a extensive process, based on expec-tations about the possibility to implement them at this moment. In addition tothose mentioned there are many other functions which might become impor-tant. Some of these are:

Reservations for e.g. parking areas and others,Extended fleet management functions,

F. Zijderhand

Tourist information,Yellow pages information andRequest to databases at central computers.

3. From applications to architecture

3.1. The design process

The design of the SOCRATES Architecture posed some special problems,since many of the RTl functions can only be specified in detail after extensiveend-users tests, but an architecture is required to be able to do those tests. Inaddition the architecture must try to take into account also future, yet unfore-seen applications.Itwas decided to base the system design on two sets of considerations:

1)The requirements from the functions mentioned in Table 1.2) A number of general design rules.

These considerations are described in more detail in the Secs 3.2 and 3.3Besides the functional requirements ('how must the data be handled by the

network') also the required data capacities have been investigated. Sec. 3.4gives an overview of the estimates resulted from that work.The design has been implemented in several pilot projects. Validation is

currently under way in the corresponding SOCRATES pilot projects and isplanned to continue on a larger scale in the DRIVE 3/4th FRAMEWORKprojects.

326 Phllips Journnl of Research Vol. 48 No. 4 1995

3.2. The requirements from the functions

Table 1in Sec. 2.1 gives an overview of the SOCRATES functions as they arecurrently considered. The third column of this table gives indications of therequirements of these function for the SOCRATES communication network.The following abbreviations are used in Table 2:

• DL (downlink): information from fixed-side to vehicles.• UL (uplink): information from vehicle to fixed-side.• BC (broadcast): informátion broadcasted to the vehicles• GA (general address): information from a vehicle to a general addresswhich is not known in the vehicle, e.g. 'to the nearest traffic centre'.

• pp (point-to-point): information between two specificprocesses, e.g. one ina specific vehicle and one in a specific fixed-side computer.

• Emer. (emergency priority): these functions require information to be sentwith a high priority.

SOCRATES: applications and architecture

TABLE2Summary ofthe network requirements.

Requirement Description

All information must be structured in small, fullyindependent digital datagrams (called messages in thispaper)For each message it must be possible to indicate ageographical area in which it must be broadcastedFor each message it must be possible to indicate theperiod during which the message must bebroadcastedFor each message it must be possible to indicate howoften the message must be broadcasted during thevalidation timePoint-to-point transmission of messages (in contrast tobroadcast) must be possible from any address to anyother; even when they are in different networksDifferent priority levels are requiredDifferent reliability levels are requiredSome type of messages must be transmittedanonymouslyDifferent levels of allowable delays through thenetwork are requiredSome, but not all, messages need an identification of thesource of the message

Destination identifier All messages need a destination address. This can be aspecific as well as a general address (such as 'nearesttraffic centre')

• Ano. (anonymous): This function requires the information to be sentanonymous.

Only a relatively small portion of the requirements is indicated in Table 1. Inthe way indicated in this table, a survey has been made of all the informationflows needed by the functions and the corresponding requirements deter-mined. A very important next step in the process was to generalise the require-ments of the functions. Each function has a specific set of requirements. Thesedifferent sets are combined together to one overall set of requirements. The

Message oriented

Area broadcast

Validation time

Repetition time

Singlecast

Priority levelsReliability levelsAnonymity

Delays

Source identifier

Philips Journalof Research Vol. 48 No. 4 1995 327

F. Zijderhand

design of the system is made according to this overall set. As an example con-sider the following.

Only the transmission of an emergency call to an emergency centre requiresthat its information is transmitted with some kind of emergency priority. In astraightforward design the emergency call would have this priority by default,while the other functions would not. However, in the SOCRATES design itwas argued that since an emergency priority is needed for .one function, itmust be available for all functions. This now means that the SOCRATES archi-tecture allows for all functions to send amessage with emergency priority, whichmight be useful e.g. for a fleet centre sending a message to one of his drivers.

The most important result of this reasoning was that the requirements havebecome function independent and that the architecture isbetter capable of deal-ing with future extensions. Moreover, it has made the design simpler and betterstructured, without many exceptions and special cases.This has led to the sum-mary ofrequirements given in Table 2 (see12) for more details).

3.3. General design rules

A number of general design rules have been defined and strictly applied in thedesign process. Systems such as SOCRATES tend to becomeprohibitively com-plex if the design is not structured with great care. 'To keep the design as simpleas possible at all levels' has been one of the main general rules.

In the design process the following rules were applied:

• The architecture must be independent of the applications.• The architecture must cover at least all functions from Table 1.• The architecture must be independent of the communication bearers.• The architecture must be independent of any specifichardware used.• The architecture must be as simple as possible.• The architecture must be open for connections to other systems at different

levels: at application level, at transport layer level, at communication sys-tem level. This implies that when SOCRATES uses a communication sys-tem, it must always be possible for other non-SOCRATES applications touse this communication system also, e.g. in a time-sharing way.

• The architecture must be open for future extensions.• All communication is based on single, independent digital datagrams

(messages). No message should be dependent on the reception or availabil-ity of an other message.

• All communication is based on store and forward of these messages.• The use of acknowledgements has been prevented as much as possible.

328 Philip. Journal of Research Vol.48 No.4 1995

PhiUps Journal of Research Vol.48 No.4 1995 329

SOCRATES: applications and architecture

• All SOCRATES modules communicate with just one common transport'layer protocol.

• The fixed-side centres must not be aware ofthe structures ofthe in-car net-works and vice versa.

• The messages can have variable lengths determined by the applications(and not by a communication system).

• The architecture must be designed for 'graceful degradation', which meansthat it does not completely break down when problems occur, but that itonly reduces the level of service.

• The architecture must be designed for 'graceful introduction', which meansthat the system can be introduced with a limited level of service (e.g. withrespect to the available information, the area covered, the communicationcapacitiës, etc.) and that the system will improve when these servicesimprove.

• The architecture must use as much as possible existing traffic (and other)centres, networks and communication systems and the functions theyprovide.

• The amount of data through the air must be as small as possible, but thisshould not be at the expense of increasing the complexity of the architec-ture.

All above mentioned general design rules have been applied in the design andthe resulted architecture as described in Sec.4 fully complies with these rules.

3.4. Estimates of the data capacity requirements

The required capacities for the data communications in RTl systems is diffi-cult to estimate at this moment. They heavily depend on the data which will beavailable, as well as on the way in which the functions will be implemented.Moreover, there is a large variation in the capacity needed, consider e.g. trafficdata during rush hours and during the night. Based on information from otherprojects and on expectations of the data needed by the SOCRATES functions,worst-case estimates have been made which are believed to give indications ofthe capacity requirements for the air link between a typical GSM base stationand the group of vehicles in its transmission area.These estimates showed that for both the downlink and the uplink the

dynamic route guidance application needs the largest capacity: in worst-casesituations about 5-8 kbit S-I of information to be sent to the cars and about2-3 kbit S-I per GSM cell to receive floating car data from the vehicles. TheDI, ES, PI and PTI applications need much less capacity. The capacity neededfor fleet management is depending on the number of vehicles involved. Per

F. Zijderhand

Fixed-sideNetwork(s)

CommunicationNetwork(s)

m-VehicleNetwork(s)

330 Philips Journalof Research Vol. 48 No. 4 1995

Fig. 5. The SOeRA TES architecture.

vehicle the capacity is also rather low (e.g. a status report every 5min up to every24 h).

4. The SOCRATES architecture

Fig. 5 shows schematically the SOCRATES architecture as resulted from theconsiderations as described in Sec. 3. In the current section the SOCRATESarchitecture is briefly described. Ref. 10 gives a detailed description of theimplementation ofthe architecture in the SOCRATES pilots.

The SOCRATES network is in fact a packet-switched network, capable ofrouting a message from any data source to any data destination and capableof using different networks connected by gateways. In the fixed-side net-work(s) and in the in-vehicle network(s) (as shown in Fig. 5) there are manysources and destinations. SOCRATES integrates both point-to-point andbroadcast/general-addressed uplink communications between these sourcesand destinations.

The networks shown as grey areas in Fig. 5 may have different transportlayers. Interoperability over different networks for the SOCRATES messageshave been achieved by introducing a Message Control Protocol (MCP, seeSec. 5), which is in fact a header for each SOCRATES message. The gatewaysare able to interpret these headers and to forward the messages accordingly intothe next network.

As can be seen in Fig. 5, all SOCRATES modules contain an interface

SOCRATES: applications and architecture

(indicated as 'Int.') which converts internal protocols into the generalSOCRATES protocol. This general protocol consists of the SOCRATESApplication Data (AD) and the Message Control Protocol as described inSec. 5. It is due to this general protocol (which is submitted for standardisationto CEN TC278) that the different modules can communicate with each otherand that new modules can easily be added.For point-to-point communication the gateways ensure among others a

proper routing ofthe messages. For the broadcast and general-address uplinkcommunication the gateways around the communication networks need to per-form more tasks. They ensure that the underlying communication networkshandles the messages according to the requirements as mentioned in Table 2.Among others they 'enhance' the communication network to broadcast infor-mation during a certain period (the validation time) at regular intervals (therepetition time) in a certain geographical area.In the vehicle the gateway provides among others a subscription function.

The broadcast information cannot be sent to a specific address in the vehicle,since the structure of the in-vehicle network should not be known by thefixed-side networks (see the general design rules). Much better and moreflexible is the current design in which the in-vehicle application processes tellthe in-car gateway which broadcast messages they want to receive. In thisway it is also easily possible for different processes to receive (i.e. to subscribeto) the same message.The gateways at the fixed-side provide an comparable function for the uplink

data with a general address. The cars do not know the addresses of e.g. the near-est traffic or emergency centre, therefore those uplink messages are forwardedby the fixed-side gateways to the most appropriate centres.

PhlUps Journal of Research Vol. 48 No. 4 1995 331

5. The SOCRATES Application Data Protocol

The SOCRATES Application Data Protocol (ADP) consist oftwo separateparts 11): the Application Data (AD) of the messages and 2) the Message ControlProtocol (MCP) to specify to the network how the message must be handled.

The MCP is a message header which contains communication parametersaccording to the requirements mentioned in Table 2. They specify (when neces-sary) the broadcasting area, the validation and repetition times, the priority, thedestination address, etc.The information (MCP and AD) is entered by the source application process

into the application layer of the network. It is routed via different gateways (ifnecessary) to the network which contains the destination application process. Inthis network the AD is delivered to the destination process. The gateways are

F. Zijderhand

not allowed to make use of any information in the AD, but they can change thecontents ofthe MCP where appropriate.

Several mobile data communication systems do exist today already. TheSOCRATES architecture together with the MCP protocol, however, has cre-ated a mobile data network. In fact SOCRATES extends the existing computernetwork in officesinto the vehicles in a transparent way. As an example, one canconnect a laptop PC which uses the Internet network to the SOCRATES in-carequipment in the same way as one would do at the office. Information send to anInternet address and given to the SOCRATES in-car gateway will be routed tothe required address, where ever it is in the world. Currently this operates usingthe UDP/IP (User Datagram Protocol/Internet) connection, but also the TCP/lP connection and other network connections will be integrated.

About twenty different SOCRATES messages have been specified. Theycover the needs for all the functions of Table 1.Common information elementshave been defined (such as for location or time) and used as much as possible.The messages also have a common structure, they all start with a protocoldiscriminator (to allow a compatible cooperation with other protocols) and amessage type indicator (which specifies the type of data in the message). Thereis also a mechanism of combining several messages of one type into one biggermessage to reduce the transmission overhead caused by the message headers.

The information elements in the messages have been coded in a way to use asfew bits as possible without losing functionality or flexibility. Estimates haveshown that e.g. in Germany in the year 2000 the costs for broadcasting RTlinformation might be in the order of 30-60 million DM per year. Typical sizesof the SOCRATES messages are around 300 bits (incl. overhead). This meansthat the addition ofjust one extra bit in each ofthemessages would increase thecommunication costs by 100-200 thousand DM per year. Or roughly speaking,each byte costs 1million DM per year.

The SOCRATES ADP (AD and MCP) have been submitted for standardisa-tion to CEN TC278 WG4.3; the publication of a draft standard is planned forDec. 1994.

332 Philip. Journal of Research Vol.48 No.4 1995

6. Conclusions

Within SOCRATES the main RTl applications have been defined and inte-grated into one common architecture to provide a full travel support system.SOCRATES uses among others the GSM mobile-telephone system which isthe best candidate for the pan-European RTl communication. The functionsas specified in SOCRATES are currently under validation to investigate theend-user acceptance of the functions. It is believed that the current level of ser-

Philips Journni of Research Vol.48 No.4 1995 333

SOCRATES: applications and architecture

vices of SOCRATES provides a sound basis for a first commercial introduction.However, more research is needed in parallel to study the large scale benefits totraffic management and to identify further required functions. SOCRATESalso shows how mobile data for fleet management can be integrated into oneEuropean RTl system which is used by private and professional users.

The SOCRATES architecture provides a well defined, open structure. Othersystems can be integrated at different levels with SOCRATES: new ADP mes-sages can be defined, other systems can use the MCP protocol and common useof the underlying networks and communication systems can bemade. AlthoughSOCRATES' aim is to provide RTl services, it has led to a general architecturewhich can be used for all kind of mobile data applications. In this senseSOCRATES created a true mobile data network.The importance of the introduetion of the MCP should not be under-

estimated. It ensures the interoperability between different networks and differ-ent communication bearers. And it achieves this interoperability without anychanges to the networks; the interfacing between networks is handled (at appli-cation level) by the gateways which perform the additional function required formobile data networking.

The SOCRATES Pilots have proven the technical feasibility and are nowvalidating the overall concepts and studying the acceptances of the end-usersand the benefits to traffic management with about 50 vehicles at different loca-tions in Europe. It is required, however, that large-scale projects (thousands ofcars) are conducted to identify the optimal organisational structures and toprove on a large scale the effects on the overall traffic of an RTl system basedon SOCRATES.

REFERENCESI) PROMETHEUS Project Description, Document Number 17-10002, July 1986, PRO-

METHEUS Secretariat.2) Advanced telematics in road transport, Proc. DRIVE Conf., Brussels, Feb. 4-6,1991, Elsevier,

Amsterdam (two volumes).3) J.L. Gifford et al., IVHS/ RTl institutional and environmental issues: A strategic policy research

and outreach agenda for the United States, Proc. VNIS Conf., Oslo, Sept. 1992.4) Universal Traffic Management System (UMTS) in Japan, Proc. VNIS Conf., Yokohama,

Sept. 1994.s) M. Mouly and M.-B. Pautet, The Evolution of GSM, in C.G. Gunther (Ed.), Mobile Com-

munications: Advanced Systems and Components, Springer, Heidelberg, 1994. .6) J. Biesterbos and F. Zijderhand, SOCRATES: A dynamic car navigation and driver

information system, Philips J. Res., 48, 299-313 (1995).7) ALERT-C Traffic Message Coding Protocol, Proposed Pre-Standard, RDS ALERT Consor-

tium, Nov. 1990.8) D. Boyce, Scope, Feasibility and cost of a dynamic route guidance system demonstration, Final

Report to Illinois Department of Transportation, 1990.9) M. de Groot, Rhine-Corridor: An RDS-TMC pilotfor radio traffic information, Proc. VNlS

F. Zijderhand

Conf., Oslo, Sept. 1993.10) D. Demery et al., All overview of the SOCRATES communication system, Philips J. Res. 48,

353-370 (1995).11) D. Demery et al., Traffic and travel messagesfor ill-vehicle applications, proposed pre-standard,

Report of Standardisation Group CEN TC278, WG 4.3, Sept. 1994.12) Draft Stage 2 Service Description OfThe GeneralPacket Radio Service (GPRS), vO.0.2,ETSI

STC TG-GPRS #2, Tdoc SMG/TG/GPRS 31/94.

AuthorsFrans Zijderhand: M.Sc. Experimental Physics, State University of Utrecht, NL, 1981; Ph.D.Nuclear Physics, State University of Utrecht, NL, 1986; Philips Research Laboratories, Eind-hoven, 1985-. Worked at Philips for two years on the development of Mobile Telephones.Worked since 1987 on the development of SOCRATES, first as system architect, later as projectleader and as technical manager. Is now responsible as project manager SOCRATES for the com-mercial introduetion of SOCRATES.

334 Philip. Journal of Research Vol.48 No.4 1995