Chapter 2

Management of Emergency Situations: Architecture and Engineering of Systems of Systems ¹

2.1. Introduction

This chapter is given over to an emergency situation scenario. Our aim is to carry out engineering studies and create the architecture for a system of systems with the objective of improving the general treatment of road accident victims in order to reduce mortality and handicap rates within a region.

In the first section, after a brief overview of the main concepts of systems engineering, we shall present the context of the emergency situation management scenario. We shall then describe the events surrounding a major accident that led to a decision being taken by the authorities of the (fictional) Tairétalet region.

The bulk of this chapter is devoted to the system-of-systems engineering activities and studies that must be carried out, putting the theoretical and practical aspects illustrated by this case study into perspective. Our viewpoint on the situation will be that of the research department that responds to the call to tender launched by the Tairétalet region.

We shall conclude this chapter by highlighting aspects that characterize the architecture and engineering of systems of systems in relation to systems architecture and engineering, as described in the founding structural documents of the ISO³/IEC 15288 standard [ISO 02, ISO 08, RUA 10c], the INCOSE⁴ systems engineering manual (Systems Engineering Handbook v3.1) [INC 07], the architecture description [ISO 10c], and NATO’s architecture framework [NAT 07, RUA 10c].

We shall aim to cover this subject in breadth rather than in depth – a necessary approach when considering a system of systems.

2.2. Main concepts of systems engineering

We shall not go into great detail here concerning these main concepts. Readers are invited to refer to [RUA 10a] for further details. Remember that systems engineering applies to artificial systems, designed by human beings.

A system is mostly made up of:

– goods or services provided to a final user;

– technical, material or software components involved in the production of these goods and services;

– organized processes and activities for production and support to create these goods and services;

– operators who carry out these processes and activities following established trade rules and procedures, using competences in terms of knowledge and practical abilities;

– information and data used by operators to successfully carry out their activities;

– a means of informing clients of the availability of proposed goods and services;

– products or services that contribute to the creation of the system, without themselves being system components (scaffolding allows us to build a house, but is not part of the building itself); and

– various types of resources (energy, etc.) and consumables (paper, etc.) needed for the successful execution of these activities and in the creation of goods and services.

In addition to the first three dimensions, respectively structural (the make-up of the system), functional (the services and functionalities produced by the system) and dynamic (how services are organized and operate), we should envisage a fourth dimension, that of temporal evolutions. These are needed to adapt to a perpetually changing environment, i.e. the development of components, functionalities and behaviors. Finally, we must differentiate between aspects belonging to the new system, with these four dimensions, that is the system of interest, and the processes and activities involved in designing, producing, using, maintaining and dismantling the system, with the methods and tools needed for these activities, which are parts of the enabling system.

“Systems engineering is the set of activities which, based on an identified operational need and using an organized approach, aim to set out this need in technical terms, transform it progressively into a system solution and demonstrate, at each stage, that this system responds to a need” [BNA 05]. Systems engineering is not a monolithic domain; on the contrary, it is by its very essence interdisciplinary. In the modeling approach used today, this translates as accounting for and integrating different models, including the economic model, the usage (operational) model, the functional model and the technical model. As we shall see, these models are not exclusive. Thus, other models, including communications models or regulatory models, may be used. This approach falls under the umbrella of modelbased systems engineering [MEL 04], which is sometimes confused with the notion of model-driven architecture⁵. This perspective conforms to the recommendations of the architecture description standard [ISO 10c].

Throughout this chapter, we shall adhere completely to this interdisciplinary approach and to the logic of model-based systems engineering, supported by recent structuring work in the domain [BOE 06, MAI 09].

As defined by [ISO 10c], “the architecture of a system constitutes that which is essential, fundamental, in relation to a system considered in its relationships with its environment. If there is no single characterization, this characterization may make use of one or all of the following properties:

– the components or elements of the system;

– the way in which system elements are organized, interconnected;

– the principles governing the organization or design of the system;

– the principles governing the evolution of the system throughout its lifecycle”.

Different models representing the architecture of the system of interest are grouped together in views. The grouping principles for the constitution of these views are based on different viewpoints, which correspond to the perspectives different actors have of the system. Thus, each view corresponds to a theme or preoccupation and brings together a set of models linked to this theme. This allows different groups involved in the system to concentrate on the particular dimensions that concern them, without having to deal with dimensions that are irrelevant to their purposes. Thus, the Tairétalet authorities are interested in the performance of the system of systems, its capacities and its attainment of assigned objectives; for this reason, the authorities will use the (global) view, program view and capability view (following the NATO architecture framework). However, these authorities will not be interested in technical details, as described in the technical view of the NATO architecture framework. In the same way, operators are interested in the facility of use and the adequacy of the system for their activities.

The architect is responsible for maintaining coherency between the different preoccupations of these different groups of participants, in order to evaluate the impact of decisions in one dimension on other dimensions and to maintain coherency between views and their respective models.

The NATO architecture framework, referred to as NAF v3 (NATO Architecture Framework, version 3), includes a set of views. It would be foolish to try and apply a canonical approach to the development of the NAF v3 views to all project types. Views should be developed as needs and must be suited to the objectives, context and constraints of each project without resorting to attempts to systematize.

In the context of our study, the order of development of NAF views is as follows:

– NATO All View, NAV: description of the objectives and stakes of the project for a system of systems for emergency situation management;

– NATO Capability View, NCV: description of expected capabilities and their performances, where relevant, allowing the attainment of defined objectives;

– NATO Program View, NPV: description of programs and the markers they use to create the systems needed to produce expected capabilities;

– NATO Operational View, NOV: description of reference and alternative operational scenarios from which systems will be created;

– NATO Systems View, NSV: description of the architecture of the systems responsible for creating reference and alternative operational scenarios;

– NATO Service-oriented View, NSOV: description of services (adapted for service-oriented architectures);

– NATO Technical View, NTV: description of standards to apply and their medium- and long-term evolutions.

Note that this is not a fixed linear sequence. Views are regularly enriched, modified and updated in the context of an iterative and incremental design process. This implies the use of rigorous configuration management.

2.3. Context of the emergency situation management scenario

2.3.1. Global context: Tairétalet

Tairétalet is a large and sparsely populated region. It contains one major town, Quercus, with access to infrastructures (hospital, emergency services, telecommunications, road, rail and air infrastructures, etc.) and two towns of lesser importance, Salix and Fraxinus, with more limited infrastructures. Tairétalet maintains a strong relationship with the neighboring region of Orion. The region appeals to tourists who wish to experience the region’s rich heritage and calm environment, and also experiences passing traffic.

Over the past few years, the number of accidents on Tairétalet’s roads has been particularly high. In most cases, these accidents were not particularly serious. However, delays in raising the alarm, the difficulty of access to accident sites by the emergency services and the inadequacy of the infrastructure for dealing with casualties, who often need to be transferred to Quercus, have rendered these accidents more serious than they were initially.

There have been several more serious cases of pile-ups or major coach accidents. The weakness of local emergency services and the inability to bring in local reinforcements within a reasonable time period renders the evacuation of casualties particularly difficult. Furthermore, due to a lack of coordination, hospital facilities 90 Complex Systems and Systems of Systems Engineering near to accident sites rapidly become overloaded and do not have the capacity to send victims directly to centers with available facilities.

One particularly serious coach accident led to an inquest, which produced a report presenting the circumstances of the accident and the actions of the emergency services. A certain level of confusion in the organization of the emergency services limited their capacity for successful access. The saturation of hospital resources and an excessive workload for hospital staff led to discontent among hospital personnel and citizens of the region. This report on the Dubbus company accident (see section 2.3.2) led the Tairétalet authorities to decide to launch our project.

2.3.2. Synthesis of the Dubbus accident report

On Monday, November 12, 2007, before dawn, on a small and little-used road in Tairétalet, the driver of a delivery lorry lost control of his vehicle. The vehicle deviated from its trajectory and entered into a head-on collision with a coach transporting boarding school pupils to Fraxinus, which was coming in the other direction.

At 0800 hours, a motorist heading towards Fraxinus discovered the accident. He went to the nearest hamlet and raised the alarm at 0805 hours and telephoned the regional call center. The call center sent out ambulances from Fraxinus, the station closest to the scene of the accident.

At 0830 hours, three ambulances from Fraxinus arrived at the scene of the accident. The ambulance personnel assessed the scale of the accident and called the fire station⁶ in Quercus to request reinforcements. They treated the most serious injuries first (hemorrhages, etc.).

Firefighters from Quercus, accompanied by emergency medics, arrived on the scene at 0940 hours with medical ambulances and emergency care equipment that they put to immediate use.

The medics, firefighters and ambulance crew assessed the seriousness of the injuries of each child, with immediate emergency care given to the most serious cases, and prepared to transfer two seriously injured children to the hospital in Quercus. The other children were sent to the hospital in Fraxinus. By 1130 hours, all of the children involved had been hospitalized.

Several children died before or during initial treatment or during the evacuation to Fraxinus. One victim, initially sent to Fraxinus, was then transferred to Quercus and died during the transfer.

The total number of victims was as follows:

– fifteen dead, including:

- the lorry driver, the coach driver and four children who died at the moment of the impact,

- three children who died between the time of the accident and receiving treatment,

- two children who died during initial treatment,

- three children who died during their evacuation to Fraxinus hospital,

- one child who died during the transfer from Fraxinus to Quercus;

– three children suffered very serious injuries and will be handicapped for life;

– ten children were seriously injured;

– five children presented only minor injuries but were traumatized and required psychological care.

An analysis of the accident and the actions of the emergency services, carried out by independent accredited experts, showed that management problems in the provision of emergency services were responsible for the deaths of six children (those who died during treatment and during transfer to the hospital) and for the permanent nature of the handicaps of the three very seriously injured children. The regional call center had no means of assessing the seriousness of the accident and so did not immediately see the need to bring in personnel from Quercus fire service. Moreover, the regional call center did not have the means to rapidly provide a synthesis of information to the ambulances from Fraxinus. Fraxinus hospital did not have the facilities needed to treat the child who was then redirected to Quercus, but neither the fire service nor the ambulance crew was aware of this. Moreover, when the fire and ambulance crews telephoned the accident and emergency department at Fraxinus hospital, they were forced to go through the hospital switchboard and, at times, placed on hold: no direct line was available for use by the emergency services. The experts also noted that means of measuring vital signs and evaluating the development of the state of victims were only available in the medically equipped ambulances (i.e. not in the simpler transport ambulances). Finally, at the hospital, teams were not able to prepare equipment to deal with the casualties of the accident and thus experienced delays in beginning treatment. The experts recommended that the whole victim treatment system be improved, without going into detail on particular constraints.

The citizens of Fraxinus and the surrounding area and the population of Tairétalet as a whole were deeply affected by this accident and demanded that these expert recommendations be followed. The members of medical staff at Fraxinus hospital were also affected and bemoaned the fact that lack of means and coordination had led to the deaths of nine children.

2.3.3. Decision of the Tairétalet authorities

Following the publication of this report, the Tairétalet authorities decided to make use of a variety of means, with the aim of ensuring:

– rapid notification of emergency service centers in case of accidents;

– rapid evaluation of the seriousness of an accident;

– deployment of emergency service resources suited to the gravity of the accident throughout the assistance procedure;

– direction of victims towards hospital facilities best suited to the seriousness of their state;

– preparation of equipment in hospital structures for rapid treatment of patients, adapted based on the diagnosis of casualties by the emergency services, a diagnosis that may develop over time;

– optimized management of emergency services and regional hospital resources in serious accident situations (coach accidents with multiple casualties, for example).

These are the results of a functional analysis carried out with the Tairétalet authorities and the main groups involved in the accident (fire service, insurance companies, etc.).

This decision may be placed at level 3 in terms of accident response, on a scale of five levels found in the standard document on global security [ISO 10b].

The first level applies to tactical command, and may be raised to strategic level if necessary, for example in cases where a lorry transporting hazardous goods is involved in an accident.

The tactical level concerns accident management, the coordination of different actors and their cooperation in a context of mutual assistance following established conventions.

OASIS⁷ proposes a structure over three levels: strategic, operative and tactical [CEN 09a, CEN 09b].

The Tairétalet authorities, situated at strategic level, pilot a project concerning the regional call center, situated at operative level, and the emergency service teams involved, situated at tactical level.

This information is at the base of the global view (NAV-1, Overview and Summary Information), in accordance with the NATO architecture framework for formulating and structuring objectives.

For the Tairétalet authorities, the attainment of these objectives is expressed by the following capability and performance data:

– mean time to intervention on the scene of an accident: 30 minutes; standard deviation: 15 minutes;

– mean time for patients to reach a suitable hospital structure: 75 minutes; standard deviation: 30 minutes;

– level of suitable treatment: 80% (the level of transfer between two hospital structures after the patient first arrives at a hospital should be less than 20%);

– reduction in the workload of emergency services and hospital staff;

– increased satisfaction levels of emergency service crews and hospital staff;

– financial or fiscal aid favoring multiservice companies that contribute to emergency service capabilities;

– shared finance involving territorial authorities, citizens and insurance companies, requiring evaluation and determination.

Moreover, as the Tairétalet authorities are aware of the difficulties involved in generalizing an approach of this kind, they envisage an incremental roll-out of these capabilities, in strict cooperation with the authorities of the Orion region.

Table 2.1 presents capabilities, following NCV-1, Capability Vision, from the NAF v3 framework.

Table 2.1. Expected capabilities of the system of systems for emergency situation management

Capabilities	Performance
- average time taken to arrive at the scene of the accident	- 30 min; standard deviation: 15 min
- time taken to reach suitable hospital facilities	- 75 min; standard deviation: 30 min
- level of access to suitable hospital facilities	- 80%; level of transfer between two hospitals after initial triage should be below 20%
- reduction in workload levels for emergency services and hospital personnel
- increase in satisfaction of emergency services and hospital staff
- finance shared between territorial organizations, citizens and insurance companies, to evaluate and state the shared inputs between territorial organizations, citizens and insurance companies.

A first step, planned for T0+24 (24 months after project launch), is planned. The contents of this first step are as follows:

– all public transport and utility vehicles (LGVs, Large Goods Vehicles) registered in the Tairétalet region and new passenger vehicles belonging to Tairétalet residents shall be equipped with accident detection equipment;

– the regional call center shall have access to a system for the reception and processing of information sent by this accident detection equipment;

– the Tairétalet authorities, insurance companies and automobile manufacturers should contribute to the pilot process for installing accident detection equipment in vehicles in the region;

– the ambulances belonging to emergency service centers and multiservice companies in Tairétalet and the helicopter and possibly ambulance services of Orion shall have a means of communicating with the Tairétalet regional call center;

– the hospital centers of the Tairétalet region shall also have access to a means of communicating with the regional call center;

– the hospital centers of the Tairétalet region shall have access to a resource management system (availability of beds in different departments, equipment, etc.) suited to their specific means of operation and capable of interoperating with the regional call center.

A second stage is planned for T0+48 (48 months after project launch):

– all light vehicles belonging to private individuals in the Tairétalet region, along with all public transport and utility vehicles in Orion, shall have accident detection equipment;

– the ambulances belonging to emergency service centers and multiservice companies in Tairétalet, the helicopter and ambulance services of Orion and the Tairétalet hospital centers shall have a means of communicating information concerning vital signs between vehicles and hospitals;

– the regional call center, emergency service centers and multiservice companies of Tairétalet shall have a means of measuring performance in emergency situations (time to intervention, resources used in the context of an accident, etc.);

– the hospitals of the Tairétalet region shall have a means of measuring performance suited to expected capabilities (time for a victim to be accepted into a suitable hospital structure, level of suitable treatment, workload of hospital personnel, satisfaction levels of hospital personnel);

– the Tairétalet authorities, the regional call center, emergency service centers, multiservice companies, hospitals and insurance companies active in the region shall contribute to the process of piloting road emergency management and have access to a shared means of representing an emergency situation in relation to their needs.

The third and final stage of the project is planned for T0+60 (60 months after launch):

– all vehicles in transit in the Tairétalet region shall have accident detection equipment;

– the regional call center shall have access to a system for receiving and processing information from the emergency detection equipment of vehicles in transit;

– the Tairétalet authorities, the regional call center, emergency service centers, multiservice companies, hospitals and insurance companies shall contribute to a continuous process of improving the management of emergency situations in the road network, in cooperation with neighboring regions sharing the same approach.

Each of these stages is accompanied by incentives and dissuasive measures, which may be fiscal, financial or judicial in nature or take an entirely different form. Plans should be made for the contents and implementation of these measures.

Finally, this incremental approach should be “smoothed”, i.e. decisions taken during the early stages should not be questioned during the later stages. From the beginning of the process, special consideration must be given to demands and constraints that may have an impact on other stages.

The Tairétalet authorities decide to employ an engineering consulting company to assume responsibility for the project and carry out the necessary activities in order to attain the expected performances for all the terms defined.

In addition to the technical aspects, which fall within its remit, the engineering consulting company must seek help from external sources in cases where the required competences are not available internally.

This organization must also act as a mediator between different parties and establish means of communication. It should recommend incentive and dissuasive solutions for implementation by the Tairétalet authorities. Finally, the organization must ensure the coherency of economic, regulatory, technical architecture and communications models, respect the time delays set out for each stage and manage overall risk throughout the project.

We shall now take the place of the engineering consulting company responding to the request issued by the Tairétalet authorities and propose a number of elements contributing to the creation of a solution.

2.3.4. Analysis of context and participants involved

A first step is to identify the context of expectations and all participants involved, known as “stakeholders” in systems engineering terms.

This context analysis allows us to identify three main domains:

– the domain of accident detection equipment, which concerns the means of detecting accidents and alerting the necessary organizations;

– the domain of emergency services, which concerns all means used to assist road accident victims (call center, ambulances, hospitals, etc.);

– the piloting and management domain, which covers the measurement and improvement of global performances.

The identification of these domains allows us to identify those concerned, i.e. stakeholders, classified according to domain.

Table 2.2. Participants concerned, by domain

Domain	Stakeholders
Accident detection equipment	Stakeholders in this domain include: – the Tairétalet authorities; – the Orion authorities; – drivers in Tairétalet; – tourists coming to, or traversing, Tairétalet; – vehicle fleet owners (rental vehicles, public transport, freight) in Tairétalet or from other regions if their fleet vehicles pass through Tairétalet; – vehicle manufacturers (automobiles, LGVs, etc.); – constructors of accident detection equipment; – mechanics who may need to install accident detection equipment in vehicles already in circulation; – supervision authorities likely to sanction or promote the use of accident detection equipment; – monitoring organizations concerned with vehicle safety and security; – telecommunications network operators; – insurance companies (for cars, drivers, vehicle fleets, etc.); – general or specialized media in the automobile domain (major newspapers, specialized expert journals, etc.). Experts in the domain, whether independent or linked to organizations, who may be called on as witnesses.
Emergency Services	Stakeholders in this domain include: – the Tairétalet authorities; – the authorities of other regions, particularly Orion; – the directors and staff at Tairétalet call center; – the directors and staff at Tairétalet emergency service centers; – the directors and staff at multi-service companies with ambulances; – the directors and staff at Tairétalet hospitals; – the directors and staff at Orion emergency service centers; – the directors and staff at multi-service companies with ambulances in Orion; – the directors and staff at Orion hospitals; – construction of ICT systems for call centers and hospitals and service providers in this specific sector; – standardization organizations. Supervisory authorities, including those contributing to the interoperability of systems in the hospital sector.
Management	Stakeholders in this domain include: – the Tairétalet authorities; – the authorities of other regions, particularly Orion; – the directors and staff at Tairétalet call center; – the directors and staff at Tairétalet emergency service centers; – the directors and staff at service companies with ambulances; – the directors and staff at Tairétalet hospitals; – the directors and staff at Orion emergency service centers; – the directors and staff at service companies with ambulances in Orion; – the directors and staff at Orion hospitals; Those responsible for the construction of ICT systems for call centers and hospitals and service providers in this specific sector.

The diagram presented in Figure 2.1 shows the context of stakeholders in the accident detection system. In addition to the identified participants, we should also consider the citizens of the Tairétalet region, both drivers and others, as, finally, the Tairétalet authorities are answerable to the region’s citizens, who are financially implicated in this project via taxes.

This first analysis allows us to make contact with those concerned and to study existing resources and methods. We need to collect requests formulated by these different participants in order to create a set of solutions that satisfy stakeholders as far as possible.

2.3.5. Results of studies on existing resources

tudies have shown that it is possible to install accident detection systems in vehicles, whether at the moment of construction or later on. This is not, however, widespread and there has been no generalized use of this equipment that would allow us to estimate the feasibility of such an approach for a whole region, with a heterogeneous range of vehicles of differing ages spread among the population. One vehicle manufacturer offers this equipment as an option in new high-end vehicles, and several equipment manufacturers offer accident detection equipment for later installation, with service propositions ranging from something fairly simple to much richer offers. Independent experts, or occasionally those linked to insurance companies and tribunals, fear that this new equipment, as an addition on an older car, might interfere with the operation of onboard electronics, including the motor. In general, car designers do not expect that such equipment will be installed at a later date and no plans are made for the possibility of adding emergency detection equipment at the moment of design. Other experts highlight the potential risks of over-confidence in equipment of which the reliability has yet to be demonstrated. These reliability problems may lead to non-detection of serious accidents due to equipment malfunction. They may also cause a number of false alarms, leading to useless and costly deployment of precious emergency resources that may then be unavailable in cases where they are truly necessary.

Several types of technology are available. The first type is based on a dedicated network, requiring the creation of a fine mesh of transmitters covering the territory. It guarantees a high quality of service (precise geo-location, high availability and rapid establishment of contact with the emergency call center after an accident). This solution includes ad hoc equipment installed in vehicles after construction, transmitters, the network and the supervision center. It is based on annual subscriptions by service users. A second type of approach uses the GSM telecommunications network and only requires subscription to a telecommunications operator. The majority of Tairétalet citizens have a cell phone, and GSM coverage of the region is good, at 90%. However, certain (mountainous) zones are not covered.

