P O N T E S U L L O S T R E T T O D I M E S S I N A

Concessionaria per la progettazione, realizzazione e gestione del collegamento stabile tra la Sicilia e il Continente Organismo di Diritto Pubblico

(Legge n° 1158 del 17 dicembre 1971, modificata dal D.Lgs. n°114 del 24 aprile 2003)

PROGETTO DEFINITIVO

EUROLINK S.C.p.A.

IMPREGILO S.p.A. (MANDATARIA)

SOCIETÀ ITALIANA PER CONDOTTE D’ACQUA S.p.A. (MANDANTE) COOPERATIVA MURATORI E CEMENTISTI - C.M.C. DI RAVENNA SOC. COOP. A.R.L. (MANDANTE)

SACYR S.A.U. (MANDANTE)

ISHIKAWAJIMA - HARIMA HEAVY INDUSTRIES CO. LTD (MANDANTE)

A.C.I. S.C.P.A. - CONSORZIO STABILE (MANDANTE)

IL PROGETTISTA

Ing. E.M. Veje Dott. Ing. E. Pagani

Ordine Ingegneri Milano n° 15408

IL CONTRAENTE GENERALE

Project Manager (Ing. X.X. Xxxxxxxxxxx)

STRETTO DI MESSINA

Direttore Generale e RUP Validazione (Xxx. X. Xxxxxxxxxx)

STRETTO DI MESSINA

Amministratore Delegato (Xxxx. X. Xxxxxx)

PI0001_F0

Unità Funzionale Tipo di sistema

Raggruppamento di opere/attività Opera - tratto d’opera - parte d’opera

CODICE

Titolo del documento

OPERA DI ATTRAVERSAMENTO IMPIANTI TECNOLOGICI ESERCIZIO E MANUTENZIONE

Management , Control and Simulation Systems Management and Control, Annex

REV	DATA	DESCRIZIONE	REDATTO	VERIFICATO	APPROVATO
F0	20/06/2011	EMISSIONE FINALE	HEGJ, HPE, PKWA, PSN	FNJE/JCA	JCA/JCA

NOME DEL FILE: PI0001_F0.docx

INDICE

INDICE 3

1. Executive Summary 8

1.1 Management and Control System (MACS) 9

1.1.1 SCADA interface 11

1.1.2 MMS interface 11

1.2 General for the Systems 12

1.3 Pending development 13

2 Introduction 14

2.1 General 14

2.2 MACS 14

2.2.1 SCADA 15

2.2.2 The description of the SCADA system is found in the E&M design basis,MMS 15

3 MACS Main Module 16

3.1 General architecture of MACS 17

3.1.1 System layout 17

3.2 Enterprise architecture 18

3.2.1 Enterprise service bus 19

3.2.2 Enterprise message model 20

3.2.3 Implementation of ESB 21

3.2.4 Service Oriented Architecture 23

3.2.5 An overall architecture of the MACS 26

3.2.6 Software System Maintenance 28

3.2.6.1 Software design principles 28

3.3 MACS Actors 31

3.3.1 O&M Technological Systems 33

3.4 Main use case 34

3.5 View Events and elements on map 37

3.5.1 Storing and querying long-term data 40

3.6 User interface 41

3.6.1 Common Control room User interfaces 41

3.6.1.1 Control room video wall 41

3.6.2 SCADA Interface 43

3.6.3 MMS Interface 43

3.7 Data Handling in MMS 45

3.7.1 Use Case Diagrams 45

3.7.2 External data 49

3.7.3 Internal data 49

3.7.3.1 User rights in relation to system access 50

3.7.3.2 Reports generated in MMS 50

3.7.4 Data communication between MMS and CSP 51

3.7.5 Data communication between MMS and BMS 51

3.7.6 Data communication between MMS and WSMS 51

3.7.7 Data communication between MMS and ICMS 51

3.7.8 Summary of MMS Interaction with Sub-Systems 52

3.8 Types of plots and tables in MMS 53

3.8.1 Plots 53

3.8.1.1 General setup of plots 53

3.8.1.2 Non-standard XY-plot 55

3.8.2 Example of Tables 56

3.9 Types of plot for use in standard reports in MMS 59

3.9.1 Plots containing data from SHMS/CSP 60

3.9.1.1 Loads 60

3.9.1.2 Displacements 61

3.9.1.3 Fatigue 64

3.9.1.4 Events 65

3.9.1.5 Stress 68

3.9.1.6 Weather 70

3.9.1.7 Traffic 70

3.9.2 Plots containing data from TMS 71

3.9.3 Plots containing data from WSMS 71

3.9.4 Plots containing data from BMS 72

4 List of requirements 72

5 Documentation Minimum Requirements 78

5.1.1 Operation Manual 78

5.1.2 Maintenance Manual 78

5.1.3 System Architecture Guide 79

5.1.4 Software Source Code Guide 79

5.1.5 Printed software source code 79

5.1.6 Troubleshooting Guide 79

5.1.7 Event Diagnosis Guide 79

5.1.8 Quality Control Documents 80

6 Quality Control Minimum Requirements 80

6.1 Sub-contractor Selection 80

6.2 Testing 80

6.2.1 Certificates 80

6.2.2 Factory Acceptance Tests 80

6.2.3 Site Acceptance Tests 81

6.3 Repairs 81

6.4 Labelling and Identification 81

7 Copyright Minimum Requirements 82

8 Design Life and Warranty Minimum Requirements 82

9 Maintenance Strategy Development 82

9.1 Failure Modes, Effects and Criticality Analysis (FMECA) 82

9.2 Recommendations for General Inspection 83

9.3 Equipment Repair and Replacement Strategy 83

Abbreviations

The following Abbreviations are the complete list for all documents under MACS/MMS

Abbreviations for system names:

BMS: Bridge Management System

CS: Communication System (internally/externally communication) CSP: Computer Simulation and Prediction

EDMS: Electronical Document Management System EMC: Electrical and Mechanical Control

ICMS: Information & Coordination Management System

MACS: Management and Control System

MMS: Management, Maintenance and Simulations SCADA: Supervisory Control and Data Acquisition WSMS: Work Site Management System

TMS Traffic Management System

Other abbreviations:

ADF Application Development Framework BI data Business Intelligence Data

CAD Computer Assisted Design COTS Commercial of the shelf software DBMS Database Management System EAP: Event Action Plan

ERP: Enterprise Resource Planning

FMECA: Failure Modes, Effects and Criticality Analysis GeoData Geographical Data

GIS Geographical Information System

GPS Global Positioning System

I&M: Inspection and Maintenance

IMAA. Inspection and Maintenance Activity Analysis JSON JavaScript Simple Object Notation

KML Keyhole Markup Language

KMZ Zipped KML file

LAN Local Area Network

LCC: Life Cycle Cost

MO: Maintenance Office

O&M: Operation and Maintenance OCC: Operation Control Centre OGC Open Geospatial Consortium RBI: Reliability Based Inspection

RCM: Reliability Centered Maintenance RDBMS Remote Database Management System RFI Rete Ferroviaria Italiana

SES Sensor Event Service

SOA Service Oriented Architecture SOA: Service Oriented Architecture SOAP Simple Object Access Protocol SOS Sensor Observation Service

UML Unified Modeling Language

WFS Web Feature Service

WFS-T Web Feature Service-Transactional WMS Web Map Service

1. Executive Summary

The Messina Bridge is a highly innovative bridge design for the world's longest span (3,300 m) to link Sicily with mainland Italy. The bridge is to be a suspension bridge formed from 4 main cables, a steel triple box girder, and steel towers with a height of 399 m. Not only are the bounds of current bridge experience being pushed to the limit with a structure that is significantly larger than the current world's longest span of 1,991 m (the Akashi Kaikyo bridge), the aerodynamic stability of the deck structure is reliant on the beneficial characteristics provided by the innovative triple deck box structure. Thus permanent monitoring and maintenance of the structure is desired to ensure that the structure is behaving as intended and remains safe to use. Furthermore a cluster of maintenance management systems for maintaining the structure in good condition for a long service life is provided.

The bridge is to be equipped with a Management and Control System (MACS), which enables the bridge operator to carry out the operation and maintenance of the bridge structure and installation in a safe and structured manner.

It is the vision that MACS is the overall framework around all the subsystems that services the construction, the operation and the maintenance of the bridge. MACS facilitate communication between SCADA and MMS subsystems, handles users and their rights in the system according to their role.

The Management and Control System will be a collection of controlling software applications with analysis and management modules and interface to the following system packages:

• Operational control (SCADA – described by Design Specifications - Mechanical and Electrical Works doc. No. CG1001-P-2S-D-P-IT-M4-C3-00-00-00-06-A)

• Management, Maintenance & Simulations (MMS, described by this document)

A detailed design for the MACS has been developed based on the technical specifications prepared by Stretto di Messina (2004) and based on the tender submission prepared by ATI Impregilo (2005). The MACS design has been updated and refined, improving the subsystems arrangement to include identified critical parameters, and taking into consideration changes in the design of the bridge and developments in IT technology.

The MACS will be a sophisticated redundant setup that will provide the owner and operator with important information concerning structural behaviour and safety as well as information that will assist with operation and maintenance planning.

The MACS will be a stand-alone system that, in function, operates independently of other operation systems of the MACS system.

This document is a design definition plan for the MACS. It cannot be used as a tender document. This design plan presents as outlined in the following.

1.1 Management and Control System (MACS)

In general it can be stated that the bridge, as a whole, can be viewed as a complex engineering project. This is also true for the IT systems that are to be developed for handling the construction, the operations and the maintenance of the bridge, before, during and after its construction.

The IT systems to be developed for supporting the construction, operation and maintenance of the Messina Strait Crossing will all need to communicate with each other. Therefore, a general architecture for data exchange between systems is a prerequisite before designing individual parts of the IT system.

The MACS will be the underlying software system which will control user access and rights in relation to system and data access. Additionally, the MACS will unite the different subsystem by defining a common communication protocol trough the use of a service layer.

The MACS will be the central module for the coordination, control and management of each sub- system.

The Management and Control system will be subdivided into two major clusters defined by:

• Operation & Control operated by the SCADA

- Traffic Management System (TMS)

- E&M Control and Monitoring (EMC)

- Structural Health Monitoring System (SHMS)

- Communication System (CS)

- Railway monitoring (RTMS).

• Management, Maintenance & Simulations (MMS, detailed in this report)

- Computing of Simulations and Predictions (CSP)

- Worksite Management System (WSMS)

- Bridge Maintenance Planning (BMS)

- Information and Coordination Management (ICMS) Electronic Document System Management (EDMS).

Figure 1.1.1 shows the overall system architecture for the MACS where MACS and MMS, which are described in this report, are highlighted.

Figure 1.1.1 Overall system architecture.

