Business process description for Road Works Warning

Based on the general use case descriptions for the short-term stationary and mobile Road Works Warning service the respective business processes are identified. As template for the business process description the generic business process from the Reference Architec-ture (Figure 7.6) is used and adapted to the specific C-ITS Road Works Warning use cases.

The comparison of the use case diagrams (Figures 8.3 and 8.5) shows that the processes of the short-term stationary and mobile use case are rather similar. Hence, in general both use cases can be described by the same process as the difference between the use cases is just in the update of the position for the short-term mobile road works before broadcasting the message to the receivers. Apart from that, the timing of the individual process steps might be different: the moving trailer in the short-term mobile scenario meets the trigger for sending updated information to the traffic control centre more frequently, therefore the centre-side process steps might be executed more often.

For a first abstract description the general process derived both from the TISA value chain and the Matrix report and generically described in detail in section 7.2.3.1 is used. Ap-plying the general business process to the Road Works Warning use cases results in Fig-ure 8.6.

The process describes – rather general but yet specific for the service Road Works Warning – the core intermediate steps from the initial trigger (road works started, the sign board was lifted up) until the final presentation of the warning to the driver. Both the short-term stationary and mobile use case can be mapped to the process – the differences are hidden inside the process steps. Not only the two use cases are covered by this general

Figure 8.5.: UML Use case diagram for short-term mobile RWW in basic mode

Figure 8.6.: General description of RWW process chain

description – as well the corresponding operation modes of Road Works Warning (basic and stand-alone) fit in there.

For a more specific description of the business process it is necessary to include some more details and to adequately describe the single steps that need to be taken in the individual use cases – from gathering the raw data until the warning is perceived by the driver – to highlight already with the business process model the differences between the use cases.

In the more use case specific description the general process steps (collect data, pre-process data, run RWW service, present RWW service) therefore are split up into several elements.

For the detailed description the following four scenarios are considered:

• short-term stationary basic service

• short-term mobile basic service

• short-term stationary stand-alone service

• short-term mobile stand-alone service

Basis for the description of the four scenarios is the more detailed but still generic descrip-tion of the business process depicted in Figure 8.7.

In Figure 8.7, the core elements of the business process (from Figure 8.6) are complemented with all modules used in the implementations of the different short-term Road Works Warning scenarios.

The previous analysis already showed that the mobile and stationary short-term use case in general are rather similar, including their process chains. Hence, for the detailed de-scription the use case options are not split up between the mobile and stationary use cases but according to the identified major difference, the operation modes of stand-alone and basic mode – here, substantial variations exist.

Figure 8.7.: Generic description of RWW use case – independent of short-term/long-term, mobile/stationary and basic/stand-alone mode

The two modes come along with different assignments of process steps to actors and com-ponent – depending on this assignment different degrees of complexity in the processing and evaluation modules are possible. Hence, two separate business processes are modeled for the basic and stand-alone use case of the short-term RWW scenario.

The short-term road works use case is realized based on the legacy road works locating system, the detailed business process for the basic operation mode is depicted in Fig-ure 8.8. The data collection comprises the call of positioning information (of the road works safety trailer) from the GPS module that is mounted on the trailer and the call of the activated arrow sign configuration (metal sheet sign and LED panel). This set of raw data is then transmitted to the traffic control centre.

In the legacy road works positioning system several preprocessing steps are already im-plemented. This mainly results of the implemented technical architecture and comprises the filtering of messages (separate road works relevant messages from operational or error messages). In conjunction with other uplink service that will be implemented on the road works safety trailer (sending error messages to the traffic control centre) this functionality is still required – however it is not specific to the Road Works Warning service.

Figure 8.8.: Detailed business process for short-term RWW basic mode implementation in Germany

The actual Road Works Warning service consists of several elements. First a map match-ing of the trailer position takes place. This is required both to improve the GPS signal as well as converting the WGS84 (World Geodetic System 1984) coordinates into the location referencing system used by the traffic control centre. Afterwards, the lane closed by the trailer is determined. Given that the GPS position has no lane accuracy and the arrow sign configuration is not completely explicit regarding lanes this information can only be deter-mined in the traffic control centre with support of a map. (There will be no map available on the trailer.) In the next step, multiple trailers are combined with each other – in case that several lanes are blocked by the short-term road works several trailers are required, in the traffic control centre they are merged into one road works object. These processing steps are followed by two optional operations: if a road works management data base is available the data from the trailer and the static data from the database are merged. This might lead to an enhanced description of the road works. And finally, an optional plausi-bility check by an operator might follow. All computations together lead to an enhanced and validated set of Road Works Warning parameters. They are passed back to the road works safety trailer.

Finally, the road works safety trailer converts the content in vehicle-understandable mes-sages and broadcasts the information via ETSI ITS G5. In the vehicles, the service results are prepared for presentation and are finally presented to the driver.

Parallel to the dissemination of the information to the road works safety trailers the in-formation is as well provided through other means. The road works inin-formation will be available via the MDM, service providers might sign up for this content and develop their own services. They might broadcast the information via cellular network, Digital Audio Broadcast (DAB) or other communication bearers.