One of the local insurance companies, Sécuroute, which has a weak presence in the region but for which road safety is an important value and a factor of differentiation from competitors, decides to help drivers wishing to make use of this new equipment by offering a reduction in insurance payments, an incentive to use accident detection devices. Sécuroute is in favor of participating in an information campaign promoting this solution on the condition that the company’s participation will be noted in information campaign materials and that it may include such information in its promotions and offers.

A regional call center, with a single “emergency” telephone number, is installed in Quercus. The tools and resources available to the center are minimal. Six permanent operators work in the center to provide 24/24 and 7/7 coverage, supervised by a manager responsible for the whole call center. When operators require additional information, for example concerning road traffic or climate conditions, they make use of websites presenting this information (for example, the Sytadin website for traffic information, www.sytadin.fr/, a French intelligent transport system) or available telephone services (for example weather reports). Operators note relevant information on scraps of paper and their workspace is organized so as to structure and enable rapid retrieval of this information. Currently, emergency service provision in Tairétalet includes an emergency response center and a fire station in Quercus and a fire station in Salix – which we shall refer to from now on as the Tairétalet emergency service centers – and a group of multi-service companies (public transport, taxis and ambulances) located in Quercus, Salix, Fraxinus and major villages in the region.

Only the Quercus fire station has the means of planning emergency interventions at the scene of an accident, with sufficient life support resources and two medically equipped ambulances. Two emergency medics and a number of nurses accompany the fire crew on their missions.

The fire station in Salix has one medical ambulance and its team includes one nurse. The group of ambulances available from multi-service companies varies and none of the vehicles is medically equipped. The drivers of these ambulances are not accompanied by nurses or medics. The fire service ambulances use a dedicated telecommunications service, but this is not the case for multi-service company ambulances: in these cases, drivers use their own portable telephone or one provided by the company.

In emergency situations, the Tairétalet region may call in help from outside, including a helicopter and medically-equipped ambulances from the neighboring region of Orion, assuming these resources are available. Only Quercus hospital has a dedicated helipad. In an emergency, a helicopter may land near Fraxinus hospital, using an empty grassy space. In this case, the helicopter pilot must be experienced as there is no signal system and there are no markings.

Among the hospital structures present in Tairétalet, only the hospital in Quercus has an automated information system allowing real-time resource management, whether in terms of equipment or bed occupancy in different services. The other hospitals have non-automated, file-based information systems, but all units aim to acquire automated information systems. Several solutions are available on the market. A major provider of computerized systems, PrimoComputing, which has a large production unit in Quercus and directly or indirectly employs a large number of workers, offers an all-inclusive solution, including materials, software and communications systems. Other solutions are based on a set of recently developed standards. A service company in Orion, SoluPlus, offers a solution based on the integration of different modules that may be adjusted to suit client needs. This company has a network of agencies across Tairétalet offering service provision in the domain of computing. Finally, other regions, including Orion, are also envisaging solutions to reduce road accident deaths. Accident detection, emergency service management and the management of hospital resources are included in different solutions suggested. The establishment of interoperable systems would facilitate the use of emergency calls for the inhabitants of these different regions, especially drivers of utility vehicles and coaches that habitually travel across several regions.

Studies have been carried out on the social, sanitary and economic benefits that may be offered by road accident detection services, but nothing conclusive has been established concerning the financial responsibilities of different stakeholders. Several regions intend to include these themes in their local Agenda 21.

The main risks identified are as follows:

– conflicts between the political and economic interests of major actors in Tairétalet on one hand, and the overall, operational, technical, human and financial satisfaction of the project on the other;

– social issues linked to the implementation of a solution disturbing the operations and social and economic balance of public and private actors in the emergency service domain;

– interoperability issues among the different systems used, both within Tairétalet and among different regions; and

– the planning and implementation of contributing or connected projects.

This study of existing means allows us to create a risk portfolio that will be maintained and managed throughout the project.

The risk portfolio includes risks of different natures, whether social, economic, financial, program (cost, time, etc.) or technical. These risks cannot be managed in isolation, independently of each other. For example, the choice of the solution offered by PrimoComputing – a proprietary technical solution that presents the advantage of protecting jobs in the region – would reduce interoperability capabilities and have a negative effect on inter-regional politics (detection of vehicles in transit, relationships with Orion, etc.). Excluding this solution, on the other hand, might generate social tensions and the potential relocation of PrimoConsulting’s activities to a region willing to adopt its solution.

On the other hand, the availability of this solution reduces program risks, particularly in terms of the time taken to implement the solution. We are thus led to create innovative solutions in order to overcome dilemmas of this kind.

2.3.6. Emergency situation management scenario: perimeter and architecture

The engineering consulting company recommends the establishment of an emergency situation scenario. This scenario will serve as a reference point in order to structure and specify different components, prepare for the qualification of all of these components after integration and, finally, to organize and structure training of the main actors concerned. It is based on the synthesis of the Dubbus accident report and on the expected capabilities defined by the Tairétalet authorities.

2.3.7. Reference operational scenario

To facilitate the expression of needs and the creation of a specification, a reference operational scenario is created. Based on the Dubbus accident, this scenario expresses, in functional terms, the emergency service procedure for a scenario of the same type, independently of possible solutions. It describes the events and main actions involved in a chronological manner. This scenario allows us to identify technical systems and participants, their coordination and the information exchanges required for this coordination, in order to improve emergency service provision.

The scene of the accident (see Figure 2.2) is, according to the NATO architecture framework, a NOV-1 operational view (NOV-1, High-level Operational Concept Description).

This reference operational scenario provides a structure for preparation of the specification of the different systems that must be used to provide the expected capabilities. It does, however, present an ideal and therefore simplified situation. It does not take account of hazards or unplanned factors that might affect the course of events.

For example, one of the vehicles involved in the accident may not carry accident detection equipment, so an alert will not be sent for this vehicle. In another case, a coach-load of tourists from another region, using a different detection system, may be involved. These potential “hazards” should be formulated in a set of alternative operational scenarios. Thus, the solutions envisaged must take into account both the reference scenario and a number of alternative scenarios. As such, these solutions present margins for maneuver and buffer zones in relation to the reference scenario to enable them to cope with these differences. Moreover, the reference scenario remains silent on a number of activities that must be carried out, or are presumed to have been carried out, which are not part of the core subject: for example, hospital admissions activities, or the collection of information on the clinical history of the patient.

Table 2.3 shows the course of this reference operational scenario, including a set of chronological events or actions, with the time of these events marked in the lefthand column.

Table 2.3. Reference scenario

Time	Action
0725	The accident occurs (not far from Salix).
0726	The accident is detected. The regional call center is informed, including information on: – the location of the accident; – the time of the accident; – identity, including type, of the vehicles involved; – the speed of the vehicles at the moment of impact; – a sound clip from the passenger cabin.
0728	The regional call center creates an accident file.
0730	The regional call center calls the closest emergency service center to the scene of the accident and transmits the accident file.
0732	The regional call center establishes a direct access number.
0733	The emergency service center team makes preparations based on the accident file received, with suitable emergency treatment equipment selected from what the center has available, and moves towards the scene of the accident.
0755	The emergency service team arrives at the scene of the accident. The emergency service team uses emergency treatment methods and equipment.
0758	The emergency service team requests urgent airlifting of a seriously injured patient (reserved vital prognosis).
0759	The regional call center contacts the emergency services in Orion to request dispatch of their helicopter, following the terms of the agreement established between the two regions.
0800	The emergency service team counts and assesses casualties, using the following categories: – serious injury, immediate on-the-spot treatment required; – serious injury, transfer possible by medically-equipped ambulance; – less serious injury, transfer possible by non-equipped ambulance; – minor injury, requiring basic first aid and possible psychological support.
0805	The emergency service personnel inform the regional call center of the number and state of casualties (gravity, trauma, vital signs, etc.) and request reinforcements.
0806	The regional call center calls the emergency service centers in Fraxinus and Quercus to demand intervention and the deployment of a medically-equipped ambulance.
0807	The regional call center makes contact with the region’s hospitals, checks availability and, by agreement with the hospitals, attributes casualties to hospitals based on their injuries and the specialisms and availability of the hospitals.
0808	The regional call center calls multiservice companies in Fraxinus and Quercus to request assistance.
0810	The regional call center creates an update to the accident file, including: – number of casualties; – seriousness of injuries; – traumatisms of casualties; – measured vital signs of casualties; – allocation of casualties to hospitals.
0820	The regional call center communicates this updated accident file to: – the hospitals concerned; – the emergency services at the scene; – the teams at the emergency service centers at Quercus and Fraxinus; – the teams of the multiservice companies involved; – the Orion emergency service center (helicopter evacuation).
0820	The medical helicopter arrives at the scene of the accident and takes charge of the casualty for which it was called.
0820	The hospitals concerned begin preparing equipment to treat the casualties.
0820	The emergency services and the hospitals make contact and set up a direct communications line.
0825	The medical helicopter takes the seriously injured casualty to Quercus hospital, where the helipad is available.
0827	Backup arrives at the scene of the accident.
0837	The emergency services and backup evacuate casualties to the correct hospitals following the information contained in the accident file.
0838	The ambulances make contact with the hospitals towards which they are transporting casualties, with regular communications on the state of the victims (vitals, etc.) and provide information to the medical team preparing to treat the casualties.
0840	The helicopter arrives at Quercus hospital and the casualty is immediately admitted to the operating theater.
0855	Ambulances arrive at Salix hospital and casualties are admitted immediately.
0910	Medically-equipped ambulances arrive at Fraxinus hospital and casualties are admitted immediately.
0915	Medically-equipped ambulances arrive at Quercus hospital and casualties are admitted immediately.
0930	The regional call center receives information from the hospitals and creates a final version of the accident file.

In the reference scenario, the casualty list is as follows:

– two deaths immediately following the accident;

– one seriously injured casualty, hospitalized in Quercus;

– ten seriously injured casualties sent to Quercus (five), Fraxinus (four) and Salix (one);

– ten casualties with minor injuries sent to Salix hospital.

This reference scenario serves as a basis for the engineering studies that follow. The model in Figure 2.3 shows the way in which this reference scenario plays out over time.

In the context of architecture frameworks [RUA 10c], this model is an operational view. It describes the way in which systems would interact in the reference scenario and is an NOV-6, Operational Activity Sequence & Timing Description.

While Figure 2.3 shows (at least partially) the way in which the reference scenario progresses over time, the model in Figure 2.4 shows this same reference scenario in terms of functions and exchanges between functions. This figure is an NOV-5 view, an Operational Activity Model.

These functions are performed by systems that interact with each other and form the main components of the system of systems.

Based on the dependency links between functions, the main functions are allocated to the physical elements that are responsible for them.

Thus:

– the “detect accident” function is carried out by the “accident detection system”;

– the “evaluate the seriousness of the accident” function is carried out by the “regional call center”;

– the “organize emergency services” function is carried out by the “regional call center”;

– the “assign casualties to available hospitals” function is carried out by the “regional call center”;

– the “evacuate casualties” function is carried out by “emergency service teams” and “hospitals”.

We shall now continue our presentation of the modeling of the reference operational scenario using an N² matrix presentation [AUT 07, AUT 08], which shows the pairings between different systems within the system of systems.

According to the NATO architecture framework, this representation (Table 2.4) is an NSV-3 Systems to Systems Matrix. This model clearly highlights exchanges between different actors and the need for coordination. The regional call center plays a major role as it ensures coordination of the activities of the Tairétalet emergency services at the scene of the accident, alongside other emergency service teams and multi-service companies offering backup, including teams from Orion for airlifting of casualties, and the Tairétalet hospitals, to arrange the allocation of casualties to hospitals based on their injuries and hospital availability.

These exchanges are based on information relating to:

– the detection of the accident, including aspects of location, timing and the state of the vehicle;

– the medical situation of casualties;

– the evacuation request, including this information and additional details concerning the availability of emergency services and their resources;

– hospital availability to organize the distribution of casualties to hospitals based on their medical situation.

2.3.8. Alternative operational scenarios

While the reference scenario acts as a structure to highlight the main functions to fulfill and the main systems responsible for these functions, it fails to dimension the system of systems to allow it to operate correctly in all possible situations. These situations may present numerous difficulties, for example in the case of a pile-up of tourist coaches from different regions on a winter’s evening in difficult weather conditions, for example freezing rain [PER 84]. The effects of the hazard, variable workloads and the scale of scenarios are not dealt with in the reference scenario. Must we, then, take account of all possible eventualities? Must all vehicles in Tairétalet have accident detection systems, or will dispensations be accorded for certain older vehicles, for example classic cars? If dispensations are accorded, what clauses will apply to these dispensations? Does the system of systems need to be dimensioned to take account of the largest possible situations? Scaling up the system, for example by acquiring a large fleet of medically equipped ambulances, would have a significant financial impact. Moreover, as the probability of such situations occurring is likely to be low, the level of use of apparatus on this scale would be low, and availability would be reduced in cases of genuine need as the equipment would effectively be mothballed from the moment of acquisition. Alternative operational scenarios help us to create alternative solutions, for example by making use of general-purpose vehicles belonging to the civil protection services or to multi-service companies with the addition, in emergency situations, of specially adapted kits.

Five alternative operational scenarios are defined as follows:

– pile-up involving two coaches, each transporting 60 passengers, of which coach one is from another region;

– collision between a school bus and a truck transporting dangerous goods (phyto-sanitary product with neurotoxic effects);

– pile-up involving several tourist vehicles and trucks, caused by difficult weather conditions (freezing fog) in an isolated sector of Tairétalet;

– multiple accidents, in a situation where telecommunications networks are not operating correctly;

– multiple accidents at a time when hospitals are already overloaded.

These alternative operational scenarios do not claim to be exhaustive, but aim to demonstrate aspects that will help to size and structure the system of systems.

2.3.9. Perimeter and component systems of the system of systems

This system of systems is made up of a number of different and independent systems that interact in a way that is formalized in the reference operational scenario to offer new functionalities and end-to-end services that none of the individual systems when taken in isolation would be able to produce. We are therefore in the presence of a system of systems as defined by [RUA 10a] and [LUZ 08].

What are these systems? In addition to highly automated systems, such as the accident detection system, we encounter other systems involving large numbers of human operators working together, collaborating and coordinating, as in the regional call center, emergency service teams and hospitals.

Table 2.5. Characteristics of the system of systems, following Maier’s criteria

Criterion	Characteristics
Operational independence
	The different systems do not systematically require other systems to operate: – the main operational function of a vehicle is to move its occupants from point A to point B. For this, it has no need to contact a call center, ambulance or hospital; – hospitals care for sick and injured individuals, irrespective of the origins of the disease or accident (e.g. work-related or domestic accidents as well as road accidents); – ambulances transport sick or injured people from point A to point B, for example from home to hospital, from a hospital to another hospital or from a hospital back to the person’s home. The road accident situation is only one possible example of transport of a sick or injured patient.
Managerial independence
	The different systems that make up the system of systems have a number of different stakeholders: – different purchasers/proprietors/constructors including the owner of a car, the car manufacturer, the regional authorities who direct the call center, the local authorities responsible for hospitals and those responsible for the construction of hospital information systems, to cite but a few; – different statuses, public/private, for emergency service centers and multi-service companies, with different economic models, including for profit/not-for-profit; – different budgets (personal/public); – different acquisition approaches (purchase, public-sector purchasing policies) in the context of relationships between different partners (B2B8, B2C9, B2A10).
Emergent behaviors
	The integration of different systems allows us to create sought-after effects: early treatment of road accident victims to reduce levels of mortality from road accidents.
Progressive development
	The development of the capability does not happen all at once, but is incremental – in this case, a three-step process.
Geographic distribution
	Systems are not co-located. They are distributed across the territory of Tairétalet or even further afield as we are also interested in vehicles in transit. Moreover, geo-location makes use of a GPS-type system that is situated in the orbital space of the Earth.

Table 2.5 characterizes this system of systems according to the criteria set out by Maier [MAI 98a, MAI 98b, RUA 10a], criteria that act as a point of reference on the subject.

The system of systems includes a certain number of systems, most of which already exist and require modification. For each function of the system of systems, we can identify the system or systems responsible, the context and the stakeholders involved. Let us begin, however, by looking at the main dimensions of systems that we must take into consideration, dealing with each in a suitable and relevant manner.

2.3.10. System dimensions: lines of development

The reference operational scenario provides a brilliant illustration of the variety and interlacing of different system dimensions and of the fact that they cannot be reduced to the technical, or technological, dimension alone. Too many projects are overly simplistic, as shown in [RUA 10a]. The system of systems includes automated information systems, such as the accident detection system that automatically communicates information on the circumstances of the accident to the regional call center, and human operators, including those working in the regional call center, who collect this information and contact the closest emergency service center. Within the emergency services center, a team makes preparations based on information received from the call center and their available resources. The execution of these actions requires a minimum of organization (who does what), competent operators trained to act as quickly as possible with minimum error, and available resources in working order. These are the dimensions described in the table. This is based on the dimensions of a capability defined by NATO (DOTMLPF¹¹) and adapted to the case of Tairétalet. In this perspective of adaptation, we add the dimensions of laws and regulations, fiscal concerns and standardization to the initial dimensions of doctrine, organization, training, material, personnel, information and facilities, while removing that of leadership.

Table 2.6. Dimensions of the capabilities of the system of systems

Criterion	Characteristics
Personnel	The “personnel” dimension concerns the employment, job description and career path of operators. The growth in the power of the regional call center may lead to the recruitment of staff, who must be able to master computer tools, and a coordinator to coordinate the actions of the emergency services. In these different situations, job descriptions are created with consideration given to likely future activities, the roles and responsibilities associated with each post, and the various tools operators must master and use. This dimension also covers the development of the activities of current operators, their training, the evolution of jobs and career paths, and the way in which the project will be executed in terms of support in changing circumstances. Thus, current operators must be trained to use the reception system for information sent by accident detection equipment either before or during the launch of this system, in order to be ready for the first stage during which operator training must be synchronized with system launch. This dimension is closely linked to the dimensions of organization and training.
Training	This dimension concerns regular operator training in the framework of large-scale simulated situations involving all actors in the emergency service chain. Accident simulation is planned to take place once every trimester, each time in a different sector of Tairétalet, to allow all actors to receive training. This dimension also takes account of different modes of operation that must be harmonized for effective cooperation. This harmonization is achieved through scenario-based training. This dimension is tightly linked to the dimensions of organization and personnel.
Organization	Most of the organizations concerned by the launch of the system of systems for emergency situation management are already in existence. These include the call center, emergency service centers, multi-service companies with ambulances, hospitals and the Tairétalet authorities. The launch of this system will have an impact on these organizations in terms of internal structure and operations and in operations carried out in coordination with other organizations. Thus, within the framework of stage one, “the hospitals of the Tairétalet region should have access to a resource management system (beds available in different services, equipment, etc.) adapted to their specific operations and capable of interaction with the regional call center”. For this to be possible, hospitals must formalize their own operations and create information systems to collect and diffuse this information. This may mean creating a new item on the list of projects underway at the hospital. Hospitals seize this opportunity to exchange information in order to facilitate coordination and management of their own resources on a regular basis, independently of particular situations. Additionally, this dimension concerns the internal culture of each organization [RUA 10a]: professional culture, regional culture and company culture, more or less linked to the public or private status of the organization. This dimension is tightly linked to the dimensions of personnel and training.
Doctrine	Current doctrine consists of treating casualties as early as possible, providing first aid at the scene of the accident before moving them to hospital, using medically-equipped ambulances for the most seriously injured victims. Information on the physiological state of the injured parties is communicated to the hospital for coordination purposes and to render the treatment process more fluid, while reducing the risks of unsuitable treatment. The engineering consulting company recommends conserving this doctrine, with modifications for the specific context of Tairétalet. An alternative doctrine would involve replacing medical ambulances with helicopters, for use with the most serious casualties, and using nonmedical ambulances for all other casualties. This alternative solution does not correspond to the values of the actors in the Tairétalet emergency service chain or to the competences developed by these actors over time, as shown in a number of reports on the operations of the emergency services in Tairétalet. This alternative solution is considered to be counterproductive and is not recommended by the engineering consulting company.
Laws and regulations	These are the means used by the Tairétalet authorities to incite motorists to install accident detection systems in their vehicles, in addition to an awareness campaign carried out in the media. This dimension also concerns the regulations stating which vehicle categories must be equipped with these systems. Contraventions are sanctioned, for example using fines. As, in the long term, all vehicles circulating in Tairétalet, including those in transit must be equipped with accident detection systems, these regulations must be established in collaboration with participants from other regions. Communications must also be carried out in these regions, and signs must be put up at road junctions separating Tairétalet from other regions to inform motorists of the rules and regulations applicable in Tairétalet. The engineering consulting company must identify these different locations and give proposals to the Tairétalet authorities.
Fiscal concerns	The engineering consulting company recommends the creation of fiscal incentives to encourage motorists to install accident detection mechanisms. In the same way, the Sécuroute insurance company provides incentives to subscribers installing systems of this kind by offering a reduction in insurance payments. Following the same lines, the engineering consulting company suggests that the Tairétalet authorities should implement regressive incentive measures. This would help multi-service companies to acquire and install systems for communication with the call center (stage one), which would then evolve in order to communicate information on vital signs between ambulances and hospitals (stage two). A measure applied over a fixed period might encourage companies to invest at the last possible moment, running the risk of failure through excessive haste. To improve chances of success, it is important that companies acquire the necessary resources as early as possible. This is why the engineering consulting company recommends that the advantages linked to incentive measures should be reduced over time.
Material equipment	Accident detection systems and the equipment needed for information exchange between the regional call center, emergency service centers, emergency service teams and hospitals all fall into the category of material and equipment. More often than not, these aspects are part of larger systems. This is the case, for example, with portable telephones used by individuals, or of GPS-type geo-location systems. These systems are not specific to the situation. We also find dedicated equipment adapted for specific missions, such as accident detection systems, or equipment allowing the communication of vital signs between the emergency service team and the hospital taking in the casualties. In these cases, we must specify, design, produce, install and launch this equipment. Various solutions are possible. The accident detection system may use a transmitter-based interface and communicate via GSM networks, or use an ad hoc network that must be acquired and put into place. In addition to the technical differences between these two solutions, the associated economic models are also different.
Facilities	This dimension covers more or less elaborate existing resources that may be used without the need for specification. However, we must clearly specify the interfaces with these facilities. We must also manage the development of these facilities and their quality of service over time. This has an impact on the main system. Examples include the progression from GSM to UMTS12, or the ability to take Galileo13 into account once this system becomes operational. These interfaces must be highlighted in terms of dependences and an ad hoc configuration management group must be established to deal with developments in the systems concerned.
Information	Information plays a crucial role in contributing to the coordination of different actors. However, we should be careful to avoid confusing that which concerns information systems, which may be processed and communicated via automated systems and must therefore be specified, and that which concerns communications between human operators without passing through an automated system. In the latter case, we must specify the communication capabilities of the operators (availability of telephone equipment for distance communications, inter-visibility, background noise, internal communications, etc.) [RUA 10a]. The message indicating that an accident has taken place transmitted from the accident detection system to the regional call center, the accident file created by the call center and communicated to the emergency services, or information concerning hospital availability is processed and communicated using automated systems, and must therefore be specified. Space must be reserved for operators to communicate elements linked to context that cannot be defined a priori.
Standardization	The engineering consulting company is conscious of the financial and other stakes involved and of the strength of demands made on all vehicles passing through the Tairétalet region. It therefore recommends that communication protocols and information exchanged between vehicle accident detection systems and the regional call center should be standardized. An alternative solution would consist of adapting the regional call center to support all protocols and exchange formats, but this would be excessively costly to implement and particularly difficult to maintain and develop. Standardization also concerns exchanges of medical information (vital signs, etc.) between ambulances and hospitals, and information linked to hospital availability.

