1

TELEMATICS APPLICATION PROGRAMME

4th FWP - SECTOR Transport TelematicsDG XIII

IN-RESPONSE / TR 1030(INcident RESPonse with ON-line innovative SEnsing)

Incident Response Model

Transportation Systems & Logistics Laboratory (TRANSLOG)Athens University of Economics and Business

by

Evangelos Kotsakis

September 19th, 1997

2

1. Incident Response System Modelling

The Incident Response (IR) subsystem is responsible for handling any incidentmessage and providing the following services

• Districting• Dispatching• Routing• On-scene advises

The modelling technique used to analyse and design the IR system is the ObjectModelling Technique (OMT) [Rambaugh 1991]. The OMT allows us to combine threedifferent modelling views of the IR system. These three models named object model,dynamic model and functional model cover different aspects of the system and specifyrespectively the static, dynamic and functional insights of the IR subsystem.

1.1. Object ModelThe IR object model represents the static, structural data aspects of the system. The

IR object model is shown in Figure 12. This object model illustrates many objectmodelling constructs and shows how they fit together into IR system.

Class Response Server defines a server object that is used to receive incidentmessages. It defines methods for capturing a incoming incident message and creatingnew delegates. Each of these delegate is able to handle a single incident message. ClassSeverity defines common parameters of the severity of an incident including the type ofincident, number of disable vehicles, number of blocked lane, type of staled vehicles,injury severity, number of injured people. Class Location defines the location in thetopological graph of the covered area. A location may be identified by using the up-stream node. The class Location defines a single attribute specifying the ID of the up-stream node.

Class Incident defines parameters that describes all the historical attributes of theincident such as date, time, weather conditions, dispatching time, travel time and on-scene time. Most of these attributes are set by the delegate who handles the incidentmessage. Class Incident Store defines some methods for accessing the data base thatstores historical data. Class Response Unit Store defines some methods for accessingvehicle location data. This data store keep information about the location and availabilityof each Response Unit.

Class Expert defines an interface between a delegate and the expert system. Theresponsibilities of this object is to provide the requested advice to a particular delegate.The advice informs the delegate what kind of RU should be dispatched and with whatprecedence. An other responsibility of the class Expert is to provide the appropriate on-scene actions to a in charged delegate. Class Advocate defines parameters for identifyingthe response unit type needed, the priority with which it should be dispatched. An Adviceis just an aggregation of Advocates

Class Response Unit defines attributes and methods related with a particularresponse unit such as response unit ID, response unit type, default location of the

3

response unit, district ID, and a flag indicating the availability of the response unit. Mostof this data is provided by the Response Unit Store object.

Class Dispatching Scheduler is used to dispatch a particular response unit accordingthe severity of the incident and the priority that has been assigned by the expert system. Itcontains an entry for each demanded response unit. It always gives permission fordispatching to those delegate that demand the particular response unit with the greatestpriority. Class Delegate Entry is a simple structure defining the response unit ID, thepriority with which the response unit has to be dispatched, and the time waiting untilpermission is granted. All the delegate entries are available to the scheduler. If a delegategrants permission to dispatch a response unit, the corresponding delegate entry isremoved from the scheduler queue.Class Traffic Agent defines a server that receives traffic information such as averagespeed or traffic volume associated with certain parts of the topological graph of thecovered geographical area. This information will be received by the Traffic Agentregularly (say every 10 min.) as a UDP packet. Traffic information will be probablytransmitted by the GUI.Class Delegate is the hart of the whole system. It arranges all the interactions with otherobjects and it is the entity responsible for restoring the traffic flow forwarding anyappropriate on-scene action generated by the expert system.

1.2. Dynamic ModelThe dynamic model represents the temporal, behavioural, control aspects of the IRsystem and it is shown in Figure 9, Figure 10 and Figure 11..

The object response server (Figure 9) has two states named stand by and assigndelegate. Initially the response server is in the stand by state and it runs in an infiniteloop waiting an incident message to be received in the input port. When an incidentmessage is received, the response server abandons its current activity and transits to theassign delegate state. During its entry to this state, it creates a new delegate and passesthe incident message to this delegate. When it accomplishes this action transits back tothe stand by state waiting again for a new incident message.

