Managing ROMANSE Incidents

Authors: KLaughlin, ROMANSE Project Manager, Hampshire County Council R..A.P.Bossom, Technical Manager, Siemens Traffic Controls Limited

Introduction

This paper looks at Incident Management in the ROMANSE Traffic and Travel Information Centre (TTIC). The ROMANSE (Road MANagement System for Europe) project has been in operation since 1992 and has achieved a fbly integrated traffic and travel information centre. Incident Management is discussed from two perspectives. Firstly from the ROMANSE TTIC Operator’s point of View, and secondly from the System Designer’s point of view.

ROMANSE TTIC Operator’s Point of View

Introduction

The ROMANSE TTIC Operator has different objectives and a very different view of the information available to him to that of the traveller. The System Operator will want to obtain information from a wide variety of sources in real time, as well as historic and fbture information. The Operator needs to use this information to keep the traveller informed, ensuring consistency, accuracy and reliability, to maintain the objectives of influencing travel behaviour and managing the transport network efficiently. The information is also used to implement strategies, either automatically or manually, in order to deal with a variety of incidents, or traffic conditions, ensuring the transport network operates at optimum efficiency or, in accordance with the local or regional policy objectives for the region, city, route, or area. ITS can be utilised not only in an integrated way, but also to target particular groups of travellers, or modes, giving priority, or restraint as required.

With regard to incident management there are a number of important stages. These range from detecting changing conditions when an incident occurs, to introducing a strategy to cater for the incident and forecasting the end of the incident. It is also important to have the information available to analyse the actions taken and subsequent conditions to determine if the action was appropriate and, if necessary, improve strategy implementation for the hture.

One of the key tasks the TTIC is the collation of traffic and travel information. Information is received either automatically from ROMANSE systems (eg. CCTV, ARTEMIS, STOPWATCH, UTC detectors) or manually from other sources.

The key issues for information collation are:-

7/ 1

+ what type of information is requestedkeceived 4 how is it requestedkeceived (e.g. telephone, fax, computer link) 4 how often is information requestedheceived 4 in what form is it presented (e.g. fax page, message on-screen, print-out) 4 how is it classified in order to be processed 4 how it is processed according to its classification 4 how is the information monitored and updated 4 how is the information cleared (i.e. when the incident/event is over)

The type of traffic and travel information that is collated can then be divided into the following groups:-

+ unplanned incidents (e.g.road traffic accidents, emergency roadworks) 4 planned/predicted events (e.g. roadworks, sports events, regular congestion) + timetables/schedules (e.g. bus and rail timetables)

visitor and leisure information (e.g. places of interest) + general public information (e.g. weather, opening of new shopping centre)

One of the first stages is to determine what constitutes an incident. There are many types of incidents which may, or may not, impact on the transport network. An incident needs to be clearly defined and the appropriate course/s of action to be taken is specified.

The term incident has been defined as an unplanned activity which has the potential to cause disruption on the public and/or private transport network. The term event is used to describe all planned or predicted activities which have the potential to cause disruption on the public and/or private transport network. Although both of these terms are used fiequently in the context of TTIC operations, the ROMANSE TTIC is more concerned with the impact that an incident or event has. For example, an overturned goods vehicle can be considered to be a serious incident, particularly if there are casualties. However, if this incident occurs on a minor route, or late at night and, consequently, has little effect upon normal tr&c flows then it could be classed as having little impact on the network. Nevertheless, observation of the incident should be maintained in case it becomes more significant, e.g. a lane closure becomes a road closure, or if it is found that the problem cannot be cleared before the traffic peak period starts.

There are few absolute rules which can be applied when deciding the significance of an incident/event. Often there are other external factors which combine to make the decision-making process one which is best left to the discretion of the Operators. However, there are certain guidelines which can be adopted. For example, incidentdevents which result in delays of less than five minutes to either public, or private transport travellers are not normally classed as significant. Other issues which should be considered when assessing an incident/event are:-

712

+ will it S e c t transport in Hampshire? (defined as the county boundary) + if outside Hampshire will it be of interest to Hampshire travellers?

(e.g. cancellation of flights fiom Heathrow Airport, London Underground strike) + are there very few other problems to report?

(if so, is it worth disseminating just for the sake of it?) + for general information, will it be of interest to travellers? (e.g. weather) + does it need to be reported to the police?

