Sep 19, 1997 - grants permission to dispatch a response unit, the corresponding delegate entry is .... via a special software that will allow him to pass efficiently and .... This field specifies the up-stream node ID nearest to the incident site.
TELEMATICS APPLICATION PROGRAMME
4th FWP - SECTOR Transport Telematics DG 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
1
1.
Incident Response System Modelling
The Incident Response (IR) subsystem is responsible for handling any incident message and providing the following services • Districting • Dispatching • Routing • On-scene advises The modelling technique used to analyse and design the IR system is the Object Modelling Technique (OMT) [Rambaugh 1991]. The OMT allows us to combine three different modelling views of the IR system. These three models named object model, dynamic model and functional model cover different aspects of the system and specify respectively the static, dynamic and functional insights of the IR subsystem. 1.1.
Object Model The 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 object modelling constructs and shows how they fit together into IR system. Class Response Server defines a server object that is used to receive incident messages. It defines methods for capturing a incoming incident message and creating new delegates. Each of these delegate is able to handle a single incident message. Class Severity defines common parameters of the severity of an incident including the type of incident, number of disable vehicles, number of blocked lane, type of staled vehicles, injury severity, number of injured people. Class Location defines the location in the topological graph of the covered area. A location may be identified by using the upstream node. The class Location defines a single attribute specifying the ID of the upstream node. Class Incident defines parameters that describes all the historical attributes of the incident such as date, time, weather conditions, dispatching time, travel time and onscene time. Most of these attributes are set by the delegate who handles the incident message. Class Incident Store defines some methods for accessing the data base that stores historical data. Class Response Unit Store defines some methods for accessing vehicle location data. This data store keep information about the location and availability of each Response Unit. Class Expert defines an interface between a delegate and the expert system. The responsibilities 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 what precedence. An other responsibility of the class Expert is to provide the appropriate onscene actions to a in charged delegate. Class Advocate defines parameters for identifying the response unit type needed, the priority with which it should be dispatched. An Advice is just an aggregation of Advocates Class Response Unit defines attributes and methods related with a particular response unit such as response unit ID, response unit type, default location of the
2
response unit, district ID, and a flag indicating the availability of the response unit. Most of this data is provided by the Response Unit Store object. Class Dispatching Scheduler is used to dispatch a particular response unit according the severity of the incident and the priority that has been assigned by the expert system. It contains an entry for each demanded response unit. It always gives permission for dispatching to those delegate that demand the particular response unit with the greatest priority. Class Delegate Entry is a simple structure defining the response unit ID, the priority with which the response unit has to be dispatched, and the time waiting until permission is granted. All the delegate entries are available to the scheduler. If a delegate grants permission to dispatch a response unit, the corresponding delegate entry is removed from the scheduler queue. Class Traffic Agent defines a server that receives traffic information such as average speed or traffic volume associated with certain parts of the topological graph of the covered geographical area. This information will be received by the Traffic Agent regularly (say every 10 min.) as a UDP packet. Traffic information will be probably transmitted by the GUI. Class Delegate is the hart of the whole system. It arranges all the interactions with other objects and it is the entity responsible for restoring the traffic flow forwarding any appropriate on-scene action generated by the expert system. 1.2. Dynamic Model The dynamic model represents the temporal, behavioural, control aspects of the IR system 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 assign delegate. Initially the response server is in the stand by state and it runs in an infinite loop waiting an incident message to be received in the input port. When an incident message is received, the response server abandons its current activity and transits to the assign delegate state. During its entry to this state, it creates a new delegate and passes the incident message to this delegate. When it accomplishes this action transits back to the stand by state waiting again for a new incident message. The object expert (Figure 9) has a similar structure as the response server. It initially enters the stand by state and waits for a severity message. When this messages is received, the expert transits to the estimate severity state in which an advice is prepared and sent to the relative delegate. When this actions is accomplished, it returns back to the stand by state waiting for the next severity message. The object dispatching scheduler (Figure 10)is an autonomous server with a similar structures as the previous ones, but it is time driven. It waits for a predefined time interval (say 10 sec.) and when this time period elapses it transits to a state called delegate checking in which it checks each delegate entry in its queue to see which entry has the greatest priority in order to grant permission and allows the relative delegate to dispatch the desired response unit. The object Traffic Agent (Figure 10) waits in an infinite loop for a traffic message to be received. When such a message is received, it transits to the update state and updates the weight table which keeps information about the time needed to move from one node to an other in the topological graph.
3
The object delegate (Figure 11) has three states, named dispatching, routing and onscene actions. It initially enters the dispatching state. As long as it is in that state, it decodes the incident message and sends the severity message to the expert. The expert processes the severity message and send back to the delegate its advice. When the advice is received, the delegate issues a permission request to the dispatching scheduler making an entry for each desired response unit in the dispatching scheduler queue. When the dispatching scheduler issues a permission, the delegates transits to the routing state in order to route the desired response unit to the destination incident site. When the RU reaches the incident site it will send back to the delegate a message saying so. When the delegate receives this message it transits to the on-scene actions state. In this final state the delegate performs all the desired steps for accomplishing the task of forwarding all the necessary on-scene messages. When the on-scene activities end, the delegate may report 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 previously occupied system resources. 1.3.
Functional Model The functional model represents the transformational, functioning aspects of the IR system. A top functional graph is shown in Figure 1. A finer grain functional decomposition will be documented later during the development. External data needed to be provided by other modules are the following: • Incident message. It is provided by the verification subsystem. It is discussed in section 3 on page 8 • Vehicle location data. It is provided by the database D1. This data comes to the incident response subsystem in a request/response way. • Traffic message. It is provided by --------. It indicates the traffic flow rate at all the edges of the topological graph which represents the covered geographical area. Its form is discussed in section 6 on page 15. • Topological graph. It represents the geographical area in a mathematical way. It is provided once by the GIS or the In-Response manager. • Weather conditions. This data is used to declare on-scene action. It is provided by -------.
4
Figure 1. top functial graph
2.
Communication Architecture
The communication architecture illustrates the way that In-Response modules interact with each other and the network resources needed to achieve a collaboration between different modules. The network communication infrastructure is shown in Figure 13. The LAN provides a local communication between In-Response modules such as verification subsystem, incident response subsystem, graphical information system (GIS), RU communication subsystem and RU positioning subsystem. A variety of different platforms may be used to implement a particular module. Different modules implemented in 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 in order to increase the performance of the system. As it is shown in Figure 13, two entirely different ways to communicate with the RUs are introduced to make the final InResponse product resilient and affordable. In the first approach, the communication with RUs may be implemented in an entirely automatic way by using a GPS or AVLS system. In that case the position of each vehicle is determined automatically by the GPS or AVLS system and any exchange of messages may be performed by using a third party system that ensure reliable message exchange by using the same resources used by GPS or AVLS (i.e. satellite, base station etc.). Many commercial GPS product come with a system that allows to send/receive messages to/from a RU. The communication link between the In-Response system and the RUs should ensure reliable message delivery since all the vital messages such as onscene 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
5
for determining the position of the RU and for passing on-scene information to RU. The telephone operator in the operational centre will communicate with the rest of the system via a special software that will allow him to pass efficiently and consistently all the information collected from the RU to the incident response module and GIS. The telephone operator should be also able to pass any message sent by the incident response subsystem to the RU. The software used as a front end between telephone operator and the rest of the system may be an event driven windowing application with a friendly user interface. The positioning handling system receives all the vehicle positioning information and store it in the vehicle location database D1. This database is updated regularly either automatically by the GPS or manually by the telephone operator by using the appropriate software 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 to the vehicle positions. The RU communication system is the module responsible for passing messages to and 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-routing phase and on-scene action delivery phase. The GIS use it to get information regarding the availability and the current state of the RU (does the RU reach the incident site? does it finish with on scene action? is it on the way back? etc.). The RU communication system may be implemented supporting either an automatic delivery system or a manual human driven system where the delivery of messages is performed via a wireless communication link (mobile phones, CB etc.). However, the RU communication system may be designed to support both human driven and automatic message delivery systems in a co-operating way that ensures greater service availability. For instance, if the automatic system is down or transiently unavailable, the human driven system may be used instead to deliver on-scene messages or to exchange any kind of information with the RUs. The implementation of the RU communication system should be performed as a separate module for the following reasons: 1. It becomes more resilient to failures since it may support more than one communication structures (human driven and automatic) for sending and receiving messages. 2. It may be replaced easily without to disturb other modules (i.e. incident response subsystem and GIS). 3. It may be designed to be affordable to the site budget. A site that is not willing to buy expensive communication equipment, it may use a human driven approach, whilst another site may afford expensive communication equipment that support a great degree of automation. However, both sites will enjoy the services provided by the In-response system with out to worry about incompatibilities with other modules. The incident response subsystem handles incidents. Incidents are detected by the detection subsystem and verified by the verification subsystem. The verification subsystem encapsulates the incident message in a UDP datagram and sends it to the incident response subsystem. The form of the incident message is discussed further in
6
section 3 on page 8 of this report. Receiving the incident message, the incident response subsystem send back to the verification subsystem an acknowledgement to confirm the reception of the message and then it examines the message and takes the appropriate decision about what type of RUs needed to be sent to the incident site (see Figure 2). The dispatching of the appropriate RUs is following by sending a dispatching notification to the desired RU via the RU communication system. The RU may confirm the reception of the dispatching message by sending back to the incident response subsystem an acknowledgement. The dispatching notification message is discussed further in section 4 on page 13 of this report. Receiving the dispatching acknowledgement, the incident response subsystem transits to the state of routing and then finds the faster route that leads to the incident site. The characteristics of the route (i.e. the sequence of nodes) form a routing message and then are encapsulated in a UDP† datagram and sent to the RU via the RU communication subsystem. The structure of the routing message is further discussed in section 5 on page 14. The incident response system then waits until the RU reaches the incident site. The incident response subsystem regularly accesses the vehicle location 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 reaches the incident site, the incident response subsystem registers the current time in order to estimate the travel time. When the traffic is restored the RU becomes available again and sends a message to the incident response subsystem to specify the end of the on-scene action duration. The incident response subsystem estimates the on-scene action time and sends a message to the historical database in order to store all the relative incident information (i.e. travel time, on-scene action time, incident severity etc.)
†
All the messages, even the acknowledgments, that are exchanged between different modules and are propagated on the LAN are encapsulated in a UDP packet (datagram).
7
Figure 2. Interaction diagram between incident response subsystem and other modules. RU regularly updates the vehicle location database either using an automatic or human driven positioning system.
3.
Incident Message
The incident message is a used to trigger the IR system. It comes encapsulated in a UDP datagram and it is received by the Response Server. This message consists of two packets; the location packet and the severity packet. The TYPE field of this message determines the type of the message (that is, Incident message) and the SN field determines the Sequence Number of the message. The sequence number is used to distinguish 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 ID indicates the beginning of the edge (or link) on which an incident occurs..
8
Figure 4. Location packet
Severity Packet The severity packet consists of a sequence of 56 bits. The structure of this packet is shown in 5th.
Figure 5. Severity packet
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 the incident. In certain situations more than one incident may occur at the same time. A particular incident is associated with a specific bit position and the incident is identified by the state of a corresponding bit in that field. Therefore the i-th incident is identified by the state of the i-th bit (for i=0..23). If that bit is on (equal to 1), it is assumed that the incident has been occurred. Under that consideration we can identify up to 24 concurrent incidents. The following table (1st) indicates some incidents and their corresponding incident class field. Table 1. Incident description
Incident Class 00000000 00000000 00000001 00000000 00000000 00000010 00000000 00000000 00000100 00000000 00000000 00001000 00000000 00000000 00010000 00000000 00000000 00100000 00000000 00000000 01000000 00000000 00000000 10000000 00000000 00000001 00000000 00000000 00000010 00000000
Incident Description vehicle runs out of gas flat tire vehicle abandoned by the driver stalled vehicle spilled oil on the road spilled toxic liquid on the road debris vehicle collision vehicle engine crash .............. .
9
For example, the incident class field 00000000 00000000 10010000 indicates vehicle collision and spilled oil on the road. Number of disabled vehicles: This field specifies the number of vehicles that have been disabled after the incident. This field 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 and we can distinguish up to 8 different categories of vehicles. Each category is associated with a specific bit position. Up to 8 different types of vehicles may be present in an incident. This information is needed in order to decide what actually kind of Traffic Restoration Unit (TRU) should be sent. If, for instance, heavy vehicles have been involved in the incident, we should dispatch an appropriate TRU that is able to lift this heavy vehicle. Previous research has shown that 5 classes can cover the requirements for categorising the vehicles. The 2nd shows certain types of vehicles classified according their weight.
10
Table 2: Vehicle classification
Vehicle Type 00000001 00000010 00000100 00001000 00010000
Description truck > 20000lb 16000lb < truck < 20000lb 10000lb < truck < 16000lb truck < 10000lb passenger car
Number of blocked lanes: This field specifies the number of lanes that are disable due to the occurrence of the incident. 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 therefore can 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 Decimal Binary 0 0000 1 0001 2 0010 3 0011 4 0100 ..... ...... 15 1111
Type no injury at all very soft injury (scratches etc..) soft injury not so bad injury but injury ........ extremely but injury
Number of Injured People: This field specifies the number of people that have been injured after the incident. This field 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
11
The above message specifies a vehicle collision incident with 4 disabled vehicles that has blocked 2 lanes. There are three very soft injured people (just scratches) and the vehicles involved in the incident are of two types; passenger cars and trucks not exceeding 10000lb.
Severity Figure The severity figure is a scalar entity (a number) that indicates the magnitude of the incident severity. This number is derived from the values of the attributes of the severity message. A proposed calculation for that number is following: SF=BL*K + IS*I + DV where SF Severity Figure IS Injury Severity DV number of Disabled Vehicles
BL I
number of Blocked Lanes number of Injuries
K is a constant that pertains to the traffic rate (or flow) per lane
12
4.
Dispatching Notification
Dispatching notification message is used by the incident response subsystem to dispatch a particular RU. The structure of this message is shown in Figure 6.
Figure 6. Dispatching message
The message consists of three fields named TYPE, Sequence Number (SN) and RU identification number (RU ID). The TYPE is an 8 bit- number that determines the message type. For this particular message this number determines a dispatching notification message. The sequence number is an 8 bit-number that is used in case the message is lost or not delivered at all and we need to send the message again. This number is used to distinguish different versions of the same message. RU ID is a 16-bit number that identifies a particular RU.
13
5.
Routing Message
The 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. This message contains the same fields as the dispatching notification message plus a field that contains the sequence of the proposed nodes. The structure of the routing message is shown in Figure 7. Each node is described by two fields; one holding its ID and the other holding a literary description of the node.
Figure 7. Routing message
14
6.
Traffic Message
The traffic message is sent regularly by the GIS to the incident response subsystem in order to update the current state of the traffic flow at all the edges of the topological graph. The form of this message is shown in Figure 8.
Figure 8. Traffic message
The TYPE and SN fields are used as in previous messages. The last field specifies the traffic flow on each edge E. Each edge description contains two additional fields; one for the ID of the upstream node and the other for specifying the average speed on that edge.
15
APPENDIX A In - Response System Scenario
†
The detection/verification (D/V) agent sends an incident message containing the location packet and 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 the delegate which from now on becomes the process responsible for restoring the traffic and providing all the necessary health emergency support. As long as incidents take place, new delegates are created by the response server and they are assigned to arrange appropriate actions for the incoming incidents. Each incident message corresponds to exactly one delegate and vice versa. The delegate decodes the incident message into an internal form represented by an incident object The location packet is internally represented by a location object and the severity packet is internally represented by a severity object. (see the Object Model for the internal structure of the incident, location and severity objects). After decoding the incident message, the delegate consults an expert system (represented by the expert object in the Object Model) in order to derive a handy view of the incident severity. The expert analyses certain attributes of the incident severity and advises the delegate by sending to it an advice. The advice may consist of one or more advocates. Each advocate contains information about the type of the response unit need to be sent to the incident site as well as the precedence with which the response unit should be dispatched. The precedence indicates a measure of the necessity of a particular response unit and it is derived from the severity attributes of the incident which imply a certain need for a particular type of response unit. The most severe incident should have the highest precedence. Let us consider for instance, that an incident has a severity that implies a need for an ambulance and a lorry. The expert prepares an advice with two advocates one for the lorry and one for the ambulance. Each advocate contains the type of the required response unit and the precedence with which it should be dispatched. If, for instance, there are many or severe injuries the ambulance should be dispatched with high precedence, whereas, if there is just one lane occupied by disabled vehicles, the lorry may be dispatched with a medium or low precedence. Under any circumstances, an advice cannot contain two advocates requesting the same response unit type. That is, the expert never advises the delegate to send two lorries or two cars or two ambulances. This is because each type of response unit is strictly associated with a certain district, so if an incident occurs in that district, only this single type of response unit which is in charge might be dispatched. However, an exception handling mechanism should be considered in case of a fireball or an extensive catastrophe. In receiving such a message, the expert may prepare an advice containing advocates associated with the same type of response units and in this case more 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
16
Now each delegate is about to perform what the expert said in its advice, (that is, to dispatch the required response units described in each advocate) but conflicts are inevitable. Two or more delegates 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. A dispatching scheduler hears all the current delegates and allows only those delegates who need a response unit with the highest precedence to dispatch the corresponding response unit. Therefore a particular response unit is allowed to be dispatched by a certain delegate only after the confirmation of the dispatching scheduler. Those delegates which are not allowed to dispatch their response units have to wait until get the scheduler confirmation. When the delegate is allowed to dispatch a certain response unit, it consults the response unit store ( a shared database) in order to find the current location and the availability state of the desired response unit. If the desired response unit is available, the delegate can directly dispatch it and dynamically suggest the route that it should follow to reach the incident site. The response unit store is updated regularly by the response units through the current delegate that has been dispatched it . The response units send regularly messages to the delegates about their state and location. The delegates store those data in the response unit store. Any other delegate that needs to know about the state of a particular response unit can get that information by accessing the response unit store. The types of information need to be stored in the response unit store are described by the response unit object (see Object Model). The delegate dynamically exchanges messages with its own despatched response units and route them by specifying each time the next hop until each response unit reaches the incident site. In response, the response units send back to the delegate their location and state. The delegate automatically places this information in the response unit store, so any one else can see where each response unit is. For example, a GIS system may get this data directly from the response unit store through an interface called monitor (see Object Model) The delegate provides the expert with some extra information held locally in the system or come from a remote station. This extra information is needed for on scene actions and it is associated with weather and traffic conditions. The severity of the message is also sent again to the expert in order to 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 the incident. These advises are sent from the expert to the delegate that in turn forwards them to the response 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 store which holds details about each incident (i.e. data, location , district, dispatching time, travel time, on scene 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.
17
APPENDIX B
Data Dictionary advice:
A sequence of one or more advocates. It is generated by the expert and it is passed to the delegate. It contains information about what type of response unit should be sent and with which precedence.
advocate:
An object containing the type of response unit (ru_type) needed and the degree of need (priority). It also contains the specific ID of the response unit that will be used to restore the incident consequences. The Boolean attribute ru_dispatch determines whether the delegate should dispatch the response unit or not. ru_type and priority are set by the expert, ru_dispatch by the delegate after the confirmation received from the dispatching scheduler, and nu_id by the delegate after consulting the response unit store.
delegate entry:
It contains the response unit ID (ru_id) that should be dispatched, its priority and a waiting time. The tu_id and priority are those sent from the delegate and received by the dispatching scheduler. The waiting time (waiting_t) indicates how long this entry stays in the dispatching scheduler list.
delegate:
The heart of the whole incident management system. It is responsible for the handling of an incident. It may be implemented as a separate process. It arranges all the data movements from one object to an other. It sends the incident to the expert and receives from it an advice. The advice is processed by the delegate that also accesses the response unit store to see the current state of the response unit. The delegate eventually learns which response units should be sent. The ID of the response unit (ru_id) that should be dispatched together with its 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. It finds the delegate that has assigned the greatest priority to the response unit. It lets this delegate to dispatch that demanded response unit and prohibits all the rest (that also need that response unit) from dispatching it. It regularly checks the entry list for new entries that may affect the dispatching scheduler decision.
18
expert:
It gives to a delegate an advice for a particular incident
incident message
A message consisting of two packets; the location packet and the severity packet.
incident store:
It stores all the incidents that have been detected and handled by the 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 severity are sent by the detection and verification subsystem (D/V). i_date and i_time are set by the response server to the current date and time respectively. Weather conditions (w_cond) and Traffic Flow Rate (i_tfrate) are set externally by consulting a database that keeps information about the weather conditions and the 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 about the location of the incident
location:
It describes the incident location as it appears in the location packet but by using an internal form that the system can handle easily.
monitor:
An interface object between the In-Response system and an external GIS system.
precedence:
The priority with which a specific response unit should be dispatched.
response server:
A demon that hears to the line to see if an incident message comes
response unit store:
A store that keeps information about the current state of each response unit. It is updated regularly by many delegates
response unit:
A Health Emergency Response Unit (HERU or a Traffic Restoration Unit (TRU)
severity packet
A packet (sequence of characters) containing information about the severity of the incident
severity:
It describes the incident severity as it appears in the severity packet but by using an internal form that the system can handle easily.
traffic agent:
It defines a server that receives traffic information such as average speed or traffic volume associated with certain parts of the topological graph of the covered geographical area. This information will be received by the Traffic Agent regularly (say every 10 min.) as a UDP packet.
19
References [Rambaugh 1991] Rambaugh, J., Blaha, M., Premerlani, W., Eddy, F., and Lorensen, W., Object Oriented Modelling and Design, Prentice Hall, 1991. [Zografos 1996] Zografos, K and Vasilakis, G., M.. “Deliverable 4.1: Functional Specifications for the Incident Response and Health Emergency Response Sub-system”, Telematics Application Programme, 4th FWP- SECTOR Transport Telematics DG XIII, INRESPONSE / TR 1030, September 1996.
20
21
Figure 9. State transition siagrams of the incident response system, response server and expert. The state of the incident response system is the aggregation of the states of five concurent objects named response server, delegate,dispatching scheduler,expert and traffic agent.
22
23
Figure 10. Dispatching scheduler and traffic agent state transition diagrams
24
Figure 11. Delegate object state transition diagram
25
Figure 12. Incident Response object
26
Figure 13. In Response Communication Architecture.