This line of development allows us to identify, differentiate and characterize the competences that the engineering consulting company must use and the “engineering” documents that must be produced.

The competences involved include, among other things and in addition to the role played by the system architect in maintaining overall coherency, technical, judicial and economic expertise and knowledge relating to human factors and to the humanities and social sciences.

Without attempting to provide an exhaustive list, the documents that the engineering consulting company must produce include:

– a technical specification of need [BNA 00] describing the functionalities of the system and a job description describing the roles of operators;

– the competences needed for successful execution of activities;

– the missions given to operators;

– a procedure describing the way in which operators should work.

We also require a plan for media communications to inform motorists of incoming regulations and invite them to install accident detection systems in their vehicles. These documents may also include recommendations to the Tairétalet authorities on the creation of regulations and fiscal measures inciting motorists to install this equipment.

2.4. Architecture of component systems of the system of systems

Having laid down an outline of the system of systems and the functionalities that it should offer, along with the different dimensions to take into account, we shall now look at each of the systems making up the system of systems.

We shall continue to apply a system-of-systems approach, as we shall not look at component systems in isolation or as separate blocks, but rather at their insertion in the overall system of systems. We shall give particular consideration to those systems with the greatest effects on the structure and dimension of the system of systems in order to highlight the set of dimensions that must be taken into account.

2.4.1. Detecting an accident: the accident detection system

We shall begin by considering the system that provides the accident detection function.

A functional analysis is carried out in cooperation with vehicle manufacturers and creators of accident detection systems along with the regional call center. This functional analysis shows that, for reasons of reliability and operational security, a function for evaluating the operation of the accident detection system is needed in addition to the central accident detection function.

Figure 2.5 describes the functional model of the accident detection system architecture produced by this functional analysis and includes automatic testing. Following the NAF v3 architecture framework, this is a system view (NSV-4, System Functionality Description). The accident detection system:

– captures a set of information from the vehicle (state of the air bags, seat belts, etc.);

– integrates this set of information;

– evaluates the coherency of this information;

– if this information corresponds to an accident (airbags inflated, seatbelt locking mechanism engaged, etc.), the system sends a message to the call center including the following information:

- geographic location of the vehicle, using a GPS captor (essential),

- date and time (essential),

- the identity of the vehicle, including the vehicle type and serial number (essential),

- the last recorded speed before impact (optional),

- the position of the vehicle, for example upside down following rolling (optional),

- the number of people in the vehicle (optional),

- a short sound recording from the cabin (optional).

Automatic testing messages from the detection system are sent to a quality of service center. If faults are communicated, or if messages cease to be received, a synthesis of information on these faults is sent to the vehicle owner. Modeling should be used within each accident detection system solution to link the system-ofsystems level with the system level.

For each accident detection system, functional and physical modeling must be carried out. For these purposes, service-oriented architectures are recommended [KOC 07a].

To illustrate this, Figure 2.6 represents the general architecture of the eCall system [ECA 06], the European accident detection project. In the NAF v3 architecture framework, this is a NOV-2, Operational Node Connectivity Description. The main operational nodes are the accident detection system in vehicles, the emergency call center, emergency service centers and hospitals. Nodes communicate with one another and are connected by communications networks.

In the context of Tairétalet, the deployment of accident detection systems, depending on the stage, involves both new and existing vehicles, vehicles registered in the region and vehicles circulating through the region but registered elsewhere.

These accident detection systems may be installed in new vehicles at the moment of construction or added to existing vehicles. Depending on the age of the vehicle, the equipment available and the accessible interfaces, it may or may not be possible to install accident detection systems in these vehicles. Based on these different cases, we are able to identify those participants who are most concerned and with whom we must act first.

We therefore have a number of possible configurations with different points to take into account.

Table 2.7. Installation of accident detection systems depending on vehicle type

Integration type	New vehicle	Existing vehicle
During construction	Details below	N/A
Later addition	N/A	Details below
Integration impossible	N/A	Details below

Concerning detection systems installed at the time of construction, we note that:

– this type of integration is based on strong links between vehicle manufacturers and the producers of accident detection systems;

– we need to identify the information communicated from the vehicle to the regional call center, the format of this information and the protocol to use;

– we must identify the years of manufacture from which vehicles will be equipped with accident detection systems and, where necessary, differentiate between years and/or models in terms of the information that needs to be communicated;

– the main parties concerned are:

- car manufacturers,

- creators of accident detection systems,

- vehicle fleet owners,

- operators of telecommunications networks, and

- the regional call center.

As a number of car and equipment manufacturers are concerned, we recommend standardizing interfaces between vehicles and accident detection systems rather than developing ad hoc solutions for each vehicle type or model, which would be very costly. Moreover, given that this equipment must also be installed in vehicles from other regions traveling through Tairétalet, we recommend that the standardization organization, bringing together car manufacturers, the creators of accident detection systems, regional call centers, regional authorities and telecommunications network operators, should operate at inter-regional or higher level. This organization should create documents describing the information exchanged between security devices (for example, the state of the equipment), semantics and format, information on dysfunctions including possible failures, communications protocols, connectors, requirements in terms of electronic resources and constraints linked to electromagnetic compatibility.

Vehicle fleet owners want the system to communicate information on the state of the vehicle on a regular basis, in addition to the information sent out in accident situations, and auto-test results. This would allow owners to anticipate maintenance of fleet vehicles and would indirectly increase their level of availability. In addition, the proprietors of fleets of logistics vehicles would like to have regular access to information on the positions of their fleet vehicles. This solution would, from their point of view, be a way for the accident detection system to produce real added value.

The authorities in Tairétalet and Orion encourage this initiative. However, it increases the complexity of the accident detection system; the system was originally mono-functional, but must develop to include new functionalities that were not initially planned for.

This is an illustration of emergent behavior, identified as one of the characteristics of a system of systems. Furthermore, insurance companies would like the system to offer a theft detection function for high-end vehicles, allowing the localization and retrieval of stolen vehicles and the interception of those responsible for the theft.

Finally, as accident detection systems regularly communicate auto-test information, the Tairétalet authorities would like this information to come with details on the geographic position of the vehicle. This would give them a good idea of the number of vehicles on the roads and their positions, used to evaluate the density of road traffic. The Tairétalet authorities aim to gain a picture of the usage of the road infrastructure depending on the time of day and day of the week, both in order to prepare and budget for maintenance and to plan and to budget for developments, for example the construction of new roads to relieve zones where gridlock or regular traffic jams occur.

These exchanges of information and new functionalities must be taken into account by the standardization organization, so that different models of accident detection systems all provide the same information.

We thus encounter the idea of creating a range of products, presenting different levels of functionalities. This is accompanied by evolutions in the economic model. The manufacturers of accident detection systems therefore carry out market research to identify the specific markets for these different systems and the functionalities sought after by different clients [RUA 10d].

We now have different market segments, split between private individuals, requiring basic accident detection functions as demanded by the Tairétalet authorities, and fleet owners, who require additional functions. With the aim of mastering design and production costs, accident detection equipment manufacturers create a modular architecture, with modules providing specific functionalities for each market segment identified.

Thus, for equipment included in vehicles at the time of construction, we find modular system architecture based on market segments, where accident detection is just one of the functions available:

– for private individual motorists: the basic accident detection system (place, date and time, detection of activation of safety equipment, with other optional information such as external temperature, windshield wiper use and the use and occupation of child seats), using the GSM network via emergency numbers, is the only option available;

– for private individual motorists buying luxury vehicles: the enriched accident detection and theft alert (geo-location) function is offered is a complement to the functions described above. This requires the use of a SIM card and subscription to a service, including a subscription to a telecommunications network operator;

– for the owners of vehicle fleets, including logistics vehicles: enriched functions providing information on vehicle state and location are available via a SIM card. This is in addition to basic accident detection functions. It requires subscription to a service, including subscription to a telecommunications network operator;

– finally, for the Tairétalet authorities: the desired function consists of the statistical collection of geo-location information to measure traffic density.

By highlighting the functions offered by the system depending on market segments (Table 2.8), we gain a clearer picture of the modular architecture of the system. This includes a common trunk, with accident detection and traffic measurement functions and all that these functions entail. It also has additional modules including functions adapted to specific market segments [RUA 10d].

This matrix also shows optional functions that may be available for different market segments, which are in some way the “cherry on the cake”, or just “nice to have”.

In the case of detection systems fitted to existing vehicles, we see that:

– This type of integration is based on a set of information made available to the manufacturers of accident detection systems and to mechanics by vehicle manufacturers. Several factors are necessary for this type of integration. First, safety equipment (airbags, seatbelts, etc.) must be present in the vehicle. Second, connectors must be available to link this safety equipment to the accident detection system. Finally, mechanics must have access to the necessary information to install an accident detection system in a vehicle (safety equipment available in the vehicle, physical interface of each device, protocol, message format, etc.) that must be described correctly in documents created by the vehicle manufacturer.

– In cases where the vehicle has no safety equipment, or where there is no documentation or there are no interfaces for these devices, a different type of accident detection system must be installed. This will be independent of the vehicle, with its own captors (brake speed, shock detection) and means of communication. This is a limited configuration; the information communicated to the regional call center is seriously reduced (date, time, detection of accident) and cannot take the state of safety equipment into account. The serial number of the vehicle must be registered with the accident detection system at the time of installation by an approved mechanic. This serial number allows call center operators to obtain more precise information on the vehicle. This also means that the accident detection system must have the means, via an interface accessible to the mechanic, of inserting the vehicle serial number. De facto, this means that accident detection systems that do not give the option of inserting a vehicle serial number will not be approved.

– In all cases, we must identify what information is to be communicated from the vehicle to the regional call center, the format of this information and the protocol to be used.

– The main parties concerned are:

- vehicle manufacturers, who must produce documents for the installation of an accident detection system;

- the manufacturers of accident detection systems, who must take these documents into consideration, and, where necessary, create specific versions of the accident detection system for different models or installation interfaces;

- the mechanics responsible for the installation of accident detection systems in vehicles based on the available installation documents;

- experts who may approve solutions and certify the correct operation of an accident detection system in a given vehicle;

- drivers who have accident detection systems installed in their vehicles;

- telecommunications network operators; and

- the regional call center.

As is often the case with systems of systems, the main difficulty for existing vehicles lies in the fact that safety equipment in these vehicles was not designed with the necessary – or at least not with standardized – interfaces.

Each type of equipment, or even each device, must be dealt with separately, which may prove to be an extremely costly and dissuasive solution. In this case, vehicle manufacturers must communicate a certain amount of information to third parties, in this case the creators of accident detection systems and the mechanics responsible for the installation of these systems. This information concerns safety systems and the information these systems may communicate, the connectivity between different safety systems and the accident detection system (for example, a CAN bus) and vehicle energy sources that may be used by the accident detection system, once again with suitable means of connection. Vehicle manufacturers must provide documentation covering these aspects, or envisage retro-design of security equipment. Finally, given the wide variety of vehicles and security equipment available, accident detection system manufacturers must develop different versions of these systems to adapt to all types of vehicles in circulation.

For vehicles with no safety equipment, an independent detection system must be installed. Besides anchoring points, the only interface needed concerns the power supply to this autonomous accident detection system.

Finally, in cases where it is not possible to add an accident detection system to a vehicle – even an independent system, for example in cars identified as collector’s items – exceptions may be applied. These derogations come with conditions restricting circulation, where classic cars will only be allowed to circulate on public holidays or with regional authorization for particular events, for example the Tour de Tairétalet meeting. This particular case concerns insurance companies as well as motorists and the Tairétalet authorities, as drivers must declare to the insurance company if their vehicle is a classic car. It is also the insurance companies who supply the ad hoc sticker that the drivers of such cars must affix to their windshield.

The integration of a system in a vehicle is merely a first step. Next, messages must be transmitted to the regional call center. Several solutions are possible for this and the economic models linked to these solutions are very different.

One solution, proposed by the PrimoComputing company, consists of creating a fine mesh network of transmitters to collect signals from vehicles. These transmitters would only be used by the accident detection system. This technology has already been used in other regions, and a high-end car manufacturer is currently in negotiations to launch the system in one particularly prestigious sector of Tairétalet where the company has a significant customer base. PrimoComputing is relying heavily on the economic impact of this technology as, if Tairétalet chooses its solution, not only will the company maintain jobs within the region, but it will also create new posts, both directly and indirectly through the use of civil engineering companies involved in the application of the technological solution. The economic model for this solution is based on an annual subscription service offered to motorists. Moreover, PrimoComputing is seeking finance to roll out the solution across a large section of Tairétalet in order to provide a high level of coverage, mainly on major roads; the company does not, however, plan to extend the transmitter network across less densely populated areas of the region. Finally, as PrimoComputing also deals in hospital information systems, the company is able to propose an end-to-end solution for the Tairétalet region.

Another solution is based on the use of GSM networks operated by telecommunications companies in Tairétalet. In this case, each vehicle must carry a SIM card and all motorists would require an account with a telecommunications operator. Communications indicating the occurrence of accidents would be carried out using a text message, including all information emitted by the accident detection system. This economic model is open for negotiation as far as telecommunications network operators are concerned. They offer to make the regional call center number free to use, meaning that no SIM card would be needed as the emergency call function of all GSM telephones would be used, on the condition that additional functions are launched for fleet vehicles and traffic density measurement (these would require subscriptions). Developments to make use of more recent technologies, including EDGEs¹⁴ and UMTS, are already planned and the first feasibility studies have been carried out by telecommunications network operators and those involved in the construction of these networks.

Currently available technologies, standards to apply and the most recent technological developments have been identified. This allows us to create a progressive and flexible architecture, as recommended in the General Recommendation for the Acquisition and Supply of Open Systems [BNA 10]. The technical view from the NAF v3 architecture framework allows us to give consideration to current standards and to those that may become available (NTV-1, Technical Standards Profile and NTV-2, Technical Standards Forecast).

The last crucial point to cover, as far as the accident detection system is concerned, involves the regional emergency call center. The director of the regional call center does not wish for the automated system in charge of receiving messages from accident detection systems to have to deal with several different protocols, message formats and different meanings attached to information. The possibility of creating a new post within the regional call center, dedicated to technical aspects not related to the job description of call center operators, is also excluded. Information received must be integrated into the existing work station used by call center operators, or into a new workstation format if development in this area becomes necessary.

The director of the regional call center must be involved in the work carried out by the standardization organization to ensure end-to-end analysis of the issue. To evaluate the gravity of a situation, regional call center operators make use of a certain amount of information that must be captured by the accident detection system and communicated to the regional call center system. This is particularly applicable to data on the number of people in the vehicle and, where available, the number of children (in child seats).

Table 2.9 provides a synthesis of the functions offered by the system, the associated economic model and the type of vehicle concerned (new/used) for different market segments identified.

This matrix shows how the economic model is constructed. The economic model is based on:

– estimated sales volume (for example, a percentage of all luxury vehicles in Tairétalet for the theft alert function);

– the cost of production;

– the sales price of accident detection mechanisms and their additional functions, and

– recurring revenue from subscription services.

In our case, the end-to-end economic model for maintenance assistance services concerns several different operators, including vehicle manufacturers and telecommunications network operators, rendering the contractual and financial set-up more elaborate. From the consumer perspective, this situation is usually ignored as the consumer deals with a single point of sale for the management of his or her subscription. Finally, the subscription of the Tairétalet authorities to the road traffic density measurement service contributes to balancing out costs [RUA 10d].

The engineering consulting company creates a technical and financial feasibility file for the Tairétalet authorities comparing two alternative solutions. The authorities decide to launch the solution most relevant to their aims, taking account of the global context in economic, social, financial and inter-regional terms. This feasibility dossier stops at the door of the regional call center; as we shall see, the organization of emergency services, in which the regional call center plays a central part, is an entirely separate project.

In this text, we shall only cover the installation of accident detection systems in vehicles belonging to private individuals. The same work should be carried out for fleet vehicles, trucks and public transport vehicles; for simplicity’s sake, these are grouped together as “fleet vehicles”.

Having covered end-to-end technical and financial solutions, we shall now consider the way in which this approach should be applied across the Tairétalet region, and specifically the way in which motorists will be encouraged to install accident detection systems in their vehicles. As motorists tend to take good care of their cars, the vehicles present in Tairétalet are mostly used, heterogeneous and wellmaintained and vehicle turnover is slow. Accident detection systems will not, therefore, become commonplace in the region’s cars through natural renewal with replacement vehicles including this equipment from the moment of construction. We must, therefore, offer incentives for motorists to install these systems in their current vehicles. This will have the effect of slowing the progress of new functionalities offered in new vehicles.

A survey is needed to gain knowledge of the vehicles present in Tairétalet, including models, ages, estimated annual mileage and main uses. We need to know what expenses Tairétalet motorists come up against and what equipment is involved. This first survey will also allow us to gain a picture of motorist behavior in relation to technological innovations, based on categorizations widely used in marketing (innovators, early adopters, the late majority and latecomers) and the associated models, including the sigmoid model [ROG 03].

The classic sigmoid model should be adapted to the context of diffusion of accident detection systems among the Tairétalet population. An ideal, theoretical model must be developed and compared with the results of a survey on the diffusion of accident detection systems.

These elements allow us to prepare a detailed communication plan and to refine the estimation of a budget to devote to fiscal incentive measures. They also assist us in identifying those motorists who are most likely to buy vehicles equipped with accident detection systems or to acquire an accident detection system in their vehicle, giving them a position as leaders in launching the imitation process.

We encounter two types of measures: incentive measures and coercive measures.

Incentive measures may be regulatory or fiscal in nature. The first regulatory measures concern new vehicles including accident detection systems. Next, fiscal measures are implemented to incite the owners of light vehicles already in circulation to add such systems to their vehicles. These incentive measures, including installation bonuses and reductions offered by insurance companies, are reductive.

Incentive measures are then gradually replaced by more coercive measures, with sanctions for motorists who contravene the new regulations (fines). After a period of relative tolerance, these coercive measures will be applied systematically. Regulatory and fiscal measures must be accompanied by effective communication on the subject to raise awareness and incite drivers to install accident detection systems. The communications plan must present different messages created for different target audiences, including Tairétalet motorists, but also vehicle fleet owners, etc. These communications should highlight the relevance and effectiveness of accident detection systems, echoing values commonly held by the people of Tairétalet. This communication is based on the results of the Dubbus report and on the decisions taken by the Tairétalet authorities in response to the issues raised in this report. The communications plan should also involve surveys to evaluate the deployment of accident detection systems. The results of these surveys will be taken into account to modify and adjust regulations and the communications plan where necessary.

Finally, a budget must be established for these measures, both to evaluate the financial impact of regional assistance given to motorists in Tairétalet and to evaluate the cost of communication campaigns. As insurance companies and vehicle fleet owners have a degree of financial involvement in the project, a cost distribution (Table 2.11) must be agreed upon between these various stakeholders.

The solution involving the creation of a mesh across the Tairétalet region with an ad hoc network is considered to be unsatisfactory and is therefore abandoned. This solution did not respond to the interoperability requirements expressed by the Tairétalet authorities, particularly in connection with vehicles traversing the region, whether from Orion or elsewhere. Moreover, the intention of PrimoConsulting to provide high-level coverage on major routes but not to extend this solution into less densely populated areas did not correspond fully to the needs of the Tairétalet authorities. The authorities want coverage to be as extensive as possible, especially for isolated areas where the use of accident detection systems is most important.