(e.g. an accident detected via the CCTV cameras)

An Operator has to decide on the significance of an item of information based upon the above criteria. All items of incoming information, whether significant or not, have to be processed by an Operator. Active information on current incidents and future events needs to be stored and be easily accessible. However, after a significant item of information has been identified and collated, the incidentlevent that it relates to must then be monitored continuously until it is no longer significant.

All these facilities need to be readily available to the System Operator and running in an integrated way to make monitoring and controlling an incident as simple as possible. To achieve this the operator needs to work through a limited number of console points with all information whether real time, historic, or predictive, presented in a single standard format. The traveller, however, needs information to be presented in a wide variety of ways. A strategic information system using geographic information systems (GIS) can facilitate both.

To alert the system operator to a potential incident, a single source for the automatically generated alarm needs to be established. The system operator then needs the facility to implement a strategy to deal with the incident. The operator who has a wide variety of systems available that can be used in various combinations, needs a quick, effective method of using those appropriate systems in the most effective way. The Operator does not want to have to set up each system individually but instead to use a central control unit to implement an integrated strategy either already stored in the system, or which can be easily configured.

It has already been stated that the over-riding priority for any Operator is the collation and dissemination of information. In order for Operators to maintain a clear perception of the ‘overall system’, they will need to access the individual elements to monitor or influence their respective role and operation as an incident develops, or conditions change on the network.

There is a significant amount of information available to indicate how network conditions develop and subsequently change until a normal situation is resumed. This information can be particularly useful in monitoring the on-going situation for an incident, or for any subsequent analysis after the incident. This information can indicate how effective the strategy was in dealing with the incident and what steps could be taken in the future to improve a similar situation. As this approach is developed, inputs to on-line models can be established to give advice or, ultimately,

113

introduce automatically strategies to deal with specific incidents, or to provide predicted information on when the situation is likely to return to normal.

esigner’s Point of View

Introduction

The System Designer’s point of view of Incident Management is driven by the need to hlfil the system requirements. From these the design for an Incident Management System (MS) can be produced.

Requirements

The System Requirements can be divided into three main areas covering incident data collection, strategy implementation and impact analysis. These can be described in more detail by the following:

(a) Incident Data Collection: receive data about potential incidents fiom a variety of sources. This data must then be collated to combine that which relates to the same incident.

(b) Strategy Implementation: when an incident has been confidently detected, strategies must be implemented to mitigate its effects. The implementation shall be either automatic where a pre-defined strategy exists, or manual. The same facility shall be capable of removing a strategy when the incident has ceased to exist.

(c) Impact Analysis. collect data about the effect on the incident and the impact of any strategies that are used to mitigate its effects. From this data it will be possible to determine the effectiveness of the implemented strategy.

Other Requirements will need to be defined to cover such things as system performance, failure criteria, and the System Operator interface. The failure criteria must take account of the effects of key system failure, particularly when it occurs once an incident mitigation strategy has been implemented.

Funetionality

From the above System Requirements the System Designer can now produce a set of functions. At the highest level of analysis, these comprise, incident data collection and collation, strategy selection, implementation and de-selection, plus strategy impact analysis. Each of these high level fimctions can be described in the following ways.

(a) Incident Data Collection. This function must be able to receive data fiom a variety of sources. These sources can be divided into other systems and manual input. Examples of other systems are those that perform functions such as, video analysis of traffic, vehicle detector data analysis, and provision

of specific incident reports. Manual input will be from the System Operator entering incident data received by fax or telephone for example.

(b) Incident Data Collation. This fbnction must be able to collate the incident data that is received in (a). Collation of the data means analysing the received data to merge that which relates to the same incident. This can be done by looking at the location provided for each set of data and combining the data where commonalties exist. Once data for an incident has been received and recognised, a degree on confidence can be assigned to that data. Different confidence levels can be used for the data provided by each source. Thus as more data is collected about the incident from different sources, the overall confidence level can be increased.

(c) Strategy Selection. This function must be able to select a mitigation strategy when an incident has occurred. The trigger for the selection of the strategy can be the degree of confidence that has been assigned to the received incident data. Other criteria can also be used, such as the incident location and incident type. The strategy definition must include actions that are to be implemented once the incident occurs.