All long-term data saved within the MACS, will be located in a common database for each cluster; one for the SCADA system and another for the MMS system. The two databases for SCADA and MMS will have a common architecture to ensure compatibility for querying data. Due to this common data storage, a common protocol for sending and query data will be defined. The outline of the protocol for the MMS is explained in the figure below.

Figure 1.1.2 Long-term data storage process.

1.1.1 SCADA interface

The SCADA interface is described by Design Specifications - Mechanical and Electrical Works doc. No. CG1001-P-2S-D-P-IT-M4-C3-00-00-00-06-A.

1.1.2 MMS interface

The MMS interface will be a portal similar to web portals. On this portal the user will have an overview of important data and the possibility of pulling reports of preset conditions. It will also be possible to change the display layout of the data plots and tables shown on the portal. This will enable the operator and bridge management to pull standard reports from each subsystem and to have a possibility of viewing only relevant data by selecting which data from MMS is to be displayed. Similarly it will be possible to control the display layout for individual plots presented on the portal. The user will be, as an example among many, able to choose if the plot should contain

data plotted as wind vs. load and later change that to wind vs. traffic.

The MMS will interact with the subsystems through the common database architecture, where there will be one database for the MMS system and another for the SCADA system through the web services. Hereby the integrity of the subsystem databases will be ensured. The MMS will be able to generate standard reports, which in general terms will contain preset plots which will be updated for every time a report is generated. The text in these reports will be partly static or dynamic depending on the setup of the report. Furthermore, the MMS standard reports can be altered without changing the subsystem architecture and the subsystems will also have the possibility of exchanging data on a direct subsystem to subsystem basis.

The MMS subsystem and the data communication are presented in Figure 1.1.3

SCADA (SHMS)

(TMS)

Web portal

Plot of data

Standard Listing of

reports Events

Statistical data Links to reports

Service Lif e Models Damage Detection

Links to reports

Diffuse data,

information and contact to external authourities

Copy of Documents

Computing of simulations and predictions

(Spec. applications)

Work Site Management Information & Coordination EDMS System Management System Management System

MMS

(Spec. applications)

Bridge Maintenance System

Figure 1.1.3 The sub-systems will interact with each other directly and through the database in MMS.

1.2 General for the Systems

The above mentioned subsystems will interact with each other through two databases, with a common architecture, one in the SCADA and another in the MMS. Furthermore all certain subsystems will have the possibility of communicating directly. The Management and Control System (MACS and sub-modules) system software's will be building upon standard software with the necessary extensions to achieve the required extra functionalities if possible, otherwise custom designed software will be developed. The MMS will share the SCADA Man-Machine-Interface in form of a large Display Wall with the SCADA system. Both SCADA operators and MMS operators are allowed to use the large display in the Bridge Control Room.

All systems and subsystems working under the MMS will be integrated and able to exchange data by means of web services, as well as address and provide display of information on local screens and/or the common large Display Wall in the Bridge Control Room.

Figure 1.2.1 shows an illustrative setup of the control room video wall with local displays for displaying of data relevant for the TMS, Safety System and SCADA, where MMS will share the SCADA interface. All systems and subsystems are connected by Ethernet and use a common service layer for communication.

Figure 1.2.1 A simplified representation of a possible Video wall user interface

1.3 Pending development

The design in its present form will be further developed under the Progetto Esecutivo phase, where a further detailing of the individual subfunction will be made. For the case of the MACS a more in depth level of detailing will be made on the software architecture, such as user rights for groups, internal as external. For the MMS a more in detail description of available standard reports will be made. Defining plots and static text should be made in collaboration with the client and users of the system.

2 Introduction

This section gives at short introduction to the bridge and the individual systems which are relevant for the report.

MACS: Management and Control System SCADA: Supervisory Control and Data Acquisition

MMS: Management, Maintenance and Simulations

2.1 General

The Messina Strait Bridge will span the Messina Strait between Calabria on the Italian mainland and the island of Sicily and will provide the first fixed link between Italy and Sicily. The suspension bridge crossing comprises a 3,300 m main span, which will be longest in the world when constructed.

The bridge carries four marked vehicle lanes, two emergency lanes and two rail lines. The bridge superstructure comprises three separate orthotropic deck steel box girders, one for each of the Sicily and Italy bound roadways and one for the railway. The three box girders are connected by transverse steel box cross girders spaced at 30 m. The superstructure is supported by pairs of hanger cables connected to each cross beam end. The hangers are connected to pairs of main cables on each side of the bridge (four main cables). The main cables are anchored at each bridge end in massive reinforced concrete anchor blocks. The main cables are supported by two steel main towers, each with a height of 399 m above mean sea level. The main towers are founded on reinforced and post-tensioned concrete footings, which are supported on underlying rock formations.

In the current Progetto Definitivo project phase, the tender design is further developed in preparation for the subsequent Progetto Esecutivo phase.

2.2 MACS

The bridge is to be equipped with a Management and Control System (MACS), which enables the bridge operator to carry out the operation, maintenance and installation of the bridge in a safe and structured manner.

The MACS is subdivided in to a SCADA and MMS part where SCADA is described by the E&M

design basis and MMS is described in section 3.6.3 of the present report. Figure 2.2.1 shows the overall system architecture for MACS.

Figure 2.2.1 Overall system architecture for MACS.

2.2.1 SCADA

The SCADA interface is described by Design Specifications - Mechanical and Electrical Works doc. No. CG1001-P-2S-D-P-IT-M4-C3-00-00-00-06-A.

2.2.2 The description of the SCADA system is found in the E&M design basis,MMS

In general MACS is the overall architecture of the whole system whereas the Management, Maintenance & Simulations (MMS) is the portal as an interface to the MACS and the subsystem, where historical data and reports are available. When it comes to handling of daily analysis of data it will be the individual subsystem under the MACS which will handle this task. The result of this analysis will then be available to the MMS unless otherwise stated. The MMS system software's will be building upon standard software with the necessary extensions to achieve the required extra functionalities if possible otherwise it will have to be developed if necessary. The MMS will share the SCADA Man-Machine-Interface in form of a large Display Wall with the SCADA system. Both SCADA operators and MMS operators are allowed to use the large display wall in the bridge OCC. In general local data displays on all workstations will have possibility of being presented on the large display wall in the bridge OCC.

The MMS it self will be a data portal enabling the operator and bridge management to display data from the entire system in forms of plots, tables and standard reports. For this matter the MMS should be able to display data from other system, either data isolated to one system, or data mixed from different systems.

The MMS subsystem and the data communication are presented in Figure 2.2.2

SCADA (SHMS)

(TMS)

Web portal

Plot of data

Standard Listing of

reports Events

Statistical data Links to reports

Service Lif e Models Damage Detection

Links to reports

Diffuse data,

information and contact to external authourities

Copy of Documents

Computing of simulations and predictions

(Spec. applications)

Work Site Management Information & Coordination EDMS System Management System Management System

MMS

(Spec. applications)

Bridge Maintenance System

Figure 2.2.2 The subsystems will interact with each other through databases in the MMS and the SCADA.

3 MACS Main Module

The following sections describe the overall architecture on MACS.

3.1 General architecture of MACS

The Operation & Control Centre (OCC) and Maintenance Office (MO) will be the central module for the coordination, control and management of each subsystem.

The Management and Control system will be subdivided into two major clusters defined by

1) Operation & Control operated by the SCADA and

2) Management, Maintenance & Simulations (MMS) operated by customized application software and customized ERP solutions.

3.1.1 System layout

The management and control system will be a collection of controlling software applications with analysis and management modules and interface to the following system packages:

• Monitoring (SCADA – described by the E&M design basis)

- Traffic Management System (TMS)

- E&M Control and Monitoring (EMC)

- Structural Health Monitoring System (SHMS)

- Communication System (CS)

- Railway monitoring (RTMS).

• Management, Maintenance & Simulations(MMS)

- Computing of Simulations and Predictions (CSP)

- Worksite Management System (WSMS)

- Bridge Maintenance Planning (BMS)

- Information and Coordination Management (ICMS)

- Electronic Document System Management (EDMS).

The main basis documents are:

• Design report - Structural Health Monitoring System (SHMS), doc. no. CG1000-P-2S-D-P-IT-M3-SM-00-00-00-01-B

• Work Site Management System (WSMS), doc. no. CG1000-P-2S-D-P-IT-M4-C3-00-00-00-03-B

• Bridge Management System (BMS), doc. no. CG1000-P-2S-D-P-IT-M4-C3-00-00-00-04-B

• Information and Coordination Man. System (ICMS), doc. no. CG1000-P-2S-D-P-IT-M4-C3-00-00-00-05-B

• Electronic Data Management System (EDMS), doc. no. CG1000-P-WV-D-P-IT-M4-C3-00-00-00-01-B

• Computing of Simulations and Predictions (CSP), doc. no. CG1000-P-1W-D-P-IT-M4-C3-00-00-00-01-B

• Design Specifications - Mechanical and Electrical Works, doc. no. CG1001-P-2S-D-P-IT-M4-C3-00-00-00-06-B

3.2 Enterprise architecture

The management and control system may be defined as one system covering all functions as described in the requirement specification GCG.F.06.01 chapter 2.2. Functional areas listed are monitoring, surveillance, management, coordination, safety and information on the current and the estimated status of the Work.

All functional areas may initially be identified as separate areas that can be split into separate subsystems. However, in reality for the management and control system it is expected to become a set of separate subsystems that will share information and share responsibility. Thereby they cannot be implemented separated standalone subsystems.

Many workflows need only the use of one subsystem, whereas other workflows need several subsystems to complete the workflow to a successful conclusion. Thereby there is need for an architectural concept that allows both “local” as well as “global” workflows.

The challenge of building a system covering the vast functional areas of MACS while keeping construction and operational cost low, and enabling building the system in several steps as work progresses while keeping present functionality active, requires flexible manageable system architecture. An architecture where exchange of information between subsystems can be established without detailed knowledge of other subsystem. Additionally, opening for inter- operational subsystem connectivity without the dependency of subsystem having to use same

internal technology.

3.2.1 Enterprise service bus

Such a flexible system architecture construct is placed in the middleware infrastructure - the communication layer. One such architecture construct is the Enterprise service bus (ESB). It provides fundamental services for complex architectures via an event-driven and standards-based messaging engine (the service bus). An ESB can be based on recognized standards easing the establishment of communications with the different subsystems/applications. An ESB make use of service oriented architecture (SOA), and preferred all subsystems and applications interface a SOA (exposing web services in communication layer).

An ESB can in popular terms be displayed as in Errore. L'origine riferimento non è stata trovata..