The object expert (Figure 9) has a similar structure as the response server. It initiallyenters the stand by state and waits for a severity message. When this messages isreceived, the expert transits to the estimate severity state in which an advice is preparedand sent to the relative delegate. When this actions is accomplished, it returns back to thestand by state waiting for the next severity message.

The object dispatching scheduler (Figure 10)is an autonomous server with a similarstructures as the previous ones, but it is time driven. It waits for a predefined timeinterval (say 10 sec.) and when this time period elapses it transits to a state calleddelegate checking in which it checks each delegate entry in its queue to see which entryhas the greatest priority in order to grant permission and allows the relative delegate todispatch the desired response unit.

The object Traffic Agent (Figure 10) waits in an infinite loop for a traffic message tobe received. When such a message is received, it transits to the update state and updatesthe weight table which keeps information about the time needed to move from one nodeto an other in the topological graph.

4

The object delegate (Figure 11) has three states, named dispatching, routing and on-scene actions. It initially enters the dispatching state. As long as it is in that state, itdecodes the incident message and sends the severity message to the expert. The expertprocesses the severity message and send back to the delegate its advice. When the adviceis received, the delegate issues a permission request to the dispatching scheduler makingan entry for each desired response unit in the dispatching scheduler queue. When thedispatching scheduler issues a permission, the delegates transits to the routing state inorder to route the desired response unit to the destination incident site. When the RUreaches the incident site it will send back to the delegate a message saying so. When thedelegate receives this message it transits to the on-scene actions state. In this final statethe delegate performs all the desired steps for accomplishing the task of forwarding allthe necessary on-scene messages. When the on-scene activities end, the delegate mayreport the incident information (such as dispatching time, travel time, on-scene time etc.)to a historical data store before it is removed from the system by freeing any previouslyoccupied system resources.

1.3. Functional ModelThe functional model represents the transformational, functioning aspects of the IR

system. A top functional graph is shown in Figure 1. A finer grain functionaldecomposition will be documented later during the development. External data needed tobe provided by other modules are the following:

• Incident message. It is provided by the verification subsystem. It is discussed insection 3 on page 8

• Vehicle location data. It is provided by the database D1. This data comes to theincident response subsystem in a request/response way.

• Traffic message. It is provided by --------. It indicates the traffic flow rate at allthe edges of the topological graph which represents the covered geographicalarea. Its form is discussed in section 6 on page 15.

• Topological graph. It represents the geographical area in a mathematical way. Itis provided once by the GIS or the In-Response manager.

• Weather conditions. This data is used to declare on-scene action. It is providedby -------.

5

2. Communication ArchitectureThe communication architecture illustrates the way that In-Response modules

interact with each other and the network resources needed to achieve a collaborationbetween different modules. The network communication infrastructure is shown in Figure

13. The LAN provides a local communication between In-Response modules such asverification subsystem, incident response subsystem, graphical information system (GIS),RU communication subsystem and RU positioning subsystem. A variety of differentplatforms may be used to implement a particular module. Different modules implementedin the same platform may be hosted by a single machine attached to the LAN. However,modules that need extensive use of resources may be hosted in different machines inorder to increase the performance of the system. As it is shown in Figure 13, two entirelydifferent ways to communicate with the RUs are introduced to make the final In-Response product resilient and affordable.

In the first approach, the communication with RUs may be implemented in anentirely automatic way by using a GPS or AVLS system. In that case the position of eachvehicle is determined automatically by the GPS or AVLS system and any exchange ofmessages may be performed by using a third party system that ensure reliable messageexchange by using the same resources used by GPS or AVLS (i.e. satellite, base stationetc.). Many commercial GPS product come with a system that allows to send/receivemessages to/from a RU. The communication link between the In-Response system andthe RUs should ensure reliable message delivery since all the vital messages such as on-scene action, dispatching and routing messages will be send and received via that link.