Insofar as the new regulations will to apply to all vehicles using the Tairétalet road network (stage three perimeter), these regulations must be created at interregional level, involving the authorities of other regions whose motorists may make use of Tairétalet roads. In addition to the need for collaboration in creating interregional regulations, we must also aim to synchronize the publication of application texts between the different regions involved and the communications programs of these different regions. Finally, at inter-regional level, regulations must be established to cover cases not already taken into consideration, for example coaches from far-distant regions, outside the reach of inter-regional regulations, without accident detection systems. Two solutions are possible: either the coach may be given a permit to circulate without an accident detection system for a limited time, or (and this second solution seems preferable) the coach company may charter a coach that conforms to regulations to allow its passengers to visit Tairétalet. This solution also seems suitable for individuals from neighboring regions who do not have the possibility of installing an accident detection system in their vehicles. Alternatively, these motorists may be able to have an accident detection system installed through a garage near the Tairétalet border. Finally, in terms of communications, tourist information on the Tairétalet region should mention the fact that motorists must have an accident detection system installed in their vehicle.

To accompany the launch of accident detection systems and reach the desired capabilities defined by the Tairétalet authorities, the engineering consulting company recommends the following approach, covering technical, regulatory, fiscal and communications aspects, which essentially constitutes a “road map” for use by the Tairétalet authorities.

This road map (Table 2.12) covers all stages of the process and includes interregional aspects. The road map, describing capability increments and the activities involved in attaining these capabilities, follows the capability view used in architecture frameworks (NCV-3, Capability Phasing).

The engineering consulting company recommends detailed coverage of this “accident detection” function using an integrated team including adequate competences for dealing with these different subjects. Table 2.13 shows a synthesis of these subjects, necessary competences and the products of various activities.

Table 2.13. Synthesis of subjects, competences and the products of activities

Subject	Competences	Products of activities
Regulatory dimension	Legal practitioner	Regional and inter-regional regulations
Fiscal dimension	Tax specialist	Regional and/or inter-regional fiscal concerns
Communications dimension	Marketing consultant	Communication plan Survey protocols Results of surveys on existing vehicles and deployment measurements
Technical dimension	Systems engineer Computer scientist Ergonomist Standardization engineer Telecommunications engineer	Standards concerning the information sent by accident detection systems to the call center (protocol, format, semantics, etc.) Standards relating to the integration of accident detection systems in vehicles Protocols for the installation/integration of an accident detection system in a vehicle

This multi-disciplinary team will produce a set of documents, including minutes of meetings and reports, which are the products of their activities. Thus, the technical standards produced will be based on the technical specifications of different devices (the accident detection system), describing them using a “black box” approach, i.e. without considering the way in which these functions, formats and protocols will be implemented in the system under consideration.

The detailed description of this equipment does not fall within the perimeter of a treatment at system-of-systems level, but is applied at the level of each individual system. We also see that certain services of systems are implemented without these systems being mentioned specifically, as in the case of GPS. This system effectively falls outside the perimeter of the system of systems being engineered by the engineering consulting company, but, in operational terms, the services it provides are needed by various component systems of the system of systems. It must therefore be treated as a system outside of the perimeter of the system of systems under study, but one with which component systems of the system of systems are linked. These systems collect satellite data and process it in a specific manner in order to provide geo-location coordinates.

Without claiming to have covered the “accident detection” function exhaustively, we have highlighted the main points for consideration, with the stakeholders involved, establishing a multi-disciplinary systems engineering team with the aim of accompanying the Tairétalet region in launching accident detection systems in accordance with the three formulated stages.

2.4.2. Evaluating the gravity of an accident, coordinating the emergency services and allocating casualties to hospitals: the regional call center

Once an accident has been detected and the information transmitted to the regional call center, the call center:

– evaluates the seriousness of the situation;

– triggers emergency services and the intervention of security forces;

– coordinates emergency services;

– coordinates the admission of casualties to hospitals in Tairétalet or neighboring regions, depending on the severity of the accident and hospital availability.

The model in Figure 2.7 provides a partial illustration of the different activities carried out by the regional call center. From the perspective of the NAF v3 architecture framework, this is an NOV-5 Operational Activity Model. It concerns planned activities rather than real activities [RUA 10f, SOU 08a]. Modeling using a finite state automaton accentuates the differences between real and planned activities, as real activities account for the learning process affecting operators, the hazards they encounter and to which they adapt and objectives that may appear contradictory.

The activities carried out by the regional call center are complex and cannot be broken down into a linear sequence of tasks. In reality, operators evaluate the gravity of a situation using not just the information communicated by a vehicle, but a wider set of information. Moreover, they carry out a number of activities in parallel in a noisy and stressful atmosphere [PAR 10a].

A systems engineering approach based exclusively on a functional analysis model or a BPM (Business Process Model) of professional processes [RUA 10f, SOU 08a] is not suitable in this case. Most process models – and functional models in particular – are weighed down by the complexity of these activities.

A model of professional processes of this kind runs the risk of leading to design errors [AMA 06, AMA 09, RUA 10a, SOM 10]. Moreover, this modeling does not take account of the appropriation of the technical equipment by its users [FID 06b, MAS 08, MAS 09, RUA 10e, RUA 10f].

Our multi-disciplinary approach brings in ergonomists to analyze activity and sociologists to provide support during the process of change. The engineering consulting company recommends that activity analyses carried out by ergonomists should run alongside a prototyping process. This allows us to affirm needs and to identify information that should be digitized from among all information exchanged, using illustrators to show operational needs [PEL 04].

The analysis of activities allows us to show “who exchanges what with whom”, and thus to differentiate information that should be digitized from other information that should remain in analog. From the moment when actors of varying origins, both in professional and cultural terms (Tairétalet and Orion regions) begin to work together and coordinate actions, they must use the same practices and a shared vocabulary that goes beyond specific trade vocabularies.

Despite the recurrence of activities, each organization adapts processes to their specific context. Thus, the emergency service center in Quercus, which is fairly heavily used but in relatively easy geographic and climatic conditions, does not operate in exactly the same way as those in Salix or Fraxinus, which are used less often but have to deal with more difficult conditions. The harmonization of practices, to facilitate coordination, should not mean the establishment of identical and rigid procedures. These procedures would not give sufficient consideration to specific contexts. The harmonization of practices should instead involve a shared basis upon which each unit may build to carry out activities in consideration of specific factors and promotes collective coordination [RUA 10f].

The analysis of activities shows that if several accident detection messages come from the same place, operators may envisage the possibility of a collision or pile-up involving multiple vehicles. The evaluation of the seriousness of the situation must take account of this and the means implemented should be adjusted accordingly. In the same way, if several accidents are detected in a small area at the same time, operators may suspect the presence of particularly difficult conditions, for example black ice. These inferences are checked against other information sources, such as local or regional weather reports. Finally, information on road traffic is also very useful. In addition to helping operators estimate the gravity of a situation, this information is relevant in evaluating the difficulties the emergency services may encounter at the scene of the accident (particular weather conditions, for example, or the density of road traffic).

In order to facilitate their task, regional call center operators appreciate having access to additional information from the vehicle involved in an accident, including the external temperature of the vehicle at the moment of impact, and information on the state of equipment such as windshield wipers and the de-icing system. This information is not usually available but the need for such details is manifest. Moreover, rather than receiving the serial number of a vehicle, operators would prefer to receive more precise information on the number of authorized passengers for the type of vehicle and the nature of materials transported by a freight vehicle, for example, particularly if these materials may be dangerous.

The evaluation of the gravity of a situation is based on information from:

– the vehicle or vehicles involved (this information contributes to the expression of need for the “accident detection” function, and particularly standards relating to information communicated by accident detection systems);

– characteristics of the vehicle (taken from databases linking vehicle serial numbers to characteristics);

– local or regional weather reports; and

– road traffic bulletins.

Regional call center operators open an accident file in which they collate information concerning the accident. Once the call center operators have carried out a first evaluation of the gravity of the situation, they call the nearest emergency service center, communicating information on the site and seriousness of the accident. They request an evaluation of the availability of the teams based at the center and the availability of specific equipment, such as medical ambulances. In order to do this, they use information contained in the accident file.

Based on the scale and seriousness of the accident, the availability of resources at the first emergency-service center and the location of the accident, operators may request assistance from other emergency service centers in Tairétalet or Orion and from multi-service companies. It then seems advisable to transmit digital information, sent from the vehicle involved in the accident to the regional call center, directly to the emergency service centers. Based on this information, emergency service teams can choose and configure resources for use; for example, the details provided may be used to parameter the navigation systems used in their vehicles. Upon arrival at the scene of the accident, emergency service teams can refine the evaluation of the gravity of the situation; in all cases, the situation is likely to have evolved since the moment the accident detection message was sent. If necessary, emergency service operatives may request new resources suitable for the treatment of casualties, for example by requesting helicopter evacuation. The request is submitted to the regional call center, where operators take responsibility for transmitting it to the relevant emergency service center in Orion. The emergency service teams must supply a certain amount of information to allow the helicopter crew to prepare for the mission, including the location of the accident, ground conditions and the availability of open space near the scene of the accident to allow the helicopter to land.

In parallel to these actions involving emergency service teams, the regional call center informs the security forces – i.e. the police station – nearest to the scene of the accident of the situation. The police must be made aware of the accident and draw up a statement. They may also play a role in facilitating the emergency services, redirecting traffic and sending out media communications to divert road users. Where necessary, they may also escort ambulances from the scene of the accident to the hospital. The security forces also require information from the accident file, including the place and time of the accident and the number and type of vehicles involved.

Moreover, if a vehicle transporting dangerous goods is involved in the accident, the regional call center contacts the Tairétalet authorities to request the implementation of an appropriate crisis alert procedure. They also contact the fire service and civil security. These different organizations are given information on the location, date and time of the accident, the vehicles involved and the dangerous materials being transported, based on available information. The notion of “dangerous material” (second alternative scenario) must mean the same thing for all involved. The names given to hazardous substances, their effects and their levels of toxicity must be described in an identical way in all regions through which the vehicles transporting these goods may circulate. Signage on utility vehicles to transmit this information must also be identical and universally understood. Computerized information describing these substances in terms of names, effects and toxicity must also be standardized so that data may be exchanged between different information systems. This information also requires confirmation; a vehicle apparently carrying hazardous substances may, in fact, be empty and clean, limiting the risks involved. Several alternative solutions are possible. The most relevant of these solutions involves including information on transported goods, with their level of toxicity and the volume of toxic products, in the initial message sent from the accident detection system to the regional call center.

Based on the information supplied by the emergency services on the number of casualties, the severity and nature of their injuries and on the information provided by hospitals concerning availability and their specialisms in emergency care, intensive care, surgery and traumatology, the regional call center creates a plan for dispatching casualties to hospitals. This plan is then sent to the hospitals in question and to the emergency service teams, indicating that the proposal has yet to be validated. Hospitals may correct the proposed plan or make counter-proposals based on the latest up-to-date information or internal constraints, for example an urgent operation not mentioned in the hospital information system. Once the plan has been validated by the hospitals and emergency services, casualties are sent to hospitals and the admissions procedure is carried out. This role of coordination is essential in avoiding distribution problems and transfers between hospitals, such as those seen in the Dubbus dossier. Moreover, these activities must be carried out in a rapid and fluid manner. It is unthinkable, for example, that callers from the regional call center should be forced to pass through the general hospital switchboard when attempting to contact the emergency unit. The use of hospital information systems provides rapid information on bed occupancy levels and availability at the hospital.

Information sharing between the various actors concerned is therefore essential.

In brief, we may identify the following:

– information on the location and circumstances of the accident;

– information on local weather conditions and specific constraints linked to the location of the accident;

– information concerning casualties, including numbers, state, type and severity of injuries and the development of their state, including information on blood groups, vital signs such as saturation, blood pressure, body temperature and specific constraints such as allergies;

– information on needs in terms of medical resources (blood, bandages, etc.) and on equipment to be used (spinal boards, cutting equipment to extract casualties from vehicles, etc.);

– information on specific evacuation requirements (e.g. helicopter use);

– information on availability at each hospital (beds available in the emergency department) and specialisms;

– information on the plan for casualty distribution based on the state of victims and hospital availability;

– information on road traffic density for access to the scene of the accident and to redirect traffic where necessary;

– specific information, for example concerning the transportation of hazardous goods.

However, not all actors use this information in the same way. From the moment at which actors begin communicating with each other, they must have means of communication that are suitable for their activity and the information they need to transmit. This may take the form of a telephone, fax machine or any other medium.

In addition to the analysis of the activities of regional call center operatives, we must also analyze the activities of emergency service operators, multi-service company employees, civil protection centers and the police. These analyses allow us to give due consideration to the distribution of tasks, procedures (written or otherwise), values subjacent to the activity, implicit communications, vocabulary used, modes of emergency management and equipment for tracking, memorization and accounting for situations (paperboards, whiteboards, etc.). Similar analyses to those carried out in emergency service centers and multiservice companies must also be carried out in the Tairétalet hospitals.

In addition to these activity analyses, we find analyses of the various documents describing procedures for use in emergency situations, including plans for specific situations. These procedures are regulatory and clearly set out the respective roles and tasks of the operators concerned.

Finally, this set of analyses should be completed by an in-depth analysis of existing resources and processes. This analysis allows us to catalog the resources of different organizations, and to determine, for each:

– a geographic location in Tairétalet, or in the vicinity of Tairétalet for equipment in Orion, with an address, contact details and zone of activity;

– the number of team members, specific competences (paramedics, doctors, nurses, etc.), their level of knowledge of the Tairétalet region (road network, habitat, urban zones, natural obstacles), their usual levels of availability (on call or otherwise), their alert level, etc.;

– available vehicles (ambulances, medically-equipped ambulances, general usage vehicles that may be adapted, specialized health service vehicles, for example for the transportation of blood or other biological products, helicopters);

– the specific equipment and medical resources available (in addition to bandages, sterilizing products, blood pouches, etc.) and their storage capacities;

– the means of communication they use, for incoming communications (dedicated numbers, e.g. emergency numbers, switchboard numbers, etc.), internal communications (use of cell phones over a secure network), outgoing communications (e.g. requests for assistance) and their use of other messaging systems (email, instant messaging, etc.);

– various other resources (generators, tents, cutting equipment, etc.);

– driver assistance resources (e.g. navigation systems) and, where these are used, which vehicles possess integrated resources;

– computer resources (suitable information system), interfaces and information available for exchange.

Based on the results of analyses of existing resources and activity analyses, we must differentiate between that which depends on the activities of human operators and cannot be computerized and that which is, or may be, automated [ISO 10a, RUA 10f]. After organization by generic processes, taking account of the limitations of the exercise in that it does not cover all possible contexts and hazards, these activities are modeled in terms of prescribed operational activities described using process models and data models. The process model is an operational view (NOV-5, Operational Activity Model). This activity model provides a foundation from which prescribed procedures are described for use by human operators and for the specification of information processing systems that support operator activities. [RUA 10f] sets out the differences between prescribed procedures and automated systems.

Table 2.14. Model of service mapping linked to operational procedures

Activity carried out by:	Human operator	Automaton
	Automaton	Automated system

We must also differentiate between computerized information, i.e. that processed by information processing systems, and analog information communicated between human operators. This includes things such as deictic actions that accompany verbal statements, for example nodding the head. In the case of computerized information, we must differentiate between structured information, for example geo-location information communicated between the accident detection system and the regional call center, and unstructured or “free text” information, for example an electronic message that a regional call center operator may send to an emergency service team. Systems engineering activity consists of identifying computerized information that is or may be structured and modeling this information to specify the information and communications systems used in processing the information.

Returning to the particularly relevant structure of N² matrices, Table 2.15 shows a first analysis of these main exchanges. The N² matrix of exchanges for emergency service coordination shows that the information from the accident file (log) is communicated to a number of actors who contribute to emergency service provision. Moreover, to successfully complete evaluation of the situation and organize emergency service provision in the shortest possible time and best possible conditions, control center operators work with various different information sources. This representation (Table 2.15) is an NSV-3 Systems to Systems Matrix following the NAF v3 framework.

Communications between regional call center operators, insurance companies and automobile manufacturers are based on the landline telephone system and dedicated telephone numbers.

Communications between regional call center operators and the emergency services, security services and hospitals, however, are based on secure communications systems such as Tetra. This solution, standardized by the ETSI (the European Telecommunications Standards Institute), guarantees the reliability of communications between various participants [ETS 08, ETS 09]. In the long run, the new generation of TOIP (Tetra over IP) communications will be used.

This process model only shows information that must be transmitted to regional call center operators. This information is taken from the information systems of partner organizations and processed by the regional call center information system in order to supply operators with a clear representation of the emergency situation. As input data, the “evaluate the seriousness of the situation” process uses the initial message produced by the accident detection system, weather information, information on the road traffic situation and other details concerning the characteristics of the vehicle involved. To do this, the regional call center information system must have access to partners’ information systems.

The identification of the vehicle involved, information that is transmitted in the accident detection message, is processed by seeking information on the proprietor of the vehicle in insurance databases. Information is also sought on the vehicle itself (whether it is a light vehicle, public transport vehicle or an LGV, the number of passenger seats, the age of the vehicle and its security devices, such as airbags and assisted emergency braking, etc.) in manufacturer databases.

If the vehicle concerned is a LGV, information on the total weight and payload (for example for toxic goods) helps regional call center operators to evaluate the situation and inform security forces and the fire service where necessary, providing them with relevant information for the organization of operations. The set of information available for all vehicles involved allows operators to evaluate the seriousness of the accident (estimated number of casualties, potential level of injuries) and the difficulties facing the emergency services (weather conditions, accessibility and any other specific conditions). In the same way, information on the geographic location of the accident and the date and time may be extracted from the message. This information is used to find data on local conditions at the scene of the accident (temperature, humidity, fog risk, black ice, snow, etc.) in meteorological databases. It may also be used to find specific information on the state of traffic (fluidity, congestion, etc.) in the road traffic management system database.

For this to be possible, the regional call center information system must be able to:

– Decode the message sent out by the accident detection system, i.e. break down the original message into segments and, for each segment, identify relevant information and associated values. For the vehicle, this would include the make, model and serial number. Other information requires translation between semantically equivalent forms to render it more easily understandable. For example, GPS coordinates are converted into street information, for example “Oven Street, Salix”; in this particular case, an up-to-date geographic information system is essential.

– Know what information is available from partner databases, its format and meaning. For example, location data may be expressed by a street name or using GPS coordinates.

– Create a request to be sent out by the information system describing the information required, from which is available, in a format acceptable to the partner information system. Request parameters include information required by the partner information system, such as local weather conditions at Oven Street, Salix.

– Send this formulated request to the partner information system.

– Receive a response from the information system.

– Correlate this response with information obtained through other requests, for example information from the insurance company indicating that the policy holder for the vehicle is 24 years old and information from the manufacturer’s information system stating that the vehicle is a five-seat sedan-type passenger vehicle.

– Present information synthesized, correlated by operators to create the accident file (log). Moreover, the information systems of partners of the regional call center must be able to:

– transmit details of the information they have available to other information systems, including details of formats and meanings;

– provide information on the required format for requests;

– receive requests from partner information systems;

– create responses to these requests;

– send responses to the information systems responsible for creating these requests.

This transaction seems simple and involves a linear scenario that presents no difficulties. In this way, it is illustrative but reductive. A traffic-centered emergency situation is intrinsically dynamic in character because of factors such as the developing state of casualties, changing weather conditions or road traffic. For this reason, we must constantly refresh and update information and seek supplementary information from other sources.

If a lorry transporting toxic matter is involved in the accident, we must identify the nature of this cargo then contact regulatory organizations in order to obtain information on necessary precautions and specific modes of operation, for example asking people living within the accident area to stay indoors. The information processes involved and the way in which these systems intertwine are highly dynamic. However, transactions do not always work in this manner; on occasion, information may not be available or a request may not follow the required format.

In addition, various pieces of information must be protected, requiring the use of information system security procedures. The regional call center information system must be authenticated and communications between this system and insurance company information systems, for example, must be protected against intrusion and against third parties trying to access the regional call center information system for criminal purposes [NCO 10, RUA 10c].

Certain information included in insurance company databases should not be communicated. If a request is received asking for this information, an error message must be generated indicating that this information is unavailable.

Information systems must respect national and regional laws, particularly concerning personal rights and the use and retention of personal data. Regional call center operators make use of several different information systems, each with their own methods of identification (including user names and passwords) in order to obtain access to services based on specific permission levels. This means that operators must supply different user names and passwords for each new service requested. From an operational point of view, this situation is far from ideal; access to a range of different services needs to be made possible using a single user name and password for each operator.

The regional call center information system must communicate with all partner systems, i.e. those of several insurance companies and vehicle manufacturers across different markets (LGVs, etc.). As each partner has their own information system, we are faced with a highly heterogeneous range of information systems, each with its own particularities (conceptual data model, accepted request format, database management, operating systems, etc.).

These different partner information systems were not designed for information exchange and the possibility for a third party information system to extract information will not have been considered. As these systems belong to different organizations, they respond to needs expressed by these organizations and are developed using a cost objective design approach within these organizations. Supplementary developments necessitated by the extraction of information for use by the call center information system will therefore not have been pre-planned or budgeted for.

The difficulties encountered in supplying desired information to regional call center operators reside in:

– the emergence of new need, outside the initial operational perimeters of systems (operational independence of systems);

– the heterogeneity of information systems;

– objectives that have neither been planned nor budgeted for and are not part of the aims of the information system owners;

– the capacity of partners in their role as acquirers and of those responsible for the acquisition of different systems to exchange engineering models relating to these systems and to the system of systems, alongside project data (planning etc.);

– the absence of planned acquisition, as each partner is responsible for its own information system and calls on an internal department or external company to supply the system.

These difficulties have an impact on the ability to:

– create a solution responding to the needs of regional call center operators;

– respect the time schedule allowed in attaining objectives;

– keep development costs at a reasonable level for all parties involved;

– manage the entire setup in a coherent manner.