Figure 3.2.1 Basic communication concept of ESB (source: xxxx://xxxxxxxxxx.xxx)

Technically the ESB can interface to/from several subsystems and applications build on different technologies. The communication concept of the ESB is that applications interface to web service and data services trough the ESB. The ESB ensure connectivity trough an enterprise messaging system, which allows subsystems and applications to exploit the value of messaging without knowledge of code-behind.

ESB is in this context considered a platform to realize a service-oriented architecture (SOA) on enterprise level. The ESB facilitate data/service/message transformation and routing for the SOA in a loose coupling and easy connection. The ESB can additionally facilitate subsystems that cannot fully comply with the rules of SOA. These non-SOA compliant subsystems are typically based on legacy components or are required separated from SOA because of high security requirements. For more information on SOA consult chapter 3.1.6

Based on industry practice and arguments listed above, ESB is selected as the major enterprise architecture construct for the management and control system (MACS).

3.2.2 Enterprise message model

The core of the ESB design is the Enterprise Message Model. Ideally, the ESB should be able to replace all direct contacts with the applications/subsystems on the bus, so that all communication takes place via the ESB. To achieve this objective, the ESB must encapsulate the functionality offered by its component applications in a meaningful way. This will occurs through the enterprise message model. The message model defines a standard set of messages that the ESB will both transmit and receive. When the ESB receives a message, it routes the message to the appropriate application/subsystem. Often, because that application/subsystem evolved without the same message-model, the ESB will have to transform the message into a format that the application can interpret. A software “adapter” fulfills the task of effecting these transformations. In Errore. L'origine riferimento non è stata trovata. is illustrated the Message Bus pattern. The basic pattern for enabling separate applications to work together.

Figure 3.2.2 Message Bus pattern - enables separate applications to work together

A second important pattern used in the ESB is the canonical data model. This pattern minimize dependencies when integrating applications that use different data structures.

Figure 3.2.3 Canonical data model pattern - minimize dependencies when integrating applications that use different data formats

The Enterprise Message Model set rules for use of the different pattern in application/subsystem context. The Enterprise Message Model is an important design tool when building the integration between applications/subsystems and shall always be updated to current use of the ESB, as an implementation of the Enterprise messaging system - the backbone in the middleware infrastructure.

3.2.3 Implementation of ESB

An ESB is constructed around the routing and transformation routines implementing the message bus and canonical data model pattern among other key SOA patterns. This is exemplified in fig 3.2.4Errore. L'origine riferimento non è stata trovata.. The routing and transformation routines are controlled by a set of configuration components. Among these components are a service registry, shared security component, a service management component and the service orchestration component that set the routines for a specific type of event or message in the routing and transformation. These components are controlled trough an ESB administration application.

The ESB is used by subsystems and their applications. Modern systems are typically prepared for a service oriented architecture by communicating with the ESB trough service interfaces. This without any specific adaption. Legacy and specialized subsystems as well as applications, require adapters to communicate through the ESB. An adapter provides the conversion of messages/information from/to the ESB. Some specialized applications will not benefit from working through the ESB. For example administration applications of a subsystem.

MMS

administrator application

MMS

Subsystem

WSMS

subsystem

GPS

Trackingsys

Adapter

Service

Adapter

ESB

Administration

Routing and transformation

Management

Service

Orchestration

interface

MMS

Legacy

WSMS

Application

WSMS

Application

Service

Adapter

Security

Service Registry (UDDI)

interface

ESB

Figure 3.2.4 Example of a ESB implementation of subsystem and applications that communicate using adapters and service interfaces in a service oriented architecture (SOA)

The described concept of ESB will form the design principle of information technology being implemented in the management and control system. The ESB is the prepared architecture construct for all intersystem and inter application communication.

There are several software vendors of ESB’s. The selection of the ESB vendor for the management and control system will be selected upon the completion of the architecture design.

The system and software design principles for the management and control system, will have to be designed according to the principles of Service Oriented Architecture (SOA). The SOA form the design rules for software architecture and systems architecture in the ESB. The following chapter describes the principles of the SOA in a context for the WSMS subsystem.

3.2.4 Service Oriented Architecture

First and foremost in the presented architectural strategy is the need for a decoupling of individual elements in the architecture. No individual component should be bound to another component by means that makes it difficult to reprogram or exchange one of these components for another component. This calls for standardized methods of communication between the individual components in the system, regardless of software platforms.

This will be achieved by employing a Service Oriented Architecture (SOA). In such a setup the development of services to expose data processing logic and data elements, using defined standards allows consuming clients to draw different types of functionality from different components and still retain the same method of communication.

Several such standards exist (some of which is mentioned here):

• SOAP (Simple Object Access Protocol)

• JSON (JavaScript Simple Object Notation)

• WMS (Web Mapping Services)

• WFS (Web Feature Service)

• WFS-T (Web Feature Service-Transactional)

• SOS (Sensor Observation Service)

• SES (Sensor Event Service)

The above listed standards are all employed in different types of web services.

The main point in using these service standards for communicating data and events between unrelated components is that all components will share the same standardized methods of communication. Components may be enhanced directly by consuming services already existing in other components. It ensures a loose coupling of services and components across different hard - and software platforms and thus mitigates the inherent complexities of constructing a complex system such as this.

The below figure illustrates the principles, seen from the perspective of the WSMS:

Figure 3.2.5 A schematic system overview from the perspective of the Work Site Management System (WSMS).

In the above example all communication occurs through web service interfaces employing the above mentioned standards. The WSMS draws data from the relevant components. At the same time the WSMS exposes several different services that may be consumed by several different client applications. If for instance there is a need for showing some form of map window in another components client all mapping data can be drawn via OGC (Open GIS Consortium) compliant services (WMS,WFS) thus reusing already compiled data stores.

In more detailed form this could be shown as follows:

cmp Interfaces diagram

«serviceInterface» Interfaces::WebServ ice: EDMS CAD

EDMS

«flow»

«serviceInterface»

Interfaces::WebServ ice: SAP

«flow»

«serviceInterface» Interfaces::WebServ ice: getTrackingInfo()

«flow»

WSMS

«flow»

«serviceInterface» Interfaces::Webserv ice: getVehicleDetails()

Sensor_type

«flow»

«serviceInterface»

Interfaces::Webserv ice:

Sensor data Sensor_type

«flow»

Env ironmental

«flow»

«serviceInterface»

Interfaces::WebServ ice: Env ironmental Sensor details

«serviceInterface»

Interfaces::GetReportData()

«flow»

MMS

«flow»

MACS

SAP AA/ETC

GPS tracking serv er

SAP MM

Primav era

Figure 3.2.6 Detailed components and interfaces diagram, again seen from the perspective of WSMS.

Here the individual parts of the interfaces are more detailed but still lack the definition of specific attributes of the data elements to be exchanged.

This level of detail can only be achieved through further analysis and is not relevant at this stage of the design process.

It should, however, be noted that the above sketched architecture is a principal architecture. This means that there is bound to be cases where it is much more practical that the individual components communicate directly. This, for instance might be the case where different subsystems are all running within the same SAP installation, where SAPis an integrated system for managing all business processes.

A comprehensive design of the services which should be developed for the different purposes will have to be formulated in Progetto Execotivo and its implementation managed by the overall project management or in a separate subproject that deals entirely with the formulation of component communication.

3.2.5 An overall architecture of the MACS

There exist many different architectural patterns for introducing a SOA like architecture (i.e. Subscriber-Publisher model) and it is too early in the design process to specify which such pattern should be used here. However, the communication of data elements between all components can be simplified as follows:

_cmp Connections

MACS

«flow»

WSMS

«flow»

SERVICE LAYERS

TMS

«flow»

ENVIRONMENTAL

SHMS

«flow»

CSP

«flow»

BMS

«flow»

ICMS

«flow»

SHES

«flow»

EMC

«flow»

S_ AP

«flow»

External Data

«flow»

SCADA

«flow»

PRIMAVERA

SAP AA/ETC

SAP MM

STR

PV2

EDMS

MMS

Figure 3.2.7 Schematic of the principle of communication between all components of the system. Notice the SAP environment where communication between components is direct. There may be several other components that will exchange data in this way.

As the above figure shows the IT systems to be developed for supporting the construction, operation and maintenance of the Messina Strait Crossing will need to communicate with each other. Therefore, a general architecture for data exchange between systems is a prerequisite before designing individual parts of the IT system. In this process it will be defined which data need to pass through the above mentioned service layer.

3.2.6 Software System Maintenance

In the design of the physical bridge great effort is taken to ensure ease of bridge maintenance during its estimated 100+ year's lifespan. In fact a major part of the software that is planned for the bridge is dealing with the planning of day to day maintenance of the bridge structure. Similar care should be taken to ensure that the software needed for operating and maintaining the bridge is maintainable. No software lasts forever and the bridge software systems will have to be maintained and, if necessary, exchanged with new software many times during the bridges lifespan. It is therefore of importance to formulate strategies that ensures sustainability.

The loose coupling of individual components as sketched above will greatly help in this perspective as parts can be changed or enhanced without the direct necessity to change any other component in the system.

There is also a need for having dedicated software components that will handle different IT related aspects of the System:

• Portfolio management

• IT Management System

• Service management

• Issue tracking

• Helpdesk

3.2.6.1 Software design principles

From a perspective of ease of software maintenance it is important to demand of any contractor that has to deliver specially developed software for the system (i.e. a web service) that certain principles are followed in this software development.

All specially developed software must be multi-tiered and object oriented in its nature whatever technological platform is used.

Figure 3.2.8 shows an example of a multi layered software architecture. The WSMS has here been

used as an example and the C# coding language shown in the figure below has been used for illustrative purposes. The language used in building the multi layered software architecture is not locked to C#.

Figure 3.2.8: Example of a multi layered software architecture developed using C#.

Multi layered software architecture illustrated above can be described as following:

1. The Data Layer that in this case consists of some relational database.

2. The Data Access Layer which is the segment of the software system where all the logic to read and write from some persistent storage is concentrated - often, but not necessarily, a relational database.

3. The Business Logic Layer which generally speaking contains the domain-specific model and logic that justify the building of the system.

4. Handling all communication between the Presentation Layer and the Business Logic Layer is a Service Layer. The service layers only role is to expose elements of the business layer thus making the degree off abstraction between any client and the logic and data of the application absolute. The service layer further gives the advantage that elements of the application can be easily exposed to any external clients (other "In Office" software or altogether external stakeholders (i.e. request for information from a national traffic service)).

5. The Presentation Layer which contains components for pre- and post-processing the action the user requested through the user interface.

The main reason for adopting such architecture is to provide clear abstraction and separation between elements of code. This gives several advantages among which maintenance of code base is very important. For instance, in the event that the DBMS is to be changed from SQL server to Oracle, the only two parts of the code that would need to be changed would be the Data Layer and the Data Access Layer, the rest of the code could ideally be left unchanged.

3.3 MACS Actors

The below diagram depicts the many different users of the coming MACS. Because the uses are described in more detail I the documents describing the different subsystems, most uses have been generalized into a generic MACS user.

uc Actors

I&M management

Security Unit

O&M Technological Systems

O&E Management

Equipment & Supply

Operational Control

Inspection (Routine)

MACS USER

Toll Unit

Inspection (non-routine)

Road Patrol

Maintenance (non-routine)

Caretaker units

GIS DATA

Generic external user

MACS administrator

ADMINISTRATOR

(from Actors)

Figure 3.3.1 Overview of the main users of MACS identified. Pls. note the generalization of all users but system administrators and external users into the MACS generic user. This is due to the general nature of the below use cases. More detailed use cases can be found in the documents

describing the individual subsystems handled by MACS (the building phase MACS is not included here (see WSMS report for details).

Actor

Description

Caretaker units

- Staff (1 day work with 24 hours on call):

- Team Leader 1, 2 and 3.

- Responsibilities:

- Routine maintenance on bridge (inc. cleaning)

- Reporting of needs for inspection and (non-routine) maintenance

Equipment & Supply

- Staff:

- Yard Manager:

- Responsibilities:

- Management of O&M equipment and spare parts

GIS DATA ADMINISTRATOR

The GIS Data Administrator is responsible for maintaining the integrity of the GIS database, maintaining meta data on geo-data, perform Import and export operations on data and prepare maps and reports for the other users of the system.

Generic external user

This user represent any outside agency or entity that wants to view or use data from MACS including but not necessarily limited to:

- Police forces

- Local road authorities

- Maritime authorities

- etc

I&M management

- Staff:

- Technical Manager

- Assistant Technical Manager (back-to-back)

- Data and Documentation Controller

- Responsibilities:

- Management of I&M work teams

- Planning of I&M

- Report to SdM Management

- Training of personnel

- Management of data and documentation

- Coordination with external authorities and agencies

- Coordination with O&E work plans and follow-up on caretaking.

- Participation in evaluation and revision of O&E Manual

Inspection (Routine)

- Staff:

- Team Leader 1,2 and 3

- Responsibilities:

- Planning of inspection activities

Inspection (non-routine)

- External consultant (assumed to be applied due to the amount of inspection work to be carried out or due to requirements on special competencies).

MACS USER

This is a generic Macs user who represents all users of MACS and anytime in the MACS lifespan

MACS administrator

This user is responsible for all administrative tasks around the MACS system. Configuration of views and management of users and their roles in MACS.

O&E Management

- Staff:

- Operational Manager

- Assistant Operation Manager (back-to-back)

- Safety & Educational Controller

- Responsibilities:

- Management of O&E work teams

- Planning of operation and handling of emergencies

- Report to SdM Management

- Safety logging, reporting & planning of safety induction, drills

- Coordination with external authorities and agencies

- Coordination with I&M work plans and follow-up on caretaking.

- Participation in evaluation and revision of O&E+I&M manuals

O&M Technological Systems

- Staff (day work/24 hours on call):

- System Manager

- Responsibilities:

- Routine adjustment of systems

- Manage maintenance and development of systems

- Administration of user help function

Operational Control

- Staff (3 shifts, 24 hours):

- Team Leader 1, 2, 3, 4 and 5.

- Responsibilities:

- Control and command of operation & emergency of the bridge

- Coordination of all parties with actions interfering with bridge

- Logging of the operation and emergencies.

Road Patrol

- Staff (3 shifts, 24 hours):

- Team Leader 1, 2, 3, 4 and 5.

- Responsibilities:

- Surveillance patrols on road

- Assistance and control on road to traffic

- Assistance and control on road to I&M works

Security Unit

- Staff (3 shifts, 24 hours):

- Team Leader 1, 2, 3, 4 and 5.

- Responsibilities:

- Patrol of fences, doors and xxxxx

- Follow-up on alarms and intruders

- Report on incidents

Toll Unit

- Staff (3 shifts, 24 hours):

- Team Leader 1, 2, 3, 4 and 5.

- Responsibilities:

- Operation of toll system

- Logging and reporting on operation

3.4 Main use case

This use case diagram basically shows the subdivision of MACS into two distint groups of functionality illustrated by XXXXX and MMS, both of whom are generalizations of a series of independently described subsystems.

Figure 3.4.1 Main use cases pls. note that the MMS & SCADA are generalizations of series of distinct subsystems

Use case

Description

UseCase : 2.1 MMS

Represents a generalization of several other use cases comprising the MMS part of MACS

UseCase : 2.1.1 WSMS

functionality

For further details see the WSMS Specification in document: CG1000-P-2S-D-P-IT-M4- C3-00-00-00-03_B_WSMS_ANX.docx

UseCase : 2.1.2 CSP functionality

For further details see the CSP specification in document: CG1000-P-1W-D-P-IT-M4-C3- 00-00-00-00_B_CSP_ANX.docx

UseCase : 2.1.3 BMS functionality

For further details see the BMS specification in document: CG1000-P-2S-D-P-IT-M4-C3- 00-00-00-00_B_BMS_ANX.doc

UseCase : 2.1.4 ICMS

functionality

For further details see ICMS details in document: CG1000-P-2S-D-P-IT-M4-C3-00-00-00- 05-B_ICMS_ANX.docx

UseCase : 2.1.5 EDMS

Functionality

For further details see the EDMS details in document: CG1000-P-WV-D-P-IT-M4-C3-00- 00-00-01_B_EDMS_ANX.docx

UseCase : 2.2 SCADA

Represents a generalisation of several other use cases comprising the SCADA part of MACS. Detailed in document Design Specifications - Mechanical and Electrical Works doc. No. CG1001-P-2S-D-P-IT-M4-C3-00-00-00-06.

UseCase : 2.2.1 TMS functionality

This usecase represents the functionality of Bridge TMS, Railway TMS and Network TMS See respective documents for further details. Detailed in document Design Specifications - Mechanical and Electrical Works doc. No. CG1001-P-2S-D-P-IT-M4-C3- 00-00-00-00.

UseCase : 2.2.2 CS- functionality

For further details see CS specification. Detailed in document Design Specifications - Mechanical and Electrical Works doc. No. CG1001-P-2S-D-P-IT-M4-C3-00-00-00-06-A.

UseCase : 2.2.3 SHMS-

functionality

For further details see SHMS documentation. Structural Health Monitoring System (SHMS), doc. no. CG1000-P-2S-D-P-IT-M3-SM-00-00-00-01

UseCase : 2.2.4 CMS functionality

This use case represents Network - and Bridge CMS functionality. Detailed in document Design Specifications - Mechanical and Electrical Works doc. No. CG1001-P-2S-D-P-IT- M4-C3-00-00-00-06.

UseCase : 2.3 View events and elements on map

The generic MACS user can choose to view different types of information in a Map Window. Amongst other the following should be displayed in a map:

• Current and expected state of the Bridge, with events' visualization (lanes' closures, traffic signals' state, maintenance sites, accidents, etc.)

• Current and expected state of vehicle traffic, with visualization of traffic parameters (flows, mean speed, congestion, queue and related length and expected waiting time)

• Current and expected railway traffic

• Current and expected Bridge structural information.

• Current and expected meteorological situation

• Current state of Sensors and other critical equipment

UseCase : 2.3.8 Log on

Logon is handled as single Sign on. When the user logs in she gets access to all parts of Macs to which she is authorized. The authorization is managed by the MACS admininstrator

3.5 View Events and elements on map

One of the main requirements in the specification of MACS is the inclusion of a possibility to view nearly all elements and their respective current or predicted state in a GIS system. The main functionality of many aspects of such a system has been described in the design of the Work Site Management System (WSMS) (pls. refer to document: CG1000-P-2S-D-P-IT-M4-C3-00-00-00- 03_B_WSMS_ANX.docx). However, when the WSMS is no longer needed as the bridge becomes operational a new definition of data layers to be included is needed and new functionality must be designed. Some data elements from the establishment and elaboration of WSMS will be continued from the construction (WSMS) to the Operational (MACS) phase.

Figure 3.5.1 Use case showing the MACS user and map views in schematic form

Use case

Description

UseCase : 2.3.1 View Current Sensor State (Events) on Map

Through the map interface the user can view the different Sensors as they are symbolized in the map as points where the point style differs according to type. When clicking a particular sensor the user can view the sensors current readings or chose to view sensor historical data. If a sensor event is triggered the sensor is highlighted in the map through a change of symbol (i.e. a larger blinking symbol appears). On click the user can inspect the nature of the event. If measured values fall below predefined values the sensor is again represented as before (trigger/detrigger).

UseCase : 2.3.2 View current and expected trafic data

The user can watch current traffic load via a thematic representation of each involved road segment (i.e. road segments are coloured according to traffic load in a "Heat Map" scheme). If the user clicks a road segment the users gets information on current load and have the opportunity to query expected loads given time. Further, the user can click CCTV (Closed-circuit television) sensors and view current traffic in a pop up screen. If necessary advanced image recognition can provide the ability to track particular vehicles as they transverse the monitoring area. From the map individual CCTV sensor can be choosen for inclusion in an array of permanently visible CCTV feeds show as a mosaic in a separate area of the video wall screen.

UseCase : 2.3.3 View Rail traffic

The user can view a map where the location of trains is dynamically show as a train approaches passes and leaves the bridge monitoring area. The user can view the state of all rail signals etc. Clicking a train will show details about the train (train identification, weight, length, speed etc).

UseCase : 2.3.4 View bridge strutural conditions

The user can view present and/or predicted structural conditions by selecting distinct structural elements for which such data exist.

UseCase : 2.3.5 View weather conditions

Weather conditions will be shown as current local conditions as indicated by on site sensors. Further expected weather conditions can be shown as reported by relevant meteorological authorities. If these authioties expose their data as WMS-T (time based WMS) it will be possible to show metrological data on map (I.E. weather surveillance radar (WSR) showing precipitation).

UseCase : 2.3.6 View sensor and communication infrastructure state

The user can monitor the state of each sensor and of each distinct element in the communication network outside of the control facility itself. If an element "falls out" or otherwise indicates an unresponsive or other problematic condition the element is highlighted in the Map

UseCase : 2.3.7 Administrate User Access and views

External consultant (assumed to be applied due to the amount of inspection work to be carried out or due to requirements on special competencies).

UseCase : 2.3.8 Log on

Logon is handled as single Sign on. When the user logs in she gets access to all parts of Macs to which she is authorized. The authorization is managed by the MACS admininstrator

3.5.1 Storing and querying long-term data

All long-term data saved within the MACS, will be located in databases, one in the SCADA and another in the MMS system. The two databases for SCADA and MMS will have a common architecture to ensure compatibility for querying data. Due to this common data storage, a common protocol for sending and querying data will be defined. The outline of the protocol is explained for the MMS in the figure below.

Figure 3.5.2 Long-term data storage process.

In order to ensure that data is sent in the correct format to the common database, a task group

consisting of the developer of the database together with developer from all other system will dictate which format the different system has to deliver there data in. This means that all sub- systems will have a data conversion layer which translates the system-individual data in to a common format which can be received by the database service layer, which handles the incoming data and the querying of data from the different systems.

This system deepened data conversion layer will also be responsible for sending queries for data to the central databases and translate the queried data into the internal format of that particular system.

3.6 User interface

3.6.1 Common Control room User interfaces

The different user interface elements needed in a control room setup are quite complex. on the one hand users have a need to sit with standard pc clients and perform isolated tasks in management and control on the other hand there is a definite need for a "Heads Up" display of many different types of views, ranging from schematic representation of sensor placement and state to real time video feeds showing traffic situations. Several different client applications will be needed in order to serve MACS data and functionality to many different groups of users.

3.6.1.1 Control room video wall

In a control room, video walls are used to share large amounts of real time information among the operators, operators who must continuously monitor for events and make mission critical decisions according to their different responsibilities. The information to display will be a mix of many different windows with maps, live CCTV feeds, schematics and other live data acquisition feeds (SCADA).

This type of display utilizes a specially designed part of the control room were one wall is void of any disturbances and is located where no natural light sources can hit it for optimal viewing purposes. The video wall it self can consist of either a back projector setup or a LED multi screen setup. Advanced video controller hardware and software allows the display of many different desktops on the same screen. The configuration software allows an administrator to define which windows will be displayed on the wall and where these will be displayed.

A typical video wall infrastructure could look like the below simplified schema:

Figure 3.6.1 Schematic hw setup for a video wall

Central to this setup is the Video wall server. This is a specialized server type that can serve up to 64 distinct video signals to the display units. Depending on the amount of desktop displays that needs to be shown on the video wall more servers are added. the individual workstations are all installed with software that allows operators (according to role and rights) to modify the layout of the video wall. I.E. in the case of an incident that demands common attention between several operatives parts of the video wall can be dedicated this 'on the fly'.

Figure 3.6.2 A simplified representation of a possible Video wall layout

The above sketched video wall layout is not fixed in it's layout but can be configured on the fly according to the changing needs of control room operatives. Some elements however should be fixed in position. In the above case a schematic representation of the bridge, rail and road infrastructure is depicted. This simplified bridge representation is indented to provide the users a better overview of all the different parts of the bridge. Clicking a general area in the schema will display further details above.

In a further elaboration of the MACS design it will be necessary to precisely dimension the video wall in terms of discrete viewing unit.

3.6.2 SCADA Interface

The SCADA interface is described in detail by the E&M design basis, as stated above.

3.6.3 MMS Interface

A user would like weather data shown next to traffic data and BMS data where the traffic data is currently shown. But the current setup is that weather data is shown next to load data. The user would then choose to have traffic data shown in that part of the screen that holds the load data, and BMS data where load data is displayed.

In other words, the user will have the possibility of choosing which data are shown on the screen and in which location of the screen. An example of a screen setups are shown below. Here the screen is divided into 4 sections; 3 data plots consuming weather, load and traffic data and a data table on top of the screen Events Reports. Each section has the possibility of showing different data. The figures display setups described in the above example. The number of subdivisions of the screen is not limited to 4. In general the portal will have the same options for arranging windows as iGoogle has.

Figure 3.6.3 Screen setup 1. Figure 3.6.4 Screen setup 2.

Apart from controlling the display setup it should also be possible to control data for the plots in the individual plots located in the windows making up the display setup. The user should be able to choose if the plot should contain data plotted as wind vs. load and later change that to wind vs. traffic.

Apart from the plotting of data the MMS portal interface will contain the possibility of pulling different kind of reports from preset templates, which are described in section 3.9 in the present

report.

Figure 3.6.5 shows an example of an arbitrary portal layout.

Events:	Date incoming	End date
Stranded car	2013-03-23 12:17:20	YYYY-MM-DD HH:MM:SS
Hanger vibration alarm	2013-03-23 10:17:20	2013-03-23 10:19:55
Heavy transport to arrive	2013-01-23 12:30:25	2013-04-16 16:30:00

limit

4m/s

6m/s

8m/s

10m/s

12m/s

14m/s

Figure 3.6.5 Illustrative setup of MMS portal showing plots and tables.

3.7 Data Handling in MMS

The MMS will be able to pull historical data from databases for the SCADA system and for the MMS system including the WSMS, BMS, CSP, TMS, SHMS and ICMS local data storage if needed. Live data should be processed locally in the individual subprograms in order to minimize the risk of system breakdown. This means that live data from the individual subprograms will be pulled directly to the necessary screens when requested.

3.7.1 Use Case Diagrams

The following Unified Modeling Language (UML) use cases illustrates how users and systems interact with the MMS and how data are produced internally in the MMS.

Figure 3.7.1, seen below, shows the main Use Case for the MACS/MMS, where different sub-"use

cases" handles the following:

1. Setup Portal Layout: Setting up the portal to the users needs

• Window arrangement

• Number of windows

• Which data should be displayed

2. Display Data: Handles requests on data for display

• Gathers data and display it according to the specifications given in 1. Portal layout.

uc 0 MMS - MAIN USE CASE DIAGRAM

MMS

1. SETUP PORTAL LAYOUT

EXTERNAL USER

INTERNAL USER

2. DISPLAY DATA

EDMS

CSP

Figure 3.7.1 Main UML chart of MMS.

Figure 3.7.2, seen below, shows the sub Use Case defining the inner functions of the "1. Setup Portal Layout", which are:

1.1 Create New Window: Function for creating a new window for displaying data.

1.2 Move Window: Function for moving any window to a new position.

1.3 Define Info in Window: Function, which lets the user define the type of data to display in a given window.

uc 1 PORTAL LAYOUT MODULE

1 PORTAL LAYOUT MODULE

1.1 CREATE NEW WINDOW

INTERNAL USER

(from Actors)

EXTERNAL USER

(from Actors)

1.2 MOVE WINDOW

SCADA: SHMS

(from Actors)

1.3 DEFINE INFO IN WINDOW

EDMS

(from Actors)

SCADA: TMS

(from Actors)

ICMS

(from Actors)

Figure 3.7.2 Portal layout UML chart of MMS.

Figure 3.7.3, seen below, is showing how the sub Use Case 1.3 from "1. Setup Portal Layout" is subdivided in the following functions:

1.3.1 Set WindowTtype and Data Type: For plots, tables or non standard plots see section 3.8.1.2.

1.3.2 Display the Available Data: Display the available data based on the selected data, plot type and information (Channel data is filter so only data which are relevant to the user selection is display for selection)

1.3.3 Choose Data for Displaying: User choose which data to display.

uc 1.3 DEFINE INFO IN WINDOW MODULE

1.3 DEFINE INFO IN WINDOW MODULE

INTERNAL USER

(from Actors)

1.3.1 SET WINDOW TYPE AND DATA

TYPE

EXTERNAL USER

(from Actors)

1.3.2 DISPLAY THE AVAILABLE DATA

SCADA: SHMS

(from Actors)

EDMS

(from Actors)

1.3.3 CHOOSE DATA FOR DISPLAYING

SCADA: TMS

(from Actors)

ICMS

(from Actors)

Figure 3.7.3 Define info in portal window UML chart of MMS.

Figure 3.7.4, seen below, shows the top level Use Case for the "2. Display Data". This Use Case consists of the following functions:

2.1 SetupWwindow: Function, which sets up the window in respect to which type of dataare to be displayed: Tables, plots, wind rose, event location etc.

2.2 Get Requested Data: Request data, from relevant subsystem, chosen for display and sent the received data to the plot function.

2.3 Draw/Write Received Data: Function for drawing/writing/plotting data chosen for display.

uc 2 DISPLAY DATA MODULE

2 DISPLAY DATA MODULE

2.1 SETUP WINDOW

SCADA: SHMS

(from Actors)

2.2 GET REQUESTED DATA

EDMS

(from Actors)

2.3 DRAW/WRITE RECEIVED DATA

SCADA: TMS

(from Actors)

ICMS

(from Actors)

Figure 3.7.4 Display data UML chart of MMS.

3.7.2 External data

Events from outside the bridge region, which will have an impact on the bridge, will be handled by the Information and Coordination Man. System (ICMS) which is described in document, CG1000- P-2S-D-P-IT-M4-C3-00-00-00-05-B. The ICMS is equipped with a set of rules (O&E manual) for which subsystem to distribute the information onto. This could be train traffic, where an event at the RFI which will affect the bridge, should be sent to the MMS for redistribution to the appropriate user or subprogram.

3.7.3 Internal data

Internal data are data generated within the MACS and subsystems. All internal data will be provided by the MACS and stored in databases for the SCADA and the MMS with a common database architecture. The internal data will be used in various ways, which the below example illustrates.

3.7.3.1 User rights in relation to system access

All users with access to the MACS and its subsystems have to be given certain rights for handling data in relation to the work needed. A description of users rights with internal user an external access is given below, but in general the user rights management will be based on need for system access and groups such as engineers, accountants, maintenance workers, etc.

Internal access

An internal user will be able to pull reports on the current and expected/predicted state of the bridge. The data used for this reports will be provided by the SHMS (current, raw data) and the CSP (expected/predicted, processed data). The current and the expected/predicted data will be plotted in the same figure/plot together with preset limits in order to easily identify trends and potential problems (current state will be defined by the rate of database updating in the individual subprograms). The prerequisites to the limits mention in the previous section is that the designers of the individual bridge parts provides the load, stress, utilization or other relevant limits to the CSP system.

The user will also be able to generate reports containing historical data, such as last month bridge load or traffic condition during national holidays.

External access

It will be possible to have external access to the portal within the MACS system. The interface available to an external user will be defined by the MACS system administrator, which will set the level of access control in relation to access to data and modifying the personal portal layout. An external user with the same rights as an internal user will be able to show the same plots as mention in the above section on internal access.

3.7.3.2 Reports generated in MMS

The reports generated in the MMS will be based on preset templates, such as "Bridge load for the last day", where historical data from the SHMS will be used in calculating values such as the mean load and plot loads for a defined period. Similar templates will be available for the traffic, point ranking and other areas of interest which will be identified.

Every report generated by the MMS will be pushed to the EDMS for document tracking.

3.7.4 Data communication between MMS and CSP

The data communication between the MMS and the CSP will be one way. The data which will be transferred between the two systems are processed measuring data originating from the SHMS. As an example the MMS could ask for the last hour of load data on the main cable, including a prediction of the load within the next 10 min. The CSP will then calculate the load prediction and deliver the full data package (current and predicted data) to the MMS for plotting.

3.7.5 Data communication between MMS and BMS

BMS will deliver reports to the MMS. The BMS reports will in reality be saved in the EDMS database, from where the MMS will get it. BMS will also provide point ranking grades of bridge elements for use in the calculation of a new point ranking grade based on the current value from inspection and data measured by the SHMS. The new point ranking grade will be sent to the BMS accompanied by a report detailing calculation process on what base the CSP has used the data in the calculation. The new point ranking grade and the accompanied report will then be use in the BMS for further evaluation of the bridge elements in question.

3.7.6 Data communication between MMS and WSMS

The WSMS will deliver reports to the MMS. The WSMS reports will in reality be saved in the EDMS document database, which will be a partition on the MMS database, from where the MMS will obtain it. Furthermore the MMS will have access to the WSMS data for displaying GIS maps and information relating to these maps. This means that the MMS will be able to display maps showing the whereabouts, in relation to storage place, of chosen work site materials.

3.7.7 Data communication between MMS and ICMS

The data interface between the MMS and the ICMS provides a list published by the ICMS. The list will contain event headings describing the content of the event. These headings should be hyperlinks to at more in depth description of the event/information. The most resent information is listed but all the backlogs of information distributed with the ICMS system are available through the MMS interface.

An Example of such information could be that RFI called to inform the bridge operation room of a heavy freight train. The list should then show the time and date of the date logged in the ICMS

system together with the time of occurrence, here being the arrival of the train. The list should be sortable in respect to heading, log time and occurrence time.

Table 1 shows how the information could look like in the MMS portal. Here date incoming is the time where the operator logs the event, i.e. the time when the operator receives the information from RFI. End date is in this relation the occurrence time, meaning that the event is set to end at the time of arrival of the heavy freight train.

Table 1 Example of event table in MMS.

Events:	Date incoming	End date
Heavy freight train to arrive	2013-01-23 12:30:25	2013-04-16 16:30:00

3.7.8 Summary of MMS Interaction with Sub-Systems

The MMS will interact with the subsystem databases through the web services. Hereby the integrity of the subsystem databases will be ensured, the MMS standard reports can be altered without changing the subsystem architecture and the subsystems will be able to exchange data on a direct subsystem to subsystem basis. A simplified overview of the communication paths needed by the MMS is shown in the flow chart below.

Figure 3.7.5 Flow chart for needed communication paths in MMS.

3.8 Types of plots and tables in MMS

The following section deals with examples of plots and table available in the MMS.

3.8.1 Plots

The following section describes a general setup of the plots shown in MMS available to the user while reviewing data from the SHMS and other relevant sub-systems. The section does not talk about 3D plots, but these plots will be possible to generate just as the 2D plot present below, with an additional axis.

3.8.1.1 General setup of plots:

• The plot will be auto scaled but it should be possible to control the axis with slides as shown below. Xxx and min value of the sliders will update automatically with respect to the plots axis.

• Legends of the plots should also be displayed but have the options of switching them on and off.

• It should be possible to trace a point on a graph showing the x and y value. The option of copying theses x and y values should also be possible.

• It should be possible to define a seconded axis on the right of the plot for comparing two vectors such as displacement and temperature.

• The axis should have the option of linear scale, log scale, inverting, dB scale and rotating

±90°.

• It should be possible to select a graph and copy its values to the clipboard for further analysis.

• It will be possible to plot a trendline for a selected graph. The options of trendlines will consist of linear, polynomial, exponential, logarithmic, power and moving average line.

• The following zoom option will be available.

1 1: Box 2: Horizontal

3: Vertical 4: All

4 5: zoom out by mouse click

6: zoom in by mouse click

• For XY-plots by clicking the legend it will make it possible to choose between different types of data display. The options available are shown in Figure 3.8.1

Figure 3.8.1 Plot options.

Figure 3.8.2 shows a general setup for a XY-plot of four different data channels.

Figure 3.8.2 General setup for XY-plots.

The plots available on the screen in the MMS will be similar to ones shown in the reports but with

the current state plotted.

3.8.1.2 Non-standard XY-plot

The following section displays the non-standard XY-plots which are available in the MSS.

An example of current and historical data would be the real time wind direction plotted together with a trail of a set number of hours for spotting trends in the wind. The figure below illustrates an example of such a plot. The updating speed should be dynamic so the operator can choose an updating speed such as; real time, 10 min, 1 h or a time defined by the operator. This should be done in order to clean up the plot if the trail of data has been set to many hours. Limits of the wind speed should also be plotted so the operator can see if the wind speed is approaching this limit,

c.f. Figure 3.8.3.

limit

4m/s

6m/s

8m/s

10m/s

12m/s

14m/s

Figure 3.8.3 Wind rose showing a trail of wind speeds and direction, current situation (blue dot) and predicted situation (red dot). The red line is the limit wind speed.

Regarding events, a plot of the location and the number of events in one location is available, as illustrated in Figure 3.8.4(every dot represent a sensor location). This plot is thought as a help for location areas with high deterioration. The scaling of the dot size which is corresponding to the number of events is dynamic relative to the sensors of interest, meaning that the size of the dot at the sensor location is scaled according to the maximum and minimum number of events for the chosen sensors. Different colors of the dot can be used for sensors overlapping each other.

Figure 3.8.4 Accumulated events and location plot.

3.8.2 Example of Tables

Events from the different subsystems will be displayed in a table showing the Event name and Date/time of registration and Date/time for the conclusion of the event. An example of such a table is illustrated in Table 2. In the case of SHMS alarms the "End time" of the event will happen at the time the SCADA/SHMS operator takes action on the event. The table will be sortable for all three columns and pressing the event name will pull up a window on the event detailing the event in greater detail, c.f. Table 3.

Table 2 Event table in MMS.

Events:	Date incoming	End date
Stranded car	2013-03-23 12:17:20	YYYY-MM-DD HH:MM:SS
Hanger vibration alarm	2013-03-23 10:17:20	2013-03-23 10:19:55
Heavy transport to arrive	2013-01-23 12:30:25	2013-04-16 16:30:00

Table 3 Detailing the event chosen from the main event table.

Events reports
Event category:	Stranded Car
Time of Event:	Date: 2013-03-23 Time: 12:17:20
Location:	At centre node
Status:	Assisting vehicle dispatched
End of event:	Date: YYYY-MM-DD Time: HH:MM:SS
Note:	Flat tier

For the standard reports within the MMS the listing will be subsystem wise, as shown in Table 4. By clicking on the system from which a report is wanted it is possible to choose from a preset number of reports topics from where the user can select the report, which is wanted, by choosing the relevant line from Table 5 to Table 8

Table 4 Standard reports main table. Table 5 Report sub-groups for SHMS.

Standard Reports

SHMS

BMS

CSP

TMS

WSMS

Standard Reports SHMS

Loads

Displacements

Fatigue

Events

Loads

Stress

Table 6 Reports/SHMS/Events

Table 7 …/Events/Alarms

Table 8 .../Alarms/Favorites

Standard Reports

SHMS: Events

Warnings

Alarms

Categories: Alarms

Favorites

Accelerometers

GPS

…

Favorites

Acc(1-2) and GPS(1-2)

Hangers

Towers

…

3.9 Types of plot for use in standard reports in MMS

The diagram shown in Figure 3.9.1 is an example on basic standard plots available within the MMS system. Sections 3.9.1 to 3.9.4 is detailing the information required by the CSP in order for the MMS to produced the plots. The number of standard plots is not fixed to the number shown in the chart below. If there is a need for more groups and subgroups then presented, the chart will be updated to reflect these needs.

The contents of the reports which will use the example of plots shown below are to be agreed on in the Progetto Esecutivo phase. A general report tools have to be agreed on in the Progetto Esecutivo phase in order to ensure that the newest technology will be used.

The limit case should be displayed on all plots in the reports. The limit will be specified by the designers.

Figure 3.9.1 Diagram of available standard reports in MMS.

3.9.1 Plots containing data from SHMS/CSP

This section gives a short description of different standard reports for data obtained from the SHMS and used in the CSP. The CSP calculations are linked to the SHMS data by making predictions based on the SHSM data. In general this means that every time a plot is generated with the SHMS data, the CSP prediction, if applied, will be a part of this plot and report. Showing predictions without the base data makes little sense so there will be no plots/reports based solely on the CSP predictions.

3.9.1.1 Loads

The total load on the bridge will be calculated from traffic load, wind load, temperature load and seismic load and plotted. Apart from the total load plot, the following sections list examples of other different load plots available in the MMS.

Traffic load

This plot could for example contain the recorded bridge load plotted against the traffic intensity on the bridge and the recorded bridge load plotted against time. The figure below shows examples on how such plots could look like. The period of time from which the data will be plotted is not fixed, but can be specified by the user requesting the report. The plots will be produced from data provided by the SHMS and the CSP. Examples of data plots and tables are given below. The data tables only illustrated the type of data needed for plotting and not the amount of data. For example the listing of temperature data means temperature data from all temperature sensors. Location/WBS relates to the individual sensors location and WBS number.

Time

Location/ WBS

Traffic [kg/m]

Load [%]

Expected load [%]

100

Load vs. traffic

Load region reserved for trains

Recorded load

Expected load load(only cars)

load(only trucks)

0 20 40 60 80 100 120

Traffic density [kg/m]

Load [%]

Figure 3.9.2 Illustrative plots of bridge load against traffic intensity and time.

Wind load

Examples of load plots in relation to wind will in general look more or less the same as the traffic plot apart from different data provided by the SHMS and the CSP and different limits. Examples of tables with data needed for plotting in the MMS system are given below.

Time

Location/ WBS

Wind speed [m/s]

Load on deck [%]

Expected Load on deck

[%]

Load on North Tower [%]

Expected Load on North Tower [%]

Load on South Tower [%]

Expected Load on South Tower [%]

3.9.1.2 Displacements

The following sections list the different displacement plots available in the MMS. A plot of expected displacements and the limit state should include measured displacements.

Expansion joint

These plots will contain information regarding the displacement of the expansion joint on both ends of the bridge. The plots will be produced from data provided by the SHMS and the CSP. Examples of tables with data needed for plotting in the MMS system are given below.

Time

Location/

Wind

Temperature

Traffic

Displacement,

WBS

speed [m/s]

[°C]

[%]

North joint [%]

South joint [%]

Towers

Plots regarding towers will contain information regarding the displacements of the towers, (direction in relation to sensors). These plots will be produced from data provided by the SHMS and the CSP. Examples of tables with data needed for plotting in the MMS system are given below.

Time

Location/ WBS

Wind speed [m/s]

Temperature [°C]

Traffic [%]

Displacement, North Tower [%]

Displacement

,South Tower [%]

Cables

These plots will contain information regarding displacements of the hangers and the main cables. The plots will be produced from data provided by the SHMS and the CSP. Examples of tables with data needed for plotting in the MMS system are given below.

Time

Location/ WBS

Wind speed [m/s]

Temperature [°C]

Traffic [%]

Displacement of hangers [m]

Displacement of main cable [m] (two types: static(GPS data) and dynamic(Acc data))

Displacements calculated from the acceleration data will be based on the dominating frequency as shown on the figure below.

Cable displacement based on dominant mode

180

Estimated cable disp.

Acceleration point

160

140

120

100

-2 -1 0 1 2

Displacement - [m]

Cable lenght - [m]

Figure 3.9.3 Illustrative plots of hanger displacement, based on dominating frequency, against cable length.

Deck

Displacement

These plots will contain information regarding the displacement of the deck. The plots will be produced from data provided by the SHMS and the CSP. Examples of tables with data needed for plotting in the MMS system are given below.

Time

Location/ WBS

Wind speed [m/s]

Temperature [°C]

Traffic [%]

Displacement of the deck [m]

Comfort

These plots will contain information regarding the calculated comfort of people using the bridge. The plots will be produced from data provided by the SHMS and the CSP. Examples of tables with

data needed for plotting in the MMS system are given below.

Time

Location/ WBS

Frequency [Hz]

Acceleration of the deck [m/s^2]

Comfort level

25-06-2013

13:32:46

13:22:46

25-06-2013

13:12:46

25-06-2013

13:42:46

25-06-2013

Comfort limit

Peak Acceleration

Frequency [Hz]

Figure 3.9.4 Illustrative plots showing comfort level on the bridge.

3.9.1.3 Fatigue

Under the fatigue plot it is possible to choose from two areas of information; information related to the cables and to the deck, respectively. Each of the two areas of information can be subdivided into bridge subcomponents.

Cables

These plots will contain information regarding the fatigue of the cables. The plots will be produced from data provided by the SHMS and the CSP. Examples of tables with data needed for plotting in the MMS system are given below.

Time

Location/ WBS

Wind speed [m/s]

Temperature [°C]

Traffic [%]

Fatigue of the cables [%]

Time used

Time left

Steel deck

These plots will contain information regarding the fatigue of the steel deck. The plots will be produced from data provided by the SHMS and the CSP. Examples of tables with data needed for plotting in the MMS system are given below.

Time

location

Wind speed [m/s]

Wind direction [°]

Temperature [°C]

Traffic [%]

Fatigue of the steel deck [%]

Time used

Time left

An example of a plot regarding fatigue could contain time used against time left calculated from the recorded fatigue measurements. Here it would be possible to estimate and present a prediction based on long term data, medium term data or short term data. The plot shown below is only an illustrative example with fictive values.

Figure 3.9.5 Illustrative plots showing fatigue level on the bridge.

3.9.1.4 Events

The following sections list examples of relevant events plots available in the MMS.

WARNINGS

These plots will contain information regarding warnings received from all kinds of events. The plots will be produced from data provided by the ICMS and the CSP. Examples of tables with data needed for plotting in the MMS system are given below.

Time

Location/ WBS

Event (Load) Duration

Event (Load)

Event (Displacement) Duration

Event (Displacement)

Location of event

It should be possible to filter the events such that only one warning for one event will be shown within a certain time span. An example could be that a warning is triggered 50 times for one sensor within 20 min. This is in reality one warning so the filter should be able to look at the time between warnings in order to group the 50 warnings in to one warning. Thus the filter should have a setting for delta time between warnings.

An event will be presented as a dot on the event location plot. The size of a dot will correspond to the number of events. It will be possible to zoom in the event location plot in order to get a better resolution in areas with many events.

A plot similar to the above mentioned will be available where the duration of the events is plotted instead of the number of events, meaning that it should be possible to identify warnings and alarms which take place over a long duration of time.

Figure 3.9.6 Events recorded by the SHMS on the bridge.

It will also be possible to get at bar plot of the different sensors showing the number of events which have been recorded for each of them. An example including number of events for four sensors is shown below.

Figure 3.9.7 Events (warnings) recorded by each sensor.

Alarms

These plots will contain information regarding alarms received from all kinds of events. The plots

will be produced from data provided by the ICMS and the CSP. Examples of tables with data needed for plotting in the MMS system are given below.

Time

Location/ WBS

Event (Load) Duration

Event (Load)

Event (Displacement) Duration

Event (Displacement)

Location of event

It should be possible to filter the events such that only one alarm for one event will be shown within a certain time span. An example would be that an alarm is triggered 50 times for one sensor within 20 min. This is in reality one alarm so the filter should be able to look at the time between alarms in order to group the 50 alarms in to one alarm. Thus the filter should have a setting for delta time between alarms.

The plots available will be similar to the plots shown under warnings above. Color coding or texturing of the dots will make it possible to difference between warnings and alarms.

3.9.1.5 Stress

The following sections list examples of plots based on the measured stress from the SHMS, which are made available to the MMS.

Towers

These plots will contain information regarding the stress in the towers due to traffic and wind. The plots will be produced from data provided by the SHMS and the CSP. Examples of tables with data needed for plotting in the MMS system are given below.

Time

Location/ WBS

Wind speed [m/s]

Wind direction [°]

Temperature [%]

Traffic [%]

Tower stress [%]

Deck

These plots will contain information regarding the stress in the deck due to traffic and wind. The plots will be produced from data provided by the SHMS and the CSP. Examples of tables with data needed for plotting in the MMS system are given below.

Time

Location/ WBS

Wind speed [m/s]

Wind direction [°]

Temperature [%]

Traffic [%]

Deck stress [MPa]

Hangers

These plots will contain information regarding the stress in the hangers due to traffic and wind. The plots will be produced from data provided by the SHMS and the CSP. Examples of tables with data needed for plotting in the MMS system are given below.

Time

Location/ WBS

Wind speed [m/s]

Wind direction [°]

Temperature [%]

Traffic [%]

Hanger stress [%]

Main cable

These plots will contain information regarding the stress in the main cables due to traffic and wind. The plots will be produced from data provided by the SHMS and the CSP. Examples of tables with data needed for plotting in the MMS system are given below.

Time

Location/ WBS

Wind speed [m/s]

Wind direction [°]

Temperature [%]

Traffic [%]

Main cable stress [%]

3.9.1.6 Weather

By use of data from the well established weather institute, a weather forecast plot will be available. The duration of the weather forecast should not be fixed to only one duration, however, it should be at least set in multiple fix intervals making it possible to choose different duration from 1 h to 5 days or more.

Wind load

Data from the well established weather institute will be used in plotting the expected load and the predicted load based on the predicted wind speed. The plot will be similar to the plot under the SHMS, see Design report - Structural Health Monitoring System (SHMS), doc. no. CG1000-P-2S- D-P-IT-M3-SM-00-00-00-01-A. The plot will be produced from data provide by the SHMS and the CSP. An example of data tables is given below.

		Current
Time	Location/ WBS	Wind speed [m/s]	Load on deck [%]	Load on North Tower [%]	Load on South Tower [%]
		Predicted
Time	Location/ WBS	Wind speed [m/s]	Load on deck [%]	Load on North Tower [%]	Load on South Tower [%]

3.9.1.7 Traffic

The traffic predictions are produced by the CSP based on traffic data available from the SHMS. The following predictions are produced:

• total vehicle traffic load on the bridge

• total rail traffic load on the bridge

• total traffic (vehicle and rail) load on the bridge

• density of vehicle traffic on the bridge

• vehicle traffic flow on the bridge

• vehicle traffic flow on the network

120

100

Predicted traffic for the day

Actual traffic

Normal traffic for the day Limit

-20

Traffic flow [%]

Figure 3.9.8 shows an example plot of data shown in the MMS.

Figure 3.9.8 Example plot of traffic prediction for one day.

3.9.2 Plots containing data from TMS

For the plots containing traffic data coming from the TMS will be accessible through reports generated by the TMS system.

3.9.3 Plots containing data from WSMS

Work Site Management plots are based on data from the WSMS subsystem and could contain following:

• Work progress monitoring

• Materials location and tracking

• Construction equipment tracking

• Transportation tracking

• Environmental monitoring

3.9.4 Plots containing data from BMS

For plots from the Bridge Management System, data and reports from the BMS subsystem will be used.

Plots using BMS data could for an example show a point ranking grade for bridge elements over time.

Plots available through BMS reports will depend on the type of reports and will include facilities for generation of I&M reports including following:

• Templates for the various report types:

- Principal Inspection report

- Special Inspection report

- Rehabilitation works report

- Supervision report

• Automatic implementation of data as stored in the BMS database

For example capture of defect data from the database and incorporation into the inspection report.

4 List of requirements

The following is a list of requirements gathered through:

• The technical specification from Stretto di Messina

• The Contractors tender design

ID		Requirement	Requirement Reference
1.	Monitoring of systems and sub-systems		A log will be kept of the up and down time of the various system and sub-systems. This feature is part of the Enterprise service bus

2.	Information on the bridges current and expected state	To the Bridge's concessionaire	Information would be given by Person in SCADA , SHMS, CSP and the portal described under the within this document
3.		To RFI	Person in SCADA or and direct link to the web portal described under MMS within this document, section 3.4.3.1
4.		To the administrators of the interconnected road/railway systems	Person in SCADA or and direct link to the web portal described under MMS within this document, section 3.4.3.1
5.		To the administrators of other transportation systems	Person in SCADA or and direct link to the web portal described under MMS within this document, section 3.4.3.1
6.		To police and other institutional Agencies	Person in SCADA or and direct link to the web portal described under MMS within this document, section 3.4.3.1
7.	The system shall operate with continuity, in every physical or environmental condition, since the bridge and the system's components will be subjected to weather, seismic-tectonic and human phenomena.		See, component no. 19
8.	Produce reports on accidents, on events, on their causes and related information, and, as a general rule, on all that will be monitored and managed by the system		MMS will have a reporting tool for handling all the listed cases, see section 3.4.3.2, 3.5.2 and section 3.6. The individual content of the reports has not been specify because it will be

		based on the chosen reporting tool. Individual sub system might also have a locally option for making a report relating to the area of interest for that particular sub system.
9.	Diffuse information, actual and foreseen, to users, concerning both the state and use of the Bridge, eventual prescriptions, proscriptions and whatever else is useful for a safe and conscious use of the Bridge	ICMS will be handling the information sharing to external and internal user by use of sms and other wireless means such as email and etc., where as MMS will handle the information sharing through the portal described under the within this document.
10.	Communicate information, actual and foreseen, to all external organizations involved in the Bridge's operative management, as regards to use and state, to eventual prescriptions, proscriptions, maintenance sites, events and related consequences	ICMS will be handling the information sharing to external and internal user by use of sms and other wireless means such as email and etc., where as MMS will handle the information sharing through the portal described under the within this document.
11.	All information collected and elaborated by the system shall be verifiable by the operator through adequate interfaces. Collected information shall be recorded so as to build a historical data base of the Bridge.	Whereas the MMS displays information generated by various sub system all alarms will be push to the SCADA operator through the portal in order for this person to make a judgment on the alarm with the help of the

		ICMS. The ICMS is linked to the O&E manual so all events should have a predefined sequence of operation in order to handle an ongoing event or predicted event.
12.	All that will be observed and controlled by the system shall be recorded, by means of adequate log-mechanisms, with the purpose of enabling, if required, to go back to the conditions in which certain phenomena occurred.	All data will be saved in the databases in MACS as stated in all sub systems.
13.	The system will visualize in real time all collected information, in the most suitable way for an immediate and efficient representation (graphs, tables, videos), and will allow the research, visualization and elaboration related to user specified periods.	SHMS data for showing information relating to the bridge will be available to the MMS through direct link and the databases, section 3.6.1
14.	Periodic tests will be automatically activated by the system in order to check the efficiency of all measurement and data transmission equipments. A manual start of the test should also be possible.	The feature will be and integrated part of the Enterprise architecture
15.	An interface for alarms, breakdowns, accidents signaling shall be provided to the operator too.	all alarms will be push to the SCADA operator through the portal in order for this person to make a judgment on the alarm with the help of the ICMS.
16.	The system will visualize in real time all information related to the events, in the most appropriate way to obtain an immediate and efficient representation (maps, tables, videos), and will grant the research, visualization and necessary elaboration related to user-specified periods or events.	By the used of ICMS event data the CSP can deliver plot to the MMS which display the event location and if chosen the number of similar events. A link to the 2 nearest video cameras will also be available, see

section 3.5.2.1

17.

The system shall provide for the exchange of information with the RFI management systems and with other analogous systems used by the manager of the interconnected roadways/highways or by the managers of other transportation systems.

The information exchange shall happen in DATEX or according to the standard in use when interconnection specifications are being written.

This feature is part of the Enterprise service bus

18.

The system's users will be at least:

• The operators of the control room, responsible for monitoring and controlling the Bridge, some of whom will act as dispatchers in TETRA coordination stations (TETRA dispatchers)

• The traffic managers, who put into practice the traffic

management strategies on the Bridge

• The traffic planners, who plan and evaluate traffic management strategies for the Bridge

• The emergencies' managers, who put into practice emergencies management strategies

• The emergencies' planners, who plan and evaluate emergencies management strategies

• The maintenance technicians, who check the functioning of the management and control system and of composing sub-systems by analyzing the correctness of the information exchange through connection via TETRA radio mobile net.

• The maintenance planners, who plan and evaluate

MACS:

A central user database will be constructed under MACS which will handle the user rights for the different users.

	the maintenance strategies of the Bridge, as well as the impact of the site's typology, localization, and times on the safety of circulation and of the Bridge in its whole • The information managers, who define the rules for information diffusion (times, modes, kind of information, etc)
19.	The data collected and elaborated shall be visualized both in	MMs will be able to
	the form of reports (tables, graphs) and on a geo-referenced	display the requested
	map. All critical data and all data useful or essential for the	information by use of
	evaluation of the Bridge's state shall be visualized, and	SHMS, CSP, TMS and
	different scenarios shall be represented as well (of-the-	ICME data, see section
	moment, expected, "historical") through a GIS interface,	3.5 and 3.6
	among which: 1. The of-the-moment and expected state of the Bridge, with events' visualization (lanes' closures, traffic signals' state, maintenance sites, accidents, etc.) 2. The of-the-moment and expected state of vehicle traffic, with visualization of traffic parameters (flows, mean speed, congestion, queue and related length and expected waiting time) 3. The of-the-moment and expected railway traffic (coaches localization) 4. The of-the-moment and expected state of the structure 5. The of-the-moment and expected weather conditions 6. The monitoring system's state (sensors and equipments, systems for accidents' detection, etc.) 7. The state of the data transmission infrastructure 8. The monitoring system's state
20.	The visualization on a geo-referenced map shall represent the Bridge's state (of-the-moment and expected) through the	See Section 3.5

localization and representation of systems, equipments, phenomena and events, to which all the useful and necessary information will be associated

5 Documentation Minimum Requirements

The following documentation shall be provided with the CSP:

• Operation manual

• Maintenance manual

• System architecture guide

• Software source code guide for special developed software

• Printed software source code for special developed software

• Troubleshooting guide

• Event diagnosis guide

• Quality Control documents

Three copies of each document shall be provided. Documents shall be provided in both Italian and English.

It is recommended that the bridge owner or operator arranges for an additional manual to be created following 3 years of operation of the bridge, reporting the typical behaviour of the System.

5.1.1 Operation Manual

The operation manual shall describe the complete operation interface of the System.

5.1.2 Maintenance Manual

The maintenance manual shall set-out all of the maintenance activities required to keep the System functional for 10 years. Maintenance activities shall be divided into the following categories:

• regular general maintenance

• event-specific maintenance

The maintenance manual shall describe the maintenance activities and time intervals that are required, how the maintenance activities shall be performed, what tools are required, and what spare parts required. The maintenance manual shall also present inspection proforma.

The maintenance manual shall also identify maintenance actions required during events that require maintenance activities e.g. inspection of equipment.

5.1.3 System Architecture Guide

The system architecture guide shall present the complete layout of the hardware of the system. It shall also provide photographs and identification of all terminals and hardware.

5.1.4 Software Source Code Guide

The guide to the non commercial available software source code shall present sufficient detail of the software source code for a competent software engineer to understand and modify the system.

5.1.5 Printed software source code

Printed of non commercial available software source code, including a guide to the source code, shall be provided for the SHMS Data Conversion, Delivery, and Query Layer.

5.1.6 Troubleshooting Guide

The troubleshooting guide shall present actions to be taken to resolve basic problems with the system including: system block, system shutdown, data channel data loss, etc.

5.1.7 Event Diagnosis Guide

The event diagnosis guide shall be prepared by the System designer and shall present anticipated causes of registered events as well as advice on subsequent actions to be taken. The event diagnosis guide shall be developed around the matrix of anticipated outcomes for automatic assessment of Bridge Event Warnings.

5.1.8 Quality Control Documents

The quality control documents shall be presented in an organised file or document with reference index..

6 Quality Control Minimum Requirements

6.1 Sub-contractor Selection

Candidates for sub-contracts shall submit evidence that they operate under an approved quality system (e.g. ISO 9001). Candidates shall submit evidence of experience with Management and Information control systems and evidence of successful high quality installations, which shall be as a minimum in the form of client references, CVs of experience, and system demonstrations. The assessment of sub-contract bids shall include an assessment of experience and quality.

6.2 Testing

Testing of sensors, cabling, hardware, software and data-processing routines shall be required at key stages within the project. Testing shall include testing of function as well as testing of accuracy. All testing shall be accompanied by quality documentation. All testing shall be agreed with the designer.

6.2.1 Certificates

All equipment, including testing equipment, shall be provided with operation certificates and warranty certificates. All sensors, and testing equipment (if appropriate), shall be provided with calibration certificates.

6.2.2 Factory Acceptance Tests

All data processing and manipulation routines shall be independently tested and approved by the designer prior to delivery to site.

All software shall be independently tested and approved by the designer prior to delivery to site. The testing process shall include a full simulation of the operation of the entire network, including signal and fault testing.

All components of the system shall be independently tested for operation and approved by the designer before delivery for installation. Components provided with certification from established European accreditation bodies (e.g. UKAS) may be exempt from testing subject to the approval of the designer.

6.2.3 Site Acceptance Tests

Immediately following installation, all components of the System, including displays, shall be tested for operation and approved by the designer before delivery of the relevant structural component to site.

Before the bridge is opened to the public, and following completion of the System installation, the System shall be proof-tested. This proof-test shall demonstrate that the System runs without the development of errors. The test shall consist of continuous operation of the System, including the performing of designed operation tasks. The test shall be performed for a minimum of 30 continuous days. When an error is discovered it shall be corrected immediately. The test shall demonstrate error-free operation for a minimum of 15 continuous days. The duration of the test shall be extended if required to demonstrate this. The sub-contractor shall be required to perform the proof-test with sufficient allowance to ensure that the System will be certified prior to the opening of the bridge.

6.3 Repairs

All defects identified during testing shall be repaired. Components affected by the defects shall be tested following repair. The procedure shall be repeated until the function of the system is demonstrated to be in accordance with the monitoring requirements, and approval is provided by the designer. All defects identified and repaired shall be formally recorded as part of the quality control documents.

6.4 Labelling and Identification

All hardware shall be uniquely labelled, and shall be linked to the appropriate element references as will be described in the Inspection and Maintenance Manual for the bridge. Cables shall be labelled at each end and at regular intervals. All labels shall be applied to the equipment before installation. All labelling shall be subject to the approval of the designer. Where appropriate and

feasible, sensor axis alignment shall be marked onto the adjacent steelwork. Labels and markings shall be permanent, but shall not damage the structure or protective system (e.g. paint system or similar).

All hardware shall be identified in the System Architecture Guide. Photographs shall be presented in the System Architecture Guide recording the position of each component of hardware, including the position and orientation of each sensor. Photographs shall be annotated with the appropriate labelling. The photographs shall be of sufficient quality and layout that it shall be possible to verify changes since installation.

7 Copyright Minimum Requirements

The bridge owner shall share all copyrights to source code of all customised and tailor-made software, and documentation.

8 Design Life and Warranty Minimum Requirements

The design life of the System shall be 10 years. The System shall function for 10 years provided maintenance activities detailed in the maintenance manual are carried out. During the 10 year period a rolling system update plan shall be maintained including complete system update at end of service life.

The minimum warranty on all components of the System shall be 1 year, subject to the exclusions listed below.

The warranty for all components of the System shall be 5 years provided that the SHMS is maintained in accordance with the maintenance manual.

9 Maintenance Strategy Development

9.1 Failure Modes, Effects and Criticality Analysis (FMECA)

A failure modes, effects and criticality analysis (FMECA) shall be performed on the System. This analysis shall consider:

• the function of the system in general

• the function of the system in delivering the monitoring requirements

• the components

• the importance of components within the context of the importance of the monitoring requirements, including the importance of sensors to the operation and maintenance of the bridge e.g. identification of high priority safety critical sensors

The FMECA shall drive the development of:

• recommendations for general inspection

• equipment repair and replacement strategy

• spare parts list

The FMECA shall be reviewed:

• following construction of the bridge

• after 5 years of operation of the bridge

Changes identified shall be incorporated into the recommendations for inspection, equipment repair and replacement strategy, and spare parts list.

9.2 Recommendations for General Inspection

Recommendations for general inspection for all components of the System shall be developed based on output from the FMECA.

A preliminary FMECA has identified the following recommendations for inspections:

• Perform regular function checks at 3-month intervals of the standby System

• Verify regularly at 3-month intervals that System data is backed-up from the MMS database

• Perform quick response inspection within 48hrs of lightning fuses following lightning strike

9.3 Equipment Repair and Replacement Strategy

An equipment repair and replacement strategy shall be developed based on output from the FMECA. The strategy shall include identification of importance of sensors, prioritisation of sensors to assist the operator in developing and reviewing strategic repair programmes, and permissible

response times in the event of failure.

Document Metadata

Table of Contents

P O N T E S U L L O S T R E T T O D I M E S S I N A

Document Metadata