The second approach uses a human driven positioning and communication system.In that case a telephone operator can exchange voice messages with the driver of the RU

Figure 1. top functial graph

6

for determining the position of the RU and for passing on-scene information to RU. Thetelephone operator in the operational centre will communicate with the rest of the systemvia a special software that will allow him to pass efficiently and consistently all theinformation collected from the RU to the incident response module and GIS. Thetelephone operator should be also able to pass any message sent by the incident responsesubsystem to the RU. The software used as a front end between telephone operator andthe rest of the system may be an event driven windowing application with a friendly userinterface.

The positioning handling system receives all the vehicle positioning informationand store it in the vehicle location database D1. This database is updated regularly eitherautomatically by the GPS or manually by the telephone operator by using the appropriatesoftware system interface. Any module in the LAN (i.e. incident response subsystem,GUI etc.) can access the data base D1 and restores any necessary information related tothe vehicle positions.

The RU communication system is the module responsible for passing messages toand from the RUs. It is basically used by the incident response subsystem and GIS.Incident response subsystem uses it to notify certain RUs during the dispatching-routingphase and on-scene action delivery phase. The GIS use it to get information regarding theavailability and the current state of the RU (does the RU reach the incident site? does itfinish with on scene action? is it on the way back? etc.). The RU communication systemmay be implemented supporting either an automatic delivery system or a manual humandriven system where the delivery of messages is performed via a wireless communicationlink (mobile phones, CB etc.). However, the RU communication system may be designedto support both human driven and automatic message delivery systems in a co-operatingway that ensures greater service availability. For instance, if the automatic system isdown or transiently unavailable, the human driven system may be used instead to deliveron-scene messages or to exchange any kind of information with the RUs. Theimplementation of the RU communication system should be performed as a separatemodule for the following reasons:

1. It becomes more resilient to failures since it may support more than onecommunication structures (human driven and automatic) for sending and receivingmessages.

2. It may be replaced easily without to disturb other modules (i.e. incident responsesubsystem and GIS).

3. It may be designed to be affordable to the site budget. A site that is not willing tobuy expensive communication equipment, it may use a human driven approach,whilst another site may afford expensive communication equipment that support agreat degree of automation. However, both sites will enjoy the services providedby the In-response system with out to worry about incompatibilities with othermodules.

The incident response subsystem handles incidents. Incidents are detected by thedetection subsystem and verified by the verification subsystem. The verificationsubsystem encapsulates the incident message in a UDP datagram and sends it to theincident response subsystem. The form of the incident message is discussed further in

7

section 3 on page 8 of this report. Receiving the incident message, the incident responsesubsystem send back to the verification subsystem an acknowledgement to confirm thereception of the message and then it examines the message and takes the appropriatedecision about what type of RUs needed to be sent to the incident site (see Figure 2). Thedispatching of the appropriate RUs is following by sending a dispatching notification tothe desired RU via the RU communication system. The RU may confirm the reception ofthe dispatching message by sending back to the incident response subsystem anacknowledgement. The dispatching notification message is discussed further in section 4on page 13 of this report. Receiving the dispatching acknowledgement, the incidentresponse subsystem transits to the state of routing and then finds the faster route thatleads to the incident site. The characteristics of the route (i.e. the sequence of nodes) forma routing message and then are encapsulated in a UDP† datagram and sent to the RU viathe RU communication subsystem. The structure of the routing message is furtherdiscussed in section 5 on page 14. The incident response system then waits until the RUreaches the incident site. The incident response subsystem regularly accesses the vehiclelocation database D1 to see if the RU reaches the destination incident site. Meanwhile,the incident response subsystem may propagate on-scene advises. When the RU reachesthe incident site, the incident response subsystem registers the current time in order toestimate the travel time. When the traffic is restored the RU becomes available again andsends a message to the incident response subsystem to specify the end of the on-sceneaction duration. The incident response subsystem estimates the on-scene action time andsends a message to the historical database in order to store all the relative incidentinformation (i.e. travel time, on-scene action time, incident severity etc.)