The business process for the Road Works Warning service in stand-alone operation is slightly different from the one depicted in basic mode Figure 8.8. In stand-alone mode, no connection to the traffic control centre is possible therefore only a limited set of func-tionalities is available (Figure 8.9). All preprocessing activities are canceled and the service activities are reduced to the generation of messages for the vehicles. In stand-alone mode only communication with the vehicles via ITS G5 is possible, the data is not published via the MDM and service providers have no access to this data for their services.

Figure 8.9.: Detailed business process for short-term RWW stand-alone mode implement-ation in Germany

In general, the stand-alone service should be active only rarely. Once active and connected to the traffic control centre a trailer might continue to broadcast the enhanced set of in-formation received when being in basic mode as long as the road works is not closed and started again or major changes of the road works configuration take place (e.g. changed configuration of arrow signs). In such a situation missing cellular connections may be by-passed without switching back to the stand-alone mode. In consequence, the stand-alone mode will only be in use right after a road works was started and in case that there are major problems with the cellular network link to the traffic control centre.

Concluding the detailed description of Road Works Warning use case, sequence diagrams were developed to show the timely course of actions for this service. The sequence dia-grams (Figures 8.10 and 8.11) additionally highlight the main difference between the basic and stand-alone use case that were already touched before.

Figure 8.10.: Sequential flow for RWW service in basic mode (UML sequence diagram)

8.7.3. Road Works Warning modules and their assignment to components The detailed description of the business process in the previous chapter shows that the service Road Works Warning is built up of a large number of smaller units. Partially, they were already used in the pre-C-ITS implementation of Road Works Warning that did not use the ITS G5 broadcast (legacy road works position in a systems like DORA¹). Accor-dingly, they can be taken from the Modular Construction System. Modules that are addi-tionally required will be registered with the Modular Construction System so that they are available for any upcoming implementation.

1System forDynamicPOsitioning of Short TermRoAdworks

Figure 8.11.: Sequential flow for RWW in stand-alone mode (UML sequence diagram) This chapter comprises first a list of modules which are required to implement the Road Works Warning service (8.7.3.1). This is complemented by the actual assignment of mod-ules to components (8.7.3.2) what is closely linked to the description of the technical view-point.

8.7.3.1. Modules

Table 8.2 indicates which modules are already existing or need slight modifications and which new (additional) modules are required. The modules are described more detailed in Table 8.3, a description that is detailed and precise enough for an implementation can be found in the deliverables of the project groups on ICS – Cooperative ITS Central Station (PG2) [C-ITS Corridor and Hessen Mobil Straßen- und Verkehrsmanagement, 2016] and IRS – Cooperative Roadside Infrastructure (PG4) [K ¨uhnel et al., 2015].

The specifications will be publicly available as soon as they are approved for tendering.

Module Description Legacy

ITS RWW

C-ITS RWW

Module 1a Retrieve the position information X Module 1b Retrieve the arrow sign configuration X Module 1c Generate a message with the retrieved

con-tent that can be sent through cellular network X_m

Module Description Legacy ITS RWW

C-ITS RWW

Module 2a Retrieve the status of technical components of the road works safety trailer (e.g. battery status and others)

X

Module 2b Generate a message with the component sta-tus / error message

X_m Transfer of data through cellular network is not wrapped into a module as this is a stan-dard task fulfilled by cellular network opera-tors. The Road Works Warning service only uses this functionality.

Module 3 Filter content and error messages (messages from Modules 1c and 2b)

X Module 4a Generate new Road Works Warning data

ob-ject

X Module 4b Update Road Works Warning data object X Module 4c Merge Road Works Warning data objects

(road works with more than one road works safety trailer)

X

Module 4d Archive / Delete Road Works Warning data object

X Module 5a Map matching of road works safety trailer

position

X_m Module 5b Determine position on traffic control centre

map

X Module 5c Determine lane that is closed by road works

safety trailer

X Module 6 Combine multiple road works safety trailers

working at the same construction site (clo-sing multiple lanes) and retrieve their rela-tive positioning

X

Module 7a Get data from RWMDB X

Module 7b Combine / Merge data from the road works safety trailer with data from the RWMDB

X

Module Description Legacy ITS RWW

C-ITS RWW

Module 8a Generate a message with the improved / up-dated content of the Road Works Warning object that can be sent through cellular net-work

X

Module 8b Generate a message with the improved / up-dated content from the traffic control centre that can be passed to service providers and other road operators (both via MDM)

X

See above – the transfer of the message via cellular network is not described here in de-tail.

Module 9 Update the received content with current po-sition and time stamp (optional – only in case that the trailer changed its position in the meantime)

X

Module 10 Generate message that can be sent through ITS G5

X Module 11 Broadcast the message to the recipients (via

ITS G5)

X Module 12 Prepare the message for presentation (X)

Module 13 Present the information (X)

Table 8.2.: Modules for RWW service