(d) Strategy Implementation. This function must implement the actions defined in the incident mitigation strategy. These can be split into two types; those that require other systems to take action, and those that require action by the System Operator. The most common examples of the actions to be taken by other systems are the display of advisory messages and changes in traffic management strategy. The output of advisory messages will usually involve the use of VMS, Information Display Units (IDU’s), fax and output to other TTIC’s. However the function must be capable of expansion to accommodate the other output mechanisms are now being developed such as, RDS-TMC and Cable TV. The System Operator may take action by passing details of the incident occurrence to other organisations, such as the Emergency Services, or broadcasters.

(e) Strategy De-selection. This function must be able to remove strategies once an incident has ceased to exist. It depends on the detection systems providing data, to show that the incident has ceased to exist. Once this data is received, an incident disappearance strategy can be implemented. This will have to be pre-defined and contain similar types of actions to those in the mitigation strategy. The actions in the disappearance strategy will not necessarily be a simple cancellation of the mitigation strategy actions since there may be a need for other remedial action.

(f) Strategy Analysis. This function must enable the analysis of the effects of mitigation strategies. The analysis must be able to show what happened when the various actions in the strategy were implemented and what other actions the System Operator took. This may involve the collection of data from other systems such as VMS.

Other fbnctions will be needed for incidents to be managed effectively. One of these is the fbnction that enables mitigation and clearance strategies to be input and made available for use by the functions in (c), (d) and (e) above. The mitigation strategy input will define the actions that it will take, plus criteria governing its implementation. These criteria will comprise the location of the incident and the

confidence level that must be assigned to the incident data before implementation of the strategy can take place. The location is very important since it is not generally possible to define strategies that are sufficiently generalised to apply in any location.

Function Incident Data Collection

Another 'function will be required to allow the System Operator access to the operation of the functions defined above, as well as that needed to input the two types of defined strategies. As noted in the section on the Operator's Point of View, the interface must be easy to use, and be capable of being operated from the minimum number of console points (terminals).

System ARTEMIS, CCTV, INGRID, Travel

Lastly, a function is needed to allow incident information to be disseminated. One way that this can be done is for information to be held in a store that can be accessed directly by other specialist systems, such as an Internet Server.

Incident Data Collation

Functional Implementation

Terminal, UTC Incident Management

Having defined the fbnctions as described above, the System Designer can now implement them. For ROMANSE this has been done through the development of several systems. These are shown in Figure 1. They implement the following functions.

Strategy Selection Strategy Implementation

Incident Management Incident Management, UTC, VMS

Strategy De-selection Strategy Impact Analysis

Strategy Input Operator Access

Incident Management, UTC, VMS RG Contram

Incident Management Incident Management ARTEMIS,

ASTRID, INGRID, Travel Terminal, UTC,

Incident Information VMS

Incident Management, Internet Server,

Although several systems are shown in the above table as providing the System Operator with access, they do not all use separate operator interfaces. Access to the Incident Management, ASTRID, INGRID and UTC systems is provided through the same interface using a single terminal (console point). For clarity System Operator interfaces to other systems in Figure 1 have not been shown.

Not all of the links between the systems shown in Figure 1 are provided electronically. For example that between the Incident Management System and the Travel Terminal is manual for the output of incident information to the Travel

716

Terminal Network. Also not shown is a fimction and link that enables the results of the RG Contram analysis to be turned into predefined strategies (or existing strategy modifications) and input to the Incident Management System by the System Operator.

Lastly the Incident Management System itself is not provided as a standdone system. It is in fact part of what is called the Integrated Traffic Management Computer (ITMC). This provides access for the System Operator to the UTC hnctions, comprehensive data storage facilities, as well as the incident management fbnctions described above.

Conclusions

The development of incident management for the ROMANSE TTIC has proceeded past the point where systems have been installed. Trials of actual strategy implementation are now being made and the results studied. These results will lead to improvements in the strategies themselves and in their implementation and co- ordinated through the ROMANSE Central Processor (RCP). The next generation of central co-ordination is being developed with the ITMC which will be operational later in 1997. Work is also going on to provide more electronic links between systems and information dissemination and to combine more of the operator access points into a single interface, available from one terminal.

Figure 1 ROMANSE Incident Management Functions

0 1997 The Institution of Electrical Engineers. Printed and published by the IEE, Savoy Place, London WCPR OBL, L

718