† All the messages, even the acknowledgments, that are exchanged between different modules and arepropagated on the LAN are encapsulated in a UDP packet (datagram).

8

3. Incident Message

The incident message is a used to trigger the IR system. It comes encapsulated in a UDPdatagram and it is received by the Response Server. This message consists of twopackets; the location packet and the severity packet. The TYPE field of this messagedetermines the type of the message (that is, Incident message) and the SN fielddetermines the Sequence Number of the message. The sequence number is used todistinguish different versions of the same message.

Figure 3. Incident message

Location Packet

The location packet has just one field that is used to describe the location of an incident.This field specifies the up-stream node ID nearest to the incident site. This Node IDindicates the beginning of the edge (or link) on which an incident occurs..

Figure 2. Interaction diagram between incident response subsystem and othermodules. RU regularly updates the vehicle location database either using anautomatic or human driven positioning system.

9

Figure 4. Location packet

Severity Packet

The severity packet consists of a sequence of 56 bits. The structure of this packet isshown in 5th.

The packet is divided into 6 fields, named Incident Class, number of disabled vehicles,vehicle types, number of blocked lanes, Injury Severity, and number of injuries.

Incident Class:

The Incident Class field consists of 24 bits and it is used to identify the type of theincident. In certain situations more than one incident may occur at the same time. Aparticular incident is associated with a specific bit position and the incident is identifiedby the state of a corresponding bit in that field. Therefore the i-th incident is identified bythe state of the i-th bit (for i=0..23). If that bit is on (equal to 1), it is assumed that theincident has been occurred. Under that consideration we can identify up to 24 concurrentincidents. The following table (1st) indicates some incidents and their correspondingincident class field.

Table 1. Incident description

Incident Class Incident Description00000000 00000000 00000001 vehicle runs out of gas00000000 00000000 00000010 flat tire00000000 00000000 00000100 vehicle abandoned by the driver00000000 00000000 00001000 stalled vehicle00000000 00000000 00010000 spilled oil on the road00000000 00000000 00100000 spilled toxic liquid on the road00000000 00000000 01000000 debris00000000 00000000 10000000 vehicle collision00000000 00000001 00000000 vehicle engine crash00000000 00000010 00000000 . . . . . . . . . . . . . . .

Figure 5. Severity packet

10

For example, the incident class field 00000000 00000000 10010000 indicates vehiclecollision and spilled oil on the road.

Number of disabled vehicles:

This field specifies the number of vehicles that have been disabled after the incident. Thisfield consists of 8 bits and therefore it can identify 256 different numbers from 0 to 255.

Vehicle Types

It specifies the types of vehicles involved in the incident. This field consists of 8 bits andwe can distinguish up to 8 different categories of vehicles. Each category is associatedwith a specific bit position. Up to 8 different types of vehicles may be present in anincident. This information is needed in order to decide what actually kind of TrafficRestoration Unit (TRU) should be sent. If, for instance, heavy vehicles have beeninvolved in the incident, we should dispatch an appropriate TRU that is able to lift thisheavy vehicle. Previous research has shown that 5 classes can cover the requirements forcategorising the vehicles. The 2nd shows certain types of vehicles classified accordingtheir weight.

11

Table 2: Vehicle classification

Vehicle Type Description00000001 truck > 20000lb00000010 16000lb < truck < 20000lb00000100 10000lb < truck < 16000lb00001000 truck < 10000lb00010000 passenger car

Number of blocked lanes:

This field specifies the number of lanes that are disable due to the occurrence of theincident. Four bits can identify up to 16 different numbers from 0 to 15.

Injury Severity:

This field is used to specify the severity of the injured people. It has 4 bits and thereforecan identify 16 different types of severity from 0 to 15. The following table (3rd)indicates some of the severity types.

Table 3. Severity types

Injury Severity TypeDecimal Binary0 0000 no injury at all1 0001 very soft injury (scratches etc..)2 0010 soft injury3 0011 not so bad injury4 0100 but injury. . . . . . . . . . . . . . . . . . .15 1111 extremely but injury