grey modulesactually belong to the service that provides operational informa-tion about the road works safety trailer to the road operator, this informainforma-tion is collected within the Road Works Warning service

Xmstands for ’needs slight modification’

(X) modules are not in focus, they are in the responsibility of the vehicle manu-facturer and brand specific

The modules listed in Table 8.2 provide the following general features:

Module Title and Description

1a Retrieve the position information

The road works safety trailer is equipped with a GNSS component.

This is used to identify the position of the trailer and code it in WGS84 coordinates.

1b Retrieve the arrow sign configuration

Module Title and Description

The road works safety trailer has a sign board that is closed when the trailer is not active. When the short-term road works is started the sign board is opened. On the sign board are two signs, a metal sheet sign with an arrow that may point to the bottom left, bottom middle and bottom right and a LED sign that can display an arrow pointing to the bottom left, the bottom right or a cross. The possible arrow sign configurations are described in the RSA [Forschungsge-sellschaft f ¨ur Straßen und Verkehrswesen, 1995].

1c Generate a message with the retrieved content that can be sent through cellular network

The position of the trailer and the arrow sign configuration is put together in a message – the detailed description for this public in-terface can be found in section 8.7.4.

3 Filter content and error messages (messages from Modules 1c and 2b)

In parallel to the Road Works Warning service various other para-meters which are relevant from an operators perspective are col-lected. They are not part of the Road Works Warning service but are transmitted to the traffic control centre together with the data from the Road Works Warning service. The filter module separates the two types of content.

Partially, the data of the operational phase might be of relevance for the Road Works Warning service.

4a Generate new Road Works Warning data object

When a trailer becomes active and first sends its position and data to the traffic control centre a new data object is initiated.

4b Update Road Works Warning data object

The trailer sends new or updated information (new position, changed configuration of arrow signs), this requires an update of the already existing data object. Alternatively, the modules on the centre side generate new or updated content, this requires an up-date of the already existing data object.

4c Merge Road Works Warning data objects (road works with more than one road works safety trailer)

Several trailers belong to one road works, the corresponding data objects are merged into one or are linked to each other

4d Archive / Delete Road Works Warning object

The road works is finished when the sign board is closed. The road works data object is deactivated and moved into an archive for log-ging purposes.

5a and 5b Map matching of road works safety trailer position

Module Title and Description

Determine position on traffic control centre map

The WGS84 coordinates determined by the trailer are converted into the traffic control centre location referencing system and the posi-tion of the trailer is determined. Eventually the posiposi-tion is corrected if the coordinates do not point to a location on the road network.

The Road Works Warning data object is updated.

5c Determine lane that is closed with road works safety trailer

With the support of the traffic control centre map the closed lane is determined and encoded. The Road Works Warning data object is updated.

6 Combine multiple road works safety trailers working at the same construction site (closing multiple lanes) and retrieve their relative positioning

A road works setup may consist of several closed lanes and there-fore multiple road works safety trailers. For a complete description of a single road works it is checked whether there are other trai-lers blocking neighboring lanes. They are combined into one road works. The Road Works Warning object is updated.

7a Get data from road works management data base

Partially, short-term road works are already registered in the road works management data base run by the road operator. The entries in the database might provide additional information that cannot be derived from the information received from the road works safety trailer. A query to the road works management data base is issued to retrieve potential additional information.

7b Combine / Merge data from the road works safety trailer with data from the road works management data base

The data from the road works management data base is merged with the data so far collected about the short-term road works. The Road Works Warning data object is updated.

8a Generate a message with the improved / updated content of the Road Works Warning object that can be sent through cellular net-work

The content of the Road Works Warning data object is encoded in a suitable message format so that it can be sent to the road works safety trailer for further dissemination to the vehicles, the detailed description for this public interface can be found in section 8.7.4.

8b Generate a message with the improved / updated content from the traffic control centre that can be passed to service providers and other road operators (both via MDM)

Module Title and Description

The content is as well published on the MDM so that service pro-viders can pick it up. The Road Works Warning object is converted into a DATEX II message.

9 Update the received content with current position and time stamp (optional – only in case that the trailer changed its position in the meantime)

Only in short-term mobile use case: after the road works safety trai-ler received the updated road works data object it updates the po-sition with the most recently determined popo-sition (from the GNSS module).

10 and 11 Generate message that can be sent through ITS G5 Broadcast the message to the recipients (via ITS G5)

The content is passed to the ITS Station, in the facility layer of the ITS Station a Road Works Warning DENM is generated.

12 and 13 Prepare the message for presentation Present the information

The receiver of the Road Works Warning DENM takes the necessary steps for presentation of the content. This is not detailed here as it is not in the scope of the C-ITS Corridor. Both the preparation and presentation of the information is in the responsibility of the

The receiver of the Road Works Warning DENM takes the necessary steps for presentation of the content. This is not detailed here as it is not in the scope of the C-ITS Corridor. Both the preparation and presentation of the information is in the responsibility of the

Im Dokument Method to develop an overall architecture for Cooperative ITS  (Seite 187-200)