We cannot reasonably envisage manual processing, as this would be too timeconsuming and would prevent the attainment of objectives related to early response to casualties.

We also do not envisage the creation of ad hoc interfaces, adapted to different partner information systems, for the information system of our operational call center.

Technological solutions currently exist that respond well to the constraints of heterogeneity imposed by the applications used in this project. These are serviceoriented architectures that have undergone standardization, facilitating the management of heterogeneity in information systems [RUA 10c].

These service-oriented architectures specify:

– protocols used between information systems; and

– the format of requests, responses and messages, independent of the subjacent technologies of each information system, in the form of a service request.

Furthermore, we must structure and organize the set of information systems involved in mutual service exchanges, as well as carrying out the same actions within each information system, and identify the applications concerned. The map produced in this way allows us to mark out broad operational domains. In terms of architecture, design principles are defined and must be applied. Operational domains must be coherent and present weak interconnections in order to reduce dependencies [BNA 10]. Design patterns are available for use, for example publish and subscribe patterns.

As a first approximation, the research department identifies four main operational domains:

– that of vehicle information, making use of the information systems of insurance companies and vehicle manufactures and, in the case of fleet vehicles, public transport vehicles or LGVs, the information system of the owners of the vehicle involved in the accident;

– that of general information, using the information systems of regional weather centers, traffic management centers and security forces;

– that of emergency services and medical and hospital information, using the information systems of emergency service centers, multiservice companies and hospitals;

– that of geographic information, which allows us to translate GPS data from the information message into geographical data to locate an accident on a map in order to assist the call center operator so the operator may transmit this information to different partners.

The first sketch of the map is inadequate in that it mixes the operational domains of core activities, including information on the vehicles involved, medical and hospital information and those domains linked to support activities, including geographic information. Moreover, the main activity of emergency service management is excluded.

Following the example of the map of professional processes in the healthcare field [OMG 08a], the engineering consulting company proposes a more highly differentiated mapping of these processes and operational domains. This second cartography highlights the fact that services providing general information are used by various, if not all, different activities. The domain of infrastructures, giving access to services, here with just one example – identity management – is used by all activities without exception. The operational domain of emergency service availability appears clearly, put into operation by trigger activities and requests for supplementary assistance. Table 2.16 represents the correspondence between operational activities and services, following NAF v3 (NSOV-3, Services to Operational Activities Mapping).

This perspective of interconnected services is a functional viewpoint, and is independent of the way in which services are provided from a technical point of view.

Certain services are produced and consumed by information systems with limited mobility, for example that of the regional call center or those of insurance companies, the regional meteorological service and hospitals.

Others, however, are produced and/or consumed by information systems with highly or completely nomadic components. This is the case with emergency service teams. The technologies used in these different cases are not the same. Web service technologies [RUA 10c] are suitable for use with service-oriented architectures with no constraints in terms of mobility or real-time performance, whereas DDS¹⁵ technology [OMG 08, PAR 05] is better suited to deal with these limitations.

In a similar way, information from the accident file is communicated to partners including the Tairétalet emergency service centers, multiservice companies, the police force, fire service and, where necessary, emergency service centers in Orion. Once again, partner information systems must be able to exchange services and information.

Throughout all of these exchanges, information must have the same meaning for all information systems, in spite of the variations between these systems. This common meaning is offered by pivot models, which supplement the service approach and deal with the sense and meaning, in technical terms, of information exchanged.

These pivot models neither describe nor prescribe the internal conceptual model of information systems, but instead deal with the conceptual exchange model. Then, for each information system, an adaptor translates information exchanged using the semantics of the pivot model to adapt it to the internal conceptual model of the information system concerned. This solution using pivot models allows us to reduce coupling between different information systems and the modification of each information system for the creation of an ad hoc adaptor. The impact on existing information systems is reduced to a minimum, in this case to the installation of the adaptor.

Suitable pivot models have been developed for different domains and, in most cases, standardized. This is the case for emergency situations, where an initial pivot model has been created, with limited semantics: EDXL (Emergency Data eXchange Language) [CEN 09a].

The OASIS¹⁶ (Open Advanced System for dISaster & emergency management) project, financed by the European Union, has given rise to the creation of a pivot model, TSO (Tactical Situation Object), currently undergoing standardization by the European Committee for Standardization [CEN 09a, CEN 09b].

This allows us to describe the main dimensions involved in managing an emergency situation such as an earthquake, industrial catastrophe or natural disaster, i.e. [OAS 08b]:

– the context of the emergency situation;

– the events that occur;

– available or implemented resources;

– the mission, both in terms of planning and activities.

These four subjects provide a tree diagram-type structure for the pivot model, and each unit of meaning is attached to one of these four themes.

Giving consideration to the way in which the situation develops, OASIS [CEN 09b] allows us to:

– locate the accident and communicate this information to the emergency services (/GEN/LOCAT, for location): event category information;

– characterize the number, age and gender of casualties and communicate this information to the relevant actors (/PPL/ADU for an adult, PPL/CHD/BAB for a baby, PPL/GND/FML for female): event category information;

– organize emergency assistance (/SAV/RTA, for road traffic accidents): mission category information;

– evaluate the level of the emergency (/CASUALTIES, for casualties): event category information;

– manage the resources to be used (/HUM/CAPAB/AMB for an ambulance, /HUM/CAPAB/MED for medical support, /HUM/CAPAB/ MED/NURSE for a nurse, /HUM/CAPAB/MED/ANSPHY for an anesthetist): resource category information;

– coordinate and monitor emergency services and describe the current situation (/CASUALTIES/CONTEXT for the current state of the emergency situation): event category information.

The richness of the OASIS pivot model [CEN 09b] allows us to express a large number of situations, in terms of:

– weather (/ICY/FRAIN for icy rain, /WIN/STORM for a storm): event category information;

– road infrastructures (/UDGN/TUN for a tunnel, /ROAD/IRD for a one-way street): event category information;

– characteristics of the vehicles involved in the accident (/VEH/CAR for a car, /VEH/TRK for a truck): event category information;

– payload (/VEH/TRK/HZD for a truck transporting hazardous substances): event category information;

– information access rights (/SECLASS for security class), context category information, used, without implementation, in processing identity management.

This pivot model is based on XML technology and is compatible with both the EDXL pivot model and NATO’s LC2IEDM¹⁷ model [OAS 08a]. It is also based on service-oriented architectures and their implementation in web services. In this way, OASIS implements service-oriented architecture patterns for the publication of and subscription to these services. Finally, using IP (Internet Protocol) technology, OASIS can connect business networks and nomadic equipment (for example GSM, Tetra and TetraPOL).

Finally, OASIS is suited for use with structures over three levels (Table 2.17): strategic, operative and tactical [CEN 09a]. The regional call center plays the role of coordination and regulation between different actors, and so is located at operative level. It is accountable for its activities and the results of emergency situations to the Tairétalet authorities, who are situated at the strategic level and launch exceptional plans where necessary, for example in cases of transportation of hazardous materials necessitating evacuation of the population. The emergency service teams who operate at the scene of the accident are found at tactical level.

The engineering consulting company recommends the use of this pivot model for exchanges between the call center, emergency services in Tairétalet and Orion, police and hospitals. It allows the expression of a large amount of information between different actors and is not dependent on a particular language.

Besides its use in road accident situations, the OASIS pivot model also allows actors to communicate in a wide range of emergency scenarios, including fires, industrial accidents and natural disasters, without the need to develop additional elements.

Table 2.17. Hierarchical levels as applied to the case study

Hierarchical level	Application to case study
Strategic level	Tairétalet and Orion authorities
Operative level	Regional call center, hospitals
Tactical level	Emergency service teams deployed

It does not, however, allow us to carry out in-depth characterization of the vehicle (presence and state of safety equipment, such as airbags). We must therefore envisage adding vehicle information to the OASIS pivot model or developing an ad hoc pivot model to allow exchanges of information between insurance companies, vehicle manufacturers and the regional call center.

The OASIS pivot model does not offer significant capabilities for describing the state of casualties. It uses general, but insufficient, keywords (/PPL/VLN/INJ for injured, /PPL/DED for deceased and /PPL/EVC for evacuated).

A possible addition to OASIS, the HL7 (Health Level Seven) pivot model [RUA 10b] for use in emergency situations, deals with the exchange of medical data. HL7 is an international ISO standard, reference ISO/HL7 21731:2006, under the title “Health informatics - HL7 version 3 - reference information model - release 1”.

HL7 covers, among other things, the following themes:

– patient administration: admission, discharge, transfer, demographic elements;

v service order entries: clinical service, observation, medication, nutrition and supplier orders;

– requests: rules for the formulation of requests and responses to requests;

– management of data retention and medical information;

– patient care requests;

– patient care: problem-oriented data.

Version 3 defines a set of formatted messages and includes a Reference Information Model, a model of medical domain data, in XML format, and a reference architecture for medical documents, CDA (Clinical Document Architecture). Like OASIS, HL7 is based on XML.

Within HL7, the care continuity document contains information that concerns the medical domain more specifically, including the vital signs of patients (blood pressure, pulse, oxygen saturation, etc.) and is suited to exchanges between emergency services, the regional call center’s emergency doctor and hospitals. This medical information helps the emergency doctor to direct casualties towards hospitals with facilities suited to their specific state.

SNOMED (Systematized Nomenclature of Medicine) is a complement to HL7 that covers vital signs and may also be used for communications concerning medical treatments to be carried out, with information on specific injuries and the parts of the body affected. SNOMED is a hierarchical classification system that covers most medical information, including illnesses, semiology, protocols and pharmacological elements. It allows indexing, storage, sorting and organization of the contents of medical files. These hierarchies include [RUA 10b]:

– clinical findings, which cover the location of the disorder, a relationship with the agent generating the disorder and its severity, etc.;

– procedure, which sets out the way to treat a disorder, differentiating between intrusive and non-intrusive procedures, for example biopsies or excisions, but also the equipment that needs to be used, etc.;

– specimen, which characterizes the specimen taken (urine, blood, etc.) and its morphology (cyst, abscess, etc.);

– body structure sets out the structure of the body concerned (thyroid, stomach, etc.) and positions in terms of laterality (left, right, right and left, unilateral, etc.);

– pharmaceutical/biologic product characterizes the active product, posology etc.;

– situation with explicit context indicates that a medical file is associated with the context in which the file is created;

– event specifies the temporal dimension of clinical characteristics (occurrence, sequentiality, etc.);

– physical force characterizes aspects that may have a role in or be a cause of an injury, for example the impact of a seatbelt, or “seatbelt syndrome”;

– physical object characterizes manmade objects, such as rubber gloves, an artificial kidney or an implant;

– observable entity is used to describe things that may be observed without being a sign or symptom, for example gender or age;

– environments/geographical locations are used to specify geographical locations, such as a country or region, and places, such as an intensive care unit;

– social context allows us to take account of social situations with effects on health, such as family status, work and lifestyle;

– organism characterizes a living organism, for example a virus, bacterium or parasite;

– substance is used to characterize elements such as allergens, foodstuffs, toxins or dental ceramics;

– staging and scales are used to describe phenomena, such as the Glasgow coma scale;

– linkage concept allows us to define relationships and associations, such as explanatory links;

– qualifier value is used to characterize an element or phenomenon (strong, soft, bitter, etc.);

– a record artifact is used to take elements such as an ECG, EEG, etc., into account.

Thus, the SNOMED model allows us to give an account of the state of the casualty, for example feverish (F-03003), and the administration of a treatment, for example an aspirin, by the emergency service team (C-C137A).

Besides organizing emergency services, the emergency call center must also direct casualties to different hospitals in Tairétalet or Orion, based partly on the state of the casualties and partly on hospital availability. To do this, call center operators must be aware of the specialisms of hospitals, the number of beds available and the availability of equipment, both at surgical and departmental (radiology, imaging, etc.) levels.

The répertoire opérationnel des ressources (ROR, operational resource directory) offers the desired functionalities. It allows us to optimize the direction of casualties towards the most suitable hospital structures following several criteria, including the distance between the scene of the accident and the hospital, and the type of care unit appropriate to the state of casualties [ARH 09a, HEN 08, MAR 07].

In France, decrees 576 and 577 of May 22, 2006 concerning emergency medicine stipulate that the ROR is compulsory. The engineering consulting company suggests that the same approach, based on regulations, should be applied to use of the operational resource directory and the standards describing, in technical terms, how this regulation should be implemented.

For each hospital structure, the ROR presents:

– the address;

– specialisms (resuscitation, intensive care, surgery, general medicine, anatomopathology, obstetrics, etc.);

– available technical functionalities (operating block, imagery, etc.);

– means of accessing resources (direct access, access via the emergency unit, etc.);

– resource availability times (including weekends);

– practical details concerning the presence of medical staff (duty doctors, on call doctors);

– hospitalization capacities (number of beds authorized, number of beds occupied, number of beds available);

– the service directory;

– other information (planned service closures, equipment failures, etc.).

Table 2.19. HL7 and SNOMED pivot models applied to operational processes

Operational process	Hospital admission	State of casualties, medical data
Evaluate gravity of situation		HL7 and SNOMED
Coordinate emergency services		HL7 and SNOMED
Request additional resources		HL7 and SNOMED
Coordinate casualty admissions	HL7	HL7 and SNOMED

Table 2.18 shows that the OASIS TSO pivot model and the ROR are suited to the management of emergency situations as they can be applied to a range of operational activities carried out by different actors and particularly by the regional call center. In addition to these models, HL7 and SNOMED are applied to operational processes for hospital admissions and the treatment of medical information, as shown in Table 2.19.

Table 2.20. Technical standards for application

Domain	Standard and reference point to apply
Telecommunications	Tetra, then TOIP (Tetra Over IP)
Information systems concerning vehicles (insurance companies, vehicle manufacturers, owners)	To be determined
Road traffic information system	OASIS/TSO
Meteorological information system	OASIS/TSO
Geographic information system	OASIS/TSO
Information system presenting emergency service availability	ROR
Information system presenting hospital availability	ROR
Medical information system	HL7
Medical information system	SNOMED

The technical standards view (Table 2.20) of NAF v3 (NTV-1, Technical Standards Profile) allows us to take account of the different standards to apply in designing or updating technical components.

For the medical information system, the separation of the HL7 and SNOMED standards into two different lines allows more flexible management of these standards, including the management of different versions.

The N² matrix (Table 2.21) provides a synthetic overview of formats suited to each exchange between actors involved in the organization of emergency services.

Services and pivot models are key elements in the interoperability standard (catalog of services). They will be included in all technical specifications [BNA 00], whether for the acquisition of new systems or for updating and developing existing systems.

These technical specifications must also cover quality of service (QoS). In this service-oriented architecture approach, we need to envisage all cases that may lead to deterioration in QoS. For example, an insurance company’s information system may be down for maintenance during the night or over the course of a weekend and thus be unable to respond to a request from the regional call center information system. This possibility must be planned for and a message indicating the temporary unavailability must be formulated to respond to the request. This message should be standardized in order to be readable by the regional call center information system and to be presented to the call center operators.

In this case, the call center operators implement a manual procedure and telephone the insurance company in question to obtain the required information. In these situations, on-call operators must be present in partner organizations. Other possible situations include instances of request rejection due to formulation errors.

Moreover, partner information systems are susceptible to evolution, with partial modification of their structure having a possible impact on interfaces. For example, a weather center may develop its system to offer new services in the form of storm and icy rain alert levels, modifying the units used to measure atmospheric pressure from millimeters of mercury to hecto-Pascals.

Moreover, partner information systems are susceptible to evolution, with partial modification of their structure having a possible impact on interfaces. For example, a weather center may develop its system to offer new services in the form of storm and icy rain alert levels, modifying the units used to measure atmospheric pressure from millimeters of mercury to hecto-Pascals.

Partners who modify their information systems, in this case the weather center, must inform other partners and the directors of the regional call center of these developments so that impact analyses may be carried out.

While the modification of units of measurement has a marginal effect (limited to the adapter that translates pressure into the format specified by the pivot model), the new services have more considerable effects on the consumer systems.

These developments of new services have an impact on interoperability standards and on the other systems that use these services.

In this particular case, the team in charge of developments in the weather center information system informs those responsible for interoperability standards and the team responsible for development of the regional call center information system of these developments. To do this, they send a set of documents and models, including the directory of new services offered by the weather center information system and the schedule for application of the new version including these services. This leads to an exchange of documents and engineering models including plans and designs and the different models described in our case study between partners. This implies that these documents and models must be understandable by all partners concerned, in this case the two development teams and the person responsible for interoperability standards.

This also means that the systems engineering tools of different partners must be able to exchange engineering models, i.e. they must be interoperable or include file import and export functions in accordance with standardized exchange formats so that engineering models respect system architecture description standards [ISO 10c].

This point is crucial, as if partner organizations are unable to communicate information it becomes impossible to carry out successful analysis of the impact of developments. No substantial development can take place without having more or less significant effects in terms of the interface with neighboring systems and the effect on interoperability standards.

The NATO architecture framework, like other architecture frameworks, was designed with the perspective of multi-partner information exchanges in mind.

Standardized modeling languages such as UML (Universal Modeling Language) [RUA 10c] and their declensions, such as SysML or UPDM [RUA 10c], should be preferred to specific notations that are not standardized and present numerous variants. The ISO 10303 standard [RUA 10c] offers a pivot model for the establishment of communications between engineering tools, principally those involved in computer-aided design.

This communication between partners concerning the development of one of their systems must occur as early as possible so that, if there are noticeable effects on other systems, those responsible for interoperability standards, other partners and the directors of the regional call center may plan developments for standards and in their own information systems. Technical specifications must be accompanied by management specifications setting out methods for configuration management, problem solving and managing development. The aim is not to communicate everything, but just to provide necessary and sufficient information to enable partners to account for developments in their own projects. The system operates through participation in regular, quarterly or biannual meetings, during which each partner discusses difficulties they may have encountered and planned solutions. Besides these regular meetings, we should envisage the establishment of a permanent structure to deal with difficulties on a daily basis and with updates to interoperability standards – a sort of “one stop shop”.

Moreover, links between the regional call center information system and those of various partners (the regional weather center, regional road traffic information center, insurance companies, vehicle manufacturers, etc.) must be formalized in service agreements and service levels. We shall discuss these concepts later.

The first stage of the study, carried out up to this point, shows that the operators of the Tairétalet regional call center are able to access necessary information for the organization of emergency service provision, taking account of all contextual elements limiting this activity. A second stage of the study consists of quantifying resources for successful emergency service provision.

This process may be expressed through a series of questions: what resources are needed for emergency service organization? What is the availability of these resources? How are these resources distributed across the Tairétalet territory?

The evaluation of requirements in terms of resources to reach assigned objectives is based on a prospective analysis that takes account of the current resources of different partners, their estimated usage and availability, and of the distribution of these resources across the Tairétalet region.

This evaluation makes use of simulations [CAN 11, KAM 10]. In these simulations, different scenarios are played out for several accident situations, ranging from minor accidents, requiring few resources, to major accidents requiring large quantities of resources. In particular, in addition to the reference operational scenario, five alternative operational scenarios are used to quantify need as a whole.

These simulations should highlight immediately available resources that are necessary for the regular management of emergency services. They should also include thresholds – points from which immediately available resources become insufficient – over time scales of 3, 5 and 10 years (note that the level of confidence accorded to these predictions is reduced as the time period increases). In some of these cases, the resources of the Tairétalet emergency service teams are already in use when a major accident occurs and the emergency service teams cannot provide a satisfactory response in relation to the scale of the accident. If these thresholds are reached, additional resources are brought into play, whether from within Tairétalet, for example from another emergency service center, or from the Orion region. These simulations also show what resources the Tairétalet region needs to acquire and position within its territory, and those it must use to respond to exceptional circumstances within the framework of a service contract.

Simulations must be based on statistical information describing trends and recent developments in accident situations (numbers of accidents in a given time period, zones of Tairétalet where these accidents occur, number and type of vehicles involved, number of casualties, severity of injuries, etc.). These simulations should be consolidated and added to using expert opinions, which put them into perspective with regard to statistical input and evaluate their relevance. These simulations only provide probabilities of occurrence and probable tendencies for the estimation and quantification of resources that need to be acquired.

These simulations must give consideration to other means of soliciting the regional call center, besides the system of systems currently being specified (for example telephone calls), especially when looking at questions of workload. These methods will remain in use in addition to the system of systems for all situations not involving motor vehicles, for example if a cyclist is involved in an accident or if a pedestrian suddenly becomes unwell. The overall workload, both of the regional call center and of emergency service and multi-service company teams, is the sum of these telephone calls and automatic calls.

We must also envisage “breakage” scenarios, for example an economic crisis or political changes in Tairétalet leading to changes in direction or a reduction in levels of cooperation with Orion region. No matter how much rigor and professionalism we put into these studies, their results will always be something of a gamble, like Pascal’s wager.

Depending on global workload, these simulations allow us to estimate:

– the number and profile of regional call center operators in different circumstances: minimum workload, normal use, crisis period;

– the resources required (number of workstations, telephones, number of lines in the internal telephone system, etc.) by the regional call center in different circumstances: minimum workload, normal use, crisis period;

– the number of medically equipped ambulances available immediately, taking account of their activities and regular moments of unavailability, the number of team members for each ambulance (medics, doctors, nurses) and the distribution of these ambulances among emergency service centers in the region;

– the number of medically equipped ambulances and team members available with 1.5 hours’ notice, and their distribution among emergency service centers in the region;

– the number of non-equipped ambulances and team members available immediately from emergency service centers and multi-service companies, taking account of their activities and regular down time, and their location within the Tairétalet region;

– the number of medically equipped ambulances and helicopters available from emergency service centers in Orion with 1.5 hours’ notice;

– the number of healthcare vehicles with appropriate kits available with 1.0 hour’s notice;

– trigger thresholds for the involvement of:

- the emergency service team (from a center or a multi-service company) closest to the scene of the accident,

- the closest emergency service team with a medically equipped ambulance,

- multiple emergency service teams (centers and multi-service companies) with medically equipped ambulances,

- the whole of the Tairétalet emergency services (centers and multi-service companies) with all available resources, including medically equipped ambulances,

- ambulances and the helicopter from Orion in addition to the Tairétalet emergency services (centers and multi-service companies);

– the number of beds that should be immediately available in Tairétalet hospitals;

– the number of beds available in Tairétalet hospitals with 2.0 hours’ notice;

– the number of beds available in hospitals in Orion with 2.0 hours’ notice in situations of serious crisis.

These estimations allow the Tairétalet authorities to:

– acquire necessary resources for the regional call center and the emergency service centers in Quercus, Fraxinus and Salix;

– organize the organic growth of the regional call center and emergency service centers in Tairétalet;

– create service agreements between multi-service companies and the Tairétalet authorities and between the Tairétalet authorities and emergency service centers in Orion;

– estimate expected performance, formulated as service level agreements, in these service agreements;

– create an inter-regional partnership contract involving the authorities of

Tairétalet and Orion governing the use of the latter’s emergency service resources, including the helicopter and the region’s hospitals. The Tairétalet authorities acquire the necessary resources, creating calls to tender for the acquisition of made-to-measure systems and buying off-the-shelf solutions for systems where possible. In developing their acquisition strategy and responding to interoperability requirements, the Tairétalet authorities make use of guides and recommendations, including those published by the BNAE¹⁸ [BNA 10]. Interoperability requirements are formulated in an interoperability standard that forms part of the “interface demands” section of the technical need specification [BNA 00].

The Tairétalet authorities and multi-service companies then establish service agreements [SEI 09]. Service agreements are also created between the Tairétalet authorities and the region’s emergency service centers to assist in the management of the latter and help reach assigned capability objectives.

In this context, the notion of service has a different meaning to that encountered in service-oriented architectures. Instead, we are dealing with a service economy, with the following fundamental characteristics:

– the immaterial nature of the service, which is not a product or goods that may be stored;

– the simultaneous production and consumption of the service, demanding specific engineering practices that break away from the linear aspect of product engineering (design, creation, production, evaluation, use);

– the participation of the client, whether the user or the Tairétalet authorities.

Initially created to formulate best practice for facility management in the software domain, the CMMI® for Services standard [SEI 09] is used in this case to formulate performance requirements in terms of service levels and to adapt the standard to this context. This standard is used by the Tairétalet authorities to manage the services provided by different partners, adapt and develop them based on accidents that occur and the statistical tendencies that emerge. Thus, if road traffic increases and the number of accidents increase significantly, the Tairétalet authorities have the means to adapt global capabilities to take account of these developments and maintain the expected levels of performance.

These service agreements mention:

– Service level agreements, which give details of:

- the respective responsibilities of multi-service companies or emergency service centers and the Tairétalet authorities, as well as those of Orion,

- service availability (24/24, 7/7),

- moments of unavailability and exceptions, for example annual holidays during which certain small multi-service companies are closed,

- an estimation of the number of service requests per year, taking account of periods during which accidents occur more frequently,

- the time taken to respond to service requests,

- management of unplanned unavailability (e.g. team member illness),

- time taken to arrive at the scene of an accident,

- methods used to call up extra resources in severe crisis situations,

- the consequences of a refusal of service,

- the methods used to create an incident report if services are not implemented correctly;

– Service requests, which give details, in the form of an accident file, including:

- a unique reference number used by the call center and the partner in exchanges relating to this accident (essential),

- the place, date and time of the accident (essential),

- the serial number of vehicles involved (essential) or their type (where available),

- the number of casualties (where available),

- an estimation of the severity of injuries (where available), Management of Emergency Situations 167

- weather conditions (where available),

- all other useful information available to and communicable by the call center;

– service requests communicated via:

- telephone communications, with or without accompanying electronic

messages containing information from the accident file,

- means of closing service requests;

– Quality of service expected, in terms (synthesizing “measurements and analysis of activity”) of:

- response time following a service request (essential),

- response time for arrival at the scene of an accident (essential),

- adequacy of the resources implemented to deal with an accident (essential),

- level of relevance of the evaluation of the gravity of a situation (essential),

- level of relevance of a call for additional resources (essential),

- all other relevant information;

– Capacity and availability management, covering:

- the means and frequency of communications by partners concerning their available and unavailable capabilities to the regional call center, for example notification that an ambulance is out of action and undergoing repairs,

- the means used by multi-service companies to communicate with the regional call center and the Tairétalet authorities concerning the acquisition or sale of resources, characterizing these resources in terms of relevant operational capacities for the call center, for example the acquisition of a new ambulance,

- the means and frequency of communications sent to the regional call center and the Tairétalet authorities concerning the results of inventories of available resources,

- the means and frequency (at least annual) of communications from the regional call center and the Tairétalet authorities to multi-service companies and emergency service centers concerning trends in terms of accidents (number of accidents, types of vehicles involved, severity, etc.) and probable future needs. Future needs are estimated on the basis of these trends, to allow adaptation of capabilities and availabilities, and to budget, where necessary, for acquisitions or transfers of personnel;

– Measurement and analysis in terms of:

- number of accident detection messages received by the regional call center, with times and locations, to evaluate periods and zones with high accident rates (essential),

- number of service requests (with times) sent to emergency service centers and multi-service companies by the regional call center (essential),

- number of service requests (with times) received and responded to by emergency service centers and multi-service companies (essential),

- number of service requests (with times) received to which services were unable to respond (essential),

- response time for a service request (essential),

- response time to arrive at the scene of an accident (essential),

- resources involved in responding to an accident (number of vehicles, personnel, etc.) (essential),

- number and type of vehicles involved in the accident (essential),

- number and state of casualties and number of fatalities at the time of arrival of the emergency services (essential),

- number of requests for additional resources (essential),

- number and type of additional resources requested (medical ambulance, planned means of resuscitation, etc.) (important),

- time needed to evacuate casualties (essential),

- number of casualties and deaths between the moment of emergency service arrival and hospital admissions (essential),

- number of false alarms (accident detection messages received in error without an accident having occurred) (essential),

- synthesis of the gravity of the accident and the state and development of casualties,

- additional information concerning factors affecting activities (weather conditions, road traffic, etc.) (important),

- number of accidents noted where the detection system did not work (essential);

– Strategic service management: updates to the service contract – either annual or at the demand of partners – to account for the development of needs, available resources and other factors or hazards encountered.

The service view defined in NAF v3 seems more appropriate to service-oriented architectures (the context in which we have used the view) than for service management, as it does not give consideration to notions of service agreements or responsibilities, or to the measurement and analysis of activities.

The results of measurement and analysis are fed into dashboards that allow the Tairétalet authorities to manage the system of systems in its entirety. This takes the form of a monthly report created by the regional call center, a biannual report for the Tairétalet authorities and an annual report for all partners involved. These summaries show trends in terms of the number of accidents and their treatment and demonstrate the weaknesses of the system of systems, allowing corrective actions to be taken and decision to be made for the development of the system of systems in response to the observed evolutions.

This service management approach should be adapted and added to in order to account for the specific circumstances of Tairétalet. Thus, how might we create service agreements between the Tairétalet authorities and multi-service companies? The engineering consulting company recommends avoiding a pay-per-action arrangement. This is because there is an associated undesirable risk that unscrupulous companies might attempt to increase the number of accidents in their zone of influence in order to increase activity. Alternative methods, avoiding the possibility of such unpleasant side-effects, will be studied in collaboration with legal experts in order to find a suitable and durable solution. The fact that emergency service centers, multi-service companies and hospitals in the Orion region may be called upon to intervene means that service agreements should be adapted to the laws and tax regulations of each region [VER 10].

Finally, the results of forecast analyses show organic growth of the regional call center to deal with an increase in the number of accidents in the region. Moreover, use of the information system, the functionalities it offers and developments in the organization of emergency services will have an effect on the activities of the regional call center operators and their working patterns. While these operators may not have been recruited or trained to carry out these new activities, they have indepth knowledge of the actors who contribute to emergency services in the Tairétalet and Orion regions and the geographic and demographic specificities of Tairétalet. They also know how to create optimal solutions in response to the random factors present in each situation. Their competences are therefore valuable in dealing with emergency situations.

We must prepare for and organize these developments in order for operators to be fully operational at the moment of launch of the information system and the new system of organization.

What, then, are the main ways in which the “operator” profession may evolve? These developments are mostly linked to the computerization of workstations, implementing the services and information exchanges described above. Moreover, new functionalities are available, for example the display of contextual information linked to an incoming telephone call, in order to assist operators in dealing with the call in the best possible conditions. This may result in the creation of a folder of written procedures, which would also include telephone numbers for contacts and fax templates for use at times when the computer system is out of operation.

New posts are created, including a post for a doctor to act as a medical regulator, to respond to regulatory demands, and bring important modifications to the way in which operators relate to each other and their supervisor. The knowledge of hospital practices and structures brought by this doctor may create difficulties for operators who, up to that point, were the only individuals with this expertise within the regional call center.

Working procedures will be modified and new procedures, suited to the new computerized workstations, will be created. These procedures must conform to the doctrine defined by the Tairétalet authorities, among other things in providing precise definitions of the thresholds at which emergency plans will be implemented. The implementation of these plans is carried out under the direction of the regional authorities, and a large number of actors from the public and private spheres contribute to their execution. Moreover, resources from other regions, including Orion, may be requested. In order for inter-regional coordination to be effective and optimal, principles, doctrines and procedures must be shared between different regions, or at the very least must be compatible. This has an effect on the procedures that operators must implement within the Tairétalet region. Furthermore, operators from different regional call centers must be trained to work together in the context of shared exercises. This all contributes to a radical modification of their activities. These developments result in changes to the job descriptions of operators and a requalification of the post, with alterations to job contracts taking the form of an endorsement.

The adoption of new ways of working by operators must be valorized and rewarded in order to promote their diffusion and appropriation. This valorization and rewards procedure may take a financial and/or symbolic form. The recommendation is that the adoption of these new practices should form part of operator objectives in an objective-based management approach. In order to avoid the possible negative effects of objective-based management, individual and collective objectives should be weighted, care should be taken to avoid competing or contradictory objectives and these objectives should be validated with operator support.

In order for operators to appropriate these new practices, they must be involved in the whole process: in creating new procedures and designing the information system. The engineering consulting company recommends the implementation of a design approach centered on the human operator [ISO 09a], with the creation of prototypes for evaluation by operators.

From this perspective, the integration of partner information systems allows us to present regional call center operators with a set of contextual information correlated to the incoming accident detection message. This set of information must be, in spirit, coherent with the layout of information in operator workstations, but without being a carbon copy of this layout. Instead, we should exploit the capacities offered by information technology and innovative man–machine interfaces to design a userfriendly interface suited to the probable future activities of operators. The proposed approach is based on the principles of human operator-centered design [ISO 09a]. The engineering consulting company recommends several iterative cycles of design and evaluation involving operators. As these systems do not yet exist, the use of simulations and simulators is suggested [PEL 04].

This approach, carried out early on, should be accompanied by an analysis of the process of appropriation of the system by operators and the new usages that emerge and must be taken into account in system updates [FID 06b, MAS 08, MAS 09, RUA 10e, RUA 10f]. The engineering consulting company recommends regular evaluation of the appropriation of the system by operators through the use of an activity analysis. This also provides an opportunity to identify new usages. The results of the evaluation of appropriation act as input for system updates and development.

Finally, despite the approaches used to combat the intrinsic shortcomings of systems and moving beyond the situations envisaged in terms of operational security, the systems making up the system of systems may fail or be, by design, incapable of dealing with situations that had or could not have been imagined beforehand. In all cases, operators must be able to continue their activities manually in the best possible conditions [AMA 06, AMA 09, PER 84, RUA 10a, SOM 10].

The results of the prospective analysis based on statistical studies show an increase in activity, allowing the identification of average activity and peaks in activity, and deduction of necessary resources in terms of operator post capacity to distribute the workload created by peaks in activity across several regions (conventions/partnerships). This organic growth of the regional call center leads to the recruitment of new operators, who are supported by longer-serving operators within the call center.

These “veterans” also play a role in professional supervision, helping new recruits to adopt trade processes, initially in order to reduce supervision at organizational level, then to take over all supervision duties as training progresses. This process is accompanied by suitable training sessions to help operators take on new supervisory roles.

Table 2.23. Organic growth of the regional call center

Job type	Current effectives	Effectives at T+48
Director	1	1
Emergency doctor	0	4
Supervisors	0	3
Operators	6	18
Total	7	26

Table 2.23 shows the organic development of the regional call center and is a human resource projection view (HV-B1 Manpower Projections) [HAN 08, SOU 08a].

Table 2.24. Career progression of regional call center operatorsi

Job type	Supervision route	Expertise route
Call center operators	Professional (on-the-job) supervision	Professional delegate
	Call center operators	Liaison agent with call centers in other regions

Table 2.24 shows the career progression of regional call center operators (HVB2 Career Progression) [HAN 08, SOU 08a].

These developments are carried out in close collaboration with operators based on their career plans. Those who choose to remain in an operator role will act as representatives and may be asked to act as liaison agents with call centers in other regions, mainly Orion.

The role of liaison agent is crucial for the coordination of activities between multiple regions [RUA 10a]. It is based on expertise and knowledge of the Tairétalet region, and on a network of relationships for the coordination of activities with other regions. Other regions delegate a liaison agent to work with the Tairétalet regional call center. These liaison agents are major contributors in the creation of shared procedures involving different regions. They also participate in the training and supervision of new recruits and in the creation of multi-region training sessions.

In addition to the organic growth of the regional call center, detailed work must be carried out on a regular basis to facilitate coordination between different members of staff, both in Tairétalet and in other regions, mainly Orion. While coherency may initially be ensured as far as doctrines and procedures are concerned, this is not sufficient.

Staff must become accustomed to working together and develop shared experiences to create a shared culture that goes beyond professional, organizational and regional cultures [RUA 10a]. This shared culture should assist in creating shared situation awareness in order to avoid ambiguity and incomprehension.

These training activities also allow the creation of shared automatisms, giving operators the means of concentrating on problematic aspects that demand their full attention. To this end, training sessions are organized involving all staff in the emergency service chain. These sessions take place in different parts of Tairétalet so that all emergency service centers and multi-service companies are involved.

Training sessions are also carried out in areas on the border between Tairétalet and Orion to allow the staff from both regions to participate. More informal followup sessions are then held with the aim of promoting personal links between staff. These training sessions should cover knowledge, practical abilities, professional practices and the transmission of information, all of which are necessary for coordination.

Table 2.25 represents the acquisition and maintenance of collective competences, and is a training view (HV-F Training) following the framework of the NAF human views [HAN 08, SOU 08a].

The engineering consulting company offers to carry out this process in association with the Tairétalet authorities and the directors of the regional call center, bringing in experts in human resources, employment law and human factors.

Table 2.25. Acquisition and maintenance of collective competences

	Knowledge	Abilities
Regional call center operators	Geographic, demographic, climatological and road traffic context of Tairétalet and Orion	Evaluate gravity of the situation Request intervention by an emergency service center or multi-service company Alert the authorities and security services of Tairétalet and Orion regarding the gravity of the situation
Emergency service teams	Geographic, demographic, climatological and road traffic context of Tairétalet and Orion	Evaluate gravity of the situation Diagnosis of casualties Alert the regional call center and hospital teams regarding the gravity of the situation
Hospital teams	Geographic and sanitary context of the Tairétalet and Orion regions	Assist with diagnosis Organize casualty admissions Send an analysis of available resources and factors affecting resources to the regional call center and emergency service teams
Security services	Geographic, demographic, climatological and road traffic context of Tairétalet and Orion	Evaluate gravity of the situation (in an exceptional situation) Provide analysis of the gravity of the situation to the Tairétalet and Orion authorities in exceptional cases
Weather services	Geographic and climatological context of Tairétalet and Orion	Evaluate risk of accidents based on weather conditions Notify the regional call center, emergency service centers, multi-service companies and the Tairétalet authorities of difficult weather conditions to allow preparations to be made
Road traffic services	Geographic, demographic and road traffic context of Tairétalet and Orion	Evaluate risk of accidents and difficulties of access to accident sites based on road traffic conditions Notify the regional call center, emergency service centers, multi-service companies and the Tairétalet authorities of difficult road traffic conditions for use in the organization of emergency interventions
Insurance companies, vehicle manufacturers, vehicle owners	Demographic and risk context of Tairétalet and Orion	Evaluate risks induced by the types of vehicles involved in the accident Notify the regional call center of vehicle characteristics for use in evaluating the gravity of the situation

The “evaluate the gravity of the accident”, “coordinate emergency services” and “allocate casualties to available hospitals” processes have been described in detail in terms of the activities of different partners, especially the regional call center, and exchanges between the information systems of different partners for coordination purposes. The service standards and pivot models used have also been presented, along with the way in which services are managed between the Tairétalet authorities and multi-service companies. Casualties must now be evacuated to hospitals that begin preparing to admit these patients.

2.4.3. Casualty evacuation: emergency service centers and hospitals

The process of casualty evacuation is mainly carried out by emergency service teams and hospitals after notification and coordination by the regional call center.

The activities involved include the treatment of casualties by emergency service teams at the scene of the accident, with characterization of the injuries of each and an evaluation of the severity of these injuries. This allows us to prepare to dispatch casualties to hospitals, taking account of the possibilities of each hospital in terms of equipment for treating different types of injuries.

Once first aid has been administered, the emergency service teams prepare casualties for transportation to the appropriate hospitals, for example by installing spinal boards where necessary. Finally, once the distribution of casualties to hospitals has been approved by the hospitals and emergency service teams, the latter transport the casualties to hospital. At the same time, hospital personnel prepare equipment for the treatment of casualties.

During transport, the emergency service teams and hospitals communicate information concerning the identity of casualties, their vital signs and clinical information. The identity of casualties is used to open administrative files for hospital admissions and to retrieve personal medical files. These files may contain important information for both hospital staff and the emergency service teams, such as the fact that one casualty has diabetes while another is receiving a treatment involving anticoagulants. Finally, hospital personnel may provide advice to the emergency services based on the development of the state of casualties.

These information exchanges are carried out by verbal communication between emergency service teams and hospital personnel and by the communication of computerized information between the automated systems present in ambulances and hospital medical information systems.

To facilitate oral communications between actors, a secure telecommunications system is used that is adapted for use by the emergency services, based on the Tetra standard [ETS 08, ETS 09].

For the communication of digital information, the engineering consulting company recommends the use of pivot models, in this case HL7 and SNOMED. The HL7 organization has created a functional specification for emergency service information systems, including information for casualty admissions (“Manage Pre- Arrival Data”, “Manage Arrival Data”) and for vital signs (“Capture EMS data”) [HL7 07]. This is the standard recommended by the engineering consulting company.

2.4.4. Continuous improvement of emergency situation management

What we have seen so far concerns operational processes, i.e. processes that are implemented at the time of an accident. The process of continuous improvement of emergency situation management is included in the domains of management, longterm piloting and operational processes. This management process is part of the third stage defined by the Tairétalet authorities.

Continuous improvement of emergency situation management involves the measurement and analysis of activity data, as we saw in the section on service management, in order to create dashboards and decide on courses of action. Transactions must be recorded in a way that enables a posteriori analysis of difficulties encountered in road traffic emergency situations and tracing and management of technical issues and development requirements, for example when dealing with a singular situation that has not previously been specified.

The regional call center information system must therefore record and store data and create dashboards.

2.4.5. Systems engineering for the regional call center, emergency service centers and hospitals

We have now created a system architecture for evaluating the state of casualties, organizing emergency services and allocating casualties to hospitals in addition to evacuating injured parties. This is an idealized architecture that only partially accounts for the diversity of the partner systems involved, which may come from the public sector or from private companies.

While the regional call center, regional traffic center, weather center, emergency service centers and hospitals in Tairétalet come under the aegis of the regional authorities, we must also deal with private companies. These include insurance companies, vehicle manufacturers, vehicle fleet owners and multi-service companies. Emergency service teams may come from emergency service centers in Tairétalet (or Orion) in the public sector, but also from multi-service companies operating in the region that belong to the private sector.

Public sector organizations and private companies have different economic and financial models based, in the first case, on not-for-profit provision of public services and, in the second case, on profitability. These groups also have different modes of operation and management. This characterizes and structures, among other things, the managerial independence aspect that we encounter in systems of systems. It has an impact on the architecture and use of the system of systems. While those organizations that are answerable to the Tairétalet authorities are obliged to follow the decisions of these authorities, this is not automatically the case for private companies. We must therefore find adequate means of implementing the recommended architecture for all stakeholders. This is a situation described by Maier and Rechtin as “private development and acquisition subject to governmental recommendations or standards” ([MAI 09], p. 120). The engineering consulting company recommends three complementary approaches.

The first, technical, approach consists of creating interoperability standards to allow exchanges between different systems. This approach takes the form of the definition of interface standards that both private and public partners must integrate into technical requirement specifications [BNA 00] for the systems they design or develop so that these systems may intercommunicate in a clear manner. Suppliers must design and create systems that conform to these interface standards.

Next, we must evaluate the conformity of systems to interoperability standards and issue certifications. The implementation of these systems is dependent on the planning, finance, contracting and creation of systems by different partners, respecting the rhythms and priorities of each. Aspects that are not related to the interoperability of technical systems but rather to the use of the resources of different organizations will be covered by a service management approach.

The second approach is of a regulatory nature. A standard is, in fact, applied voluntarily and is not obligatory in and of itself. For a standard to be adopted by all partners, it must be accompanied by regulations specifying the conditions of application and its compulsory nature for those working in the relevant domain. The authorities of Tairétalet and Orion will therefore be responsible for the creation and implementation of these rules, in collaboration with the various actors involved.