Number of Injured People:

This field specifies the number of people that have been injured after the incident. Thisfield consists of 8 bits and therefore it can identify 256 different numbers from 0 to 255.

Example:

Considering the following severity packet, determine what information it specifies.

00000000 00000000 10000000 00000100 00011000 0010 0001 00000011

12

The above message specifies a vehicle collision incident with 4 disabled vehicles that hasblocked 2 lanes. There are three very soft injured people (just scratches) and the vehiclesinvolved in the incident are of two types; passenger cars and trucks not exceeding10000lb.

Severity Figure

The severity figure is a scalar entity (a number) that indicates the magnitude of theincident severity. This number is derived from the values of the attributes of the severitymessage. A proposed calculation for that number is following:

SF=BL*K + IS*I + DV

where

SF Severity Figure BL number of Blocked LanesIS Injury Severity I number of InjuriesDV number of Disabled Vehicles

K is a constant that pertains to the traffic rate (or flow) per lane

13

4. Dispatching Notification

Dispatching notification message is used by the incident response subsystem todispatch a particular RU. The structure of this message is shown in Figure 6.

The message consists of three fields named TYPE, Sequence Number (SN) and RUidentification number (RU ID). The TYPE is an 8 bit- number that determines themessage type. For this particular message this number determines a dispatchingnotification message. The sequence number is an 8 bit-number that is used in case themessage is lost or not delivered at all and we need to send the message again. Thisnumber is used to distinguish different versions of the same message. RU ID is a 16-bitnumber that identifies a particular RU.

Figure 6. Dispatching message

14

5. Routing MessageThe routing message is sent to the RU via the RU communication system and it

specifies a sequence of nodes that the RU should follow to reach the incident site. Thismessage contains the same fields as the dispatching notification message plus a field thatcontains the sequence of the proposed nodes. The structure of the routing message isshown in Figure 7. Each node is described by two fields; one holding its ID and the otherholding a literary description of the node.

Figure 7. Routing message

15

6. Traffic MessageThe traffic message is sent regularly by the GIS to the incident response subsystem inorder to update the current state of the traffic flow at all the edges of the topologicalgraph. The form of this message is shown in Figure 8.

The TYPE and SN fields are used as in previous messages. The last field specifies thetraffic flow on each edge E. Each edge description contains two additional fields; one forthe ID of the upstream node and the other for specifying the average speed on that edge.

Figure 8. Traffic message

16

APPENDIX A

In - Response System Scenario†

The detection/verification (D/V) agent sends an incident message containing the location packetand the severity packet of the incident.

The response server receives the incident message

The response server creates a new process called delegate and gives the incident message to thedelegate which from now on becomes the process responsible for restoring the traffic andproviding all the necessary health emergency support. As long as incidents take place, newdelegates are created by the response server and they are assigned to arrange appropriate actionsfor the incoming incidents. Each incident message corresponds to exactly one delegate and viceversa.

The delegate decodes the incident message into an internal form represented by an incident objectThe location packet is internally represented by a location object and the severity packet isinternally represented by a severity object. (see the Object Model for the internal structure of theincident, location and severity objects).

After decoding the incident message, the delegate consults an expert system (represented by theexpert object in the Object Model) in order to derive a handy view of the incident severity. Theexpert analyses certain attributes of the incident severity and advises the delegate by sending to itan advice. The advice may consist of one or more advocates. Each advocate contains informationabout the type of the response unit need to be sent to the incident site as well as the precedencewith which the response unit should be dispatched. The precedence indicates a measure of thenecessity of a particular response unit and it is derived from the severity attributes of the incidentwhich imply a certain need for a particular type of response unit. The most severe incident shouldhave the highest precedence. Let us consider for instance, that an incident has a severity thatimplies a need for an ambulance and a lorry. The expert prepares an advice with two advocates onefor the lorry and one for the ambulance. Each advocate contains the type of the required responseunit and the precedence with which it should be dispatched. If, for instance, there are many orsevere injuries the ambulance should be dispatched with high precedence, whereas, if there is justone lane occupied by disabled vehicles, the lorry may be dispatched with a medium or lowprecedence. Under any circumstances, an advice cannot contain two advocates requesting the sameresponse unit type. That is, the expert never advises the delegate to send two lorries or two cars ortwo ambulances. This is because each type of response unit is strictly associated with a certaindistrict, so if an incident occurs in that district, only this single type of response unit which is incharge might be dispatched. However, an exception handling mechanism should be considered incase of a fireball or an extensive catastrophe. In receiving such a message, the expert may preparean advice containing advocates associated with the same type of response units and in this casemore than one response units of the same type might be dispatched to the incident site.

† Words or terms in bold face are defined in the data dictionary

17

Now each delegate is about to perform what the expert said in its advice, (that is, to dispatch therequired response units described in each advocate) but conflicts are inevitable. Two or moredelegates may demand the same response unit (two neighbour incidents occur in the same district).To resolve certain conflicts and race conditions, a dispatching scheduler is needed. Adispatching scheduler hears all the current delegates and allows only those delegates who need aresponse unit with the highest precedence to dispatch the corresponding response unit. Therefore aparticular response unit is allowed to be dispatched by a certain delegate only after theconfirmation of the dispatching scheduler. Those delegates which are not allowed to dispatch theirresponse units have to wait until get the scheduler confirmation.

When the delegate is allowed to dispatch a certain response unit, it consults the response unitstore ( a shared database) in order to find the current location and the availability state of thedesired response unit. If the desired response unit is available, the delegate can directly dispatchit and dynamically suggest the route that it should follow to reach the incident site. The responseunit store is updated regularly by the response units through the current delegate that has beendispatched it . The response units send regularly messages to the delegates about their state andlocation. The delegates store those data in the response unit store. Any other delegate that needsto know about the state of a particular response unit can get that information by accessing theresponse unit store. The types of information need to be stored in the response unit store aredescribed by the response unit object (see Object Model).

The delegate dynamically exchanges messages with its own despatched response units and routethem by specifying each time the next hop until each response unit reaches the incident site. Inresponse, the response units send back to the delegate their location and state. The delegateautomatically places this information in the response unit store, so any one else can see where eachresponse unit is. For example, a GIS system may get this data directly from the response unitstore through an interface called monitor (see Object Model)

The delegate provides the expert with some extra information held locally in the system or comefrom a remote station. This extra information is needed for on scene actions and it is associated withweather and traffic conditions. The severity of the message is also sent again to the expert in orderto estimate the actions that must be taken to restore the traffic flow and remove any disable vehicle.The delegate seeks on scene advises for minimising the clearance time and the consequence of theincident. These advises are sent from the expert to the delegate that in turn forwards them to theresponse units which are on the incident site waiting on scene removal information.

When the removal is accomplished, the delegate updates a data base known as the incident storewhich holds details about each incident (i.e. data, location , district, dispatching time, travel time, onscene time, incident severity etc.). This data may be used for a future configuration of the system(i.e. reallocation .of response units through Districting).

After the accomplishment of its mission, the delegate dies and frees any operating system resources.

18

APPENDIX B

Data Dictionary

advice: A sequence of one or more advocates. It is generated by theexpert and it is passed to the delegate. It contains informationabout what type of response unit should be sent and with whichprecedence.

advocate: An object containing the type of response unit (ru_type) neededand the degree of need (priority). It also contains the specific IDof the response unit that will be used to restore the incidentconsequences. The Boolean attribute ru_dispatch determineswhether the delegate should dispatch the response unit or not.ru_type and priority are set by the expert, ru_dispatch by thedelegate after the confirmation received from the dispatchingscheduler, and nu_id by the delegate after consulting theresponse unit store.

delegate entry: It contains the response unit ID (ru_id) that should bedispatched, its priority and a waiting time. The tu_id and priorityare those sent from the delegate and received by the dispatchingscheduler. The waiting time (waiting_t) indicates how long thisentry stays in the dispatching scheduler list.