The third approach is of a fiscal nature and supplements regulations by adding incentive and dissuasive elements. This may take various different forms in practice, for example through fiscal aid that is reduced over time to encourage companies to apply regulations as early as possible. Companies not applying these regulations will not profit from this fiscal aid. Sanctions, such as the removal of operating licenses, may be used as a last resort.

These three complementary objectives must be developed collaboratively with the aim of assisting the deployment of technical solutions and service contracts, while respecting planned time schedules. Next, we must ensure the coherency of these three approaches in developing interoperability standards and service contracts based on new needs or technological solutions. These developments must be organized and planned so that each partner may give appropriate consideration to them in the creation of acquisition plans, programs and budgets, taking account of the specific evolutions of their own system(s). The difficulty here lies in the diversity of partner situations.

Certain partners do not yet possess information systems and are currently in the process of acquiring such equipment. These partners may naturally integrate interoperability standards into the technical specification of their new systems.

Those partners who already possess a made-to-measure system take interoperability standards into account when planning updates. In this case, there is not necessarily a convergence between planned updates and the schedule for different stages in the system of systems. This point should be the subject of negotiations and must be resolved. If the update schedule is very different from the planned schedule, there may be a need to plan a specific update, but we then encounter problems linked to planning this update in relation to the original plans.

Finally, for those who have bought off-the-shelf information systems, the situation is more difficult. This system is unlikely to offer the required services and it will probably be necessary to carry out specific developments if the necessary application programming interface is available. In cases where the information system is completely closed, with no available programming interface, and does not offer the desired services, we will need to identify possible solutions the Tairétalet authorities may use for partners acquiring this type of system.

It is very likely to be difficult to synchronize the evolutions of the different systems that make up the system of systems so that versions conforming to the same versions of interoperability standards can be launched simultaneously. This is due to the managerial independence of systems that evolve following the separate schedules of each partner organization.

Faced with these difficulties, various solutions exist, based on bottom-up and top-down compatibility between different versions. Bottom-up compatibility is the ability of a system to be compatible with one or more old versions of the standard that constitutes the point of reference at a given moment. Top-down compatibility is the ability of a system to be compatible with a future version of the standard in force at a given moment.

Figure 2.9 presents the bottom-up and top-down compatibility of different versions of a system in relation to versions of the ROR interoperability standard. It shows three versions of the interoperability standard, and the three versions of the systems used in the regional call center and hospitals in Quercus, Fraxinus and Salix, respectively. The figure shows a chronology of the three versions of the ROR interoperability standard: the first from T+0 to T+11, the second from T+12 to T+26 and the third from T+27 to T+37, the limit of the timeline.

The Tairétalet authorities adopt the same schedule for the three versions of the emergency call system. As the development schedule for the information system used in Quercus hospital is already fixed, however, the new version of the information system supporting version 2 of the ROR interoperability standard cannot be launched before T+18. The same goes for the information system used by Fraxinus hospital, which will be able to support version 2 of the interoperability standard from T+20. The information system used by Salix hospital can support version 2 of the ROR interoperability standard, but will launch version 3 of its own system before version 3 of the ROR interoperability standard is launched.

The regional call center information system may also operate using version 2 of the interoperability standard in correspondence with that used by Salix hospital, but must continue to support version 1 until T+20, the point at which the information system used in Fraxinus will switch over to version 2 of the standard.

From T+12 to T+20, the regional call center information system must remain compatible with version 1 of the interoperability standard: this is an example of bottom-up compatibility. In the same way, the regional call center information system must remain compatible with version 2 of the interoperability standard from T+27 to T+33 as the information systems used by the hospitals are not evolving at the same rate.

Looking at the information system used by Salix hospital, we see that the launch of a version of this system supporting version 3 of the interoperability standard occurs before other systems evolve. This decision was made based on the fact that the new version supports functionalities that will be especially useful for this particular hospital.

In this context, two solutions are possible:

– The first solution is for the new version of the Salix hospital information system to remain compatible with version 2 of the interoperability standard, at least from T+25 to T+27. Once again, this is an example of bottom-up compatibility.

– The other option, based on top-down compatibility, implies that the regional call center information system must be able to operate using version 3 of the interoperability standard as early as T+24. In other words, the specifications of version 3 must already be known during the development of version 2 of the regional call center information system. This second solution is not practical, so we plan to use bottom-up compatibility for the information system used in Salix hospital.

We thus see that it is not possible to deal with systems making up a system of systems in isolation. The development and schedule of different systems must be taken into account in order to determine their impact, both on the architecture of the system of systems and at the level of individual component systems.

In this context, extremely rigorous management of the configuration of different partner systems is an absolute necessity that no participant can afford to ignore.

The engineering consulting company offers services relating to the architecture of a solution, assisting the acquirer, as part of a service agreement. This organization will be responsible for the following activities, which it will carry out on behalf of the Tairétalet authorities:

– creation and maintenance of a directory of partners, including the following information:

- the identity of the partner,

- contact details,

- the name and contact details of the partner’s representative, for example the director of information systems,

- the items on the operational “map” owned by the partner in question;

– creation of a specification for the implementation of a secure telecommunications network, in conjunction with the Tairétalet authorities and the operators of telecommunications networks in the region, including:

- standards to apply,

- technical specification of transmitters, the network and the supervisor,

- specification of transmitter localization studies for the Tairétalet region,

- reservation and designation of specific frequencies for networks of this kind;

– creation and maintenance of the layout and schedule of applications contributing to the “evaluate gravity”, “coordinate emergency services”, “allocate casualties to hospitals” and “evacuate casualties” processes, in collaboration with delegates from partner organizations of the regional call center, including, among other things, the following information (service view and program view of the NAF):

- the operational process concerned,

- the functional sector concerned,

- the directory of available services and their versions,

- resources for the provision of available services,

- technologies of external interfaces used (web services, CORBA, etc.),

- schedule of planned developments for application resources and services,

- details of the partner who owns the applicable resources and services;

– the creation of four target service-oriented architectures and the following interoperability standards:

- the crisis management standard, based on OASIS/TSO,

- the standard for the operational resource register,

- the medical information standard (administrative information and vital signs), based on HL7 and SNOMED, and

- the standard for information concerning the vehicle, to be defined;

– each of these four interoperability standards must contain a definition of:

- cartography of applicable standards and current versions,

- register of services, including service quality levels, and

- cartography of protocols used;

– maintenance, configuration management and publication of versions of standards (service catalog, etc.);

– directive of requests for change, technical facts, impact analysis and review of the system-of-systems architecture, including:

- retro-design, including the resolution of technical details corrected in a “primitive” manner, without configuration management and without updating engineering documents,

- evaluation of gaps between existing and target architectures,

- updates to engineering documents,

- evaluation of impact in terms of schedule, budget and performance maintenance,

- risk management;

– watching for technological developments, particularly where standards for the domain are concerned;

– certification of systems and the evaluation of their conformity to interoperability standards, presenting the following information:

- the label, characteristics and version of the standard to which the certification applies,

- nominal and borderline performance (maximum load, etc.),

- report on observed gaps,

- permitted derogations, where applicable,

- the environment, managed through configuration, used for certification,

- date and place of certification,

- the identity of the experts responsible for certification, and

- signatures of experts responsible for certification;

– the creation of service contracts, the definition of services and of quality of service where applicable to the resources of multi-service companies, in partnership with those responsible for these companies;

– the creation of service measurements and of means of capitalizing on the results of these measurements;

– the creation of the regional call center information system, the design and evaluation of user interfaces in an incremental and iterative manner, in close cooperation with regional call center operators, implementing design principles and activities centered on human operators [ISO 09a];

– supporting the Tairétalet authorities and the person responsible for the regional call center in the organic growth of this center and emergency service centers;

– the creation, management and use of tools for managing emergency situations, based on the regional call center information system (stage three).

In order to carry out these activities successfully, the engineering consulting company creates a project team made up of:

– a technological watch cell;

– a cell responsible for collecting information on operational needs (help desk);

– a cell for the creation of an architecture at system of systems level, interoperability standards and the maintenance of coherency between the architecture and standards, with regular participation from members of partner organizations, whose role consists of:

- acting as reference contacts between the project groups of their organizations and the “emergency situation management” project group,

- communicating with project groups in their organization concerning demands at system of systems level that affect their systems, interoperability standards, system of systems-level planning and all other relevant and structuring information produced by the “emergency situation management” project group,

- piloting analyses of the impact of system of systems-level demands and interoperability standards on their organization’s systems,

- informing the “emergency situation management” project group of planned developments in the systems of their organizations, technical details that may affect performance or the period required for execution, and any other important information or decisions,

- negotiating operational parameters, service provision and time constraints,

- managing the integration of their organization’s systems within the “emergency situation management” system of systems, and

- contributing to the organization and preparation for certification of their organization’s systems;

– a cell devoted to the creation of an information system for the regional call center and the user interfaces involved, along with their evaluation in collaboration with call center operators;

– a cell to support the Tairétalet authorities in managing the organic growth of the regional call center and emergency service centers and the development of the call center information system;

– a cell covering legal, regulatory and fiscal considerations;

– a cell responsible for the certification of each system in relation to applicable interoperability standard(s).

Some of these actions are continuous, while others take place over limited periods of time. First, we shall describe the activities that occur at specific moments in the project schedule. Then we will look at recurring activities.

In Table 2.26, we differentiate between activities in the technical domain, for example the creation of interoperability standards and the call center information system, and activities in the regulatory and fiscal domains. We then provide a second table covering service management activities and a third table covers activities linked to human resources.

Table 2.26. Road map for the deployment of emergency service organization

Schedule	Technical domain	Regulations and fiscal concerns
	Project launch
T+1	Identification of all partners involved in the project Creation of a directory of these partners, both in the private and public sectors
T+1	Creation of specification for the launch of a secure telecommunications network
T+2	Creation of a map of partner applications in collaboration with delegates
T+2	Launch of call to tender for the creation of a secure telecommunications network
T+3	Update and consolidation of standardized reference points for application in service and information exchanges (within computerized services)
T+4	Creation of targeted service-oriented architectures and interoperability standards (crisis management perimeter and operational resource register)
T+4	Creation of plans for the implementation of interoperability standards by partners, taking account of their own plans for system development.
T+4	Receipt and analysis of offers for the creation of a secure telecommunications system Selection of an offer that best responds to the specification
T+5	Publication of the first version of each targeted service-oriented architecture and each interoperability standard (crisis management perimeter and operational resource register)	Creation of rules for the application of service-oriented architectures and interoperability standards, without mentioning a version number but specifying the current published version of the service architecture and interoperability standards
T+8	Impact analysis for each interoperability standard on partners’ existing systems
T+8	Consolidation of plans with partners
T+9	Beginning of launch of secure telecommunications system (both the network and the installation of terminals in the regional call center, emergency service centers, multi-service companies, hospitals, civil security and security force centers)	Creation of fiscal rules for application to the implementation of service-oriented architectures and interoperability standards
		Publication of rules for application of service-oriented architectures and interoperability standards
T+10	Beginning of creation of the regional call center information system, design and evaluation of user interfaces, taking into account the fact that this must include service management and means of measuring service provision	Publication of a document explaining the application of fiscal rules concerning deployment service-oriented architectures and interoperability standards
T+11	First cycle of design and evaluation of user interfaces for the regional call center system
T+13	Second cycle of design and evaluation of user interfaces for the regional call center system
T+14	Third and final cycle of design and evaluation of user interfaces for the regional call center system
T+15	Beginning of certification of partner systems
T+18	Validation (qualification) of the regional call center
T+19	End of certification of partner systems
T+20	Approval of regional call center system in terms of capacity to receive messages from accident detection systems
T+20	First iteration of end-to-end integration (reception of accident detection messages, collection of contextual information, access to the operational resource register)
T+20	End of roll-out and validation (qualification) of the secure telecommunications system
T+20	Beginning of initial training of regional call center operators
T+21	Second iteration of end-to-end integration
T+22	End-to-end validation of the system of systems using an emergency situation scenario
T+23	End of initial operator training and creation of several emergency situation scenarios for continued operator training
T+24	Stage one target: the regional call center should have a system for the reception and processing of information sent by accident detection equipment: – ambulances belonging to the emergency service centers and multi-service companies in the Tairétalet region and emergency service center ambulances in Orion should have a means of communicating with the regional call center – hospitals in the Tairétalet region should also have a means of communicating with the regional call center – hospitals in the Tairétalet region should have a resource management system (beds available in different services, available equipment, etc.) suited to their specific operations and capable of interoperation with the regional call center
T+24	Creation of the target service-oriented architecture and interoperability standards (medical data perimeter, admissions and vital signs)	Creation of rules for the application of the service-oriented architecture and interoperability standards (medical data perimeter, admissions and vital signs)
T+24	Creation of plans for the implementation of interoperability standards (medical data perimeter, admissions and vital signs) by partners, taking account of their own plans for system development	without mentioning a version number but specifying the current published version of the service architecture and interoperability standards
T+30	Publication of the target service-oriented architecture and interoperability standards (medical data perimeter, admissions and vital signs)	Creation of fiscal rules concerning the application of service architecture and interoperability standards (medical data perimeter, admissions and vital signs)
T+30	Analysis of impact of interoperability standards on existing systems of partners (medical data perimeter, admissions and vital signs)	Publication of rules for the application of the service architecture and interoperability standards (medical data perimeter, admissions and vital signs)
T+32	Consolidation of plans with partners	Publication, for application, of fiscal rules concerning the application of the service architecture and interoperability standards (medical data perimeter, admissions and vital signs)
T+36	Beginning of certification of partner systems
T+40	End of certification of partner systems
T+43	First iteration of end-to-end integration for medical data, with the call center, hospitals, emergency service centers and multi-service companies, both in Tairétalet and Orion
T+46	Second iteration of end-to-end integration
T+47	End-to-end validation of the system of systems
T+48	Stage two target: – ambulances belonging to the emergency services and multi-service companies in Tairétalet, the ambulances and helicopters belonging to the Orion emergency services and the Tairétalet hospitals should have a means of communicating information on vital signs between healthcare vehicles and hospitals – the Tairétalet authorities, the regional call center, emergency service centers, multi-service companies, hospitals and insurance companies in the region should contribute to the process of piloting emergency situation management on the roads and have access to shared means of representation of the emergency situation
T+50	Approval of the regional call center system in terms of the capacity to receive messages from accident detection systems in vehicles in transit through Tairétalet
T+60	Stage three target: the regional call center should have a means of receiving and processing information sent by the accident detection equipment of vehicles in transit.

Having looked at technical, regulatory and fiscal aspects, we shall now deal with service management and the associated regulatory and fiscal aspects in a second table in order to facilitate understanding. Service management is mainly found in the second and third stages of implementation.

Table 2.27. Road map of the roll-out of service management

Schedule	Service management	Regulations and fiscal concerns
	Project launch
T+3	Creation of service contracts, definition of services and quality of service relating to the resources of multi-service companies, in partnership with the directors of these companies
T+4	Creation of service measures and means of capitalizing on the results of these service measures
T+8	Creation of modes of valorizing services adapted to the project
T+12	Signature of service contracts with Tairétalet emergency service centers, multi-service companies and hospitals
T+15	Creation of plans for the implementation of means of measurement by partners	Creation of regulations for the application of means of measuring service provision, without mentioning a version number
T+16	Publication of the first version of means of measuring service provision	Creation of fiscal rules applicable to the implementation of the means of measuring service provision
T+16	Analysis of the impact of means of measuring service provision on existing partner services	Publication of rules governing the application of means of measuring service provision
T+17	Firming up of plans with partners	Publication, for application, of fiscal rules governing the application of means of measuring service provision
T+18	Creation of means of measurement within each organization and of means of consolidating these measures within the regional call center
T+23	Beginning of certification of partner systems
T+29	End of certification of partner systems
T+31	First iteration of end-to-end integration of service measures between the regional call center, emergency service teams and multi-service companies, both in Tairétalet and Orion
T+33	Second iteration of end-to-end integration
T+35	Implementation of service management with associated means of measurement
T+47	Synthesis of measures for use in annual service contract update
T+48	Annual update of service contracts
T+48	Stage two target: – the regional call center, emergency service center and multi-service company ambulances in Tairétalet should have a means of measuring performance in emergency situations (time taken to intervene, emergency service workload, satisfaction levels of emergency service personnel) – the hospitals in Tairétalet region should have a means of measuring performance suited to the expected capabilities (time taken for a patient to be taken on by a suitable hospital structure, workload of hospital personnel, satisfaction levels of hospital personnel) – the Tairétalet authorities, regional call center, emergency service centers, multi-service companies, hospitals and insurance companies in the Tairétalet region should contribute to the process of piloting the management of emergency situations on the roads and have a shared means of representing emergency situations
T+59	Synthesis of measures for use in annual service contract update
T+60	Annual update of service contracts
T+60	Stage three target: the Tairétalet authorities, regional call center, emergency service centers, multi-service companies, hospitals and insurance companies in the Tairétalet region should contribute to the process of improving the management of emergency situations on the roads, in cooperation with neighboring regions that share the same approach.

Having looked at the roll-out of technical systems followed by that of service management, with the associated regulatory and fiscal aspects, we shall finish by presenting a road map of activities linked to human resources.

These different road maps are all interlinked. At the technical level, the design of information system user interfaces for the emergency call center and their evaluation echo the analyses of probable future activities found in the road map of human resources activities. The design of user interfaces must, in fact, be based on the sharing of activities between operators and on the definition of activities that must be supported by the information system.

Table 2.28. Road map of activities linked to human resources

Plan	Human resources	Regulations and fiscal concerns
	Project launch
T+3	Analysis of activities of regional call center operators
T+4	Evaluation of the gap between current activity and probable future activity, taking account of developments of the profession (computerization of work stations, contribution of an emergency medic)
T+8	Launch of working procedure developments, accounting for the organic growth of the regional call center and the computerization of work stations, with regional call center operators
T+9	Establishment of coherency between procedures in the regions concerned, mainly Tairétalet and Orion
T+9	Identification of activities that must be supported by the regional call center information system
T+9	Creation of manual procedures in case of failure in one of the systems in the system of systems
T+9	Creation, with operators, of possible career paths (supervision/expertise)
T+10	Preparation of user interface design and evaluation sessions, with the participation of regional call center operators
T+11	Contribution to the first cycle of evaluation of user interfaces of the regional call center information system
T+13	Contribution to the second cycle of evaluation of the user interfaces of the regional call center information system
T+14	Contribution to the third cycle of evaluation of the user interfaces of the regional call center information system
T+15	Update of working procedures, doctrine and pooling between the Tairétalet and Orion regions.
T+16	Evolution of operator job descriptions and requalification of the post, taking account of the evolution of activities	Modifications in job contracts, in the form of endorsements, to take account of the development of activities, the requalification of posts and the objectivebased mode of management
T+16	Establishment, with operators, of an objective-based management approachsd
T+17	Creation of training plans suited to different career paths and to the computerization of work stations
T+20	Beginning of training of regional call center operators
T+21	Second iteration of end-to-end integration
T+22	Evaluation of the appropriation process by operators and via feedback
T+22	End-to-end validation of the system of systems using an emergency situation
T+23	End of initial operator training and implementation of several emergency situations for continued training of operators
T+24	Stage one target: – the call center must have a system for receiving and processing information sent by accident detection equipment – ambulances from emergency service centers and multi-service companies in Tairétalet, and the ambulances of emergency service centers in Orion, should have a means of communicating with the regional call center – hospitals in the Tairétalet region should also have access to means of communicating with the regional call center – hospitals in the Tairétalet region should have resource management systems (beds available in different services, equipment, etc.) suited to their operations and able to interoperate with the regional call center
T+26	Preparation and creation of a first training session, with identification of points to cover (knowledge, practical abilities, transmission of knowledge)
T+27	Evaluation of the appropriation process by operators and feedback
T+27	Creation of a results report for the first training session and its contribution to the creation of a shared image of the emergency situation.
T+32	Preparation and creation of a second training session with manual mode and systems, identification of points to cover (knowledge, practical abilities, transmission of knowledge) taking account of the results of the first session
T+33	Evaluation of the appropriation process by operators and feedback
T+33	Creation of a results report for the second training session
T+34	Analysis of the appropriation procedure by operators and analysis of new usage, syntheses of integration iterations and training sessions
T+34	Insertion of the results of the appropriation process in the information system evolution process to successfully implement updates
T+36	Preparation and creation of a third training session with the Orion region; identification of points to cover (knowledge, practical abilities, transmission of knowledge) taking account of the results of the second session
T+37	Creation of a results report for the third training session and its contribution to the creation of a shared image of the emergency situation.
T+42	Preparation and creation of a fourth training session with the Orion region, with systems and in manual mode; identification of points to cover (knowledge, practical abilities, transmission of knowledge) taking account of the results of the third session
T+43	Creation of a results report for the fourth training session and its contribution to the creation of a shared image of the emergency situation
T+45	Creation of a synthesis report of the results of the four training sessions and their contribution to the creation of a shared image of the emergency situation
T+46	Insertion of the results of the appropriation process into the information system evaluation process for successful implementation of updates
T+48	Stage two target: the Tairétalet authorities, regional call center, emergency service centers, multi-service companies, hospitals and insurance companies in the Tairétalet region should contribute to the process of piloting emergency situation management on the roads and have a shared means of representing an emergency situation

We must also add recurring activities to the activities included in these three road-maps. These activities, which fall outside the realm of planned activities, include the collection of technical information, new needs expressed by operators or partners and watching the development of standards in order to organize and plan updates to systems based on these standards.

Finally, we must measure activities and service calls in order to be able to take an approach based on the continuous improvement of the accident management process.

The main section of this chapter, the case study, has allowed us to identify points for consideration in terms of systems engineering, so that the expected capabilities will be produced and the systems of the system of systems will contribute to these goals.