delegate: The heart of the whole incident management system. It isresponsible for the handling of an incident. It may beimplemented as a separate process. It arranges all the datamovements from one object to an other. It sends the incident tothe expert and receives from it an advice. The advice isprocessed by the delegate that also accesses the response unitstore to see the current state of the response unit. The delegateeventually learns which response units should be sent. The ID ofthe response unit (ru_id) that should be dispatched together withits priority are sent to the dispatching scheduler.

detection/verification A subsystem responsible for sending incident messages

dispatching scheduler: It contains an entry for each demanded response unit.Each response unit in an entry is associated with a delegate. Itfinds the delegate that has assigned the greatest priority to theresponse unit. It lets this delegate to dispatch that demandedresponse unit and prohibits all the rest (that also need thatresponse unit) from dispatching it. It regularly checks the entrylist for new entries that may affect the dispatching schedulerdecision.

19

expert: It gives to a delegate an advice for a particular incident

incident message A message consisting of two packets; the location packet and theseverity packet.

incident store: It stores all the incidents that have been detected and handled bythe system so far. It is a database containing incident objects

incident: It contains all the necessary information to describe the nature,severity and the location of an incident. location and severityare sent by the detection and verification subsystem (D/V).i_date and i_time are set by the response server to the currentdate and time respectively. Weather conditions (w_cond) andTraffic Flow Rate (i_tfrate) are set externally by consulting adatabase that keeps information about the weather conditions andthe mean traffic flow in the incident site. i_dispatching_t,i_travel_t, and i_on_scene_t are set by the Delegate

location packet A packet (sequence of characters) containing information aboutthe location of the incident

location: It describes the incident location as it appears in the locationpacket but by using an internal form that the system can handleeasily.

monitor: An interface object between the In-Response system and anexternal GIS system.

precedence: The priority with which a specific response unit should bedispatched.

response server: A demon that hears to the line to see if an incident messagecomes

response unit store: A store that keeps information about the current state of eachresponse unit. It is updated regularly by many delegates

response unit: A Health Emergency Response Unit (HERU or a TrafficRestoration Unit (TRU)

severity packet A packet (sequence of characters) containing information aboutthe severity of the incident

severity: It describes the incident severity as it appears in the severitypacket but by using an internal form that the system can handleeasily.

traffic agent: It defines a server that receives traffic information such asaverage speed or traffic volume associated with certain parts ofthe topological graph of the covered geographical area. Thisinformation will be received by the Traffic Agent regularly (sayevery 10 min.) as a UDP packet.

20

References

[Rambaugh 1991]Rambaugh, J., Blaha, M., Premerlani, W., Eddy, F., and Lorensen, W., ObjectOriented Modelling and Design, Prentice Hall, 1991.

[Zografos 1996]Zografos, K and Vasilakis, G., M.. “Deliverable 4.1: Functional Specifications forthe Incident Response and Health Emergency Response Sub-system”, TelematicsApplication Programme, 4th FWP- SECTOR Transport Telematics DG XIII, IN-RESPONSE / TR 1030, September 1996.

21

Fig

ure

9.

Sta

te t

ran

siti

on

sia

gram

s of

the

inci

den

t re

spon

se s

yst

em,

resp

on

se s

erver

an

d e

xper

t. T

he

stat

e of

the

inci

den

tre

spon

se s

yst

em i

s th

e ag

greg

atio

n o

f th

e st

ates

of

five

con

cure

nt

obje

cts

nam

ed r

espon

se s

erver

, del

egat

e,dis

pat

chin

gsc

hed

ule

r,ex

per

t an

d t

raff

ic a

gen

t.

22

23

Fig

ure

10.

Dis

pat

chin

g sc

hed

ule

r an

d t

raff

ic a

gen

t st

ate

tran

siti

on

dia

gram

s

24

Fig

ure

11.

Del

egat

e obje

ct s

tate

tra

nsi

tion

dia

gram

25

Fig

ure

12.

Inci

den

t R

espon

se o

bje

ct m

odel

26

Fig

ure

13.

In R

espon

se C

om

mun

icat

ion

Arc

hit

ectu

re.