We shall now characterize the specificities of system-of-systems engineering in relation to systems engineering as it is described in reference documents [INC 07, ISO 08].

2.4.6. Specificities of system-of-systems engineering

Several specific characteristics set system-of-systems engineering apart from systems engineering. These characteristics are not radically different, and are already sketched out in systems engineering, but they become crucial considerations in the context of systems of systems.

These specificities are as follows:

– the plurality and diversity of partners, both in acquisition and supply, public and private sectors, presenting different economic models and showing managerial independence;

– the integration of isolated project approaches that are independent from each other within an integrated system-of-systems approach. This point is new and generates a “project-of-projects” way of working in connection with these systems of systems. This implies that different projects share the same reference point in terms of project management, methods and tools that are at least compatible, if not completely interoperable;

– a system-of-systems architecture based on open systems and interoperability [BNA 09];

– an iterative and incremental approach that breaks with the traditional linear approach described in manuals and standards;

– a complementarity of top-down and bottom-up approaches, which again breaks explicitly with traditional approaches. Bottom-up approaches require us to update design documents linked to the existing system and carry out a certain amount of retro-design. We also find corrections of technical aspects carried out within the system itself in a less formal or “primitive” manner, without updates to engineering documents or management at configuration level;

– an interdisciplinary approach, which is not itself new as systems engineering is multi-disciplinary by nature in the engineering techniques it uses, but becomes essential in the context of systems of systems, including disciplines outside the field of engineering, such as law, marketing, economics, human factors, etc.;

– the implication and effective contribution of operators is already recommended in systems engineering, and becomes essential in the case of systems of systems. Human resources and organization are major aspects that should be considered part of developments. These do not fall under the umbrella of engineering sciences, but humanities, social sciences and the management of human resources;

– the creation and management of interoperability standards;

– the management of evolutions and configurations;

– the certification of systems in relation to an interoperability standard;

– the coherency of the system-of-systems architecture;

– the current limits of architecture frameworks and description languages to purely technical dimensions, which must be added to and enriched to take nontechnical dimensions into consideration (economic model, communications model, etc.);

– last, but not least, an iterative and incremental approach, known in systems engineering, that breaks radically with the linear V-model approach considered to be the point of reference. This iterative and incremental approach takes account of feedback from the first iterations to fuel the development of the following iterations.

These specificities, often radical, also show that systems engineering as defined in standardization documents is incomplete and requires adaptation for complex systems.

2.5. Conclusion

This chapter has shown how system-of-systems engineering activities are carried out through the use of a case study, moving from a capability requirement to the definition of technical and non-technical means to respond to this need.

The systems engineering approach, which for us is by definition interdisciplinary, has led us to take a broad rather than in-depth approach to this case study. Effectively, system-of-systems engineering does not consist of engineering the component systems of the system of systems.

In addition, an in-depth, strictly technical approach is inadequate when dealing with systems and systems of systems. In this, we intentionally set ourselves apart from exclusively technical studies that do not give consideration to economic models, usage models or contractual, judicial and fiscal dimensions. From our point of view, these works enter into in a damaging impasse that prevents the growth and diffusion of systems engineering.

2.6. Acknowledgements

Thanks are due in particular to Benjamin Hermant for his extremely relevant reading of and remarks on the text, Robert Marcouf, who lent me his “haven” in Provence to write part of this chapter in peace, and Étienne Remaud, the illustrator responsible for Figure 2.1.

Thanks are also due to Jean-Luc Garnier, my co-leader on the Systèmes de Systèmes et Services; Architecture et Ingénierie technical committee of the AFIS (Association Française d’Ingénierie Système), the other members of this 3S-AI committee, and Olivier Habart and Bruno Carrier-Marquis for invaluable discussions.

2.7. Bibliography

[ADA 07] ADAC, Results of the eCall Feasibility Trial; Extended Version, ww­w.e­sco­pe.­inf­o/d­own­loa­d/e­cal­l_t­ool­box­/Re­por­ts/­eCa­ll%­20M­ach­bar­kei­tss­tud­ie%­20E­rge­ bn­is_­EN_­200­706­27.­pdf, 2007.

[AFI 10] AFIS, www.afis.fr, 2010.

[AMA 06] AMALBERTI, R., “Violations et migrations ordinaires dans les activités à risques: conséquences pour la résilience globale et la gestion du retour d’expérience en entreprise”, Actes du Colloque Ergo’IA 2006, Biarritz, October 2006.

[AMA 09] AMALBERTI R., “Violations et migrations ordinaires dans les interactions avec les systèmes automatisés”, Journal Européen des Systèmes Automatisés, n° 4, 2009.

[ARH 09a] ARHIF (Agence régionale de l’hospitalisation d’Ile de France), Répertoire opérationnel des ressources Ile-de-France, 2009.

[AUT 07] AUTRAN F., CATTAN D., GARNIER J.-L., LUZEAUX D., PEYRICHON M., RUAULT J.-R., “Coupling component systems towards systems of systems”, International Conference on Software and System Engineering and Applications (ICSSEA 2007), Marne-la-Vallée, December 2007.

[AUT 08] AUTRAN F., AUZELLE J.-P., CATTAN D., GARNIER J.-L., LUZEAUX D., MAYER F., PEYRICHON M., RUAULT J.-R., “Coupling component systems towards systems of systems”, 18^th International Symposium of the International Council on Systems Engineering (INCOSE’08), Utrecht, Netherlands, June 2008.

[AUZ 09] AUZELLE J.-P., Proposition d’un cadre de modélisation multi-échelles d’un système d’information d’entreprise centré sur le produit, thesis presented at the Henri Poincaré University, Nancy I, 2009.

[BAC 08] BACHATÈNE H., GARNIER J.-L., RUAULT J.-R., “Adaptability of software intensive systems, facing new threats and opponents new tactics”, NATO Symposium “Agility, Resilience and Control in Network Enabled Capabilities (NEC)”, Amsterdam, May 2008.

[BNA 00] BNAE, RG Aéro 000 08 A, Expression du Besoin – Guide pour l’Élaboration de la Spécification Technique de Besoin, 2000.

[BNA 05] BNAE, RG Aéro 000 77, Management de Programme – Guide pour le Management de l’Ingénierie Système, 2005.

[BNA 10] BNAE, RG 000 120, Program Management - General Recommendation for the Acquisition and Supply of Open Systems, 2010.

[BOE 06] BOEHM B., “Some future trends and implications for systems engineering and software engineering processes”, Systems Engineering, vol. 9, n° 1, 2006.

[BOU 10a] BOURGEOIS D., “La solution”, Connected Emergency, www­.sa­nte­-li­mou­sin­.fr­/ p­roj­ets­/pr­oje­ts-­de-­tel­esa­nte­/in­for­mat­isa­tio­n-d­es-­smu­r, 2010.

[BUT 10a] BUTRUILLE L., www.samu06.org, 2010. Management of Emergency Situations 199

[CAN 11] CANTOT P., LUZEAUX D., Simulation and Modeling of Systems of Systems, ISTE, London and John Wiley and Sons, New York, 2011

[CEE 03] CEE, Systèmes de Transport Intelligents: l’Intelligence au Service des Réseaux de Transport, European Community, europa.eu.int/comm/dgs/energy_ transport/index_fr .html, 2003.

[CEN 09a] CEN (European Committee for Standardization), Disaster and Emergency Management – Shared Situation Awareness – Part 1 : Message Structure, CWA 15931- 1:2009 D/E/F, CEN, 2009.

[CEN 09b] CEN (European Committee for Standardization), Disaster and Emergency management Shared Situation Awareness – Part 2: Codes for the Message Structure, CWA 15931-2:2009 D/E/F, CEN, 2009.

[CER 09] CER (Centre d’Études sur les Réseaux, les Transports, l’Urbanisme et les Constructions Publiques), Présentation du Domaine Fonctionnel 2: Gérer les Services d’Urgence, CER, April 2009.

[COL 09] COLAS C., SARRON J.-C., Résilience des Hommes et des Systèmes Militaires, internal documents, July 2009.

[DAR 10a] DARTIGUES M., Interconnexion des SAMU, Document d’Information, orumip.net/docs/IntercoSAMU_docv1_0.pdf), 2010.

[ECA 06] ECALL DRIVING GROUP, Recommendations of the DG eCall for the Introduction of the Pan-European eCall, ww­w.e­cal­l.f­i/P­osi­tio­n_p­ape­rs_­DG_­eCa­ll_­v2.­pdf­, 2006.

[ECA 07] ECALL DRIVING GROUP, eCall Communications Test Bench – Structure and Content of MSD, FDS and MDS messages, www­.ec­all­.fi­/eC­all­_ms­d_e­n_0­220­07.­pdf­, 2007.

[ESA 04] ESAFETY FORUM ECALL DRIVING GROUP, Memorandum of Understanding for Realisation of Interoperable In-Vehicle eCall, www­.es­cop­e.i­nfo­/do­wnl­oad­/ec­all­_to­olb­ox/­inv­ehi­cle­_ec­all­_mo­u.p­df, 2004.

[ETS 08] ETSI, TR 100 392-17-4, Terrestrial Trunked Radio (TETRA), Voice plus Data (V+D), Part 17: TETRA V+D and DMO Specifications, Sub-part 4: Release 2.0, ETSI, 2008.

[ETS 09] ETSI, EN 300 392-1, Terrestrial Trunked Radio (TETRA), Voice plus Data (V+D), Part 1: General Network Design, v1.4.1, ETSI, 2009.

[FID 06a] FIDOCK J., Organisational Structure and Information Technology (IT): Exploring the Implications of IT for Future Military Structures, DSTO, Edinburgh, 2006.

[FID 06b] FIDOCK J., The Model of Technology Appropriation: A Lens for Understanding the Process of Human Systems Integration, DSTO, Edinburgh, 2006.

[HAN 08] HANDLEY H., HSI in Network Enabled Capability (NEC): The Human View www­.ma­npr­int­.ar­my.­mil­/pr­ese­nta­tio­ns/­Dr.­%20­Hol­ly%­20A­.%2­0H.­%20­Han­dle­y.p­df, 2008. 200 Complex Systems and Systems of Systems Engineering

[HAZ 06] HAZEL G., BOPPING D., “Linking NCW and coalition interoperability: understanding the role of context, identity and expectations”, Human Factors in Network-Centric Warfare Symposium, Sydney, 2006.

[HEN 08] HENAFF-DARRAUD D., “Répertoire Opérationnel des Ressources (ROR)”, reimp’Hos, Journée Télésanté 2008, 2008.

[HL7 07] HEALTH LEVEL 7, Emergency Department Information Systems (EDIS), Functional Profile, Draft Version 1.02, HL7, 2007.

[HSS 10] HSS, Healthcare Services Specification Project, hssp.wikispaces.com, 2010.

[INC 07] INCOSE, INCOSE Systems Engineering Handbook v. 3.1, INCOSE, 2007.

[ISO 02] ISO/IEC 15288: 2002, Ingénierie des Ssystèmes – Processus de Cycle de vie des Systèmes, ISO, 2002.

[ISO 08] ISO/IEC 15288: 2008, Systems and Software Engineering – System Life Cycle Processes, ISO, 2008.

[ISO 09a] ISO/DIS 9241-210, Ergonomie de l’Interaction Homme-système – Partie 210: Conception Centrée sur l’Opérateur Humain pour les Systèmes Interactifs, ISO, 2009.

[ISO 10a] ISO/IEC FCD 29148, Software and Systems Engineering – Life Cycle Processes – Requirements Engineering, ISO, 2010.

[ISO 10b] ISO/DIS 22320, Societal Security – Emergency Management – Requirements for Command and Control, ISO, 2010.

[ISO 10c] ISO/IEC FCD 42010, Systems and Software Engineering – Architecture Description, ISO, 2010.

[KAM 10] KAM L., “Model-driven design and simulation”, in LUZEAUX D., RUAULT J.-R., Systems of systems, ISTE, London and John Wiley and Sons, New York, 2010.

[KOC 07a] KOCH N., Automotive Case Study: UML Specification of on Road Assistance rap.dsi.unifi.it/sensoria/files/FAST_report_1_2007_ACS_UML.pdf, 2007.

[LUZ 10a] LUZEAUX D., “Systems of systems: from concept to actual development” in: LUZEAUX D., RUAULT J.-R., Systems of Systems, ISTE, London and John Wiley and Sons, New York, 2010.

[LUZ 10b] LUZEAUX D., “Methods and tools for system of systems engineering” in: LUZEAUX D., RUAULT, J.-R., Systems of Systems, ISTE, London and John Wiley and Sons, New York, 2010.

[MAI 98a] MAIER M., “Architecting principles for systems-of-systems”, Systems Engineering, vol. 1, n° 3, 1998.

[MAI 09] MAIER M., RECHTIN E., The Art of Systems Architecting, CRC Press, London, 2009.

[MAR 07] MARTY G., AZEMA O., “Politique d’informatisation des urgencies”, Etat des Lieux & Perspectives, ORUMIP, 2007.

[MAR 09] MARMOUD D., BLAISE C., La Vitrine Technologique: Focus sur Connected Emergency, l’Ordinateur Portable Innovant pour le SAMU, alternativemedia.fr/ info_view.php?i=2748, 2009.

[MAS 08] MASSARD N., “L’appropriation de l’ERP par l’utilisateur final: Comment influencer ce processus vers les pratiques attendues par l’équipe projet?”, 13^th Conference of the AIM, Pre-ICIS, December 2008.

[MAS 09] MASSARD N., “Revisiter la notion d’appropriation: pour une application au cas des ERP”, 14th Conference of the AIM, June 2009.

[MEL 04] MELLORD S., SCOTT K., UHL A., WEISE D., MDA Distilled: Principles of Model-Driven Architecture, Addison-Wesley, London, 2004.

[NCO 10] NCOIC, Secure Formatted Information Exchange Gateway Pattern, NCOIC, 2010.

[OAS 08a] OASIS, Open Advanced System for dISaster and emergency management, The Tactical Situation Object, www­.oa­sis­-fp6.org/, 2008.

[OAS 08b] OASIS, Open Advanced System for dISaster and emergency management, Oasis Terms and Concepts, www.oasis-fp6.org/, 2008.

[OAS 08c] OASIS, Open Advanced System for dISaster and emergency management, IT Framework, www.oasis-fp6.org/, 2008.

[OAS 08d] OASIS, Open Advanced System for dISaster and emergency management, Communication, www.oasis-fp6.org/, 2008.

[OMG 07] OMG, Open Management Group, Data Distribution Service for Real-time Systems, 2007.

[OMG 08] OMG, Open Management Group, Health Level Seven, Healthcare Services Specifications Project, ww­w.h­l7.­org­.uk­/ma­rke­tin­g/w­ork­sho­ps/­HL7­UK_­OMG­_06­310­1.a­sp, 2008.

[PAL 09] PALMQVIST R., SCHYLBERG L., JONES A., Legacy Services Capability Pattern, NCOIC, 2009.

[PAR 05] PARDO-CASTELLOTE G., OMG Data-Distribution Service: Architectural Overview, www­.om­gwi­ki.­org­/dd­s/c­ate­gor­y/o­rig­ina­l-a­uth­or/­ger­ard­o-p­ard­o, 2005.

[PAR 10a] PARM Samu 63, P.A.R.M c’est quoi?, http://parm63.free.fr/, 2010.

[PEL 04] PELLEN-BLIN M., BRY A., CHOUVY N., “La conception d’organisations futures et les IBEOs (Illustrateur de besoin d’exploitation opérationnelle)/IBEO tool: Designing the work organisation of the future warship control centres”, Ergo’IA 2004, Biarritz, 2004.

[PER 84] PERROW C., Normal Accidents, Doubledays, New York, 1984.

[RAM 09a] RAMU CA (Le Réseau d’Aide Médicale Urgente de Champagne-Ardennes), IHE Meeting, March 17, 2009, wi­ki.­ihe­.ne­t/i­mag­es/­d/d­8/I­HE_­Pre­sen­tat­ion­-Gr­oup­e_I­HE_­17­_ma­rs_­200­9_v­3.pdf, 2009. 202 Complex Systems and Systems of Systems Engineering

[RAY 10] RAYNAL L., BONNEAU G., LABY M., BOULNOIS H., HARRIS J.S., BONNAUD A., BORN A., Information Dissemination Shared Database Capability Pattern, NCOIC, 2010.

[ROG 03] ROGERS E., Diffusion of Innovations, Free Press, New York, 2003.

[RUA 06] RUAULT J.-R., “Esquisse de processus visant à améliorer la capacité d’adaptation des systèmes à leurs environnement”, Ergo’IA 2006, Biarritz, October 2006.

[RUA 09a] RUAULT J.-R., COLAS C., SARRON J.-C., LUZEAUX D., “Ingénierie système et résilience des systèmes sociotechniques”, 5^e Conférence annuelle d’Ingénierie Système AFIS, Paris, 2009.

[RUA 09b] RUAULT J.-R., “Adaptabilité des systèmes à logiciel prépondérant – Appropriation et démarche orientée aspect”, Journal Européen des Systèmes Automatisés, n° 4, 2009.

[RUA 10a] RUAULT J.-R., “The human factors within the context of systems of systems”, in: LUZEAUX D., RUAULT J.-R., Systems of Systems, ISTE, London and John Wiley and Sons, New York, 2010.

[RUA 10b] RUAULT J.-R., “Systems of systems in the healthcare field”, in: LUZEAUX D., RUAULT J.-R., Systems of Systems, ISTE, London and John Wiley and Sons, New York, 2010.

[RUA 10c] RUAULT J.-R., MEINADIER J.-P., “Standardization in the field of system and systems of systems engineering”, in: LUZEAUX D., RUAULT J.-R., Systems of systems, ISTE, London and John Wiley and Sons, New York, 2010.

[RUA 10d] RUAULT J.-R., POURCEL C., “Marketing, ergonomie et ingénierie système: jouer la complémentarité pour innover”, Actes de la Conférence ErgoIA 2010, 2010.

[RUA 10e] RUAULT J.-R., “Interopérabilité organisationnelle; les enjeux pluridisciplinaires”, GIS Interopérabilité des Systèmes Scientific Seminar, Nancy, 2010.

[RUA 10f] RUAULT J.-R., “Ergonomie et BPM; quelles complémentarités?”, Interview with Gautier Barrère, www­.ga­rga­ris­mes­-er­gon­omi­que­s.c­om/, 2010.

[RUA 11a] RUAULT J.-R., COLAS C., SARRON J.-C., LUZEAUX D., “Résilience des systèmes sociotechniques: application à l’ingénierie système”, Génie Logiciel, March 2011.

[RUB 08a] RUBIN K., The Practical Guide for SOA in Health Care, hssp.wikispaces.com/ PracticalGuide, 2008.

[SCH 10] SCHNEIDER S., What Is Real-Time SOA?, Real-Time Innovations Inc., 2010.

[SEI 09] SEI, CMMI® for Services, v. 1.2, 2009.

[SOM 10] SOMMERVILLE I., Designing with Murphy in Mind; Giving Failures the Respect That They Deserve, SEPG Europe, 2010.

[SOU 08a] SOULIER E., BUGEAUD F., RUAULT J.-R., “Nouveaux concepts pour la collaboration entre experts des facteurs humains et ingénieurs des systèmes”, Ergo’IA 2008, Biarritz, October 2008.

[THO 04] THOMPSON J., Organizations in Action, Transaction Publishers, New Brunswick, 2004.

[TIC 09a] TICSANTE, Du Nouveau pour la Plateforme Régionale Santé-Limousin, www­.ti­csa­nte­.co­m/s­how­.ph­p?p­age­=st­ory&n­ews­Pag­e=7&id=458&story=458, 2009.

[TIC 10a] TICSANTE, Samu/Centre 15 de Midi-Pyrénées: Lancement de l’Interconnexion Informatique des CRRA, www.ticsante.com, 2010.

[VER 04] VERET D., RUAULT J.-R., “Articuler le volet juridique et le management de projet informatique pour jouer gagnant”, Le Droit et les Projets, La Cible/La Revue Francophone du Management de Projet, n°100, March 2004.

[VER 10] VÉRET D., “Contractual aspects of the acquisition and use of systems of systems”, in LUZEAUX D., RUAULT J.-R., Systems of Systems, ISTE, London and John Wiley and Sons, New York, 2010.

[WAV 07] WAVECOM, Implementing eCall: Vehicle Emergency Communication, Wavecom Blue paper n°2, ww­w.w­ave­com­.co­m/m­edi­a/f­ile­s/b­lue­pap­ers­/pa­per­002­.pd­f, 2007.

---

1 Chapter written by Jean-René RUAULT.

1 Aide à la conception de systèmes de Transport Interopérables en France.

2 Network Centric Operations Industry Consortium.

3 International Organization for Standardization.

4 International Council on Systems Engineering.

5 These two approaches are very different, as model-based systems engineering is not based on the transformation of models in the computing sense of the term. Any attempts to transform regulatory or economic models would be meaningless and pointless.

6 Translator’s note: note that our imaginary emergency scenario takes place in France, where the role of the fire service is relatively broad, including provision of certain medical services.

7 Open Advanced System for dISaster & emergency management (www­.oa­sis­-fp­6.o­rg/).

8 B2B: business to business.

9 B2C: business to customer.

10 B2A: business to administration.

11 DOTMLPF: Doctrine, Organization, Training, Material, Leadership, Personnel, Facilities.

12 Universal Mobile Telecommunications System.

13 A global navigation satellite system independent from GPS in the US and Russia’s GLONASS.

14 Enhanced Data rates for GSM Evolution.

15 DDS: Data-Distribution Service.

16 www­.oa­sis­-fp­6.o­rg.

17 Land Command and Control Information Exchange Data Model.

18 Bureau de Normalisation Aéronautique et Espace.