semantic web based multi-agent framework for real … › bitstream › 1807 › 32645 › 5 ›...

SEMANTIC WEB BASED MULTI-AGENT FRAMEWORK FOR

REAL-TIME FREEWAY TRAFFIC INCIDENT MANAGEMENT

SYSTEM

by

Mahmoud Osman Abou-Beih

A thesis submitted in conformity with the requirements

for the degree of Doctor of Philosophy

Graduate Department of Civil Engineering

University of Toronto

© Copyright by Mahmoud Abou-Beih (2012)

ii

ABSTRACT

Title: Semantic Web based Multi-agent Framework for Real-time

Freeway Traffic Incident Management System

Name: Mahmoud Osman Abou-Beih

Degree: Doctor of Philosophy

Department: Department of Civil Engineering, University of Toronto

Year of Convocation: 2012

Recurring traffic congestion is attributable to steadily increasing travel demand coupled with

constrained space and financial resources for infrastructure expansion. Another major source of

congestion is non-recurrent incidents that disrupt the normal operation of the infrastructure.

Aiming to optimize the utilization of the transportation infrastructure, innovative infrastructure

management techniques that incorporate on edge technological equipment and information

systems need to be adopted to manage recurrent and non-recurrent congestion and reduce their

adverse externalities.

The framework presented in this thesis lays the foundation for multi-disciplinary

semantic web based incident management. During traffic incident response, involved

stakeholders will share their knowledge and resources, forming an ad-hoc framework within

which each party will focus on its core competencies and cooperate to achieve a coherent

incident management process. Negotiation between various response agencies operators is

performed using intelligent software agents, alleviating the coordination and synchronization

burden of the massive information flow during the incident response. The software agents

provide a decision support to human operators based on the reasoning provided from the

underlying system knowledge models. Ontological engineering is used to lay the foundation of

the knowledge models, which are coded in a web based ontology language, allowing a

decentralized access to various elements of the system.

iii

The whole system communication infrastructure is based on the Semantic Web technologies.

The semantic web facilitates the use of, in an enhanced manner, the already existing web

technologies as the communication infrastructure of the proposed system. Its semantic

capabilities help to resolve the information and data interoperability issues among various

parties. The web services concepts combined with the semantic web allow the direct exploration

and access of knowledge models, resources, and data repertories held by various parties.

The developed ontology along with the developed software system were tested and

evaluated by domain experts and targeted system users. Based on the conducted evaluation, both

the ontology and the software system were found to be promising tools in developing pervasive,

collaborative and multi-disciplinary traffic incident management systems

iv

ACKNOWLEDGEMENTS

It is true that pursuing Ph.D. studies is a challenging undertaking, and it has been a life-changing

experience for me. This thesis would not have been possible without the support I have received

from many people in various ways. I would like to convey to them my heartfelt gratitude and

sincere appreciation.

I was truly lucky to have two rather than one supervisor. It would be hard to overstate my

gratitude to my Ph.D. supervisor, Professor Baher Abulhai, for his continuous support and

thoughtful guidance. With his wisdom, efforts and enthusiasm, many obstacles have been

overcome smoothly. Prof. Tamer El-Diraby was able to teach me several things throughout our

four-year encounter. His guidance, flexibility, and open-mindedness enabled the knowledge

discovery process to be enjoyable, beneficial and eventually fruitful.

Above all, I dedicate this thesis to my father’s soul. He had been an exemplary role model, and

an inspiration for me to achieve throughout my life. He was able to forge in me a relentless

passion for knowledge. I will forever be indebted to his dedication and unconditional love.

Equally grateful, I would have never endured these many years without emotional support from

my mother. I will be forever thankful to her for providing me with her deepest love and support

throughout my life and the course of my doctoral studies.

I would like to thank my colleagues at the Centre for Information Systems in Infrastructure &

Construction for sharing my quest to understand, design and implement ontologies. In addition, I

must thank the many domain experts whom I interviewed throughout the course of my research.

Their practical insight has significantly contributed to the quality of this work. Last but not least,

I would like to thank the members of my advisory committee who provided valuable comments

and guidance to my research.

v

TABLE OF CONTENTS

Abstract ........................................................................................................................................... ii Acknowledgements...………………………………………………………………………….….iv Table of Contents…...……………………………………………………………………………..v List of Tables.………………………………………………………………………………….…ix List of Figures………………………………………………………………………………….…xi

1 Introduction ........................................................................................................................... 1 1.1 Motivating Scenario ......................................................................................................... 3 1.2 Problem Statement ........................................................................................................... 4 1.3 Objectives ......................................................................................................................... 6 1.4 Scope ................................................................................................................................ 9

1.4.1 Ontology Scope ......................................................................................................... 9 1.4.2 Multi Agent System Scope ..................................................................................... 11

1.5 Contribution ................................................................................................................... 13 1.5.1 The Ontology .......................................................................................................... 13 1.5.2 The Multi Agent System ......................................................................................... 14

1.6 Limitations ..................................................................................................................... 15 1.7 Thesis organization ........................................................................................................ 16

2 Literature Review ................................................................................................................ 18 2.1 Summary ........................................................................................................................ 19 2.2 Traffic Incident management system ............................................................................. 19

2.2.1 Incident Management Processes ............................................................................. 23 2.2.2 Stakeholders Roles and Responsibilities ................................................................ 24

2.3 Review of Traffic incident Management Systems ......................................................... 24 2.3.1 Comprehensiveness of the MAS Traffic Management Capabilities....................... 25 2.3.2 Underlying Processes Realization and Integration ................................................. 25 2.3.3 MAS Knowledge Model Related Criteria............................................................... 27 2.3.4 Software Architecture and Technology Related Criteria ........................................ 32 2.3.5 Concluding Remarks of the Studied MAS.............................................................. 35

2.4 Incident Management in Other Infrastructure Sectors ................................................... 36 2.5 Semantics of Incident Management ............................................................................... 40

2.5.1 Incident Management Semantics in Energy Sector ................................................ 41 2.5.2 Incident Management Semantics in Information Technology Sector..................... 42 2.5.3 Incident Management Semantics in Transportation Sector .................................... 42

3 Research Framework .......................................................................................................... 44 3.1 Summary ........................................................................................................................ 44 3.2 Ontology Development Methodology ............................................................................ 45

3.2.1 Ontology Scope Definition ..................................................................................... 46 3.2.2 Formulation of Competency Questions .................................................................. 48 3.2.3 Taxonomy Building ................................................................................................ 48 3.2.4 Relationship Analysis ............................................................................................. 49 3.2.5 Axioms .................................................................................................................... 51

vi

3.2.6 Ontology Evaluation ............................................................................................... 51 3.3 SWIMS Development Methodology ............................................................................. 53

3.3.1 Scope Definition ..................................................................................................... 53 3.3.2 Stakeholders Identification ..................................................................................... 54 3.3.3 Traffic Incident Management Underlying Processes .............................................. 57 3.3.4 Requirements Analysis ........................................................................................... 61 3.3.5 SWIMS Evaluation and Performance Measures .................................................... 66 3.3.6 Use Cases ................................................................................................................ 68

4 Ontological Model for Threats &Vulnerability ................................................................ 72 4.1 Summary ........................................................................................................................ 72 4.2 Benchmarks .................................................................................................................... 72 4.3 The Proposed Ontological Model .................................................................................. 74

4.3.1 The Spatial/Physical Sub-model ............................................................................. 74 4.3.2 Temporal-business sub-model ................................................................................ 77 4.3.3 The Risk Model....................................................................................................... 83

4.4 Interim Analysis ............................................................................................................. 86 4.4.1 Fuzziness of the Risk Concepts Continuum ........................................................... 86 4.4.2 Causality ................................................................................................................. 87 4.4.3 Externality and the Ambient Human Threat ........................................................... 88 4.4.4 Interdependency ...................................................................................................... 90 4.4.5 Rejection of the Accidental ..................................................................................... 90

4.5 Taxonomical Representation of RLM-Onto .................................................................. 91 4.5.1 Threat ...................................................................................................................... 91 4.5.2 Vulnerability ........................................................................................................... 93 4.5.3 Incidents/hazards..................................................................................................... 95 4.5.4 Impact ..................................................................................................................... 97 4.5.5 Countermeasure ...................................................................................................... 99

4.6 Attributes ...................................................................................................................... 103 4.6.1 Possibility (Severity Levels) Attributes ................................................................ 103 4.6.2 Temporal Attributes .............................................................................................. 106 4.6.3 Spatial Attributes .................................................................................................. 106 4.6.4 Concept Specific Attributes .................................................................................. 106 4.6.5 Attributes Modalities ............................................................................................ 107

4.7 Relationships model ..................................................................................................... 108 4.8 Ontology Axioms ......................................................................................................... 109 4.9 Developing Impacts...................................................................................................... 113

4.9.1 Representing Hazard Risk..................................................................................... 115 4.9.2 Assessment of impacts .......................................................................................... 117

5 Traffic Incident Management Ontology .......................................................................... 120 5.1 Summary ......................................................................... Error! Bookmark not defined. 5.2 Motivating scenario ...................................................................................................... 120 5.3 TIM-Onto Taxonomy of threats ................................................................................. 123 5.4 TIM-Onto Taxonomy of Vulnerabilities .................................................................... 125 5.5 TIM-Onto Taxonomy of situational factors ................................................................ 127 5.6 TIM-Onto Taxonomy of Incidents ............................................................................. 130

vii

5.7 Measuring Incident Impacts ......................................................................................... 133 5.8 Modeling the Traffic Incident ...................................................................................... 134 5.9 Modeling the Traffic Incident Management System.................................................... 139

5.9.1 Traffic Incident Management Processes ............................................................... 140 5.9.2 Traffic Incident Management Actors/Roles .......................................................... 144 5.9.3 Traffic Incident Management Products ................................................................ 147

5.10 Incident Management Best Practices ........................................................................... 150 5.10.1 Institutional Best Practices .................................................................................... 150 5.10.2 Operational Best Practices .................................................................................... 153

5.11 Estimation of Incident Duraction Best Practices .......................................................... 167

6 A Framework for Traffic Incident Management ........................................................... 171 6.1 Summary ......................................................................... Error! Bookmark not defined. 6.2 Introduction .................................................................................................................. 171 6.3 SWIMS Components Underlying Rationale ............................................................... 172

6.3.1 Underlying Rationale of Using Web-services ...................................................... 174 6.3.2 Software Agents Underlying Rationale ................................................................ 174

6.4 SWIMS conceptual Architecture ................................................................................. 176 6.4.1 SWIMS Conceptual Architecture vs. Requirement Analysis .............................. 177 6.4.2 Physical Resources Layer ..................................................................................... 177 6.4.3 Basic Resources Layer .......................................................................................... 177 6.4.4 Advanced Resources Layer................................................................................... 180 6.4.5 Software Agents and Presentation Layer .............................................................. 181

6.5 SWIMS Process Workflow ......................................................................................... 182 6.6 SWIMS Software Agents ............................................................................................ 185

6.6.1 SWIMS Agent Acquaintances ............................................................................. 187 6.6.2 SWIMS Management Platform ............................................................................ 188 6.6.3 SWIMS Agents Internal Architecture .................................................................. 189 6.6.4 SWIMS Rules ....................................................................................................... 192 6.6.5 SWIMS Agent Communication ........................................................................... 194 6.6.6 SWIMS Messages Ontologies and Content Languages ....................................... 193 6.6.7 SWIMS Interaction Protocols .............................................................................. 195

6.7 SWIMS Implementation Architecture ......................................................................... 201 6.8 Demonstration Scenario ............................................................................................... 206

7 Evaluation........................................................................................................................... 211 7.1 Summary ......................................................................... Error! Bookmark not defined. 7.2 Evaluation of TIM-Onto Ontology ............................................................................. 211

7.2.1 Review of Design Competency Questions ........................................................... 212 7.2.2 Automated Consistency Check ............................................................................. 213 7.2.3 Expert Evaluation Interviews ................................................................................ 214

7.3 SWIMS Framework Performance Evaluation ............................................................. 225 7.3.1 Requirement Conformity Assessment .................................................................. 225 7.3.2 Automated Reasoning ........................................................................................... 225 7.3.3 Focus Group .......................................................................................................... 226

viii

8 Summary, Conclusions and Recommendations .............................................................. 235 8.1 Proposed Solution ........................................................................................................ 236 8.2 Research Contribution .................................................................................................. 237

8.2.1 The Ontology ........................................................................................................ 237 8.2.2 The Multi Agent System ....................................................................................... 238

8.3 Conclusions .................................................................................................................. 238 8.4 Recommendations ........................................................................................................ 240

8.4.1 Recommendations Related to Ontology Development ......................................... 240 8.4.2 Recommendations Related to SWIMS ................................................................ 241

References .................................................................................................................................. 244 Appendix-A Overview of Ontologies and Software Agent Technologies.............................256 Appendix-B Description of Threat Concept Taxonomy........................................................269 Appendix-C Incident Duration Estimation.............................................................................244 Appendix-D SWIMS Framework Components......................................................................275 Appendix-E Survey on Traffic Incident Management Best Practices at City of Toronto..296 Appendix-F Ontology Validation Survey................................................................................312 Appendix-G Semantic Web Incident Management System Evaluation Questionnaire......323

ix

LIST OF TABLES

Table 2-1: Incident Management Stakeholders, Roles and Responsibilities…………………….23

Table 2-2: MAS Traffic Management Characteristics…………………………………………..26

Table 2-3: Endowed Knowledge Model Characteristics………………………………………...30

Table 2-4: Knowledge Model related criteria……………………………………………………31

Table 2-5: Software Architecture related criteria………………………………………………..33

Table 2-6: Incident Management Capabilities in Various Civil Infrastructure Sectors………….38

Table 2-7: Semantics of Incident Management in Different Civil Infrastructure Sectors……….41

Table 3-1: Ontology Evaluation Criteria Used in This Research………………………………..51

Table 3-2: Description of Supported Stakeholders’ Tasks/Responsibilities…………………….55

Table 3-3: Horizontal Decomposition of SWIMS Value Chain………………………………...57

Table 3-4: TIM Key Processes Business Rules/Decision Criteria and Main Attributes………...59

Table 3-5: SWIMS Strategic Level Requirements………………………………………………61

Table 3-6: Traffic Incident/Attributes from Different Responders Perspective…………………62

Table 3-7: Process Level Requirement Analysis………………………………………………...63

Table 3-8: SWIMS Data/Information Flows Requirements…………………………………….65

Table 3-9: Performance Measures of Toronto COMPASS TIM system………………………..67

Table 4-1: Examples of Threat Types Resulting from the Two Defined Modalities……………94

Table 4-2: Examples of Different Vulnerability Modalities…………………………………….96

Table 4-3: Examples of Different Impacts………………………………………………………99

Table 4-4: The Ontological Model Concepts Attributes………………………………………..103

Table 4-5: Newly Introduced Cross-Concept Relationships to DOCK………………………...108

Table 4-6: Examples of Hazard Correlation to Threat-Vulnerability Pairs…………………….112

Table 4-7: Description of Solicited Threat-Vulnerability Relationships……………………….113

Table 5.1 TIM-Onto Competency Questions vs. Strategic Requirements………………….…121

Table 5-2: TIM-Onto Act of God Threat Taxonomy………………………………………….122

Table 5-3: TIM-Onto Man-Driven Threat Taxonomy………………………………………...123

Table 5-4: TIM-Onto Vulnerability Taxonomy……………………………………………….125

Table 5-5: TIM-Onto Situational Factors Taxonomy…………..……………………………..127

Table 5-6: Traffic Incident Source Threat, Vulnerabilities and Relevant Situational Factors…131

x

Table 5-7: TIM-Onto Impact Measures………………………………………………………..133

Table 5-8: Correlation between Threat, Vulnerability, Situational Factors, and Incidents…….134

Table 5-9: Examples of Incident Correlation to Threat-Vulnerability Pairs…………………...135

Table-5.10: TIM-Onto Best Practices Sources and Their Underlying Design Objectives……..150

Table 5-11: Required Functional Processes for Each TIM Type………………………………151

Table 5-12: Organizational-roles versus Incident Type………………………………………...152

Table- 5-13: Competency Questions for TIM-Onto Operational Best Practices……………...153

Table 5-14: Required Number of Response Units vs. Incident Attributes……………………..154

Table 5-15: Incident Response Plan Components……………………………………………...156

Table 5-16: Matrix A of Relative Priority Ratios……………………………………………….158

Table 5-17: Intensity of Relative Weights Importance…………………………………………161

Table 5-18: Traffic Incidents Priority Attributes Index Value………………………………....162

Table 5-19: Matrix of Relative Significance of Priority Response Criteria……………………163

Table 5-20 Relative Significance between Possible Variations of Priority Criteria……………165

Table 5-21 Final Priority Criteria Score………………………………………………………..166

Table 6-1: SWIMS Architecture Components versus Design Requirements………………….177

Table 6-2: Supporting Resources and Execution Rules for SWIMS Tasks……………………183

Table 6-3: SWIMS Software Agents Responsibilities and Designated Stakeholders…………185

Table 6-4: SWIMS Software Agents Desire Knowledge Rules……………………………….192

Table 6-5: SWIMS Interaction Protocols………………………………………………………201

Table 7-1: Ontology Evaluation Criteria and Tools……………………………………………211

Table 7-2: Respondents for TIM-Onto Evaluation……………………………………………214

Table 7-3: Respondent Compliance to Selection Criteria and Familiarity about Research

Premise………………………………………………………………………………………….220

Table 7-4: Respondent Compliance to Selection Criteria and Familiarity about Research

Premise………………………………………………………………………………………….221

Table 7-5: Respondent Evaluation of TIM-Onto Navigational Ease………………………….222

Table 7-6: Respondent Overall Evaluation of TIM-Onto….………………………………….223

Table 7-7: Underlying Objectives of SWIMS Evaluation Questionnaire……………………...228

Table 7-8: Respondents’ Inputs on SWIMS Evaluation Questionnaire………………………..233

xi

LIST OF FIGURES

Figure 1-1: Ontology Scope .......................................................................................................... 11

Figure 1-2: Main Research Components ...................................................................................... 17

Figure 2-1: Traffic Incident Management System Processes as Depicted in Literature………... 21

Figure 3-1: Research Methodology Tools……………………………………………………….45

Figure 3-2: Ontological Engineering Methodology Steps……………………………………….46

Figure 3-3: SWIMS Design Methodology Overview…………………………………………...54

Figure 3-4: Organizational Hierarchy of TIM Stakeholders………………………………….… 57

Figure 3-5: Traffic Incident Management Time Footprints………………………………….…..68

Figure 3-6: (a) Level Groups of SWIMS Applications Functionalities……………….………...70

Figure 3-6: (b) Use Cased of Detection and Verification Package………………………………70

Figure 3-6: (c) Use Cases for Emergency Response Package…………………………………...70

Figure 3-6: (d) Use Cases for Traffic Control/Travel Information………………………………70

Figure 4-1: DOCK Ontological Model……………………………………………………….….74

Figure 4-2: Civil Infrastructure Domain Abstract Components…………………………………76

Figure 4-3: The Proposed Ontological Model…………………………………………………...77

Figure 4-4: Infrastructure Asset (Physical Product) Classification Modalities………………….78

Figure 4-5: Process Functional Modality………………………………………………………...81

Figure 4-6: Hazard Possibilities………………………………………………………………….87

Figure 4-7: The VTS Continuum and Artificial Divide Lines…………………………………...89

Figure 4-8: Incident Modality Families …………………………………………………………99

Figure 4-9: Impacts and Countermeasures taxonomy………………………………………….101

Figure 4-10: Impact Assessment Logical Procedure…………………………………………...118

Figure 5-1: Traffic Incident Taxonomy………………………………………………………...130

Figure 5-2: TIM-Onto Components and Extended Ontologies………………………………..139

Figure 5-3: TIM-Onto Process Functional Modality…………………………………………..142

Figure 5-4: TIM-Onto Process Modalities…………………………………………………….143

Figure 5-5: TIM-Onto Process Attributes……………………………………………………..143

Figure 5-6: TIM-Onto Actors and Roles Taxonomy…………………………………………..146

Figure 5-7: TIM-Onto Road Product…………………………………………………………..147

xii

Figure 5-8: Road Product Modalities as Extended from DOCK……………………………….149

Figure 5-9: Traffic Diversion Decision Rule…………………………………………………..168

Figure 5-10 (a): Decision Tree for Estimation of Incident Duration…………………………...169

Figure 5-10 (b): Decision Tree for Estimation of Incident Duration…………………………..170

Figure 6-1: Abstract Representation of SWIMS Main Components…………………………..173

Figure 6-2: SWIMS Abstract Architecture…………………………………………………….176

Figure 6-3: SWIMS Traffic Incident Management Process Workflow Using BPMN………...183

Figure 6-4: SWIMS Agent Acquaintance Diagram……………………………………………187

Figure 6-5: SWIMS FIPA Compliant Management Platform…………………………………188

Figure 6-6: SWIMS Agents Single Pass Vertical Layered Architecture………………………190

Figure 6-7: The JADE asynchronous message passing paradigm……………………………...194

Figure 6-8: Transferring between ACL Message Format to Java Classes……………………...197

Figure 6-9: FIPA Contract Net Interaction Protocol……………………………………………199

Figure 6-10: SWIMS Implementation Components…………………………………………...203

Figure 6-11(a): Preliminary Incident Attributes collected through Dedicated Webpage………206

Figure 6-11 (b): Incident Alert is sent to Communication Officer and Closest Cameras to the

Incident Scene are identified to verify the Incident…………………………………………….207

Figure 6-11 (c): Detailed Incident Report is prepared and sent by the Communication Officer.208

Figure 6-11 (d): Detailed Incident Report sent by the Communication Officer is received by

various Emergency Responders……………………………………..………………………….208

Figure 6-11 (e): The Emergency Medical Service Agent utilize the ‘Route Guidance’ and ‘Real

Time Network Links Travel Time’ to guide Emergency Units to Incident Scene………………208

Figure 6-11 (f): Traffic Operation Center Agent receives the Incident Report and a ‘Mesoscopic

Traffic Simulation’ Web-service is triggered to determine Impacted Area…………………….209

Figure 6-11 (g): Impacted Area is calculated along with Impacted Intersections and suggested

Traffic Signal Plans……………………………………………………………………………..209

Figure 6-12 (a): SWIMS Agents Interaction Diagram…………………………………………210

Figure 6-12 (b): SWIMS underlying GIS Web-services deployed on ESRI ArcServer……….211

1

1 INTRODUCTION

One of the major problems identified during traffic incident management is the efficient

coordination between various response agencies (Kachroo, 1997). Traffic incident management

is a multi-agency, multi-jurisdiction problem that requires careful planning and coordination

among various involved stakeholders (Ozbay, 1999). Incident response is formed of sequential,

interrelated processes; encompassing wide array of involved stakeholders, e.g. transportation

agencies, law enforcement, fire rescue, emergency medical services, etc.

Current incident management practices most commonly follow centralized decision-

making paradigms inherited from older legacy systems. Typically in legacy traffic management

systems, response agencies are centrally coordinated, and the provided decision support tools

focus primarily on traffic operators, and put less emphasis on other responders (Rindt et al.,

2007). Coordination between incident responders has been mediated more by intra-disciplinary

tradition and training, and experience gleaned from multidisciplinary response, rather than well

organized, pre-planned coordination.

An integrated incident management system that provides coordinated multidisciplinary

response will decrease incidents fatalities, increase responders’ safety, and significantly decrease

response and relief time. Such system would optimize responding units dispatch to incident

scene; define on-scene roles, mutual expectations and interactions (NTIMC, 2006). However,

such an integrated system encompasses a multitude of challenges that are summarized in the

following points:

§ Information flow and management: any system must be able to handle continuous flow of

data, and update its decisions and coordination across various parties accordingly.

§ Information and data interoperability: incident management involves multi-discipline

agencies possessing heterogeneous information systems; each has its own data syntax,

schema, and semantics. Interoperability has been identified as the key challenge in having an

integrated and unified incident management system. Pursuing the semantic interoperability is

the key point to resolve the syntactic and schematic heterogeneity.

2

§ Sharing common traffic incident management domain knowledge model: A domain

knowledge represents the core and fundamental best practices, proven theories, and shared

standards pertaining to a certain domain. Although there are significant formal coordination

and liaison agreements between responding agencies; each agency still operates under its

internally developed governing policies and response procedures. As reported in the literature,

domain core concepts were found to be interpreted differently among responding agencies

(Austroads, 2007). This has resulted in different perspectives in quantifying incident

associated impacts; consequently different decisions regarding required response measures.

Developing an integrated incident management system dictates having a shared knowledge

model that encompasses policies and procedures belonging to different response agencies.

Such knowledge model must be developed using cross-domain shared and standardized

incident related terminology.

§ Software interoperability and resources access: an integrated incident management system

must allow access to specific resources and databases available at involved agencies through

an adequate underlying communication infrastructure. Involved stakeholders should be able to

invoke required services remotely, transfer input data in the compatible format and obtain

back the outputs in a seamless manner, regardless of the service location over the

communication network.

Recent trends in informatics research are advocating the use of ontologies as the foundation for

building knowledge models for systems that require collaborative coordination and decision

making. Traffic incident management is certainly one such system. Ontology represents

knowledge (not just data) in human-readable, yet machine-processed format. It provides an

efficient tool in supporting human-oriented communication and providing common platform for

data representation and knowledge sharing. Accordingly, ontology is capable of resolving

semantic, schematic, and syntactic heterogeneities.

Ontology captures the knowledge of a certain domain through defining sets of

representational concepts (vocabulary) in formal declaration; categorizing those terms into

taxonomic hierarchies and describable relationships. The interpretation of the captured concepts

is constrained using formally coded axioms; assuring that no dual interpretation exists for the

same concept.

3

This thesis is the first attempt to develop and implement a semantic informatics system

within the traffic incident management domain. The core component of this system is an

ontology that encapsulates the knowledge pertaining to this domain; forming collaborative

knowledge-based system that serves loosely coupled networks of incident responders. During

traffic incident response, Stakeholders will share their knowledge and resources, forming an ad-

hoc framework within which each party will focus on its core competencies while cooperating

with other stakeholders to achieve integrated and cooperative incident management processes.

Negotiations between various response operators are performed using intelligent software

agents, alleviating information flow coordination and synchronization burden from human

operators. Software agents will be used to provide decision support to human operators. When

integrated with inference engines, agents can inquire any domain, draw conclusions, proof and

trace the steps involved in their logical reasoning using the semantic knowledge models

(ontologies) of that domain.

The software agents utilize existing tools such as service-oriented architecture (SOA),

Web 1.0, 2.0 and the upcoming Semantic Web (Web 3.0) to manage and integrate the flow of

data and information in a distributed environment. Software services and data repositories

belonging to various stakeholders will be implemented as Web Services. A Web Service is a

software application deployed and invoked over the WWW; allowing direct exploration and

access to the before mentioned resources. It is considered to be the most prominent

implementation of SOA. Software agents have proven useful in dynamically managing and

coordinating the execution of Web Services.

1.1 MOTIVATING SCENARIO

The motivation and hence the outcome of this research can be illustrated by two scenarios, a

primary and secondary one. The primary scenario is a freeway incident being managed by

multiple responders belonging to various agencies involved in the incident management process.

The scenario takes place on the freeway network surrounding a major North American

metropolis. Throughout the incident response lifecycle, each involved agency has different roles

and responsibilities that may change based on the incident impacts evolution.

4

Upon occurrence of a traffic incident, key responders form an ad-hoc framework where

different actors (response agencies) are allowed to join or leave the framework based on the

incident evolution and response requirements. Once an incident is detected, the actual occurrence

of the incident need to be verified and essential attributes must be collected in order to determine

required response measures. These measures include determining the number and type of

response units, incident command hierarchy and traffic control and detour (if necessary) plans.

Developing such plan requires clear understanding and identification of key incident

management processes and actors; in addition to cross-agency policies and procedures.

Accordingly, decision makers belonging to involved agencies will collaboratively be able to

determine trade-offs necessary for coordinated response; creating a response plan that provides

timely response, efficient utilization of resources, improved safety, reduced congestion and

decreased pollution (Ozbay 1999).

The secondary scenario focuses on how to endow the developed knowledge model with

the capability to identify the root causes underlying traffic incident occurrences. Such causes

may range from various situational factors leading to drivers’ error (e.g. age, mental alertness

…etc.) up to existing vulnerabilities in the freeway system (e.g. sharp horizontal curve), in

addition to the threats that might exploit those vulnerabilities, e.g. landslides, extreme weather

events …etc. Examples of beneficiaries of this capability would include law enforcement official

investigating traffic incidents occurrence, highway safety designers/researchers attempting to

implement proactive measures to mitigate similar incidents future occurrence.

1.2 PROBLEM STATEMENT

Each responding agency, within traffic incident management framework, has a decision making

structure that incorporates three components: products (instructions, plans …etc), processes (e.g.

verification, dispatch, and traffic management processes) and actors (administrators, onsite crews

…etc). Orthogonal to these are data, information and knowledge related to these components.

Data and information exchange is not enough to achieve an integrated incident management

system. What is most important is the integration and synchronization of processes and the

effective linkage of decision makers belonging to various response agencies. Various incident

management systems have been proposed and deployed worldwide (Gupta et al., 1992 and Logi

5

et al., 2001). However none of such systems achieved the before mentioned integration, which

can be attributed to the following three aspects:

§ Incomplete solution for the problem: current incident management practices can be viewed

as a centralized decision making process, in which response agencies are centrally

coordinated usually through central traffic operation center. The provided decision support

tools primarily address traffic operators, ignoring other response agencies within the incident

management framework. Furthermore, such centralized workflow of data and information is

overwhelming and may lead to delays in the overall decision-making process.

§ Weak knowledge representation: most widely recognized and deployed incident

management systems rely on traditional expert system technology (Gupta et al., 1992, Logi et

al., 2001). Such technology has several shortcomings: 1) expert systems are brittle, dealing

poorly with situations that require bending the rules, 2) they are isolated, self-contained

software entities; very little emphasis is placed on capabilities to support interaction with

other knowledge bases or external software components, and 3) as the system develops,

extending its functionalities is usually accompanied with inconsistencies and redundancies

that are difficult to avoid (Ozbay, 1999).

§ Lack of Interoperability: the multidisciplinary nature of traffic incident management

dictates the need to grant involved agencies direct access to each other databases and

information resources. Accordingly, enabling those agencies to support their core

competencies; along with enhancing their cooperative decision making capabilities. A key

element in achieving interoperability among interacting parties is to resolve semantic

heterogeneity in the organizational integration elements (processes, products and actors) along

with syntactic heterogeneity in data and information systems. None of the reviewed incident

management systems provided direct approach to resolve the semantic and syntactic

heterogeneities; only providing data mapping tools to resolve data syntactic heterogeneities

leaving the semantic heterogeneity unresolved.

To address the requirements of decision makers and operators in the incident management

domain, there is a need for an effective interoperable system. Such system must support

knowledge sharing and prompt the integration of targeted stakeholders in the decision making

process; primarily through addressing the before mentioned aspects. The suggested framework

6

adopts an informatics view of integration. Informatics systems focus on knowledge sharing and

human communication as means for achieving synchronized integration of processes workflow.

Ontology is considered the core of establishing a knowledge-enabled system for informatics.

The proposed framework is committed to traffic incident management domain ontology.

This ontology is combined with another ontological model that defines root causes that traffic

incidents may stem from. Such integrated inheritance may aid the developed ontology to provide

potential explanations for factors that may have contributed to the incident occurrence; in an aim

to mitigate future occurrence and to support law enforcement officials in incident investigations.

1.3 OBJECTIVES

The core objective of this research is to advance the incident management domain using

semantic interoperable models. This requires building a semantic-web-based multi-agent incident

management system based on ontology that encapsulates domain knowledge and achieves

interoperability. Such ontology should address the knowledge associated with traffic incident

management over its complete lifecycle, including elements related to traffic incident risk.

Accordingly, the ontology should capture the following aspects:

§ Traffic incident management organizational integration elements: i.e. actors, products,

and process workflows. Actor refers to various responding agencies, while product refers to

various outputs resulting from the incident management process (e.g. response plans, data,

information, decisions…etc.). Process workflow refer to modeling interaction patterns

between various involved stakeholders based on the reported incident attributes. It is our goal

to develop the first such ontology and establish the concept. Exhaustively detailed modeling

of traffic incident management components and processes is out of the scope of this research;

with the understanding that others will expand the basic ontology developed herein over time.

§ Incident management response procedures and policies: each responding agency has its

own response rules and best practices, represented in the form of response policies/procedures

manuals and experienced operators’ tacit knowledge. Encapsulating such knowledge will

support responders’ cooperative decision making and allow them to operate in full

understanding of mutual expectations and interactions during the response process.

7

§ Incident risk associated elements: in general, every incident occurrence can be related to

underlying sets of situational factors and threats exploiting certain vulnerabilities in the

transportation system. For example, a drunk driver (situational factor) on a snowy day (threat)

may lose control of the vehicle on a sharp horizontal curve (vulnerability). Endowing the

developed knowledge model with the capability to identify those threats and vulnerabilities

will aid in incidents root cause analysis. Consequently, supporting incident scene

investigations and the development of future mitigation measures.

The full coverage of the above three aspects in one ontology-based multi-agent incident

management system is an extensive research endeavour that is beyond the scope of one thesis. In

this research, we establish the concept, develop the first-of-a-kind domain-level ontology for

traffic incident management and produce a multi-agent framework for semantic web incident

management. The proposed ontology and system capture key organizational integration elements

and response procedures/policies. In addition, it addresses relevant set of risk associated

elements to help to identify incident causes. In modelling organizational integration elements

(i.e. products, process, and actors), the developed ontology extends DOCK ontology developed

by EL-Diraby et al. (2010).

To illustrate the value of ontology-based systems, a layer of software agents is developed

on top of the proposed ontology. Those agents resemble different stakeholders in the incident

management domain; and use the underlying ontology for reasoning about the domain using

formally coded rules and explicitly constrained domain knowledge. Based on different scenarios,

involved stakeholders’ agents build an ad-hoc framework. Software agents utilize specific

middleware (Web Services) to link existing applications and assure integration of data, flow of

information, processes synchronization and provide decision support to human operators. The

following lists the three main objectives of this research.

1. Develop an ontological model for civil infrastructure risk associated elements.

Create a generic ontological model for civil infrastructure risk associated elements. Risk

elements can be defined in terms of external threats (naturally occurring or man-driven) that may

exploit system internal vulnerabilities and materialize them into incidents. The aim is to develop

an abstract, high level model that captures the domain knowledge. This model can be extended to

8

addresses specific sectors within the infrastructure domain such as traffic incident manamgent.

This includes the following two sub-objectives:

§ Analyze the state-of-the-art initiatives related to modeling risk associated elements within

various civil infrastructure sectors and identify key strengths and weaknesses in them.

§ Integrate the developed ontological model with the civil infrastructure modeling framework

(DOCK) developed by El-Diraby et al. (2010). As such, the developed model will be

endowed with the capability to map the topology of civil infrastructure and aid in creating

design support tools that can identify weaknesses (vulnerabilities) within them.

2. Develop domain ontology for traffic incident management.

The domain ontology primarily focuses on the traffic incident management domain; capturing

the full lifecycle of incident management, including both proactive (root cause analysis) and

reactive (response processes) measures. Through extending the DOCK ontology (El-Diraby et

al., 2010), the developed ontology models the topology of the traffic network along with other

organizational integration elements. In developing such ontology the following two sub-

objectives must be achieved as well:

§ Understand the practice and needs of the traffic incident management through analysis of

current literature as well as response measures deployed at the City of Toronto emergency and

traffic operations centers.

§ Identify improvements in current practices and processes that can be achieved through the use

of a semantic model for information exchange and stakeholders integration.

3. Develop a Multi Agent System (MAS) to support collaborative traffic incident

management.

Software agents bridge the gap between end users and various services provided by the

system. Agents are endowed with inference capabilities that support reasoning about the

domain using the underlying ontology. Specific objectives in developing the system MAS

include:

§ Fully capture the roles of various responding agencies in the traffic incident management

process and resemble each agency with at least one software agent. The software

9

architecture redesigns the incident management process workflow into a distributed and

collaborative decision-making process.

§ Compile best practice rules that are used to enhance the overall efficiency of the incident

management process. These best practices are an extended module of the developed

ontology axioms, coded in the software agents’ inference engine programming language.

Software agents use these axioms to control the processes workflow and execution and

present the operators with decision support mechanisms.

§ Implement traffic incident management shared services and resources as Web Services with

open and standard interfaces. Incident response services and resources encompasses a wide

array of software entities, including: traffic control hardware data grabbers, GIS and non-

spatial databases, a variety of software applications (e.g. simulators and other traffic

control algorithms), web applications such as geo-coders, mapping and routing

applications …etc. Each group of services/resources perform specific tasks corresponding

to an operation within the incident management framework. Different agencies perform

their response processes through utilizing specific sets of services and resources. Intelligent

software agents are used in cooperative manner to build, compose, and monitor the

execution of these services.

1.4 SCOPE

Advanced knowledge enabled systems are still in the early implementation stages in the civil

infrastructure domain. Developing ontologies or decision support systems that address all or the

majority of the domain issues is beyond the scope of one thesis. Accordingly, the scope of the

work undertaken by this research is limited as follows:

1.4.1 Ontology Scope

The development of comprehensive ontology that fully captures the full lifecycle of traffic

incident management is an extensive task. Hence, in developing the ontology, the focus is on the

reactive side of incident management lifecycle, i.e. response processes. The proactive side of

incident management lifecycle that defines incidents occurrence root causes (e.g. geometric

10

design vulnerabilities) is introduced in this research in abstract but adequately illustrative

manner. The rationale for this is as follows:

a. Domain complexity: proactive incident management is primarily addressed by the research

conducted in the highway safety domain. In such domain there is no consensus agreement

regarding identifying incident root causes, which was found to vary based on geographic

locations, driving habits, and performance of the highway system…etc. Furthermore, there

is a complete absence of previous work in the semantic representation in that domain.

b. Ontology evolution: lessons from other domains have shown that ontologies evolve over

time and based on use. Given the lack of previous work on ontology development in both

highway safety and traffic incident management domains, it was decided to focus on the

reactive side of the incident management lifecycle, which is more direly needed. In addition,

the primary focus is to capture domain level knowledge and concepts while minimizing the

used axioms as much as possible, in order not to preclude future developments.

c. Need for practical tools: informatics systems are still in their early stages of

implementation in the field of civil engineering. It is important to build applications that are

of practical industry use, in order to prove the concept and gain industry recognition.

Maintaining the ontology as efficient as possible through decreasing its complexity to the

lowest possible extent is essential for industrial experts to effectively evaluate the developed

ontology success in achieving targeted goals.

As such, Figure 1-1 depicts the delimitation of the proposed ontology with respect to the

following four criteria:

§ Setting: the ontology focuses on traffic networks located in the urban context.

§ Sector: the ontology mainly captures freeway and the neighbouring arterial network.

However the ontology can be extended to address surface streets.

§ Actors Perspective: due to the multitude of stakeholders and actors involved in the traffic

incident management process, the developed model must make assumptions regarding the

perspective of its primary targeted users. As such, the developed ontology adopts the

perspective of traffic incident responders.

11

Lifecycle: incident management lifecycle can be split into two parts, proactive and reactive

measures. Proactive measures encompass the planning and design of transportation infrastructure

and incident management programs development. While reactive measures cover various

response process along with required rehabilitation and maintenance operations to restore the

infrastructure to normal operating

conditions.

Figure 1-1: Ontology Scope

1.4.2 Multi Agent System Scope

Similar to the developed ontology scope (as indicated in Figure 1-1) the proposed framework

software agent system is subject to the following delimitations:

1. Focus on urban freeway networks: the main focus of this research is on urban freeway

network.

2. Focus on response processes: software agents are developed with primary objective to

support the response processes, primarily providing the following functionalities:

12

a. Determining type and optimum number of response units required. This includes

determining response units closest to the incident scene and guiding them to-and-from

that scene.

b. Prioritizing response to multiple concurrent incidents with constrained available response

resources.

c. Interfacing with traffic control systems for freeway ramp meters and neighbouring

arterials intersections signals.

d. Determining the need for traffic detouring based on estimated incident duration and the

anticipated resulting delay.

e. Provide high-level explanation of factors that might have contributed to the incident

occurrence.

3. Capture tacit and explicit knowledge pertaining to traffic incident management:

explicit knowledge refers to knowledge formally captured in cross-organizations

cooperation policies, best practice guides and response operation manuals. Tacit knowledge

refers to rules of thumb and experiences gleaned by experienced operatives.

4. Provide decision support rather than a decision making system: the traffic incident

management problem is tackled in a way that intends to provide human operators with

sufficient knowledge to aid in decision making rather than eliminating human operators

from the decision making processes.

1.5 CONTRIBUTION

The contribution of this research can be viewed from two perspectives. From a knowledge

management perspective, the main contribution lies in the modeling and interoperability of

knowledge within the traffic incident management domain. The developed ontology acts as an

enabler of information and knowledge sharing and seamless interoperable flow across various

responding agencies. Orthogonal to this knowledge management perspective, the contribution of

this research can be broken down based on the research objectives as illustrated in the following

subsections.

13

1.5.1 The Ontology

1. Creating a generic ontological model representing knowledge pertaining to risk elements

associated with civil infrastructure: the developed ontological model conceptualizes threat

events along with the vulnerabilities that these events might exploit in civil infrastructures. It

is generic in nature covering the electricity, water, telecommunication, and transportation

sectors. Owing to it modular architecture and top-down modeling approach, the ontological

model can be extended to address specific sector/s in any required level of detail.

The proposed model will facilitate knowledge sharing, reuse, and creation. It can be used

to develop ontologies addressing the management of large-scale incidents that may impact

more than one infrastructure sector. This due to the fact that the extended ontologies

pertaining to various infrastructure sectors will be sharing the same core concepts and thus

backward reasoning can be used.

2. Creating traffic incident management ontology: the developed ontology will extend the

above mentioned ontological model to formally capture the traffic incident management

domain. It will model incident response agencies organizational integration elements using

shared terminologies and concepts, thoroughly defining binding and constraining relations

between these concepts. Such endeavour will resolve one of the major impediments for

interoperability among various responding agencies.

3. Formally capturing the explicit knowledge belonging to different response agencies: each

responding agency has its own response policies and procedures, defined using agency

specific terminology. The ontology will formally capture, using the formally defined, shared

terminology, the explicit knowledge pertaining to response policies and procedures

belonging to various response agencies. As such, a consistent interpretation for those rules

will exist among various responders allowing them to interact and operate in complete

understanding of their mutual expectations and interactions during traffic incident response.

4. Identifying the tacit knowledge used in traffic incident response: using expert interviews, the

tacit knowledge that experienced response operators deploy during various incident

scenarios will be solicited. This is significantly important due to the scarcity of literature as

well as the superficial nature of current incident response guides and documented

procedures.

14

5. Provide formal high level explanation of factors underlying traffic incident occurrence: by

extending the civil infrastructure risks ontological model, the developed ontology will be

capable of providing explanation of traffic incidents occurrence root causes. Such capability

is not provided by any traffic incident management system, based on the literature review

conducted by the author.

1.5.2 The Multi Agent System

1. Integrate various response agencies in traffic incident decision-making process: each

responding agency will be resembled with one or more software agent. Agents will infer the

required response actions using the formally and constrained ontology axioms. Based on the

incident characteristics, each software agent will be responsible for allocating, composing,

and managing a set of resources and services that resemble its agency core competencies.

This will break the currently centralized workflow of the decision making process within the

incident management system, achieving a faster decision-making and more adaptation to the

evolutionary nature of traffic incidents.

2. Creating a prototype portal for distributed response resources and services sharing: the

response resources and services will be implemented as Web Services. The real power

behind using the Web Services paradigm lies in providing novel applications in response to

changes in requirements in flexible and scalable manner. This will enable the system to

respond efficiently to changes in incident response procedures and technologies. An

administrator within the system can replace one service with another that was recently

developed or discovered. Such flexibility allows the system users to handle substantial

changes in their IT infrastructure with relative ease and at low cost. Furthermore, this

changes the incident management systems development approach from algorithm

implementations to services discovery and composition.

3. Building ad-hoc framework of responding agencies: based on reported incident attributes

responding agencies will be invited to join or leave an ad-hoc framework. Such distributed

environment is the true contribution of modern informatics systems, where semantic

software systems (ontology-based) help establishing seamless flow of information and

workflow synchronization. In addition, it will link decision makers; establishing virtual

teams that are based on exchange of knowledge rather than just information.

15

1.6 LIMITATIONS

The following are the main limitations of this research:

1. The developed ontological model provides only a high level abstraction of risk elements

associated with various civil infrastructure sectors. It cannot be assumed to be neither

comprehensive nor complete. Such limitation can be seen as advantage in maintaining the

generic nature of the developed model, inducing in it the flexibility to be extended to model

any civil infrastructure sector in greater level of detail.

2. The ontology does not offer a consistent way of representing the reliability of the knowledge

it contains. As such, the knowledge contained in the ontology is assumed to be true.

3. The ontology models organizational integration elements with varying degree of details. It

primarily focuses on modeling actor and process concepts and to less extent the product

concept. Product related concepts are used in modelling transportation infrastructure

topology as well response process outputs. The ontology mainly focuses on freeway

corridors. It is to be extended to model other types of road networks (i.e. arterials and

surface streets) in future endeavours.

4. The explicit knowledge pertaining to traffic incident management is based on response best

practices and guides devised for major North American metropolitans.

5. The tacit knowledge pertaining to traffic incident management is extracted from interviews

conducted with traffic operators and emergency responders at the City of Toronto and thus

cannot be assumed to be exhaustive or universal.

6. The proposed multi-agent system is developed based on the tenet that all involved

stakeholders are willing to share their information and data repositories as well as deploy

their database and legacy software systems as Web Services..

7. The developed software system operates within a security sensitive context. However, the

security of the developed software system is not discussed in this research.

1.7 THESIS ORGANIZATION

This thesis is organized into 8 chapters. Chapter 2 provides the literature review that introduces

the reader to the anatomy of traffic incident

of most widely recognized agent and knowledge

chapter goes on to provide a high level overview of incident management systems in other civil

infrastructure sectors, outlining lessons that could be learned from them. Finally, the chapter

concludes with a review of semantic modeling initiatives in various civil infrastructure sectors.

Chapter 3 presents the adopted research methodology in this thesis; presenting the metho

used to build the ontology and create the multi

Chapters 4 to 6 presents the three main components developed within the premises of this

research, depicted in Figure 1-2.

associated with various civil infrastructure sectors. It defines comprehensive taxonomy of

threats, vulnerabilities and anticipated incidents that may stem from them. Chapter 5 presents the

traffic incident management ontology. Aside from extending the ont

this chapter focuses on modeling response processes, response actors and their associated roles.

The chapter then concludes with presenting axioms coding incident management best practices

and incident response rules.

Figure 1-2: The Three Main Components of this Research Built Upon the Top of One Another

Chapter 6 provides a complete overview of the developed multi

reasoning model incorporated in the developed agents is based on the TIM

developed in Chapter 5. This chapter

of the system components, followed by overview of the system conceptual architecture. It then

provides an explanation of the system incident management workflow thr

16

THESIS ORGANIZATION


the reader to the anatomy of traffic incident management, in addition to a comparative analysis

of most widely recognized agent and knowledge-based incident management systems. The


tlining lessons that could be learned from them. Finally, the chapter


Chapter 3 presents the adopted research methodology in this thesis; presenting the metho

used to build the ontology and create the multi-agent system.


2. Chapter 4 presents the ontological model of risk elements



traffic incident management ontology. Aside from extending the ontological model in Chapter 4,



2: The Three Main Components of this Research Built Upon the Top of One Another

Chapter 6 provides a complete overview of the developed multi-agent system.

reasoning model incorporated in the developed agents is based on the TIM-Onto ontology

ped in Chapter 5. This chapter starts with stating the rationale underlying the use of each


provides an explanation of the system incident management workflow thr


management, in addition to a comparative analysis

based incident management systems. The


tlining lessons that could be learned from them. Finally, the chapter


Chapter 3 presents the adopted research methodology in this thesis; presenting the methodology


Chapter 4 presents the ontological model of risk elements



ological model in Chapter 4,



2: The Three Main Components of this Research Built Upon the Top of One Another

agent system. The

Onto ontology

starts with stating the rationale underlying the use of each


provides an explanation of the system incident management workflow through using a

17

demonstration scenario. The chapter then provides a detailed analysis of the system’s different

software agents, and the overall implementation architecture. Finally, it concludes with a

demonstration scenario that provides exhibits from the system different graphical user interfaces.

Chapter 7 provides an overall evaluation of the research. It outlines how the ontology and

the developed software system were evaluated through using domain experts’ interviews and

focus groups. Finally, Chapter 8 provides the summary and conclusion of this work.

18

2 LITERATURE REVIEW

2.1 SUMMARY

In the author’s point of view, the Traffic Incident Management (TIM) literature to be broadly

divided into two categories: program management and enabling technologies (e.g. computational

algorithms). TIM program management literature has originated mainly from response agencies

responsible for coordinating operational activities and dealing with actual real life scenarios. It

led to the development of institutional collaboration policies, best practice guides, and standard

response procedures. Enabling technologies literature is a product of researchers and academics

from different disciplinary fields and is evident in applications such as optimized signal-

timing/ramp-metering algorithms, in-vehicle tracking, traveler communication devices …etc

(Zografos et al., 2002).

However, the integration of these two lines of research in real life traffic management

practices has been primarily relying on ad-hoc experience rather than well-defined frameworks.

Such integration is mainly achieved through the realization of various underlying TIM

processes, process governing structures/roles, and the provision of interoperability among

heterogeneous IT systems. In comparison, infrastructure sectors have achieved much progress in

developing those integration requirements for their intra-sector incident management programs;

providing lessons to be learned for in the traffic domain (Macaulay, 2009).

Another perspective in the TIM domain is the emphasis to adopt proactive as well as

reactive measures in managing traffic incidents (Berdica, 2002). The rise of security concerns

and the need to protect the civil infrastructure against natural threats has shaped the incident

management literature in the last decade (Macaulay, 2009). Vulnerability assessment became a

prerequisite for building incident management programs across various infrastructure sectors; as

it helps to plan the required level of response actions based on expected scale of impact

(Giuffrida, 1985). In addition there is growing need to understand threat-vulnerability correlation

in order to better assess cross-sectors propagation of incident/s impacts (Macaulay, 2009).

However, there is no common consensus in the literature regarding the semantics related to

incident or vulnerability concepts across the various civil infrastructure sectors or even within

19

the same sector. This significantly hinders cross-sectors collaboration and coordination in case of

major incidents impacting interdependent sectors assets, as outlined in Chapter-1.

This chapter briefly describes the incident management anatomy. It compares the major

capabilities of traffic incident management programs to similar programs in other infrastructure

sectors; identifying capabilities that should be incorporated and lessons to be learned. The

semantics related to incident management domain in various infrastructure sectors is then

outlined. A detailed comparative analysis of agent-based traffic incident management systems is

presented herein as well. Brief background on the tools used to build the proposed TIM system,

i.e. ontologies, agent technology, and service-oriented architecture (SOA) is given in Appendix-

A of this thesis.

2.2 TRAFFIC INCIDENT MANAGEMENT SYSTEM

Traffic incident management is systematic planned coordination of human, institutional, physical

and technical resources to minimize traffic incidents impact on transportation network

performance, relieve involved victims and improve motorists and responders safety (FHWA,

2010). The first recognized incident management systems were developed in California in early

1970’s to counteract the widespread of wild land fires events. Those systems coordinated the

multidisciplinary response teams, focusing primarily on resolving multi-jurisdictional and multi-

agency institutional issues (Austroads, 2007).

Subsequently, the FHWA and other states all over the U.S. recognized the need to adopt

similar systems to aid highway departments, police and other related agencies to manage traffic

related incidents efficiently (Ozbay, 1999). Those systems were placed in centralized Traffic

Operations Center; taking the advantage of back then emerging communication and computing

technologies. Today, various incident management systems are operated and deployed in cities

worldwide.

2.2.1 Incident Management Processes

Traffic incident management can be characterized by seven main processes, summarized in the

following paragraphs and depicted in Figure 2-1.

20

Figure 2-1: Traffic Incident Management System Processes as Depicted in Literature (Ozbay 1999)

21

1. Incident Detection: is the process by which the emergency response centers become aware

of the occurrence of traffic incidents (Austroads, 2007). The most reliable source for incident

detection is routine police patrols. Other sources include: two-way radios from public

agencies, public phone calls, and dedicated freeway service patrols. In many cities, traffic

sensors are used to automatically detect changes in traffic flows due to incidents.

Increasingly, incident detection in many highly congestion metropolitans is achieved by

closed-circuit television (CCTV) (Ozbay, 1999).

2. Incident Verification: is the determination type and location of a detected incident (FHWA,

2010). Incident verification is needed the most when an incident is reported through un-

trusted source such as anonymous public phone calls or untrained operators/observers who

might exaggerate the incident severity or mix up locations and/or other relevant details (Hall,

2001). Video surveillance of major traffic has been widely used as an effective way to reduce

incident verification time, confirming location and guiding appropriate response (Charles et

al., 2003). In addition, police agencies use video image to investigate incidents instead of

extending the closure time of incidents scene. In case of the incident not falling in the

proximity of CCTV camera, police or highway patrols are dispatched to the reported incident

scene to verify the occurrence (Charles et al., 2003).

3. Incident Response: is the dispatch, coordination, and management of appropriate personnel

and equipment in order to relief involved victims and clear incident scene (Ozbay, 1999). It

involves allocating the closest response facilities to the incident scenes and guiding response

units to-and-from the incident scene. Adequate response requires in-depth understanding of

traffic incidents nature, governing institutional policies and laws as well as appropriate steps

and resources necessary to clear and restore normal traffic conditions (Farradyne, 2000].

Typically, police dispatchers coordinate communications throughout the incident clearance

operations. However, traffic operations centers are emerging in many cities to perform such

role (Ozbay, 1999).

4. Motorist Information Dissemination: is the dissemination of incident-related information

and probable diversion routes to motorists to support informed travel decision and mode

choice (Austroads, 2007). Currently, there are several information dissemination channels

including; Variable Message Signs (VMS), highway advisory radio, commercial radio

stations, mobile phones, call centers, in-vehicle text and voice displays, internet, emails…etc.

22

However, motorists act with varying behavior according to information source. For example,

only 30% of motorists will divert if they see the information on VMS or hear it on the radio,

but 70% will divert if they received the information simultaneously from both sources

(Talaat, 2008).

5. Traffic Management and Recovery Monitoring: is setting the necessary traffic control

measures to ensure the safety of incident responders at the scene, and minimizing incident

impact on the network performance (FHWA, 2010). On-scene traffic measures includes:

establish manual traffic control, managing road space by opening/closing lanes and managing

onsite crews to assist in managing traffic. Off-scene traffic measures includes managing

traffic control devices such as signals, ramp metering, VMS and if necessary, generating

diversion routes away of incident location (Austroads, 2007).

6. Incident Site Management: is the effective management of equipment and personnel at

incident scene, usually performed by police or firefighting personnel. Upon the arrival to the

scene, incident responders will be responsible for the following activities:

§ Securing and protecting the incident scene

§ Assisting and extraction of injured victims

§ Fires extinguishing and controlling hazard material contaminations

§ Managing on-scene traffic and preventing secondary incidents

§ Incident scene investigation and reporting to incident management centers

7. Incident Site Clearance: is the safe and timely removal of the incident and termination of

incident related conditions. Around 80% of incidents in urban areas are minor and do not

need towing. Usually, the police officer at the incident scene diagnosis and decide upon

required clearance resources (Ozbay, 1999).

23

2.2.2 Stakeholders Roles and Responsibilities

A large number of stakeholders are involved in a major incident; typical roles of those

stakeholders are outlined in Table 2-1(FHWA, 2010; Austroads, 2007).

Table 2-1: Incident Management Stakeholders, Roles and Responsibilities

Stakeholder Roles and Responsibilities

Police § Provide emergency call center, and coordinates communications

§ Assume role of Incident Commander, supervise response actions

§ Secure incident scene, safeguarding property

§ Assist responders in accessing the incident scenes

§ Perform first responder duties § Control arrival and departure of

responders § Conduct crash investigation § Perform onsite traffic control § Establish emergency access routes § Ensure responders safety

Fire/Rescue § Rescue/extricate victims § Extinguish fires

§ Contain or mitigate the release of hazardous materials

Emergency Medical Services

§ Provide triage, medical treatment to those injured at the incident scene

§ Determine destinations and transportation requirements for injured victims

§ Transport victims for additional medical treatment

Transportation Agencies

§ Implement traffic control strategies and provides supporting resources

§ Monitor traffic operations § Disseminate motorist information § Assess and directs incident clearance

activities

§ Perform incident detection and verification (service patrol/TMC) § Develops and operates alternate routes § Assess and performs emergency roadwork

and infrastructure repair

HAZMAT Crew § Clean up and dispose of toxic or hazardous materials

Media Services Providers

§ Broadcast information on congestion and incident delays

§ Provide alternate route information

§ Provide video or photography services § Radio, television, and telephone systems § E-mail, pager and internet services

Towing/Recovery Service

§ Remove disabled/ wrecked vehicles and debris from incident scene

§ Mitigate non-hazardous material (cargo) spills

24

2.3 REVIEW OF TRAFFIC INCIDENT MANAGEMENT SYSTEMS

This section presents an evaluation framework that focuses on comparing five agent-based traffic

management tools that were implemented and/or tested in real life environment; Table 2-2

demonstrates the reviewed system. Systems that were developed based on a pure rule-based

expert systems approach were omitted from the scope of the study (e.g. FRED), as expert

systems are an out-dated knowledge modeling technology (Zhang and Ritchie 1994). On the

other hand, the systems under review applied structured knowledge architectures of different

problem solving methods (PSM) explicitly expressed in a declarative fashion, providing

underlying justification for their suggested actions (Logi and Ritchie, 2002).

The evaluation approach employs a checklist of evaluation criteria to assess and compare

different multi-agent system (MAS) based on selected methodological features (Giorgini et al.,

2004). It assesses MAS from the conventional software systems perspective as well as agent

based ones. The former provides well established list of generic system engineering features

while the latter presents various agent-oriented aspects. Also several evaluation criteria were

added to account for software and web-based applications new industry standards such as:

support for ontology, service-oriented- architecture, etc. The evaluation criteria were grouped

under four categories, each focuses on a specific aspect of the MAS framework, in order to

assure the objectiveness of the comparative analysis as well as to ease the evaluation framework

validation by domain experts. The elements of the evaluation framework thoroughly discussed in

the following subsections.

2.3.1 Comprehensiveness of the MAS Traffic Management Capabilities

The investigated systems were research prototypes that addressed either freeway corridors or

intra-city arterials network. In order to demonstrate their full potential, some of those systems

included a full array of traffic control subsystems (traffic signals, ramp meters, and VMS’s).

Incorporating an optimal algorithm for each of those subsystems was way beyond feasible within

the vicinity of a research prototype (Rindt et al., 2007). In fact, all of the investigated systems

used simplified operational algorithms in order to reduce the implementation complexities.

While those assumptions are acceptable for research purposes, they are unsuitable for real life

deployment.

25

Thus the scope is not to evaluate those subsystems optimization algorithms but rather to assess

the MAS capability to incorporate different traffic control subsystems and capabilities. The

MAS traffic management capabilities are better judged by the comprehensiveness of their

endowed knowledge model KM and its ability to model various subsystems control knowledge.

In addition to the flexibility of the MAS architecture to adopt modular structure and/or to

provide interfaces that allow plug-and-play of subsystems control algorithms. Such flexible

architecture will allow the system to adapt to changing requirements and to incorporate newly

evolved algorithms in a seamless manner.

2.3.2 Underlying Processes Realization and Integration

The reviewed MAS focused mainly on automating some traffic incident management TIM

processes and/or providing a decision support tools to the human operators (Logi and Ritchie,

2002). However, they did not investigate how to fit the provided solution within the regional

TIM system organizational structure and processes workflow. It is in the authors’ view that the

unsuccessful/short deployment of the reviewed MAS can be largely contributed to the absence of

an underlying process model.

The software applications under study, if deployed, will likely have large scale

implication on the whole TIM system key operational processes and organizational structure.

Therefore, a thorough understanding of the regional TIM system structure and dynamics is

essential in order to assure the successful deployment of such applications. Process models

allow the developers to thoroughly understand the system dynamics and use software solutions

as the enabling technology to achieve system improvements, representing an added value rather

than just automating existing processes.

None of the reviewed systems incorporated non-traffic agencies (e.g. police, firefighters,

emergency medical services …etc.) into their organizational structures, which contradicts the

multidisciplinary nature of the TIM process. TIM is a collaborative decision making process,

the traffic MAS must be capable of representing this. However, only the CARTESIUS model

demonstrated the possession of intra-agency communication capability through the defining its

TIM domain as a multi-jurisdictional problem. It models the TIM process as two interacting

agents (Freeway and Arterial) exchanging information/data to reach a consistent global plan.

26

Table 2-2: MAS Traffic Management Characteristics CARTESIUS InTRYS TRYSA2 KITS FLUIDS System Goal Freeway Corridor &

neighbouring arterials TM Freeway Corridor TM Freeway Corridor TM Urban City TM Urban City TM

Key theoretical contribution/s

Applying FA/C algorithm in DPS TM environment

Modular knowledge layer complementing TM capabilities

Agents’ Structural Cooperation mechanism

Knowledge layer act as decision support tool above traffic subsystems

Reasoner for traffic input questions

Major characteristics

- Reflect TM jurisdictional distribution. - Local management of TM data resources

- Divide network into homogenous problem area - Inconsistency detection and resolution by coordinator agent

- Divide network into problem areas - Inconsistency detection and resolution by game theory

Generic building block libraries, if integrated with site-dependent knowledge creates site specific application model

Answers and explanations in a user-system dialogue context

Deployment/s Lab simulation – City of Irvine, California U.S.A.

Site validation – Barcelona, Spain

Lab simulation – Barcelona, Spain

Site validation – Florence, Italy

Lab demonstration – Turin, Spain

Deployment area characteristics

4miles of 3 freeway segments and 20-km2 of adjacent arterials

City of Barcelona ring road, and five adjacent arterials

City of Barcelona ring road, and five adjacent arterials

City center major arterial system, “Viali Ring” (8km) Unspecified

Traffic Control Infrastructure

258 loop detectors 34 VMS 22 signalized intersections 18 ramp meter drives



200 loop detectors 30 signalized intersections Unspecified

TIM area definition

Reflect TM jurisdictions division

Areas of consistent traffic behaviour and direction

Areas of consistent traffic behaviour

No division Total area management

No division Total area management

TM strategies - Traffic signals timing - Traffic diversion (VMS) - Upstream ramp metering

- Traffic signals timing - Traffic diversion (VMS) - Upstream ramp metering

- Traffic signals timing - Traffic diversion (VMS) - Upstream ramp metering

- Problem analysis/explanation - Pre-timed signal plans

Problem analysis/explanation

Supp

orte

d T

IM A

lgor

ithm

s

Incident detection Abdulhai neural networks model [ref] Not supported Not supported Not supported Not supported

Incident delay calculation

Akcelik model based on queuing theory

Deterministic queuing theory model

Deterministic queuing theory model Not supported Not supported

Incident duration Empirical model HCM-1994 Not supported Not supported Not supported Not supported

Congestion detection

Event driven based on change in traffic patterns

Fuzzy rules based on change in traffic patterns

Fuzzy rules based on change in traffic patterns

Problem detection by predefined patterns of traffic behaviour

Problem classifying using frame based reasoning

Ramp metering Demand/Capacity strategy (plus interface for ALINEA) ALINEA algorithm ALINEA algorithm Not supported Not supported

Traffic signal control

Akcelik &Gazis single signal optimization algorithms

Case specific pre-time signal plans

Case specific pre-time signal plans

Scenario based signal timing plans Not supported

CMS

Intuitive driver behaviour model: Compliance Rate (CR) = f(problem type, delay, CR threshold)

Not supported Not supported Not supported Not supported

27

2.3.3 MAS Knowledge Model Related Criteria

Table 2-3 summarizes the endowed knowledge models characteristics, while Table 2-4 presents

the key benchmarking criteria of the reviewed MAS knowledge models. The endowed

knowledge model together with the software architecture represents the two significant elements

in determining the MAS capabilities. All the reviewed MAS present the TIM domain KM as a

structured collection of Problem Solving Methods (PSM) (Ossowski et al. 2004, 2005). Although

building knowledge bases using PSM facilitates their re-implementation in similar situations,

they still suffer from some serious limitations:

§ Firstly, PSM do not prerequisite formalized conceptualization of the domain knowledge,

which might lead to the same domain concepts being interpreted differently in various

applications within the same domain.

§ They do not have the expressiveness to describe the elements and attributes that define TIM

processes workflows as well as their underlying operational policies, rules and guidelines.

Such elements and attributes proved to be crucial to incorporate in the developed knowledge

bases in order to assure the system successful deployment, as pointed earlier.

§ When extending some application functionalities or modifying existing rule in response to

changing needs, PSM do not provide mechanism or tools for consistency check, essential to

assure that there is no contradiction or conflict between the new functionalities/rules and

existing one.

§ PSM do not allow the deduction of new knowledge from existing ones. In fact the problem

solving strategy is usually coded in a rule-based format. This will leave the system brittle and

susceptible to failure when faced with situations that is not pre-coded in the knowledge base.

§ The only available reusability option is to extend the generic upper level PSM modules to

develop new application specific knowledge bases. The use of the abstract PSM does not

guarantee the interoperability between the different developed applications.

§ Finally, the use of common vocabulary is very limited in PSM. Common vocabulary

provides a common language among interacting applications, and expressing properties of a

particular domain among involved stakeholders. They are the components of the message

28

contents exchanged between interacting software agents and form the foundation of the

Agent Communication Language (ACL) in a specific domain (Bellifemine and Poggi, 2004).

The KM’s endowed in the reviewed systems were designed to address traffic congestion and/or

incidents management (Cuena et al., 1995). They lack a core model that captures the whole

traffic engineering domain in an abstract manner. It became a common practice in knowledge

engineering to develop an abstract upper level model of a specific domain, and later extend this

model to cover other sub-areas of the domain (Hernandez et al., 2002). Such model will assure

that the extended models share the same concepts and logic structures, achieving interoperability

and on the same time reducing conflicts and consistency errors between sub-models. In addition

to allowing the system to provide inference at various levels of abstraction, reducing required

computational costs as well as providing reasoning to best fit the current situation requirements.

However, the development of such core model was hindered due to the fact that the systems

under study were modeled using frames representation and procedural rules. Capturing a whole

domain, even in an abstract manner, using those tools is both too tedious and sophisticated to

accomplish.

Four different cooperative behaviour patterns were identified to be used by the systems

under review. The first of these, Organizational structuring, used by CARTESIUS, provides a

framework for activity and interaction through the definition of authority relationships, yielding

client/server architecture for task and resource allocation among agents. However, centralized

client/server is contrary to the decentralized nature of multi-agent systems. KITS deploys a

Contract net protocol approach, in which agents take on two roles, a manager and contractor.

The premise of this form of coordination is that if an agent cannot solve an assigned problem

using local resources/expertise, it will decompose the problem into sub-problems and try to find

other willing agents with the necessary resources/expertise to solve these sub-problems.

InTRYS deploys a centralized planning approach, where a coordinating agent receives

partial or local plans from individual agents, identify potential inconsistencies or and conflicts

and combines them into a multi-agent plan where conflicting interactions are eliminated.

However, this approach suffers from synchronizations delays, creating a system bottleneck

represented at the coordinating agent. On other hand, TRYSA2 deploys structured cooperative

negotiation model. In this approach, agents individually share their partial plans and tasks,

29

incorporating a conflict resolution algorithm, based on Game Theory, to reach a consistent global

plan. It is considered to be the most relied upon technique for agents coordination; promoting

concurrency in execution of agents task, significantly reducing synchronization and

computational loads.

However, on the TRYS family agents communicated using messages, and the contents of

those messages is based on procedural rules coded using a script language, i.e. no conceptual

model of vocabularies. The TRYS family is the only reviewed MAS to show commitment in

providing common domain concepts, even though in a very limited manner (only 9 terms).

Finally, only the TRYS family reported the re-use capabilities of their KM in similar application

scenarios, reporting 75% decrease in deployment time when comparing their MAS to other

similar TIM systems.

30

Table 2-3: Endowed Knowledge Model Characteristics

CARTESIUS InTRYS TRYSA2 KITS FLUIDS Model Competencies

What is the problem? What is the response?

What is happening? What may happen if? What to do if?

Where is the problem? How severe is it? What is the problem cause?

What is the problem? Where is the problem? What is the response?

What is happening? What may happen if? What should be done?

KM Approach Structured collection of Task, Inference and Domain knowledge (PSM)

Structured collection of Task, Inference and Domain knowledge (PSM)

Structured collection of Task, Inference and Domain knowledge (PSM)

Unspecified

Hierarchal collection of Task, Inference and Domain knowledge (PSM)

Organization of Agent’s Knowledge

Jurisdictional organization (freeway and arterials differentiation)

Topological structure approach (spatial breakdown of the traffic network into consistent one-way sub-network)

Topological structure approach (spatial breakdown of the traffic network into consistent two-way sub-network)

Functional organization Topological organization

Functional & Topological organization

Reasoning Structure

Problem characterization Problem description Problem response

Diagnosis Prediction Configuration

Model Revision Diagnose Repair

Model Revision Diagnose Prediction Prioritize solution

- Conversation analysis - PSE navigation - Inference structure

KM Architecture

5 level structured collection of KU. Top level formed of three modules: problem characterization, monitoring, & control.

7 Knowledge unit encapsulate both procedural and declarative knowledge

7 Knowledge unit encapsulate both procedural and declarative knowledge

Local domain knowledge using frames representation and structured collection of KU

Presentation Layer Problem Solving Medium Underlying Information System

Conceptual Models Does not exist

Two Ontologies defining Network Physical Structure & Control Plans

Two Ontologies defining Network Physical Structure & Control Plans

Does not exist Unstructured domain conceptual vocabularies

Knowledge Models

- Problem Scenarios - Demand Model - Control Actions Plans

- Physical network Structure - Problem Scenarios - Demand Model - Control Actions Plans - Abstraction Functions Model - Compatibility Model - Priority Model

- Physical network Structure - Problem Scenarios - Traffic Distributions - Historic Traffic Demand - Control Plans interrelations - Agents dependencies - Norms

- Data completion model - Problem Identification - Flow behaviour - Local control decision - Control priority -Global consistency check

Unspecified

Coordination Policy

Two interacting agents using RPC Centralized (coordinator agent) Autonomous based on

cooperative behaviour

Support centralized or complete autonomous model

Single agent system

Knowledge representation

Frame and rule based predicates

Frame and rule based Triplet predicates

Frame and rule based Triplet predicates



KM Software Environment G2 Expert System Shell KSM Software tool Object oriented extension of

SICStus Prolog KSM Software tool KSM Software tool

31

Table 2-4: Knowledge Model related criteria

CARTESIUS InTRYS TRYSA2 KITS FLUIDS

Autonomy Supported w/ user’s inputs at decision points

Supported w/ user’s inputs at decision points

Complete autonomy of interacting agents

Supported w/ user’s inputs at decision points Not supported

Reactivity Event driven AID algorithm or Users system entry

Perception layer Perception layer/ interaction with other agents requests

Perception layer User Interaction

Domain conceptualization Congestion/Incident Management

Congestion/Incident Management




Knowledge representation Rule based Expert System

Rules, frames representation, and hierarchal PSM




Completeness/ Expressiveness Application limited Application limited Application limited Application limited Application limited

Abstraction Single level of reasoning

Single level of reasoning



Various levels of abstraction

Consistency check capabilities Limited Limited Limited Limited Limited

Modularity Low support Medium support Medium support Medium support Medium support

Cooperative behaviour Yes-FA/C algorithm Yes- Upper level coordinator agent

Yes-Structural cooperation mechanism

Yes- Upper level coordinator agent Unspecified

Support message communication Synchronous messages Unavailable Synchronous messages Unavailable Unavailable

Use of Domain vocabulary Unavailable Very limited Very limited Unavailable Limited

Provide underlying reasoning

Supported Supported Supported Supported Supported

Ease of Understanding Medium Medium Medium Medium Medium

Model reuse Not supported Substantial customization

Substantial customization



Use of Ontology Not supported Limited Limited Not supported Not supported

32

2.3.4 Software Architecture and Technology Related Criteria

Software architecture refers to the structure and relationship between systems components, while

technology refers to the used tools and applications to implement those components and the

interfaces between them. Only software technologies that had significant impacts on the system

behaviour and performance were included. This is due to the fact that the technologies used in

development of reviewed systems had been out-dated and their detailed evaluation will be

irrelevant. It should be noted that aspects that are not related to the TIM capabilities or

performance are not included in the evaluation criteria, e.g. security, as they are considered out

of the scope of this article. Table 2-5 provides the items included in this comparative analysis.

Interoperability is perceived as one of the key components for MAS. The ability to

support different kind of hardware and operating systems, communication networks as well as

agent architectures, will determine to a big extent the success of the MAS deployment. In

addition, the MAS should provide the capability to support interoperability between legacy and

conventional software systems. This sort of interoperability is realized through using middleware

solution to build the MAS and to support their execution and essential operations such as

communication and coordination (e.g. JADE) (Bellifemine et al., 2001). However, none of the

reviewed system was built using such type of middleware, or even provided the built-in interface

to supports such approaches. The Internet is currently the most important application domain,

providing various mature Web-based technologies (e.g. Web services) for MAS communication

and integration with heterogeneous software and hardware systems are available to achieve this

sort of integration.

Even though the reviewed systems exhibit modular software architecture, they have a

tight integration between their business logic (algorithmic codes) and the code implementing the

Graphical User Interfaces used by the operators (Logi and Ritchie, 2002). Such behaviour is

mainly induced by the tools used to build the MAS, e.g. G2 expert system shell for

CARTESIUS and Tcl/Tk command language for other MAS. The tight coupling leads to

complexities in modifying existing operational rules, extreme difficulties in upgrading existing

traffic control algorithms and made the adding of new enhancements or features a sophisticated

process. In addition, any attempt to modify or extend the existing business rules (used TIM

algorithms) by non-programmer traffic engineers became extremely unfeasible.

33

Table 2-5: Software Architecture related criteria CARTESIUS InTRYS TRYSA2 KITS FLUIDS

Dynamic Structure Strictly 2-agent system

New agent of the same platform can be added with significant customization New agents of the same

platform can be added

New agents can be added to the system with significant customization

Not supported

Agent interoperability No other agents from other platforms can be added.

Interface can be provided at the controller agent level only

Size of MAS 2 18 11 3 main agents & 8 functional agents 1

Agent interaction/communication protocol

Java Remote Procedure Calling Linda tuple space Linda tuple space Unspecified Unspecified

Message exchange capabilities Not supported Linda tuple blackboard Linda tuple blackboard Not supported Not supported

Robustness Failure of any agent will fail the systems

Agent failure will impact only the area the agent is responsible for

Controller agent is the bottleneck, its failure severely impact system

Failure of any agent will fail the systems

Single Agent system with single point of failure

Support for legacy systems Not supported Not supported Not supported Supported through customized interfaces

Supported through customized interfaces

Agent implementation language

G2 Expert System & C++ language Prolog & C++ languages Prolog & C++ languages Unspecified Unspecified

Human-computer interaction GUI GUI GUI of Monitoring Agent GUI GUI/Agent Presentation layer

Compliance FIPA Medium support Low support Low support High Support Low support

34

Another point that worth mentioning is, G2 is a proprietary language, thus the vendor lock-in

limits the development of third party tools that might be used in the system. The existence of

general purpose libraries (e.g. C++ DLL) that support system programming tools decreases the

developers coding time as well as the propensity for faults in the system design, since general

purpose libraries receive substantial testing by its users community reducing the prevalence of

bugs. However, the Tcl/Tk and Prolog languages used to code the TRYS agent family provide a

set of limited third party tools that can be used to develop GUI and other supporting capabilities

for the MAS.

The two interacting agents model that relies on Remote Procedures Calls (RPC) for

communication deployed in CARTSIUS, limits the implementation of the system to include

more than two agents structure that lies in its original deployment. In addition, RPC may cause

the system to remain indefinitely suspended, in case of network communication failure between

the two interacting agents. In the TRYSA2 system communication between agents is realized

through Linda tuple space using Blackboard Architecture. In addition of being out-dated

technology, Linda coordination language is of limited execution speed compared to Message

Passing Interface systems. In terms of communication requirements (i.e. synchronization effort),

compared to TRYSA2 both CARTSIUS and InTRYS has limited amount of exchanged

messages. Obviously, during the social interaction process of TRYSA2 much more messages are

exchanged. However, the social interaction process supports system concurrency, i.e. the ability

of the system to multi-task and synchronizes multiple activities at once, irrespective to those

activities nature or functionalities.

From an architectural point of view only the TRYS agent family truly support scalability;

however the introduction of new agents to the system does not take a plug and play paradigm.

InTRYS system requires only editing the coordinator agent, reducing modifications to only one

component of the system. On the other hand, all TRYSA2 agents require to be edited when the

system is scaled up. With the exception to TRYSA2, all of the reviewed systems are considered

to be single point failure systems, i.e. exhibits poor robustness. InTRYS and KITS system

bottleneck lies in the supervisor agent, FLUIDS is a single agent system, and in CARTESIUS

the failure of any of the two interacting agents will fail the system. The TRYSA2 approach, in

contrast, allows agents to recover from failure, which rise from the fact of the autonomy of

35

traffic agents in managing their sub-areas. In fact, a failure of one agent might be beneficial to

the system conflict resolution mechanism, as it neutralize a possible source of negative inference.

2.3.5 Concluding Remarks of the Studied MAS

The shortcomings of the reviewed MAS are crosscutting including, oversimplified implemented

TIM assumptions, software architecture associated problems, limitations of endowed KM, and

tentative system design methodologies. Based on the comparative criteria presented in this thesis,

the following items envision the elements that should be incorporated in any future design of

MAS in the traffic engineering domain:

1. An open-dynamic architecture Web-based system, where various components can be

added or removed based on the traffic problem dynamics. Such components may be:

emergency dispatch software, evacuation planning algorithm ...etc. The new Web-based

service oriented applications (e.g. Web services) will provides means to integrate

conventional software components and application in a loosely coupled manner with the

system. In addition to promoting modularity, it facilitates the system access and monitoring

by various involved stakeholders, who will be able to modify existing or add new

components in an authorized manner.

2. Enhanced knowledge modeling techniques, Ontologies represent the state of art in

knowledge modeling. They describe multiple aspects of the problem domain at various levels

of abstraction in a conceptual model built using taxonomic hierarchies of domain formalized

vocabulary. Promoting the modular structure of the KM, and are equipped with consistency

check mechanisms and evolution tools essential for model derivation and extension. They

capture system actors, processes structure, and constraining rules; all of which are necessary

to define the system underlying process model.

3. Compliance with the ITS Architecture and the new FIPA standards, in order to assure

the alignment and the interoperability of any newly developed MAS with the existing TIM

software and hardware systems.

4. Follow a formal software design methodology (e.g. TROPOS) combining both Agent-

oriented and knowledge engineering approaches that define agents corresponding

36

organizational roles and acquaintances, adequately assessing agent knowledge modeling and

system requirements (Giorgini et al., 2004).

5. Focus on providing a decision support tool, separating heuristic knowledge from traffic

optimization codes and algorithms. Therefore separating business logic from implementation

algorithms/codes; consequently avoiding oversimplified assumption for the incorporation of

optimization algorithms and promoting system modularity facilitating its future modification

and upgrading.

6. Use new software industry standards for service oriented message, yellow and white pages

services that allow agents and software applications to communicate and register their

services within the system. Therefore supporting system scalability, robustness (through

redundancy), and message exchange capabilities.

7. Use general purpose Web-based language, e.g. Java, which will facilitate the system

adoption by developers, future modifications as well as access to unlimited third parties and

open source libraries to enhance and extend system functionalities.

8. Use agent systems middleware that promotes interoperability between heterogeneous

software and hardware systems (e.g. JADE) (Al-Aidaroos and Shuang-Hua Yang, 2005).

2.4 INCIDENT MANAGEMENT IN OTHER INFRASTRUCTURE SECTORS

This section briefly outlines previous work on developing incident management capabilities in

different civil infrastructure sectors, in an aim to draw lessons learned from other sectors

experiences and identify capabilities that should be incorporated in future traffic incident

management systems. Irrespective of the sector, civil infrastructures service disruptions/outages

shall only occur infrequently, impact only small area, have short duration and limited impact. In

order to achieve such objectives, infrastructure systems were equipped with incident

management capabilities. Although those capabilities vary depending on the sector, they still

share multiple common core management and control processes (Macaulay, 2009).

It must be emphasized that providing detailed analysis of each sector incident

management capabilities is out of this thesis scope, as it not feasible as well as irrelevant.

However, the aim is to provide comparison between main issues addressed in each sector; those

37

issues can be then extended and examined in details based on each sector nature and dynamics.

The author identified five main comparative criteria summarized in the following paragraphs,

while Table 2-6 summarizes major incident management capabilities in various civil

infrastructure sectors:

1. Assessment Strategy: with the exception of the transportation and information technology

sectors, incident management programs in other civil infrastructure sectors were primarily

approaced from vulnerability management approach, ignoring reactive incident management.

Vulnerability is defined as an internal weakness attributed to the entity/system, while threat is

an external event that exploits existing vulnerabilities. Even though these sectors possessed

capabilities for disruptions monitoring and dysfunctions/damages repair, much of their

incident management work focused on predicting locations prone (vulnerable) to incidents

and identifying necessary proactive countermeasures to minimize incident related impacts,

e.g. spare operational units and/or strategic resources allocation for immediate response

(Zografos et al., 2002). In fact, it can be said that those sectors focused more on vulnerability

management rather than incident management (Taylor, 2008).

With the rise of security concerns and the fear of terrorists attack, the nature of threat

factors that might exploits civil infrastructure systems vulnerabilities came into consideration

as well (Birkmann, 2006). For example a system overload threat has very different impact on

the network compared to sabotage or terrorist threats. However, only the information

technology sector took the track of defining the incident management capabilities in terms of

assessing the vulnerability of system components and correlating them with identified threat

agents that might exploit them (Albert, 2004). The definitions of threats and vulnerabilities

are discussed in more details in section 2.5.

2. Institutional Coordination and Cooperation: incident management is multidisciplinary by

nature; there is always significant informal agreements and liaison between responding

agencies (Ozbay, 1999). The transportation sector was the first to realize the importance of

developing formal collaboration agreements and protocols (Jenelius et al., 2006). After the

events of September 11, the US government established the Federal Emergency Management

Agency (FEMA) in an aim to carry over the role of institutional coordination. This model

was soon followed by several countries worldwide. FEMA created standardized organization

38

structures, processes and procedures as well as specifications for required resources

(Giuffrida, 1985). However, the integration and bridging of those standards with involved

parties heterogeneous IT systems and the interoperability of those systems still remains to be

achieved.

39

Table 2-6: Incident Management Capabilities in Various Civil Infrastructure Sectors

Transportation Information & Communication Energy Water Supply

Assessment Strategy

- Adopts both separate vulnerability assessment and incident reactive response approaches. - Mature incident management system with no integration with proactive assessments

- Adopts proactive vulnerability management approach that influences the design of an advanced reactive incident management system. - Defined strong correlation between threat agents and vulnerable elements.

- Proactive approach, focusing on predicting vulnerable locations. - Proactive measures are critical elements redundancy and resource allocation.

Support emergency maintenance plans only.

Institutional Coordination & Cooperation

- Formal inter-agency collaboration agreements - Standard organizational structure for incident management hierarchy.

-Not supported due to the private nature of the sector Unavailable Unavailable

Process Realization & Integration

- Informal realization of underlying process, required actors and designated roles. - Processes workflow is coded in the form of best practices and operational procedures.

- Clear formal incident management process model defining information exchange interfaces, actors, and designated roles.

Unavailable Unavailable

Established Shared Domain Semantics

-Very limited and are systems specific; developed to approach system level interoperability rather than domain level. -Same concepts has been used interchangeably and in different contexts with different interpretations.

-Several ontologies specifically tailored to describe sector incident management domain core concepts. -No census on domain core ontology, leading to multiple interpretations to same concepts.


Technology Integration & Lifecycle

- Technology integration is an important element in such sector. - Several standards for software systems have been developed, e.g. U.S. ITS Architecture and European ITS KAREN. -Established unified data exchange formats (e.g. DATEX) and abstract information sharing protocols in ITS Architectures.

- Regularly updated standards for software systems integration and lifecycle management. - Well established protocols and interfaces for information and data sharing, to mention few TCP/IP, REST, SOAP, RPC…etc.


40

3. Process Realization and Integration: Similar to the transportation sector, IT sector incident

management capabilities involve multiple processes belonging to different interacting

stakeholders. Process realization and modeling is an important step towards integrating

various stakeholders into an efficient cooperative incident management process. However

based on the author’s literature, only the IT sector took on the effort for modeling the

processes necessary for its incident management capabilities (Alberts, 2004). Much of the

work found in the information technology sector incident management literature was led by

the Institute of Software Engineering (ISE) at the Carnegie Mellon University (Alberts,

2004). In their incident management framework, the ISE defined vulnerability management,

risk assessment, institutional cooperation, and process integration to be all part of the

incident management framework (Alberts, 2004). The primary focus was on processes

workflow; defining process models to be enterprise driven, identifying roles and

responsibilities to ensure accountability, defining interfaces and communication channels

with supporting policies and procedures for coordination across process and process-actor.

4. Technology Integration & Lifecycle: nearly all civil infrastructre sectors were equipped

with technological capabilities that aided them to monitor their networks and report incidents

(Gorman et al., 2004). However, issues like technology lifecycle as well as inter and intra

sector data sharing and interoperability was not investigated thoroughly.

5. Domain Semantics: in order to achieve cross sector collaboration, various involved

stakeholders should share the same understanding regarding domain core concepts (Gorman

et al., 2004). However, based on the author’s literature incident related concepts were

interpreted differently within the same domain, as shown in detail in the following section.

However, only the information technology sector had took serious steps in building

ontologies to achieve semantic homogeneity among various stakeholders (Lukasik, 2003).

In conclusion of this section it can be said that the IT incident management capabilities were

found to be the most comprehensive among all other CI sectors. It addressed both proactive (i.e.

vulnerability management) and reactive (response coordination) measures as well as processes

realization and integration (Alberts, 2004). In addition, no argue that the vulnerability

management in CI sectors had led to better assessment of risks associated with incidents impacts

and justified the allocation of required response resources. Even though investments in

41

mitigations and preparedness have much higher return on investment compared to costs of relief

and recovery, focusing only on proactive measures had led to the ignorance of important issues

such as: institutional coordination and cooperation, development of operational best practice

guides, and technology usage and integration (Macaulay, 2009).

2.5 SEMANTICS OF INCIDENT MANAGEMENT

One of the key contributions of this thesis is the development of shared conceptual model

(ontology) for civil infrastructure incident management. This model can be then extended to

address specific systems in various civil infrastructure sectors, e.g. traffic networks, water

supply, electricity transmission networks … etc. Sharing common understanding of domain core

concepts is vital during major incidents that require efficient cross-sector coordination and

collaboration (Landwehr et al., 1994). The creation of shared conceptual model starts by

establishing common consensus among incident management stakeholders regarding the domain

(i.e. incident management in civil infrastructure) semantics.

The achievement of the before mentioned objective is not straightforward task. Incident

management has been addressed primarily in the civil infrastructure literature from vulnerability

management perspective; the term incident has been used interchangeably with threat, hazard

and risk to refer to the same thing while each of these terms is completely different from the

other (Taylor, 2008). Such contradictions in interpreting the domain core concepts hinder cross-

sector knowledge sharing and communication; leading to conflicting decisions and actions.

Measuring vulnerability of critical infrastructures helps to identify expected scale of

incident/s impact and thus the required level of response actions, i.e. incident management

processes. In fact, it can be said that vulnerability management is a prerequisite for successful

incident management measures (Birkmann, 2006). Vulnerability and incident management are

complementary but different; however there is somehow fuzziness is establishing distinction

between them in civil infrastructure incident management literature (Taylor, 2008). The

following subsections illustrate the semantics used to express the incident management domain

core concepts in various civil infrastructure sectors. Table 2.7 summarizes the interpretation of

incident management related concepts (Semantics of Incident Management) in the different civil

infrastructure sectors.

42

Table 2-7: Semantics of Incident Management in Different Civil Infrastructure Sectors

Vulnerability Threat Hazard

Transportation

Susceptibility to incidents that may cause considerable reduction in road network serviceability (Berdica, 2002). Taylor (2009) defines vulnerability as consequence of link failure.

Any external event (incident) that may lead to reduction in network capacity (Jenelius, 2010).

Used interchangeably with threat

Information Technology

Vulnerability is a system weakness. If realized by external threat agent, will lead to unwanted incident (Dos et al. 2008).

Threat is an event initiated by external agent Moriera and Martimiano (2004).

Unspecified

Energy Systems Holmgren (2007) defined vulnerability as an event leading to critical situations.

Threat is a critical situation that results from a deliberate event (US DOT Energy, 2009).

Hazard is a critical situation that results from non-deliberate even (Birkmann, 2006).

2.5.1 Incident Management Semantics in Energy Sector

The U.S. Department of Energy had produced a guide for vulnerability management for its

critical infrastructures. The primary focus was terrorist related incidents; the guide provided a

framework for 1) analyzing energy networks architecture, 2) assessing threat environment in

terms of physical, operational and procedural related security breaches, and 3) defining the

adequate response actions based on the expected scale of threat impact. In this report, incident

management was addressed completely from vulnerability management perspective and clear

mix up was made between threat and incident concepts.

Holmgren carried out similar studies focusing mainly on electric power supplies

(Holmgren et al., 2007). He defines vulnerability as “an event” that might lead to critical

situations “hazards”. Those critical situations evolve due to lack of system robustness and

resilience to various threats and hazards. He defined hazards to be an outcome of accidental

events while threats to result from deliberate events. Furthermore, the vulnerability assessment

approach involves evaluating the level of system vulnerability and examining options for

enhancing robustness/resiliency. Consequently, development of response plans to possible

critical situations and finding basis for choice between different responses.

Based on the author’s literature, the energy sector did not approach the incident

management domain directly but rather from the context of vulnerability assessment. In such

approach, the degree of response actions (incident management measures) was justified based on

43

the expected level of impact. Within, the same sector contradictions existed on defining the

domain core concepts. For example, vulnerability was seen in (Birkmann, 2006) to be an

inherited system physical or cyber weakness, while in (Holmgren and Molin, 2006) was

referenced as the incident event itself.

2.5.2 Incident Management Semantics in Information Technology Sector

The information technology sector was the first to realize the importance of semantics in the

incident management domain. Various ontologies were developed sharing the same perspective

of incident management, but providing different understandings of domain concepts. Tsoumas

and Gritzalis (2005) identified the following terms in their incident management ontology: asset,

stakeholder, vulnerability, countermeasure and threat. A stakeholder possesses an asset, which

can be compromised by vulnerability.

In addition, a threat initiated by an external agent targets the asset and exploits the

vulnerability of the asset in order to achieve its goal. Exploitation of a vulnerability leads to the

realization of an unwanted incident, which has a certain impact. Furthermore, countermeasures

reduce the impact of the threat with the use of controls. Finally, security policy formulates the

controls into a manageable security and incident management framework that is possessed by

stakeholders (Dos et al. 2008). Moriera and Martimiano (2004) developed security incident

management ontology. Their ontological model can be stated as: an agent performs an attack

that can cause a security incident; to perform the attack, the agent exploits a vulnerability to get

access. A security incident implies to consequence/s, counteracted by response measures.

2.5.3 Incident Management Semantics in Transportation Sector

The transportation sector had kept a clear distinction between vulnerability and incident

management. The former is well established in the transportation engineering literature, while

the latter has been an active area of research in the last decade (Jenelius et al., 2006). Incident

management in the transportation sector had focused more on the reactive measures, however

with the rise of security concerns vulnerability had moved in as an integral part in incident

management frameworks in order to develop adequate response plans based on expected scale of

impact.

44

Berdica (2002) defined vulnerability of road network as the susceptibility to incidents that may

cause considerable reduction in road network serviceability. Reducing the road network

vulnerability can hence be regarded as reducing the risks involved in various incidents. She

focused more on proactive rather reactive measures and on everyday incidents rather than

catastrophic ones; approaching the incident management problem from robustness perspective,

aiming to develop robust system.

On the other hand, Jenelius (2010) defined vulnerability to be conditional on threat

exposure; assessing criticality in terms of risks associated with impacts, investigating how is the

normal state can be restored (Jenelius et al. 2006). Taylor related the concept of vulnerability to

the consequences of link failure rather than the probability of link failure. He outlined that while

reliability and vulnerability are related concepts, reliability focuses on performance and

probability of failure, while vulnerability focuses on weaknesses and consequences of failure

(Taylor, 2008).

2.6 CONCLUDING REMARKS

The system developed within the scope of this thesis benefits from the achievement of the

extensive body of knowledge and research presented in this chapter, but will extend and integrate

the desirable elements in one system. The proposed system which is discussed in the following

chapters will be built upon an ontological knowledge model that encapsulates multii-disciplinary

knowledge pertaining to various involved stakeholders. Each involved response agency will be

represented with one or more software agent that acts on behalf of the human operator, and

prompt for input/s whenever necessary.

The software agents will utilize the underlying ontological knowledge model to perceive

the surrounding environment and reason for required actions using coded knowledge model

rules. Web services technology assures the shared access to required software/data resources

along with ensuring pervasive reliability and standardized acces of the developed system.

45

3 RESEARCH FRAMEWORK

3.1 SUMMARY

The research methodology follows an objective-centered approach and has three core

components, depicted in Figure 3-1.

For each of three core components, a set of development and evaluation criteria was

defined, as depicted in Figure 3-1. The development of ontologies and the multi-agent system

was guided by the benchmarking similar work in the literature. The sections in this chapter

focus primarily on the development tools, while evaluation tools are discusses in detail in

Chapter 7. The next section presents the Ontology development methodology, while section 3.2

presents the Semantic Web Incident Management System (SWIMS) development methodology.

Figure 3-1: Research Methodology Tools

46

3.2 ONTOLOGY DEVELOPMENT METHODOLOGY

The development of the ontology in in this research was guided by the Ontological Engineering

Methodology developed by Grüninger and Fox (1995), depicted in Figure 3-2. The ontology

development was derived by a motivating scenario. A motivating scenario is a detailed narrative

about a certain domain; emphasizing on specific problem/s in the domain or gaps that need to be

addressed by the ontology. It explains why the ontology is being developed and the intended

users. A conceptual model discusses the logic underlying of the ontology; illustrating

assumptions made about the domain; defining intended usage and bounding scope. The

motivation scenario for the developed ontology is outlined in Chapters 5.

Figure 3-2: Ontological Engineering Methodology Steps

The following three design principles have guided the ontologies development process:

§ Multi-perspective Approach. The ontology was designed to support the polymorphic nature

of concepts in the civil infrastructure domain in general and traffic incident management in

particular; allowing multi-perspective viewing of the ontology concepts in different possible

contexts.

47

§ Extensibility. The ontologies should allow for future extension, to address new applications

or in adaption to evolving needs.

§ Ease of Navigation. The ontology should be easy-to-navigate, i.e. the locating of concepts in

the taxonomy should not be difficult.

3.2.1 Ontology Scope Definition

As mentioned earlier in Chapter 1, one of the main components of this research is the

development of a domain conceptual model for civil infrastructure threats and vulnerability

associated elements. This model can be extended to develop various ontologies addressing risk

assessment or emergency management for different civil infrastructure sectors such as

transportation, energy, and water. The research further focuses on an ontology addressing

incident management in traffic networks. The incident management focus, however, does not

mean that the core conceptual model is only limited to this application.

Ontology scope definition aims to determine what functionalities the proposed system

will provide, based on identifying target stakeholders requirements, system objectives, and the

proposed added values. Although the requirement analysis literature reviewed by the author was

found to focus primarily on software applications, it can be argued that similar approaches can be

used to develop ontological models in different domains. In this essence, the author uses

requirement analysis approaches to develop the proposed system underlying ontology, critically

benchmarking the limitations of similar models found in the literature, and understanding the

modeling needs in the traffic incident management domain.

3.2.1.1 Core Conceptual Model Scope Definition

In defining the civil infrastructure threat and vulnerability conceptual model scope, the author

examined how previous knowledge/information modeling initiatives attempted to model the

domain of interest, i.e. civil infrastructure sectors. It was found that the various attempts to

conceptualize different civil infrastructures sectors associated risks or emergency situation

shared the following:

§ Semantic Heterogeneity. Domain core concepts were perceived differently among various

critical infrastructure sectors. Leading to different way to quantify risks and assess criticality.

48

§ Lack of Interoperability. All data models are sector-specific, as a result seamless data flow

and exchange between IT systems belonging to different sectors is hindered by the current

data representations forms.

§ Knowledge Representation. Most of the previous initiatives focused on data/information

format and exchange rather than knowledge modeling and capturing.

§ Object Oriented. Previous initiatives did not rely on object oriented modeling techniques for

their data modeling. Thus unable to capitalize on object oriented advantages such as

reusability, resiliency, adaptability, ease of integration, and appeal to human cognition.

Accordingly, the following set of requirements was deemed necessary in the domain-level

ontology, i.e. the conceptual model should be able to:

1. Provide a generic model describing elements of risk associated with various critical

infrastructure sectors.

2. Capture the relationship with civil infrastructure risk associated elements and describe their

correlations.

3. Capture the components defining civil infrastructure vulnerability.

4. Capture civil infrastructure topology, define component assets, system boundaries,

functions, and attributes and provide a standard way for capturing such topology.

5. Define the criticality thresholds associated with civil infrastructure threat and vulnerability

risk associated elements.

6. Represent the notion of concepts hierarchy, expressing the attributes of its concepts

7. Represent the notion of semantic similarities between inter and intra sector/s concepts.

8. Finally, the model needs to be able to represent the different contexts/domains that make a

particular piece of information valid.

49

3.2.1.2 Traffic Incident Management Ontology Scope Definition

The traffic incident management ontology underlying motivation scenario was elicited from real

life traffic incident management scenarios. The scope definition was carried out through

benchmarking its knowledge modeling capabilities to similar models in the literature, as shown

in Chapter 2., in addition to the author’s involvement in modeling the traffic management

requirements for Ministry of Transportation of Ontario Traffic Operations Centers, which will be

discusses in more details in coming section of this chapter.

3.2.2 Formulation of Competency Questions

Competency Questions (CQ) are formulated based on the carried out requirements analysis. They

represent the questions the ontology must be able to answer, characterizing its problem solving

capabilities. CQ guides the design of ontology; in fact the capability of the ontology to answer

the design CQ determines its conformance to development requirements. The formulation of CQ

is a two steps approach, which starts first by stating the questions informally; and later on

formally, utilizing the ontology defined terminologies and axioms. Informal refers to articulation

in natural language while formal refer coding using any ontology specification language, using

first-order-logic in case of developed ontology.

3.2.3 Taxonomy Building

Taxonomy is a hierarchy of related concepts. In the developed ontologies taxonomic hierarchies

were developed through the extraction and identification of main concepts in the infrastructure

and emergency/risk management domain. The taxonomy was constructed through gathering

exiting glossaries of terms and taxonomies of concepts found in related work in the literature,

including structured data models, codes, regulations, best practice guides, and interviews with

domain experts. The domain ontology taxonomy was mainly extracted from structured data

models, while the application ontology taxonomy was more knowledge intensive and relied on

unstructured data and knowledge, best practice guides, codes …etc.

The taxonomy building process used the Relationship Navigational Analysis taxonomy

building methodology (Gómez-Pérez , 2004). This methodology poses questions to concepts that

are already defined in the domain; discovering relationships with concepts holds with each other

as well as identifying the sort or type of the relationships. The Relationship Navigational

50

Analysis is considered to be an exploratory approach in modeling a domain of interest; helping to

identify concepts and relationships. Finally, it should be noted that the process of taxonomy

building is iterative by nature and involves multiples cycling of trials to reach a satisfactory

taxonomy (Fensel, 2002).

3.2.4 Relationship Analysis

The previously mentioned Relational Navigation Analysis methodology provides a systematic

technique for determining the relationship structure between domain core concepts. This

technique utilizes a series of Relationship Analysis Questions to extract domain relationships

(Osman, 2007). The 13 relationship categories used in defining the ontologies relationship

concepts are summarized below:

1. Generalization relationships: connects a concept to other concepts included in the

taxonomy.

2. Characteristic relationship: correlate a concept to other concepts that represents its

attributes, parameters, and/or metadata.

3. Descriptive relationship: link a concept to other concepts representing definitions,

illustrations, explanations, and/or descriptive information.

4. Aggregation relationship: connects a concept to other concepts that represents the whole

functionally or structurally.

5. Membership relationship: connects a member concept to of a collection to other member

concepts or a whole collection.

6. Classification relationship: connects a concept to its instances.

7. Ordering relationship: represents some kind of ordering between the ontology concepts.

8. Activity relationship – deals with relationships that exist among concepts that are involved

in some kind of process, activity or task.

9. Influence relationship – connects an item of interest to the item over which it has some

kind of influence (i.e., causal or control relationship)

10. Intentional relationship – connects a concept to the goals, objectives, and/or opinions,

associated with it.

11. Socio-organizational relationship – connects a concept to position, authority, alliance, role,

and/or communication associated with the concept social or organizational structure.

51

12. Temporal relationship – connects concepts based on temporal attributes.

13. Spatial relationship – connects concepts based on spatial attributes.

3.2.5 Axioms

Axioms define and constrain the interpretation of ontology concepts through using a formal logic

language. Formalization in the developed ontologies is achieved through using first order logic.

Definition axioms define concepts in terms of previously defined ones, while constraining

axioms are first-order logic sentences that constrain the interpretation using primitive terms and

definitions. They are used to demonstrate the ontological model competency.

3.2.6 Ontology Evaluation

Ontology evaluation is the technical assessment the ontology to assure its conformance to design

objectives and scope. Within this research, the developed ontologies were evaluated using

standard verification, validation and assessment techniques. Based on Gomez-Perez el al. (2004)

ontology is evaluated on the following components level:

§ Individual definitions and axioms

§ A module of definitions and axioms

§ Definitions/axioms imported from other ontologies

Gomez-Perez (2004) defines ontology verification as ensuring that the ontology

definitions/axioms are implemented correctly satisfying design requirements, competency

questions, and intended applications. Ontology validation refers to whether the ontology does

fully and formally capture the intended model and no other unintended models do exist.

Ontology assessment is focused on judging the ontology from a user’s point of view, usually

through a focus group of domain experts.

The ontology evaluation process must always be conducted using some sort of reference

criteria. These criteria might be requirements specifications, competency questions, and/or

formal excerpt models capturing intending ontology usage applications or scenarios. The

standard reference evaluation criteria of ontology were identified to be:

1. Consistency Check. Refers to the existence of contradicting interpretation for the same

concepts using different ontology axioms.

52

2. Completeness Check. Refers to the incompleteness of individual concepts definition in the

ontology, therefore the incompleteness of the ontology. An ontology is said to be complete if

all core concepts within the domain of scope are covered and can be inferred out of the

ontology according to the intended scope and meaning. In addition, for inexplicitly stated

knowledge, they should be inferred using ontology concepts and axioms.

3. Conciseness Check. A concise ontology is an ontology that stores no unnecessary or

redundant concepts or axioms.

4. Expandability Check. Refers to ability to add new concepts and axioms to the ontology

without altering the original well-defined ontological model.

5. Reusability Check. Refers to the ability of the ontological model to be incorporated in other

models conceptualizing different applications or even domains. Ontology reusability relies

on the degree in which the ontology can be reused to conceptualize new applications depends

if the ontology is dependent on certain types of tasks and/or methods or subdomains for the

domain reusability case.

The ontologies developed in this research employed all the above evaluation criteria, utilizing the

evaluation tools mentioned in the following points. Table 3-1 lists the usage of each of these

tools in the ontologies evaluation, while Chapter 7 of this thesis provides illustrative examples on

the used evaluation techniques and tools.

Table 3-1: Ontology Evaluation Criteria Used in This Research

Reference Evaluation Criteria Protégé Error Checker Expert Interviews Competency

Questions

Semantic Inconsistency Errors * * Circulatory Errors * * * Partition Errors * Completeness * * Redundancy * Expandability *

1. Protégé Error Checker. Protégé is the most widely used ontology editing application

developed in Stanford University informatics labs and the author utilizes its ontology

checking capabilities.

53

2. Expert Interviews. Refers to interviews carried out with domain experts in order to

evaluate the completeness and coverage of the ontology.

3. Formal Competency Questions. Answering the formulated competency questions to

check the developed ontology conformance with the development requirement analysis.

3.3 SEMANTIC WEB INCIDENT MANAGEMENT SYSTEM (SWIMS)

SWIMS development methodology adopts the approach defined by Bellifemine et al. (2001);

combining a top-down and bottom-up approach that accounts for both the existing system

capabilities (i.e. legacy systems and human operators) and the application overall needs (i.e.

requirements). There are four fundamental phases in the software development lifecycle:

planning, analysis, design and implementation/testing (Bellifemine, 2001), depicted in Figure 3-

3. The following sections in this chapter focus primarily on the first two phases, while the other

two phases are discussed thoroughly in Chapter 6 of this thesis. Both planning and analysis are

general in nature and independent of the adopted platform. Conversely, the design and

implementation phases specifically assume JADE as the implementation platform and focuses

directly on the classes and concepts provided by it, the discussion of which is deferred to Chapter

6.

The planning phase is closely related to the problem/s the system is trying to solve. It

defines the system scope; clearly identify directly involved stakeholders and their desired

objectives. The steps involved in the planning phase can be summarized as follows:

§ Step 1: Scope Definition. The problems the SWIMS system is trying to solve as well as

target goals and solution/s scope.

§ Step2: Stakeholders Identification. The users targeted by the SWIMS system are identified

together with each stakeholder’s objectives (business needs).

§ Step3: Processes Architecture. Models the business processes underlying each of the

SWIMS system services, including required resources and actors’ roles.

§ Step5: Requirement Analysis. Specifically points out required capabilities for the SWIMS

system business processes in order to fulfill required services objectives.

54

§ Step6: Performance Measures. Define the evaluation metrics for each process as well as

measurements for system services quality.

§ Step 7: Use Cases. The requirements from the previous steps are analyzed and use case

diagrams are created.

Figure 3-3: SWIMS Design Methodology Overview

3.3.1 Scope Definition

A traffic incident management (TIM) system can be divided into the following three main

components: (i) incident detection and verification, (ii) emergency response logistics, and (iii)

traffic management and motorist advisory. Emergency response is considered the least to be

addressed in the TIM literature; as most TIM previous work focused on developing isolated

models addressing the other two components (Zografos, 2002). Emergency response poses

multiple challenges: (1) involves multidisciplinary stakeholders, (2) formed of multiple highly

dynamic and cross-related processes performed under time pressure, (3) mostly rely on real-time

information coming from spatially distributed and heterogeneous IT systems, and (4) requires

the cooperation and coordination with on-scene incident responders (Ozbay, 1999).

55

SWIMS scope is stated as ’providing a framework for integrating various TIM systems

components into one coherent system, while specifically addressing incident emergency response

logistics’. Specifically, to assist various TIM operators in determining appropriate response

strategies and support the execution steps required for these strategies implementation. Response

strategies require collaborative cooperation of several agencies, thus SWIMS design does not

only focus on addressing strategies development but also the support of various individual and

agency-level interactions that take place.

3.3.2 Stakeholders Identification

Arguably, the most important step in the planning phase is to identify the key stakeholders

involved in TIM processes. SWIMS framework is designed to support three groups of

stakeholders directly involved in TIM, which are: 1) roadway travelers, 2) traffic operators, and

3) emergency response operators. Table 3-2 provides a description of supported stakeholders’

tasks/responsibilities within SWIMS framework. It should be mentioned that the system is

designed (illustrated in Chapter 6) to easily accommodate additional user-tasks and/or other

future stakeholders (e.g. evacuation planners, freight operators …etc.). However, the ones

addressed herein were deemed to be the most significant, based on the TIM literature and the

domain experts interviews (Appendix-J) carried out by the author.

As previously mentioned in Chapter 1, roadway travelers’ role in TIM is expected to

significantly rise and become even more vital in the next few years. With the advancement in

smart phone technologies and wide spread of social web tools and applications, travelers can

provide more accurate, credible and comprehensive incident information than ever before. For

example, a roadway travelers sending photo/s taken by smart phones to Google Maps based

traffic incident alerts portal, will allow incident responders to better assess the extent and

severity of the incident rather than waiting to arrive to incident scene or relying on

unclear/inaccurate reports. In addition, the coordinates of the smart phone reporting the incident

can be used to accurately locate the incident or even identify the identity of the alert sender to

further enhance the alert credibility.

In addition, SWIMS adopts the US Home Land Security Department, National Incident

Management System (NIMS) organizational hierarchy in identifying stakeholders in TIM

(Giuffrida, 1985), depicted in Figure 3-4. This hierarchy defines nine types of Actor-based, and

56

four types of Role-based stakeholders. Each actor-based stakeholder performs a unique set of

functionalities that cannot be performed by any other actor, while role-based stakeholders

represent a set of generic tasks that can be performed by designated actors based on the incident

type and severity. For example for low severity car collision incidents, law enforcement officers

usually overtake the role of incident commander; however if the incident involves hazard

materials spills, the unit leader of a HAZMAT team will overtake this responsibility. NIMS was

developed in 1980 in an aim to standardize on scene TIM, allowing various stakeholders to adopt

an integrated organizational structure for traffic incident management (Giuffrida, 1985).

Table 3-2: Description of Supported Stakeholders’ Tasks/Responsibilities

SWIMS Emergency Services Operators (Police, Fire/Rescue, and 911 Call Centers)

§ Operator receives and log incident information in a database, for major incidents there can be very large number of calls that need to be handled.

§ Determine the required initial response and dispatch resources; often relying on the first responder to arrive the incident scene to verify incident extent and severity, so it takes time to fully mobilize.

§ In case of multiple incidents, the operator uses the initial information available to respond to the most perceived to be serious and adjust response as required.

§ Control centers monitors progress and coordinate communication with other responders; they rely on updates from on scene crews and traffic operation centers surveillance.

SWIMS Traffic Management Center/Operator

§ Monitors traffic hotlines for incidents reporting from public, professional drivers, and contract patrols.

§ Receives phone calls reporting or asking for verification of an incident occurrence from other agencies such as police, fire, ambulance, local government…etc.

§ Monitors traffic control systems as well as automatic incident detection systems.

§ Review CCTV cameras to verify potential incident and provide videos to other responders.

§ Deploy incident response, including traffic management plans for ramp metering, updated signal timing, and VMS.

SWIMS Motorists/Travellers

§ Report incident occurrence to emergency service or traffic operation centers, usually through phone calls. Preliminary incident report from public is usually inaccurate, conflicting, and may lack credibility especially for off peak reported incidents.

§ Receives traffic and information updates and perform informed travel decision accordingly.

§ Inquire regarding current traffic conditions through internet access or calling traffic hotlines.

57

Figure 3-4: Organizational Hierarchy of TIM Stakeholders

Incident commander is the highest point of authority during TIM, this role is responsible for

evaluating incident situation, providing the tactical objectives, controlling the cross-agency

communication process, and most importantly assign required response resources.

Communication officer is responsible for receiving incident alerts and notifications from

multiple sources, verifying the incident occurrence, generating and sending initial incident report

to the incident commander. In addition, the communication officer may take over some of the

incident commander duties in major incidents.

Liaison officer functions as point of contact between the system and various public and

commercial media services providers. This role is not directly in the TIM and concentrates on

coordination with media organizations and agencies that disseminate incident information to

impacted passengers and travellers.

A safety officer is a technical role that varies with the incident type, this role updates and

approves the initial incident response plan based on the incident preliminary reports. It is usually

a domain expert with sufficient knowledge on specific types of incidents, e.g. incidents involving

severe contaminations, high risk criminal activities …etc.

58

3.3.3 Traffic Incident Management Underlying Processes

SWIMS process hierarchy starts with level ‘0’ for value chains, up to level ‘3’ for process

procedure. Level ‘1’ represents major operational processes; their objectives fulfill SWIMS

strategic goals and their metrics define the direct added value to end-user (traveller). SWIMS

level ‘2’ processes are technical processes; their metrics define SWIMS operational efficiency;

they are directly correlated to available system IT capabilities and resources performance. Table

3-3 provides an architectural analysis of SWIMS processes; the processes structure presented in

the table is derived from the Canadian ITS Architecture, corresponding to the user-services

defined in the previous section (2010).

Table 3-3: Horizontal Decomposition of SWIMS Value Chain

Level 0: Value Chain – Traffic Incident Management

Level 1 Processes Level 2 Processes Process Controller

1. Detection

1.1 Automatic Incident Detection 1.2 Telephone call 1.3 CCTV Camera Detection 1.4 Freeway patrol 1.5 Internet Alert

§ 911 Emergency Center/Operator § Traffic Operations Center/Operator § Police Call Center/Operator

2. Verification

2.1 CCTV Camera Verification 2.2 Scene Dispatch Verification 2.3 Determine Actors’ Roles 2.4 Incident Report Generation

§ Traffic Operations Center/Operator § On scene law enforcement officer § Freeway patrol

3. Emergency Response

3.1 Initial Response Plan Generation 3.2 RU Assignment and Dispatch 3.3 RU Routing (Scene Access/Egression) 3.4 Incident Scene Monitoring

§ Traffic Operations Center/Operator § Police Call Center/Operator § Emergency Response Operator § Emergency Vehicle Driver

4. Traveler Information 4.1 VMS Update 4.2 Web Update

§ Traffic Operations Center/Operator

5. Traffic Control

5.1 Duration and Delay Estimation 5.2 Simulation/Impact Area Estimation 5.3 Signals Timing 5.4 Ramp Metering Update 5.5 Network Monitoring


Processes are assigned based on the hierarchal structure defined in Figure 3-4 according to one

or more of the following criteria: technical skills, organizational position, geographical location,

and/or workload balance. Finally, each process in the presented architecture is integrated (if

required) with existing legacy systems and resources. Table 3-4 illustrates key TIM processes

59

together with their corresponding flow rules/decision criteria, performance metrics, legacy

resources, and associated risks that should be incorporated in the system design.

For each process in Table 3-4, process metrics are defined; such metrics can be used for

system monitoring allowing the identification of on time, overdue and at risk processes. This in

turn will allow the prior anticipation of problems ahead of time, reassigning work and managing

risks and fulfilling performance goals. In addition, each process has one or more identified risks

that can be grouped under one of the following three categories: technical, temporal, and liability

risks. Liability risks refer to the legal responsibility of the traffic management agency on

disseminated incident and traffic information, i.e. what if they increase travel time delay rather

than easing it. Temporal (delay) risks as the name implies refer risks that might delay any of the

incident relief efforts. Technical risk (improper assessment, inaccurate estimation and improper

roles assignments) as well as temporal risks usually lead to safety and operational impacts; safety

impacts result from the delay in relieving incident victims, while operational impacts refer to

increase in network level of congestion and total travel delay.

60

Table 3-4: TIM Key Processes Business Rules/Decision Criteria and Main Attributes

Process Business Rules/Decision Criteria Metrics Legacy Systems/Resources Risks

§ Detection

§ If incident reported by police/service patrols à Triggers incident report generation process § If incident reported by other sources à

Triggers incident verification process

Detection Time- Occurrence Time

§ Automatic Detection Algorithm § Map visualization application

§ Detection delay

§ Incident Verification § If incident locations is not within any camera à

Dispatch police/service patrol to incident scene

Verifcation Time - Detection Time

§ CCTV camera image/video captures § Locate closest camera algorithm § Map visualization application

§ Improper assessment § Verification delay

§ Determine Actors Roles § Given incident type and severity à

Determine actors for incident command hierarchy roles

NA NA § Improper roles assign

§ Incident Report Generation NA Incident Attributes NA § Insufficient Data

§ Initial Response Plan Generation

§ Given incident type and attributes à Determine required type and number of RU

Type/ No. RU NA § Improper assessment

§ Response Units Assignment and Dispatch NA Dispatch

Time § Closest facility algorithm § GIS Locations Map/s

§ Improper assessment

§ RU Routing NA Response Time

§ Shortest path algorithm § GIS Locations Map/s

§ Travel Delay

§ Duration/Delay Estimation § If delay and duration greater than threshold à

Traffic diversion is warranted Duration &Delay

§ Incident Duration Regression Model § Deterministic Queuing Algorithm

§ Inaccurate estimation

§ Simulate Traffic /Impact Area Determination NA NA

§ Traffic micro simulation application § GIS Map and software application

§ Inaccurate estimation

§ Signal Timing/ Ramp Metering NA NA

§ Signals optimization algorithm § Coordinated ramp metering

algorithm § GIS Map and software application

§ Total Travel Time Delay

§ Traveller Information NA Travel Time § Network Traffic Conditions Website § Map visualization application

§ Total Travel Time Delay § Information liability

61

3.3.4 Requirements Analysis

SWIMS requirement analysis addresses the TIM framework from two different but

complementary levels of abstraction, the strategic and process level requirements. Strategic level

addresses top level requirement that lay the foundation for cross organizational collaboration

during the incident management process. Process level requirements identify required

capabilities for the processes defined in the previous measures, enabling them to deliver the

system design objectives. In assessing current incident management practices, the following

question may be helpful in pointing out areas for TIM program development:

§ Are there gaps in the delivery of incident response services?

§ Are there any legal issues, constraints and concerns about liability?

§ How to address decision making subjectivity in currently performed incident response

processes?

§ Is there a need to formalize some of the decision making tasks?

§ How to address the dynamic nature of the incident management process and the

requirements of handling massive information flows among cross related processes?

§ What are the needs for data/information interoperability between different processes?

§ Do any of the involved stakeholders’ responsibilities conflict, and what are their priorities?

§ How to evaluate the proposed system and judge its performance?

3.3.4.1 Strategic Level Requirements

The development of the strategic level requirements was guided by the TIM Assessment

Framework developed by the US FHWA (2010). The FHWA Assessment Tool defines key

enabling criteria that are fundamental to achieve multidisciplinary collaboration during the

incident management process. These criteria are categorized under three main groups as depicted

in Table 3-5. Strategic level requirements are addressed by SWIMS underlying ontology and

Web 2.0 capabilities, as discussed in details in Chapter 5 and 6.

The major challenge facing incident responders is the existence of multiple-systems

operating independently, for example Police, Fire, Ambulance and transport agencies operating

separate control centers and using different communication and control systems. Prior to

incident detection and verification, control centers should determine adequate scale of response.

Planning ahead by considering all possible incidents that can arise and develop response

62

protocols, can save time when a response action is required. Also debriefs after each major

incident are invaluable to fine tune protocols and incorporate learning and update procedures.

Table 3-5: SWIMS Strategic Level Requirements

1. Institutional Requirements

1.1 Provide formal definitions of domain core concepts and formally identify shared terminologies to be

exchanged in interagency communication and to be used in describing response processes procedures.

1.2 Adopt incident proactive measures and risk assessment in TIM; identifying anticipated threats, existing

vulnerabilities, expected scale of impact, and quantify associated risks.

1.3 Develop formal and shared understanding regarding each responder process-roles, responsibilities and

define an agreed incident command hierarchy.

1.4 Establish criteria for incidents coding; including type, severity, and evolution monitoring measures.

These criteria should be agreed upon and shared among involved actors.

2. Operational Requirements

2.1 Formally define response process procedures using shared terminologies, including standard responses

to broad categories of incidents

2.2 Formally define each process constraining policies, associated liabilities and risks.

2.3 Define each response process performance measures, including establishing targeted thresholds

2.4 Identify each process predominant attributes, resources, products/outputs, actors, and actor-roles.

2.5 Determine the appropriate level of response, i.e. number and type of RU required to respond to each

classified incident type

3. Communication and Technology Requirements

3.1 Provide hardened/redundant communication system

3.2 Provide the ability to merge, integrate and interpret data from multiple resources; including heterogenic

IT systems as well as cross agency data/video information sharing.

3.3 Provide means to efficiently integrate freeway travellers in incident detection/verification and travellers

information dissemination processes using advancement in communication technologies and evolving

Web2.0 capabilities

The importance of creating formal shared definitions of domain shared concepts and

terminologies cannot be overstated. In a survey for TIM practices in 21 US states, Balke el al. (as

shown in Table 3-6) found that traffic agencies and other emergency responders tend to have

different definitions for incidents and its related attributes (Austroads, 2007). This has resulted in

different perspectives in quantifying incident associated impacts; consequently different

63

decisions regarding required response actions. As a result, Balke recommend having a one-size

fits all, i.e. common shared terminologies describing the different aspects of TIM (Austroads,

2007).

Table 3-6: Traffic Incident/Attributes from Different Responders Perspective (Austroads, 2007)

Concept Traffic Agency Perspective Emergency Services Perspective

Incident Non-recurring event that reduces road capacity or causes abnormal increase in demand

Event that requires response, jeopardizing public safety, life and/or property

Categories Based on traffic impact Based on number and severity of injuries and truck involvement

Performance Measures Detection, response, duration and clearance time

Mainly response time; used to justify preplanned resources allocation

Predominant Attributes Roadway type, location, no. of vehicle involved, lanes blocked, and duration

Location, no of injuries, Fire or HAZAMT contamination

Operational Procedures

Have incident response manuals to deal with different types of incident on the roads including plans and alternative routes

Have guides to deal with emergency services in dealing with safety and operations as they attends to the incidents on the road

3.3.4.2 Process Level Requirements

Process level requirement defines the capabilities required in TIM process with sufficient level

of detail however still solution independent, depicted in Table 3-7. These requirements were

determined from the TIM literature as well as through interviewing domain experts and incident

response operators. In the conducted interviews, the author had assessed the importance of each

proposed process requirement relative to system design objectives and targeted process

performance goals. The interview form is available in Appendix-E of this thesis. Process level

requirements were then used in developing the system architecture and design of system

components, as discussed in details in Chapter 6.

The analysis of the user requirements indicated tight coupling between system design

goals/objectives and response processes (i.e. response units assignment, dispatching, and routing,

to the incident scene). The objective of the response unit (RU) assignment and dispatching

processes is the identification, transfer of incident related information and the assignment of

appropriate RU for incident relief with the objective to minimize RU dispatch time. The

objective of the routing process is to minimize time to/from the incident scene in order to rapidly

relief and evacuate injured personnel.

64

Table 3-7: Process Level Requirement Analysis

1. Detection and Verification

1.1 Detect incidents from multiple sources and increase public involvement in detection and verification

process using rising social Web 2.0 tools.

1.2 Provide a graphical map interface for incident location and to visually monitor incident

evolution/response

1.3 Provide incident support system that enable to log events, coordinate incoming information using maps,

camera vision, current traffic conditions, locations of RU (using GPS), internet and media traffic reports

1.4 Share real time video feeds among emergency services responders, enabling then to directly verify

reported incident and determine individual scale of response

2. Emergency Response

2.1 Utilize support information that provides emergency operators with lists of contact detail of key

personnel, equipment and material by geographic area and location.

2.2 Locations of RU bases, including service area of each on duty RU

2.3 Determine number and type of RU needed to serve a given type of incident

2.4 Assign RU to incidents

2.5 Determine dispatching priorities in case of more than one verified incident

2.6 Routing of RUs to verified incident location, including warranting signal priorities

2.7 On scene traffic capacity restoration decisions

2.8 Monitoring of incident response resources performance (including graphical interface support)

3. Traffic Control and Traveller Information

3.1 Provide incident specific information to freeway motorists using suitable media resources, including:

commercial radios, Web 2.0 applications, emails/text messages (out of scope)

3.2 Update freeway VMS regarding incident occurrence (out of scope) 3.3 Provide motorist with travel time estimates for route segments 3.4 Optimize freeway ramp metering in response to prevailing traffic conditions

3.5 Generate traffic signal plans on freeway neighboring arterials in response to incident occurrence

3.6 Estimate incident duration based on incident attributes

3.7 Calculate expected total travel delay in the network resulting from the incident occurrence

3.8 Generate route diversion plans to divert incident impacted traffic (out of scope)

65

The processes requirements illustrated in the table above, dictates the provision of real time

information related to traffic characteristics, evolution of incident attributes, and availability and

characteristics of incident response resources. Aside from real-time information, the TIM

response processes require data/information related to spatial deployment of response resource to

determine RU service area and the corresponding response/utilization time. In addition, different

responders need to access and share traffic CCTV cameras video/image captures to verify

incident occurrence and individually assess the extent of required response.

Traffic operators need continuous flow of network traffic conditions data (speed, flow,

and density) in order to optimize signals timing and ramp metering to encounter of incident

impact on network performance. TIM processes require wide array of data/information flow to

support their functionality. Table 3-8 illustrates data/information flow requirements, essential to

support SWIMS processes requirements outlined in the Table 3-7.

The detection process is carried out by a combination of monitoring, surveillance and

notification processes. Based on (FHWA, 2010), the most predominant source of incident

detection in urban areas is freeway travellers’ cell phones, but the information credibility and

accuracy of this mean is largely questionable. However, with the wide spread of internet

connected smartphones, the efficiency of this source can be impressively enhanced using

evolving social web tools to check alert sender identity and thus incident alert credibility. Most

emergency call centers operate computer aided dispatch (CAD) systems that support call-takers

by prompting the questions to ask, providing support systems including maps, provided contact

details of responder including other agencies, providing means of logging information,

identifying the status/location of potential responder and tracking responders

The operator who first receives incident detection alert is responsible for creating incident

log and creating of initial report for distribution among other emergency service units. Typical

data required for incident log comprise a description of incident location, type, severity,

surrounding weather and roadway (i.e. number of lanes blocked) conditions. Incident locations

may is usually a verbal location reported from motorists on the scene or precise spatial

coordinates reported by on-vehicle may-day system, by all means incident location need to be

referenced to a digital map system.

66

Table 3-8: SWIMS Data/Information Flows Requirements

Process Input Data/Information Output Data/Information

Detection

§ Automatic Incident Detection (AID) software/algorithm monitoring CCTV images or vehicle detection systems. § Public phone calls emergency number (911 calls),

directed to police or emergency centers. § Telephone calls from freeway passengers using cellular

or road-side emergency phones. § Freeway or police patrols calling their respective

communication centers. § Closed Circuit Television (CCTV) cameras monitoring

the freeway network.

§ Incident alert report, containing initial incident classification and preliminary incident attributes § Incident estimated occurrence time § Incident recorded detection time

Verification

§ Initial incident report from detection process including all output data/information

§ Closed Circuit Television (CCTV) cameras monitoring the freeway network. Closed Circuit Television (CCTV) camera captures verifying incident occurrence, location and extent of severity

§ Phone call from police/freeway patrol dispatched to the incident scene

§ Exact incident location of a map; including both coordinates and address § Incident type classification § Incident severity attributes including:

number of fatalities, injuries, vehicles and trucks involved § Number of lanes blocked at incident

location roadway section.

Emergency Response

§ Incident report from verification process including all output data/information

§ Closed Circuit Television (CCTV) camera captures to assess extent of severity and individual required response efforts

§ GIS map defining network topology § RU locations and corresponding service areas § RU utilization data § Weather conditions data

§ Response plan identifying number and type of RU

§ RU dispatch requests and response messages

§ Route guidance data

Traffic Control/ Traveller Information

§ Incident report from verification process including all output data/information

§ Response plans from the emergency response process § Real time traffic data (flow, speed and density) § Historical traffic data § Traffic network simulation model § GIS map of signal and ramp meters locations

§ Incident duration and delay § Incident impact area § Route diversion plans § VMS messages updates § Traffic conditions webpage updates § Traffic broadcasts

Incident verification involves confirming incident occurrence and refining related data, obtaining

best possible information on location, nature, extent, and severity to enable effective response.

Verification process is conducted on two phase, the initial and on-site verifications. Initial

verification is carried out when the preliminary detection source is unreliable or the incident

reports are contradictory, most effective source is CCTV cameras in traffic control centers. On-

scene verification is conducted by first on-site emergency responder (police, fire, or ambulance),

who provide preliminary assessment of current status and advise on response requirements.

67

When an incident is reported SWIMS determines the type and locations of RUs to respond to the

incident and then route them to the incident scene, based on minimum en-route travel time. In

parallel with the response, communication links and the chain of command are established;

initial traffic management and provision of motorist information are commenced.

3.3.5 SWIMS Evaluation and Performance Measures

There is a need to measure and monitor TIM processes performance to assess their degree of

fulfillment to system targeted objectives as well as identifying opportunities for system

improvement and innovation (FHWA, 2010). The primary objective of any TIM system is to

minimize the incident duration, which is the time elapsed between incident first detection and the

clearance of incident up until the restoration of normal traffic conditions (Ozbay, 1999). The four

incident duration temporal metrics that are closely related to SIWMS performance measures are:

1. Detection time. Time interval from the occurrence of an incident until the time that the

incident is detected.

2. Verification time. Time elapsed between receiving the detection alarm and verification of

incident occurrence

3. Dispatching time. Time interval between incident detection\verification and dispatching of

the first available RU to be assigned to service the incident.

4. Response time. Time interval between the assignment of an RU to an incident and its arrival

at the scene of the incident.

SWIMS core objective is to minimize those four time footprints. These measures are closely

related to incident attributes (i.e. location, severity, time of occurrence, surrounding

environmental and traffic conditions), TIM system capabilities (available response resources,

supporting IT infrastructure, governing policies and constrains), and freeway traffic

characteristics (i.e. level of congestions and existing ITS capabilities) (Austroads, 2007). These

metrics significantly affect the incident duration and thus can be used to derive system users

travel delay cost that in turn can be used to support business cases for TIM development and

improvement. In addition, the duration of an incident determines to a great extent the degree of

the utilization of the response units, i.e. the extent of on-scene engagement of available

resources; thus the response resources availability to serve other incidents.

68

Figure 3-5: Traffic Incident Management Time Footprints

Average incident duration time components as identified by the City of Toronto Compass

Program are given in Table 3-9. The table classifies traffic incident into main three categories,

minor non-crash, minor crash and major crash. It should be noted that none of these incidents

involves trucks. These values will be used to evaluate the performance of the devised system, as

it will be evaluated in the same operation conditions and deployment sites.

Table 3-9: Performance Measures of Toronto COMPASS TIM system

Incident category Minor non-crash Minor crash Major Crash

Phase I Detect Verify Activate Incident Response

0-5 min 0-5 min

10-20 min

0-5 min 0-5 min

10-20 min

0-5 min 0-5 min 0-5 min

Phase II Arrival to Incident Scene Incident Site Clearance

10-15mins

10-35mins

30-60mins

Phase III Restoration of normal flow

Unknown Unknown Unknown

Agency Involvement

Assumes mobile police patrol and main roads TMC operators for all types of crashes

§ Police (possible) § Towing/Recovery

Crews (possible)

§ Police (definite) § Fire/Rescue (possible) § Towing/Recovery

Crew (possible)

§ Police (definite) § Fire/Rescue (definite) § Emergency Medical

Services (definite) § Towing/Recovery Crew

(definite)

69

3.3.6 Use Cases

Use-cases are an effective way to capture the potential functional requirements of a new system,

each use case present one or more scenarios that demonstrate how the system should interact

with the traffic/emergency operators or another system to achieve specific design objective/s.

There are number of standards for representing use cases, the most popular is the Unified

Modeling Language (UML) specifications, which defines the use-cases using graphical notations

(UML, 2010). As early mentioned, SWIMS provide four main processes for TIM, each process

is represented with a package that incorporates all the functionalities corresponding for the

process requirements early defined. Figure 3-6 illustrates the level groups of SWIMS application

functionality and the corresponding use-cases for each group.

3.3.7 Concluding Remarks on SWIMS Development

SWIMS was developed to tackle the key shortcomings identified in previously developed traffic

management MAS as per the conducted literature review outlined in Chapter 2. It is incorporated

with tools and capabilities to specifically overcome the eight main issues identified in section

2.3.5 and as summarized below in the same order as section 2.3.5:

1. SWIMS follows the SOA (Service Oriented Architecture) software paradigm to provide

an open-dynamic web-based architecture. The various system functionalities are

implemented as Web Services, which are plug-and-play components that can be easily

replaced. For example, the system utilizes basic traffic controls algorithms for incident

area wide traffic control, i.e. ALEANA and Webster. However, these traffic control

components can be easily plugged-off the system and replaced by more sophisticated

ones, according to the advancements in the traffic engineering domain. Legacy software

entities are integrated into the system through Web Service interfaces. Similarly,

unlimited number of software agents can join the system utilizing its open software

architecture along with the flexibility provided by the underlying knowledge model.

2. SWIMS underlying reasoning knowledge model is built using state of the art ontological

engineering knowledge modeling techniques. Ontologies allow the creation of modular

knowledge models that are capable of semantic reasoning and deducing new knowledge

from existing ones. The modular structure provides the flexibility of adding new

70

functionalities to the system upon need and as the system evolve. The advanced semantic

reasoning capabilities allow for knowledge model consistency checks so that no new

added knowledge would impact the reasoning integrity of existing ones, i.e. minimizes or

even eliminates conflicts among the model reasoning outputs.

3. SWIMS is built using JADE agent development methodology and middleware (Giorgini

et al., 2004). This methodology and middleware are FIPA compliant and is being

recognized now as one of the software industry standards for creating multi-agent

software systems. Furthermore, the used middleware is based on Java programming

language. This will facilitate the system adoption by developers, access to unlimited third

parties and open source libraries to further enhance the system performance. Java is now

considered the most widespread language for web based software applications

development, and based on the conducted literature none of the existing MAS were built

by Java. In fact, none of the reviewed MAS were developed by any web based

programming language, which will ultimately hinder their deployment on a pervasive

manner.

4. The system domain knowledge is captured through an ontological model, while the

algorithmic and optimization capabilities are deployed as Web Services. Therefore the

system underlying business logic is separated from the codes and algorithms;

consequently avoiding oversimplified assumptions associated with algorithmic

approaches, promoting modularity and facilitating future modifications and upgrading.

72

4 ONTOLOGICAL MODEL FOR THREATS &VULNERABILITY

4.1 PRECIS

Traffic incidents are a type of civil infrastructure incidents, which can be seen as a result of a

threat exploiting system vulnerability. To put the semantic description of traffic incidents, a

generic ontological model of vulnerability and threats in civil infrastructure systems is presented

first. The proposed ontological model is an extension of the DOCK ontology by El-Diraby

(2009). It also benchmarks work in related domains of other critical infrastructure sectors

(transportation safety, energy and computer security).

4.2 BENCHMARKS

One of the main lessons learned from the analysis of ontological modeling of vulnerability and

threats in others domains is the emphasis on the life cycle nature of both concepts. Incidents

should not be seen as a random occurrence or an event that relates only to transportation systems

operations. It has to be considered in all phases of infrastructure (transportation) system life

cycle—starting with planning (to avoid incidents, reduce vulnerability and understand threats),

budgeting, design, construction, operation, maintenance/rehabilitation, and decommissioning.

The proposed ontological model extends DOCK (El-Diraby, 2010). “Thing”, the base

term in DOCK, is categorized into two dimensional matrix. The first dimension is an aggregation

of three fundamental “Things”: concept, relation and axioms. The second is modality (means for

creating varieties of the “Things”) (see Figure 4.1). For example, applying the modality

“damaged”, “deteriorated”, “crucial” to the concept “bridge” produces the varieties: “damaged

bridge”, “deteriorated bridge”, and “crucial bridge”, respectively. It also assures that

“deteriorated crucial bridge” will/can be recognized as a type of bridge

The taxonomy of “concept” in DOCK recognizes the following categories: entity, quasi-

entity, environment, abstract concept, and system. Orthogonal to all of these is the last category

of concepts, the attribute concept. Entity encompasses three fundamental (ever re-occurring)

concepts in any informatics ontology: action, product and actor. A product can be knowledge,

knowledge item, physical product, and decision. Knowledge describes the conceptualization of a

73

specific subject, acquired either through experience or education (Osman, 2007). Knowledge item

is a physical or symbolic manifestation of knowledge, physical product is a tangible product of a

process, while decision is the selection of a course of action (Osman, 2007). An actor is an entity

that stimuli action/s either actively (e.g. operator) or passively (e.g. customer), usually refers to

human beings.

An action is modelled as either a process or event that produces/updates a product, uses

resource/s, and involves role/s carried out by actor/s. An event is defined as a noteworthy

instantaneous or temporally short occurrence that might or might not have an actor involvement

(El-Gohary, 2008). On the other hand, a process is structure of tasks (actors’ roles), usually

performed in certain sequence, producing service/product within a specified temporal duration.

A quasi-entity is formed of constraint, condition, resource, and mechanisms. Input is an

umbrella concept for resource and conditions. A resource is an entity characterized by being

quantifiable, consumable, reusable, being component of or committed to, and having usage and

consumption specification (El-Diraby, 2009). A resource can be: physical (e.g. equipment or

material), human, and financial. Mechanisms refer to logical and/or virtual resources that

conceptualize the way a system perceive and interact with its surrounding, it is divided into:

guides (theories, algorithms, scientific principles, and best practices), methods (techniques of

performing processes), and measures (tests and conformance metrics).

Constraints represent the elements that influence and control the behaviour of system

output, defined as: laws, specifications, user requirements, conditions, and surrounding controls.

Condition describes the boundary conditions of another concept without making any claims to

how restrictive they may be. For example, the type of contract, the type of project (whether civil

or building), and weather conditions describe what surrounds a project. A role is a designated

task in a process that can be fulfilled by unique or different actor/s.

An attribute is a concept describing certain characteristic of an entity through specific

numerical value, type or other class concept. Modalities are the distinct different forms of

perceiving a thing (i.e. an Entity and its orthogonal concepts). Abstract concepts include (the

definition of) things such as time, space, risk, motive, interest (of humans). It is important to

notice that meta-model ontology did not make any claim on the structure of abstract concepts and

were considered outside of its domain.

74

As shown in Figure 4-1, the concepts in DOCK are organized in four levels (zero through 3) that

can be seen as a measure of uniqueness (or independence) of concept and its degree of

granularity. Concepts in level zero are ever repeated in ontologies and represent the universals in

DOCK. Levels 1 and 2 include the main claims of DOCK (and its main interest). In fact, DOCK

does not include any concepts in level 3, as this is dedicated to sub-domain concepts.

Input

Concept

Mod

ality

System

Abstract C. Environment AttributeEntity

Product StateRoleActorAction

Sequence

Constraint

Resource

Spatiotemporal Location

Domain

Context

Boundary

Family

Genericentity

Quasi-entity

RelationAxiom

Thing

has

has

Level 1

Level 2

Nat

ural

Env

ironm

ent

Artif

icia

l Env

ironm

ent

SpaceTime

Knowledge

Risk

Level 3

Mechanism

Condition

Virtual Environment Quantity

Quality

Decision

Belief

Level 0

Figure 4-1: DOCK Ontological Model (El-Diraby, 2009)

A system is a set of interacting or interdependent entities. In DOCK, a system has the following

types (modalities) which are used interchangeably to describe the system concept:

§ Domain: refers to categorization of a system from a functionality perspective, e.g.

transportation domain having components such as: links, travellers, vehicles, legislations,

budget… etc. While the sub-domain/s for the transportation system might be an intelligent

transportation system, freeways system… etc. Within a specific domain Dock recognizes a

variety of subdomains: Mission-related (Operations & Production, Logistics & Storage,

Control &Monitoring and Operations Management), Mission Support (Power,

Communication, Life Support and Structure), Support activities (Administrative, Legal, and

75

Maintenance), and finally Protection (Physical Security, Cyber Security, Fire Protection,

Emergency Response, Safety Protection and Medical Support).

§ Context: this system is the result of applying different modalities to a domain to create a new

specific type of it that represent a specific situation (El-Diraby, 2009). For example, one can

talk about a new transportation system vs. an old one), secure vs. non-secure transportation

management system. The interrelationships and behaviour of concepts in a specific context

vary from their main (typical) behaviour, which is always described in formal domain. For

example, a privately run transit system establishes a management structure and

interrelationships between its entities that are different from a publically run system.

Similarly, vulnerable transportation system portrays different behaviour and follows

different rules from secure transportation systems. In short, a domain is meant to augment

some basic concepts that are typically related to each other (cohesive), while context is

meant to modify and scope these concepts and, more importantly, their interrelationships at

different situations.

§ Boundary: this system augments all entities that relate to a concept that are not necessarily

cohesive. For example, a traffic incident boundary is a reference to the geometrical

alignment of the road, vehicle conditions, driver conditions, weather conditions, status of the

nearby area, level of adequacy of response agents, and available resources to these agencies

at the time of incident.

§ Family: a reference (or a bag) to concepts that have similar modality but are not necessarily

related. For example, the family of secure concepts include secure document, secure

transaction, secure car, secure transportation systems, secure call. Of special interest is one

type of family: sequence. It refers to a life cycle of events. So an incident, for example, can

be represented as a sequence.

Each civil infrastructure system has a surrounding ecosystem that influences its behaviour and is

impacted by its performance/failure as well. The surrounding ecosystem is further extended into

four sub-concepts, defining the elements of nature/environment. These sub-concepts are: air,

water, soil, and living organisms (plants and animals).

76

Act

or

Proc

ess

Figure 4-2: Civil Infrastructure Domain Abstract Components

4.3 THE PROPOSED ONTOLOGICAL MODEL

The proposed ontological model is shown in Figure 4-3 below. The model aims to provide

consistent definition of civil infrastructure Vulnerabilities, Threats, resulting Incidents and

iMpacts along with their Risks (hereinafter referred to as VTIMR). These five core concepts are

correlated to the physical aspect of the incident, i.e. the actual infrastructure asset that is subject

to them. More importantly, VTIMR are defined in relation to and as part of a coordinated multi-

jurisdictional process structure that spans typical asset life cycle; encompassing work processes

of participating stakeholders (actors) and their roles. These concepts are portrayed in three

interlocking sub-models, each addressing an important aspect and some supporting concepts.

These sub-models are defined in the following subsections, and depicted in Figure 4-3.

4.3.1 The Spatial/Physical Sub-model

This is a reference to the assets that can be exposed to threats and that could be vulnerable. The

development of this model was motivated by the fact that adequate risk assessment requires the

presence of an infrastructure descriptive model that accurately emulates civil infrastructure assets

77

topology at various levels of granularity. Such model will aid the decision maker to understand

the infrastructure asset structure and dynamics, extracting related attributes and indicators that

could be used to assess existing vulnerabilities. The model breaks down the infrastructure asset

into major elements and interfaces to external entities, deducing which element/interface

availability, failure or malfunction will cause the most adverse effects.

Figure 4-3: The Proposed Ontological Model

An asset is defined as an entity that partially or fully provides a service, which in turn can be

intermediate or terminal. It is a physical product taking different levels of aggregation (e.g. road

median, bridge, and electricity distribution network). It has a configuration (i.e. how its

components are aligned together), behavior (involves consumed resources, output products,

associated processes, performance …etc), and finally interconnectivity through exchange

interfaces defining its connectivity to other assets/systems.

78

Osman (2007), defined a product ontology for AEC (on top of DOCK), which will be adopted

here to describe civil infrastructure assets. An asset is described under three different group

modalities which are: Hierarchical role, Functional, and Compositional. Figure 4-4 illustrates a

schematic diagram of these three modalities and their enriched description of the civil

infrastructure asset. The given figure emphasizes the functional aspect of each product, i.e. some

products are more important more than the others based on their functionality and hierarchal role.

Figure 4-4: Infrastructure Asset (Physical Product) Classification Modalities (Osman, 2007)

The Hierarchical modality classifies an asset based on the role they play within the infrastructure

network (e.g. main structure, support structure, auxiliary feature, and device). Function implies

the function that the asset performs (e.g. conveyance, mobility, accessibility, protections, control,

etc.). The Compositional modality captures the notion of aggregation and composition between

various civil infrastructure asset components. It classifies assets into the following three sub-

categories:

§ Component: the smallest unit in infrastructure assets such as a single pipe strand in a water

system, a device (such as a valve), a signal, etc.

79

§ Sub-composition: this category is referred to as sub-system in Osman’s work. It has been

replaced here to avoid any confusion with the concept system in DOCK. It refers to a set of

coherent components that make up a (relatively) small composition, such as a water line, a

local transit system…etc.

§ Composition: is referred to as system in Osman’s work. This refers to large scale composition

such as city-level water distribution network, sewer plant, transportation system ...etc.

4.3.2 Temporal-business sub-model

This facet of the ontological model addresses the lifecycle of the asset along with associated

business process in correlation with VTIMR elements, defined in details in the following

paragraphs:

§ Lifecycle: Any sound representation of VTIMR has to address their behaviour and their

knowledge across the typical life cycle of the asset or the system they exist in. For example,

VTIMR of a bridge has to be addressed during planning, budgeting, design, construction,

operation, maintenance/rehabilitation and decommissioning of its life cycle. Similarly,

VTIMR has to be an integral part of the analysis, development, approval, implementation of

transportation systems or its components/sub-systems (such as transportation legislations,

policy making, finance, and customer relations/communication).

§ Business Aspect: this includes reference and integration of business processes of various

actors (who are engaged in VTIMR) and their roles. The management of VTIMR is not

solely a technical issue (where an expert system or an algorithm will be sufficient to manage

it). Rather, it must be seen as a coordinated multi-jurisdictional enterprise that weaves a

multitude of agencies to handle a set of processes in (typically) a dynamic (if not ad hoc)

manner. El-Gohary (2008) presented an ontology for processes that is built on top of DOCK.

Also, Zhang (2010) developed ontology for actors and roles on top of DOCK. Both are used

to represent the business aspect of VTIMR.

In her work, El-Gohary (2008) classified AEC processes based on their functionality (functional

modality), resulting in four main functional-based classifications of the process, depicted in

Figure 4-5:

§ Core Processes: are product-oriented processes, i.e. creating product or deliverable. They are

mainly technical and highly depended on the infrastructure sector characteristics. There are

80

two types of core processes, which are: technical design/planning and technical

construction/execution.

§ Management Processes: are enabler to core processes; assuring that the design/planning and

construction/execution are delivered according to objectives. Management processes manage

core infrastructure asset operations while utilizing provided resources, handling stakeholders,

and controlling operational variables. Accordingly, management processes have been further

classified into five main categories: objective-centered, core-operations resource,

stakeholders’ relationship, and variable management processes.

Objective-centered management processes include: scope, time, cost, quality, and

occupational health and safety management processes. Core-operations management

processes include: design, procurement, construction/execution management processes.

Resource management process include: knowledge, human, financial, and physical resources

management. Relation management processes include: stakeholders, contract, and partnering

relation management. Variable management processes include: risk, change, and emergency

management processes

§ Knowledge Integration Processes: utilizes an integrated approach to formally and extensively

embed key concepts, knowledge and experience in an asset throughout its lifecycle to achieve

the overall targeted objectives, e.g. constructability and maintainability processes.

§ Support Processes: are necessary to support other types of processes and include:

communication, information management, and administration processes. Support process do

not serve a primary direct project objective/purpose, but they are key enablers and indirect

influencer for achieving project objectives.

In addition, El-Gohary (2008) classified processes based on: lifecycle phase (planning,

execution, and operation), domain (social, economic, social…etc.), sector (transportation, energy,

telecommunications…etc.), scope, temporal extent, virtuality, security, accessibility….etc. For

the complete process modalities refer to El-Gohary (2008).

81

Figure 4-5: Process Functional Modality, El-Gohary (2008)

In describing the civil infrastructure actors, DOCK, and its extension by Zhang (2010) recognizes

a multitude of roles and a limited set of actors. Fundamentally, an actor represents a set of stable

innate skills acquired by a person or an organization. In contrast, a role is a reference to a set of

functions that are specified with the “context” of a process or an organization. Actors are

stereotypes of “internal” capabilities of humans and organizations. They reflect competencies

that are innate in them and, hence characterize their identity.

On the other hand, the definition of roles is process-driven. They are stereotypical

functions that hold irrespective of the actor who is performing them (role holds no matter who is

doing it). The role of a “project manager” can be performed by an engineer (civil, mechanical, or

electrical), an architect, or a technician. However, by virtue of his/her education, an engineer

possess certain (stable) capabilities and attributes that hold no matter what is assigned to him/her

in a project (actors hold irrespective of what is being done). In addition, an actor may play

different roles simultaneously at same or different contexts. In describing actor, role concepts,

the following modalities are used:

82

§ Domain: actors and roles are both classified according to their domain of expertise into

technical and non-technical. These are further subdivided into specific domains such as

engineering, business and law.

§ Level: this modality further classifies actors into a set of levels. Technical actors are divided

into Professional, technician, laborer, and non-skilled laborer. The non-technical actors are

classified into: professional, specialist and clerk. This modality emphasizes the core innate

attribute of actors adopted in DOCK: skill/experience level of education.

§ Seniority: roles are classified as basic, advanced, and specialized based on organizational

function to be performed. For example, urban planner is a role in DOCK. This represents the

basic or generic level of seniority. A chief urban planner is more senior. A rehabilitation

urban planner is a specialized role.

§ Span of control: roles can be dedicated to projects (project role) or corporate level (corporate

role). For example, Project estimator is a role at the project level. Corporate estimator is a

role at the corporate level. These modalities can be further classified based on the geographic

extent of control (typically for corporate roles) into: local, regional, national and

international.

In addition to the above mentioned modalities, actors are further classified into: individual actor

(human being), organizational actor, and other actor (refers to software agents or artefacts such

as vehicle-car unit in a transportation simulation). This actors’ taxonomy can be used to classify

actors based on the before mentioned modalities; i.e. their domain (e.g. civil, electrical, and

mechanical engineers), skill level (professional, technician, skilled/non-skilled labour…etc.)

Organizational actors are further classified based on a three dimensional base

modalities according to: 1) ownership (Government and Non-Government), 2) profit-making

sense (for-profit and non-profit), and 3) domains of expertise (such as engineering, business,

law). Within these dimensions, two additional categorizes have been introduced: level of

operation (e.g. International, national, or local organization), and licensing status (e.g. licensed

gas contracting firm).

83

4.3.3 The Risk Model

This model is a new addition to DOCK; proposing the following representation of VTIMR. The

terms Threat, Vulnerability, and Hazard have often been used casually and interchangeably in

the literature to describe civil infrastructure related risks (Macaulay, 2009). For example houses

built in flood plain area (vulnerability) might go on for decades without encountering floods

(threat). However, the location of the houses in an area (vulnerability) prone to floods (threat)

creates a hazard state which might materialize into an undesirable event (incident) in case of

flood occurrence. On the other hand, this hazard state would never have existed if the houses

were built on elevated terrain that keeps them intact from flooding threats.

The demarcation between vulnerability and threat and that between hazard and incident is

not that easy. Take for example, a design error that later-on could cause faster decay in a bridge.

Does this indicate system design vulnerability, i.e. the system is week to a degree that it cannot

discover such error. Others could see this as an internal threat. What about an intentional mistake

by a malicious person? Does this count as a threat or as vulnerability? What about mistake in the

code of design itself? The confusion relates to both perspective and granularity issues—two

major sources of conflict and problems in the proposed ontological model development.

The solution proposed by this ontological model is to treat any of these conflicting

situations that are external to the “system” as threat and anything that is internal as vulnerability.

In the hazard-incident front, anything that materializes is an incident, otherwise it is a hazard.

The following sub-sections presents risk associated elements (VTIMR) as defined in risk model.

4.3.3.1 Vulnerability

Holmgren (2006) defines vulnerability as the properties and characteristics of an infrastructures

system that might weaken or limit its ability to maintain its intended function or service, when

exposed to threats and hazards that originate both within and outside of the boundaries of the

system. Wisner et al. (2004) define vulnerability in terms of the susceptibility of a system/asset to

a threat together with its coping capacity to that threat. Bohle (2001) extends this definition to

differentiate between system susceptibility, coping capacity, and adaptability to threat/s impacts.

Adaptability is the ability of the critical infrastructure asset to adapt itself to changed

circumstances, excluding any attempt/s to reduce threat/s impacts.

84

Within the proposed ontological model, Vulnerability is defined as civil infrastructure system,

sub-system, and/or component attribute describing one or more internal CI system weakness

that can be exploited by a certain set of threats. In other words, an internal (possibly latent and

typically evolving) condition, state of affair, or attribute of an asset, process or a system that

makes it susceptible to a set of related/relevant threats.

4.3.3.2 Threat

Threat is defined as a class of external quasi-actions (events or processes) that might be

potential source or cause of danger if they exploit specific corresponding asset vulnerabilities.

Those actions might be natural (i.e. act of God) or man-driven. We use quasi to describe threats

as threats are only a contextual description of a genuine action. For example, a severe

thunderstorm in the middle of a desert is not a threat to any infrastructure. It is just a natural

event. In other words, threat casts designate a genuine action into a new form indicative of its

danger relative to infrastructure context. Consequently, threat and vulnerability exist as pairs.

4.3.3.3 Situational Factor

A situational factor represent a “boundary” of entities and/or attributes that can play a role in

triggering a vulnerability or a threat; or become a catalyst for the formation of hazard in a

situation that otherwise does not arise to such state; or similarly, foster the upgrade of a

hazardous situation into an incident. To illustrate, a sharp curve on a road is vulnerability, while

an inattentive driver is a threat. The combination of these two makes a hazardous situation. If the

sharpness of the curve and/or the level of inattentiveness increase, an accident (incident) could

take place. If this takes place during rush hour (situational factor); then the magnitude (severity)

of the incident (and consequently its potential impact) will increase. Finally, if this takes place at

a major arterial (situational factor); the impacts could also be exasperated.

4.3.3.4 Hazard

Hazard is a state of affairs where both vulnerability and its relevant threats (threats that can

exploit such vulnerability) co-exist without maturing to a full-scale incident (i.e. a pre-curser to

an incident). Hazard can be defined as an undesired CI system state resulting from the mere

coexistence of threat-vulnerability pair, imposing potential source of harm/danger on CI system.

The concept of Hazard describes possible threat-vulnerability interactions.

85

4.3.3.5 Incident

An incident is the materialization of specific hazard state into an undesirable event that is usually

followed by negative impact/s on the CI system and/or the surrounding ecosystem/s. An event

that evolves- out /materializes due to a hazardous state of affairs. In other words, the co-existence

of threats and vulnerability in its own does not necessarily materialize into an incident. It does so

only if the interaction passes a threshold that transfers the latency of a hazardous situation into a

clear measurable incident.

4.3.3.6 Impact

An impact is a (bag) reference to all consequence of an incident (causalities, costs and time

impact). Impact can be defined as undesirable change in system components attributes as a result

of threat related incident occurrence, which might lead to partial or full disruption of the

provided services/s and/or negative effects on the human-users (either end or intermediate) as

well as the surrounding ecosystem. The risk model provides three set of metrics to quantify

impacts, which are monetary, time, and numbers.

Aside from providing flexibility, having multiple metrics for risk allows the

quantification of impacts that is controversial to assign a monetary value for impacts such as

number of mortalities or variation in people’s time value…etc. However, at the end of the day

both time and number can be changed into a monetary value. The impacted system/component is

the impacted entity, which can be civil infrastructure system-, asset- product (physical or cyber),

process (core, support, and management), and/or actor (user, operator, owner…etc). In addition

an impact can be Direct or In-direct system impacts, as discussed in more details in section 4.5.4.

4.3.3.7 Risk Risk is one of the overused terms in this domain. It is used to describe a risky condition (in other

words, vulnerability), possible risk (close to the definition of threat in this ontology), and

consequential risks (similar to impact). This again is attributed to linguistic inaccuracy and the

prevalence of insurance terminology in the domain.

In this ontology risk is defined as the typical definition of risk, which is the multiplication

of the severity (possibility) of concept multiplied by the probability of its occurrence. Each of the

above concepts has a probability and possibility of occurrence. While probability refers to

likelihood, possibility references the severity level (threat severity modality). For example, an

86

earthquake is a threat. According to the Richter scale, it has 9 possibilities. In a certain region

(say, San Francisco), each possibility has its own probability of happening, which could be

different in another region (say, Toronto). Risk (of each of the above concepts) is defined as the

multiplication of its probability by its possibility.

Consequently this ontology recognizes threat risk (TR), vulnerability risk (VR), hazard

risk (HR), incident risk (IR), and impact risk (MR). Of course, hazard risk (HR) and incident risk

(IR) are overlapping. To illustrate, the possibility of an incident: an incident is a materialized

hazard. The higher the threat intensity and the corresponding degree of vulnerability, the more

critical the Hazard state is. Figure 4-6 illustrates the Threat-Vulnerability matrix; each cell in the

matrix resembles a possible Hazard state corresponding to specific Threat-Vulnerability pair. Let

i and j denote the possible arrays of specific threat intensities and the corresponding vulnerability

degrees, respectively. Then there are i×j possible hazard states criticality level for this specific

threat-vulnerability pair. Based on the nature of threat (T) and vulnerability (V), at some point

hazard (H) passes the passive threshold and becomes an incident (I).

For simplicity purposes, hazard states are grouped under five categories, as shown in the

figure. The shadings gradation in the matrix represents the possible criticality levels of the

hazard state. The dormant attribute represents a state that is unlikely to materialize into an

incident, and extreme critical representing high susceptibility of CI system to failure. High

intensity threats do not necessarily represent a critical hazard state, as long as the system is

unsusceptible or extremely resilient (limited to no vulnerability) to the anticipated threat intensity

(e.g. maximum security and safety at nuclear power reactor). As a general rule, the more critical

the hazard state is - the higher the vulnerability probability, i.e. the more likely the threat will

exploit the existing vulnerability.

The probability of an incident occurrence is defined in terms of probability of threat “Ti”

occurrence and probability of “Ti” exploiting vulnerability “VTi”, which can be stated as follows:

Probability (IncidentTi) = Probability (ThreatTi) ∩ Probability (VTi)

87

Figure 4-6: Hazard Possibilities

This can be also be interpreted as: the probability that the threat “T” having an intensity “i” will

result in an incident, is equal to the probability of threat occurrence and the success of such threat

to exploit system vulnerability given its intensity level. Obviously, the higher the criticality of the

hazard state, the more probable is the incident occurrence. Figure- 4.6 depicts the expected

relation between the incident probability of occurrence and Hazard criticality level. The Incident

probability is closely related to the civil infrastructure system reliability, irrespective of the

impacts or given that the impacts are minor. In fact Incident Probability can be taken as a

measure of systems reliability.

4.3.3.8 Coping Capacity & Countermeasures

Some literature use the terms coping capacity and resilience interchangeably, while they

complement each other they are different. In this ontological model, resilience is the inverse of

vulnerability (as it is also an internal attribute). Countermeasures are

processes/resources/mechanisms that can be used a priori or posteriori to mitigate/ reduce the

scale of threat related incidents impacts. Hence, it determines the ability of the system to recover

from incidents. Countermeasures are either proactive (i.e. mitigation and/or preparedness) or

reactive (i.e. response and/or recovery). An incident management system is an example of

reactive countermeasure in anticipation of the occurrence of traffic related incidents. Coping

88

capacity is a system attribute indicative of the ability of a system to cope with an incident and its

impacts. It is a reference (and metric) to all available countermeasures. So, it is impact-oriented

not vulnerability or resilience related. It encompasses a set of countermeasures. Other related

concepts as defined in DOCK include: attributes, constraints, resources, environment and

abstract concepts. Orthogonal to all of the above is modality (as in DOCK).

4.4 INTERIM ANALYSIS

This ontology makes the assertion that vulnerability and threat go hand in hand, i.e. vulnerability

is only meaningful only in relation to one or more threats that can exploit it. To this end,

Susceptibility can be seen as situational/contextual nature of vulnerability and threat. For

example, to be prone to earthquakes threat, a building facility must be located in an area falling

within an earthquake zone. If a structure is not earthquake-retrofitted (and otherwise fit) this

represents a generic vulnerability. If the structure is in located in an earthquake prone area; then

it is susceptible, i.e. exposed to potential threats, exist in the context of matching/relevant threat.

Hence, the structure is vulnerable.

If the same structure is located in an area with no earthquake activities, then it is not

vulnerable (as it is not susceptible). In other words, susceptibility is the representation of the

assertion that vulnerabilities exist only relative to threat context, i.e. vulnerability exists

(considered) only if exposed to matching/relevant threats that can (specifically) exploit such

vulnerability. Otherwise, this vulnerability is reverted to a general/generic weakness in the

system.

4.4.1 Fuzziness of the Risk Concepts Continuum

The nature of vulnerability, threats and situational factors is that they are interlinked and as such

it may be hard at some points to discern some of them from each other. Take for example the

scenario of a traffic accident. The existence of a sharp curve is clearly vulnerability in the system

that can be exploited by the threat (inattentive driver). The intensity (possibility) and probability

of the accident can be exasperated by a set of “concepts” (situational factors) such as poor

visibility, poor weather conditions, traffic volume, and the importance of the traffic accident

within the overall transportation network. The question that arises now is how to categorize these

89

concepts into vulnerability, threat, and situational factors (VTS). Figure 4-7 is a schematic

representation of the fuzziness between the before mentioned concepts.

Figure 4-7: The VTS Continuum and Artificial Divide Lines

4.4.2 Causality

The causal nature of threats was chosen as a demarcation criterion between threats and

situational factors. In the above example, poor visibility and poor weather can “cause” an

accident on its own independently from the threat of inattentive driver (albeit with slim

probability). As such, these two “concepts” should be dealt with as threats. In contrast, the

relative importance of the accident spot, is clearly a boundary condition to the accident, and as

such should be categorized as a situational factor. The traffic volume should also be categorized

as situational factor. One can argue that in congested traffic situations, accidents are more

probable. This however, is not the cause for accident, if all drivers follow traffic regulation and

best practices of courteous/safe driving. Otherwise, road rage is the threat (that was exasperated

by the traffic ‘situational factor’).

Important note (linguistic confusion): many practitioners refer to a congested strip/point on a

highway as vulnerable or even risky. This is just due to the prevailing “insurance” terminology

and the typical re-use and re-association of linguistic terms.

90

4.4.3 Externality and the Ambient Human Threat

Similarly, there could be fuzziness in demarking some threats from vulnerabilities. Generally,

the external nature of threats is a demarcation that was selected by this ontology to make the

identification of genuine action as threats easier. This means that, effectively, threats are mostly

related to natural events and man-made intentional actions that are external to the system. So, a

sabotage or malicious action is a threat. First it is an action. Second, it is outside the system.

However, some fuzzy “situations” could arise. Take for example, a design error by a bridge

engineer, an error in the bridge design code, inadequacy of communication systems, in efficient

decision making systems, an intentional sabotage by an insider (versus an outsider). Are these

vulnerabilities or threats?

It is claimed that this demarcation is even harder to discern because it relates to the

perceptual (perspective) and granular nature of these two interlinked concepts (that is threat and

vulnerability). To explain, let us consider the difference between a design error and a code error.

From the perspective of the design team/consultant, the code error is an external factor and that is

a threat. An error by one of the designers (in violation of an otherwise correct code) is certainly a

“cause” for the bridge being inadequately designed (which is an attribute of the bridge and is,

consequently, categorized as vulnerability). But the design error is an internal factor to the design

domain. One can also argue that an error by a human is to be expected and that the real cause of

the error is the inadequate training of the design engineer, or lack of proper communication, or

inadequate review process.

According to the demarcation internal-external between vulnerability and threat,

inadequate review process and poor communication are internal to the design team/consultant

process structure and should be seen as vulnerabilities. Inadequate training of the designers is

also vulnerability as it describes an attribute of an element of the design process. Of course, all of

these are caused by (possibility) other factors such as bad decision making practices in the said

organization.

From this discussion, so far, we can conclude that some vulnerabilities are chained in

causal relationships, i.e. one vulnerability can lead to another. For example, the inadequate

decision making within the design organization (V), may haves lead to two parallel

vulnerabilities: poor communication channels and inadequate review process. Which threat has

91

led to the creation of all these vulnerabilities? It is the catch all threat: human nature (which is

prone to incompleteness and mistakes).

So far, this does not solve the “design error” categorization problem. In fact, if we link

“design error” to the catch all threat “human nature”, then it should be categorized as a threat.

However, this is an internal factor and all attempts have been made to make all internal factors

vulnerabilities and all external factors threats (just to make things easy). There are three

solutions:

§ Accept that there are internal threats: this means that we call a design error a threat (that is

caused by another threat: human nature). It also means that we consider insider sabotage

acts as internal threats. While this is easy to do, it can bluer the lines of vulnerability and

threat again.

§ Introduce a cyclical nature to threats and vulnerabilities: this means that we allow a causal

relationship between threat and vulnerability. Currently, the only relationship between

them has been kept to: T exploits a set of V (and its inverse: V can be exploited by a set of

T). This approach will establish relations such as: V can result in (cause) a set of T, or a T

can result in (cause) a set of V. In our view, and for semantic clarity, this should be

avoided. The only evolutionary relationship between Threat and Vulnerability should

remain that of exploitation (and subsequent generation of hazards or realization of

incidents).

§ Expand the perspective nature of Vulnerability and Threat: by dividing any domain into a

set of domains we may be able to solve this problem. For example, we established that a

design code error is factor that belongs to the code making domain which is a super-

domain to the design domain. As such it is outside the bridge design domain and can

qualify to be a “threat” from the perspective of a bridge designer. Can we handle the

design error within the bridge design domain in the same way? In other words, can we

divide this domain into a super domain which produced the “design error” and assume in

turn that this is a “threat” to the design process? This again can lead us to mixing

vulnerability and threat or assuming that they evolve into each other. Note, similar

arguments can be made about the “code error”. While it is conceivable to treat it as a

threat to the “design domain”, it is not clear how to categorize it again in the super

domain “code making”.

92

This being a contemporary pragmatic ontological model (i.e. it accepts dual nature of concepts

and adheres to making sense to end users) has opted to make one exception to the external-

internal divide. That is anything that related to human error or intentionality. Errors are threats

even if they evolve into or within a domain (not being an external). In other words, a design error

is made by an insider and is considered a threat on the grounds that it is just a manifestation of an

“ambient threat” which is “human nature” or “human-related”. So, in effect we have just created

a special behavioural context for human based and related threats that make them transcend

domains, i.e. the external-internal divide does not apply to human-based factors.1

4.4.4 Interdependency

Vulnerabilities and threats can be seen as independent or interdependent. Given that a

thunderstorm is beyond the control of anyone, such event (threat) is independent. Of course, we

can still study and analyze its process-wise formation (process and conditions of reaching such

event). Interdependency refers to inter-system relations. For example, a water plant that receives

power from a power plant has power vulnerability. Disruptions and/or incidents in the power

plant are threats that can exploit this vulnerability. Of course, if the power plant has a diversified

and redundant power supply, this can increase its coping capacity. The study of interdependency

is out of scope of this research.

Scenarios such as the above are referred to as “resource vulnerabilities”. One can argue

that these vulnerabilities relate more to (or part of) coping capacity. However, it is the

susceptibility of the system (any system) to shortage in its resources that tipped the scale in favor

of calling such concept vulnerability. Any endangerment to system resources is vulnerability.

This can be overcome through two coping capacity means: increasing system resilience

(redundancy) and providing alternative sources of resources.

4.4.5 Rejection of the Accidental

In the discussion above, all human-based factors have been discussed and categorized as threats.

One could have argued for “humans” to be an “ambient vulnerability”. This was rejected because

1 For more on contemporary pragmatism, see the Stanford Encyclopaedia of philosophy. For its role in DOCK, see El-Diraby, 2011.

93

of another major axiom in this ontology. This “rational” axiom assumes that all hazards and

incidents are causal. Moreover, something can be done to prevent them, i.e. there are no

accidents. Rather, there are factor that can cause incidents and there are inefficiencies that, if

exploited, incidents take place. One can argue that vulnerabilities are as “causes” of the incident

as threats, which is a valid argument. However, the actionable nature of threats (and their typical

in-controllability) has tipped the scale in their favours in most cases in this ontology.

In other words, the threat model in this ontology is more expansive than vulnerabilities.

Consequently, the number of defined vulnerabilities is smaller than threats. Vulnerability is also

just limited to one definition: attributes that indicate a weakness in the system that can be

exploited by a threat (external or ambient). Of course the rejection of the accidental does not

means rejecting an ‘accident” such as a chemical explosion, or a traffic accident or a construction

accident. What is claimed here is that these accidents take place due to rational and formal

reasons not due to chance.

4.5 TAXONOMICAL REPRESENTATION OF RLM-ONTO

This section focuses primarily on the taxonomic structure of the concepts presented in the risk

model discussed in section 4.3.3, which describes risk associated elements. The taxonomic

structures of the concepts defined in sections 4.3.1 and 4.3.3 are thoroughly defined in (El-

Driaby 2010), and can be referenced the context of this previous work.

4.5.1 Threat

Except for the work by Luiijf (2006), most classification of threats is not semantically cohesive.

This extensive taxonomy is a product of research project funded by the European Commission

Vital Infrastructures Threats and Assurance (VITA) (Luiijf, 2006). VITA list provides

extensible, detailed and generic threat taxonomy that can be used to analyze threats to critical

infrastructures. However most of the concepts in this taxonomy were kept hidden from the public

outreach due to security reasons. The major concepts found in that taxonomy were incorporated

and extended within developed ontology.

Other taxonomies were found to be no more than threats checklists developed for specific

areas/applications rather than complete CI sector, e.g. biomedical threats (Hu, 2009). In the

94

information and communication technology, several threats lists were found (Chakrabarti et. al.

2002, Pfleeger et al. 2010). However the analysis of those lists showed that they are often

unbalanced and incomplete, focusing primarily on man-driven threats and the threat agent

intentions, motivation and capabilities in assessing the associated risk factors. Such approach is

sector specific, addressing specific scopes with surrounding factors and situations limitations.

The proposed ontological model classifies threats in terms of four orthogonal, correlated

modalities, which are:

§ Causal-agent: defines a Threat as either Natural or Man-Driven. Natural threats do not have

direct human involvement and they are seen to fall in the act-of-God category. On the other

hand Man-driven threats, as the name implies, are a result of human actions.

§ Temporal Nature: defines threats as either being evolving (e.g. forest fires and floods) or

sudden (e.g. earthquakes and tsunamis).

§ Domain: chemical, radioactive, biological, geophysical, hydrological, metrological, and

cyber.

§ Intentional vs. Non-intentional, this mainly refers to man-driven threats.

Threats that are induced as a result of human-environment interaction but do not have direct

human interference are also categorized as Natural Threat, e.g. acidic rain, which might result

from human industrial activities but there is no human direct control on its temporal or spatial

occurrence as well as ecological lifecycle. Table 4-1 illustrates some types of threat by

combining the “creating agent” and “domain” modality. Of course, the other threat modalities

are orthogonal to Table 4-1 and can be used to fine tune these types further. Figure 4-9 depicts

the threat modalities taxonomic hierarchy.

Those major sub-concepts are further broken down into other sub-concepts and so forth.

The complete threat taxonomy is given in Appendix-B. For the taxonomy to be consistent all

elements must be distinct and occur only at one place. However as the taxonomy becomes large,

certain threat concepts may become inter-related and the ontology users may become unaware

where to fit a certain concept in the taxonomic hierarchy. For instance tsunami, which is defined

as a Hydrological-Natural Threat, is scientifically known to be directly caused by a massive

oceanic earthquake, which in turns can be classified as Geophysical-Natural Threat. Therefore

there is a need to identify recursive relationships within the ontological model to acknowledge

95

the fact that some threats may evolve as an impacts of other threats. This sort of relationships is

discussed in detail in section 4.7 of this chapter.

Table 4-1: Examples of Threat Types Resulting from the Two Defined Modalities

Threat Modality Act of God/Natural Man-Driven Threats

Intentional Non-intentional

Chemical

The corrosive action of atmosphere saturated with suspended salt particles nearby sea shores

High acidic mineral content soil

Hard water

Vandalism chemical Explosion

Intentional forests fire using flammable materials

Refer to any source of human error (ambient

threat)

Radioactive Upper atmosphere high energy rays emissions

Cosmic emissions from the sun

Radioactive terrorist attack

Smart electromagnetic bomb

Biological Lake water parasite contamination

Birds flocks at airports runways

Wild animals highway crossing

Infectious bacterial attack

Geophysical Earthquake

Landslide

Volcano

Slope failure due deliberate human action

Hydrological River flood

Snow Avalanche

Tidal Waves

Terrorist attack on a water dam

Sabotage of water piping system

Meteorological

Thunderstorm

Aerosols

Cyclones

Wind Gales

NA

Cyber NA Cyber attack

4.5.2 Vulnerability

Vulnerability is closely linked to the intrinsic physical and the operational characteristics of the

exposed system/asset. The concepts defined in this section are closely tied to the vulnerability

susceptibility component previously discussed. The following modalities have been used to

generate vulnerability taxonomy, while Table 4-2 summarizes these modalities:

§ Physical Modality: describes weaknesses in the geometric, mechanistic, and

physiochemical characteristics of civil infrastructure system/asset components. Example of

mechanistic vulnerability is insufficient bearing, shearing or tension stress. Physiochemical

96

vulnerability refers to vulnerabilities due to civil infrastructure components chemical and

physical properties, e.g. corrosiveness, material reactivity, electrical resistance/conduction,

heat transfer, low ignition point…etc. A sharp horizontal curve is an example of geometric

vulnerability.

§ Virtual Modality: is classified as either being Cyber or Logical. Cyber refers to

data/information, communications systems related vulnerability. Logical describes the

deficiencies in civil infrastructure processes design and management. Management

vulnerabilities are usually identified after the occurrence of an incident, after which

planning shortcomings, lack of preparedness and/or inadequate response to emergency

situation are realized.

§ Domain Modality: refers to the context of the vulnerability, e.g. safety, security,

economic, management, legal/liability…etc. For example legal/liability vulnerability refers

to gaps existing in national or sector civil infrastructure governing and protecting laws that

may be exploited by man-driven threat agents to escape criminal prosecution or to claim

unjustified legal or financial compensations.

§ Resource Modality: every system has susceptibility to shortage in its resources. It can be

expressed financially, quantitatively, qualitative, capacity ratio …etc. Capacity constraint

in the transportation network is an example of resource vulnerability. Another example of

resource vulnerability is the absence of adequate firefighting units and equipment in a

certain neighbourhoods may leave the buildings in that area vulnerable to fires imposed by

various threats.

97

Table 4-2: Examples of Different Vulnerability Modalities

Vulnerability Modality Example Domain Modality

Physical

Physiochemical

Low ignition point of component material Safety – Chemical Vulnerability

Component material corrosiveness reactivity Chemical Vulnerability

High electrical conductivity of component materials. Physical Vulnerability

Mechanistic Low flexural strength concrete column Safety Vulnerability

Low skid resistance of pavement surface (i.e. low friction coefficient) Safety Vulnerability

Geometric

Sharp highway horizontal curve Safety Vulnerability

In sufficient utility bury depth Safety Vulnerability

Misshaped surrounding security fence. Security Vulnerability

Virtual

Cyber

Weakness in automated systems security procedures

Security/Management Vulnerabilities

Software System Firewall flaw Security Vulnerability

Logical

High density human population Safety/Security Vulnerability

Litigation policy flaw Legal Vulnerability

Improper design of passenger checking procedure at airport.

Security – Management Vulnerability

Resource

Insufficient number of fire engines Safety/Management Vulnerability

Insufficient number of trained personnel Human-resource Vulnerability

Insufficient budget for an organization Financial Vulnerability

4.5.3 Incidents/hazards

Incident (and their kin, hazard) are categorized according to a set of modalities:

§ CI Sector/System Modality: describes incidents in terms of the sector they belong to,

according to one of the following Transportation, Electricity, Telecommunication, and

Water. For each sector incident can be further classified to express the various operational

incidents within the sector, e.g. road blockage incident, highway incident, electric outage

incident, water (pipe) damage…etc.

§ Domain Modality: For example, safety, security, criminal, industrial (workplace or

occupational).

98

§ Impacted entity modality :

o Human-related Modality: defines four sub-concepts for human related incidents,

which are: Injury, Fatality, Infection, Stroke (e.g. heat stroke) and Toxication.

o Environmental Modality: defines the incident in terms of the impacted ecological

elements, which are: earth, water, biological, and weather. For example landslide

incident (earth), ice-blockage incident (weather), bird strike incident (biological)…etc.

o Property-related Modality: incidents are categorized according to the impacted

property type. For example, Facility/Structures, Machine/Equipment and Vehicles

related incident. Those concepts also have an ownership modality, i.e. either public or

private. Each of the sub-concepts is further categorized under Fire, Damage,

Dysfunction and Contamination incidents. For example truck fire, facility

contamination, building collapse…etc.

§ Material-related Modality: is further categorized as either hazardous or non-hazardous

incident. Hazardous2 materials (Hazmat) are classified based on their nature into

radioactive, corrosive, flammable, poisonous …etc. Non-hazard material incidents includes

a wide range of material, such as: commodities, manufactures, mines and minerals,

livestock, agricultural products, non-hazard chemical, building material, and natural earth

crust. They are also classified either as fluid (gas or liquid) or solid. This sort of

classification in characterizing incidents related to the traffic sector, especially the incidents

that involves material spill and the nature of spilled material is required by the incident site

clearance personnel.

§ Medium-related Modality: classify incidents based on the medium they originally

initiated from. Three sub-concepts are defined based on the only three possible mediums,

which are: aerial (air), ground (terrestrial), and maritime incidents.

2 Of course, these linguistic terms should not be confused with the ontological term hazard.

99

Figure 4-8: Incident Modality Families

4.5.4 Impact

Impacts are measures of the total cost of an incident. Total cost here is not limited to monetary

value. Rather, it refers to the total damage associated with an incident. Impacts are classified as

being short or long term, monetary and non-monetary. Figure 4-9 depicts the taxonomy of

impacts. Monetary impacts are classified as either being direct or indirect. Direct impact refers to

the direct impact of an incident on CI system/asset components, and the provided service

integrity. Indirect impacts are collateral impacts that are not directly related to the occurred

incident. Table 4-3 illustrates example of each impact category.

100

Table 4-3: Examples of Different Impacts

Monetary Impact Non-monetary impact

Direct Indirect Macroeconomic Environmental Social Short-term

Lost property Repair cost Compensations

Lost wages Revenues Loss Medical treatments User costs Service interruption cost

Total travel delay Productivity loss

Temporary contaminations. Death of wildlife animals & living organisms

Reduced community activity Psychological scares.

Long-term

Increase in insurance premiums Associated litigation costs Post-incident public and media outreach costs.

Reduction in property value Human injury rehabilitation cost

Loss of competitive edge Loss of economic activities Increase public health care cost

Irrevocable damage to the eco-system Pollution

Migration

Direct monetary impacts encompass the direct monetary costs associated with an incident

impacts, such as: cost of damaged (lost property), repair/recovery cost, associated

compensations, increase in individuals insurance premiums, litigation costs…etc. Indirect costs

include lost wages (of employees), lost business revenues, reduction in property value, long-term

negative impacts on public health system (due to increased care after a chemical or radioactive

incident, for example), user costs due to service interruptions (such as traffic user costs due to

prolonged traffic accident)… etc.

Environmental impacts do not refer to the monetary value of lost eco-system or even the

costs of its restoration. It measures irrecoverable damage to the eco-system in the surrounding

area of an incident such as lost habitat, irrevocable contamination of ground water. Social

impacts again do not include the costs to compensate affected people. It refers to strains on local

community due to incident. For example, reduction of social ties, forced migrations, interruption

of social events, psychological scares. Macro-economic impacts are evident in examples as loss

of competitive edge, impacts on local development patterns, changes to land use, sustained

impacts on productivity, and negative impacts on national innovation capacity.

101

Figure 4-9: Impacts and Countermeasures taxonomy

4.5.5 Countermeasure

Countermeasures are classified as either proactive or reactive. Proactive Measures are measures

taken in the preventive phase, in prior to anticipated threat/s occurrence. On the other hand,

Reactive Measures refer to processes carried out in response to threat occurrence, aiming relief of

threat impacts and restoration (fully/ or partially) of any interrupted services. The following

sections elaborate more on each of the two concepts.

4.5.5.1 Proactive Measures

Proactive measures are defined as either mitigation or preparedness measures. Preparedness

measures aims to decrease the severity of an incident impact, while mitigation measures try to

completely eliminate an incident anticipated impacts. Preparedness measures are further

extended into the following sub-concepts:

§ Redundancy/Backup: Redundancy is providing the service through an alternative system

or component with an acceptable level of variation e.g. multiple routes between every

origin-destination pair in the traffic network. Backup is maintaining the same service

102

quality through replacing malfunctioning components/systems, such as replacing an

identical power generator in a energy production plant.

§ Social: the presence of community awareness and training programs to counteract threats

and minimize the accompanied impacts.

§ Policy/Procedural: refer to laws, safety and security procedures that guide CI

administrators, emergency officials and public actions during emergency situations. It

includes laws that obligates and promotes impacted areas recovery efforts as well as

guides and procedure for emergency response and recovery.

§ Economical: is the presence of adequate financial resources to provide the above

mentioned countermeasures as well the insurance service plans necessary to relief the

severity of the anticipated threats impacts.

Mitigation measures are divided into Physical (e.g. building a dam to protect a flood prone area),

Operational (e.g. evacuation processes to human population prior to a highly anticipated

volcanic eruption incident occurrence), and Legal (e.g. laws that prosecutes drunk driving or

prohibits building in flood prone areas).

4.5.5.2 Reactive Measures

On the other hand, reactive measures are categorized as with response or recovery processes.

Response measures refer to the emergency rescue, medical services and humanitarian aid

processes, which are essential to relief threats related incidents impacts. Recovery refers to the

processes aiming to restore impacted CI system functionalities, either partially or fully.

Depending on the level of aggregation of the countermeasures (system, sector, and strategic), the

recovery process takes three different modalities.

On a system scale, recovery measures aim to restore interrupted or disturbed CI system

services. This level of aggregation focuses primarily on the operational recovery of the impacted

system ensuring that it provides its mission service/s at an acceptable level of quality. It also

includes a physical recovery represented in the replacement and rehabilitation of the impacted CI

system components. Sector level recovery (e.g. transportation sector) refers primarily to the

economical dimension of the recovery process, where the required financial resources necessary

to reconstruct and rehabilitate impacted CI components are allocated. This level of aggregation

aims to restore the economic output of the sector to the pre-threat impact state.

103

On the most abstract level of aggregation, the strategic level aims to the relief of the socio-

economic impacts of the threat occurrence. It encompass mechanisms that ensure early recovery

processes that aim to both save lives and preserve the livelihoods of impacted communities by

strengthening essential local governance capacities and ensure a broad based participation of

various emergency response institutes and agencies in a framework for early recovery. It

provides the processes essential to create conducive surrounding environment to stabilize

vulnerable communities and achieve the sustainable reintegration of displaced population

through access to social services, economic networks, and strengthening rule of law.

4.6 ATTRIBUTES

Attributes are modeled as classes into a hierarchal taxonomy, defining the relation between each

attribute and its meta-attribute using is-a relationship. Attributes are used to describe root risk

concepts, depicted in Table 4-4. Some of these attributes are generic, i.e. associated with core

concepts (i.e. severity, temporal and spatial attributes), while others are concept specific. It

should be added the attributes used to describe countermeasure concept are the same as these

used to describe the process concept defined in IC-PRO-Onto (El-Gohary, 2008), and thus will

not be addressed herein.

Arguably the most important attribute of threat concept is probability/frequency of

occurrence, which is used to quantify risks associated with its occurrence. The probability of

some man-driven threats are extremely difficult to quantify (such as terrorist attacks), and are

defined using subjective measures.

4.6.1 Possibility (Severity Levels) Attributes

Severity can be assessed using either subjective or objective measures, depending on the

described concept. Some concepts have established scientific or domain quantitative measures to

assess their severity/intensity. Other concepts are difficult to quantify and are subjectively

assessed by domain experts.

104

Table 4-4: The Ontological Model Concepts Attributes

Attribute

Concept

Risk Temporal Spatial Control Prediction Evolution Possibility

(Severity) Probability

Threat ● ● ● ● ● ●

Vulnerability ● ● ● ● ● ● ●

Situational Factor

● ● ●

Hazard ● ● ● ● ● ● ●

Incident ● ● ● ● ● ● ●

Impact ● ● ● ● ● ● ●

Susceptibility ● ● ● ● ●

Countermeasure ● ● ●

Coping Capacity ● ● ● ●

105

§ Threat Possibility (Severity) Attribute: relates to the intensity of the threat. Natural

Threat concepts can be easily quantified using established scientific measures of intensity.

For example, Richter magnitudes scale for earthquakes, wind speed for gale storms, and

water perception depth for rain storms. Unlike natural threats, man-driven threats have no

standard measure for their intensity (severity indicators).

For example, there is no objective severity scale for threat represented by drunk driver on

a highway. Usually, subjective judgment can be used in some cases to assess man-driven

threats severity. For example, high rise crane operator mistake has extreme capability of

large scale damage compared to towing truck driver error.

§ Vulnerability Possibility Attribute: relate to the degree/level of weakness. The values

describing civil infrastructure system products and processes attributes; determine to great

extent the system behavior and ‘indicate’ weaknesses (vulnerabilities) against anticipated

threats. Such weaknesses are determined based on arrays of defined constraints and

mechanisms ‘thresholds’ that relate the system behavior to anticipated threat/s severities.

The system attributes defining vulnerabilities are called vulnerability indicators, and the

vulnerability severity is expressed as ‘the difference between the values of constraints and

mechanisms ‘thresholds’ and the system vulnerability indicators’.

Vulnerability Indicators/Severity attributes play vital role in risk management. Due to the

fact that vulnerability represents the manageable part of risk, assessing it can be used to

understand to predict possible modes of failure and reduce/prevent anticipated impacts. A

vulnerability severity measure can be qualitative, quantitative, or rank variable. However,

some areas of vulnerabilities such as institutional vulnerability are very complicated to

measure and quantify even though they are perceived as important and will be only assessed

using subjective measures (Morse, 2004).

§ Incident Possibility Attribute: depends to great extent on causing instigators (threat and

vulnerability) severity as well as surrounding environment and situational factors.

§ Impact Possibility Attributes: Impact severity is expressed either in terms of total costs or

number of impacted entities.

106

§ Hazard Possibility Attribute: depends on causing threat-vulnerability pair severities.

Typically qualitative and rank variables are used to describe hazard severity due to the fact

that the hazard concept is dependent on two multidimensional concepts and often is ill

defined. It is difficult and perhaps even impossible to reduce this concept into a single

equation that produces quantitative value.

4.6.2 Temporal Attributes

Natural threats have temporal duration representing life cycle, e.g. snow storm or earthquake

duration. Threat duration defines another temporal attribute which is time of occurrence

(duration start point). Vulnerability has duration attribute as well which is characterized as being

either continuous (permanent) or intermitted. Example of intermitted vulnerability is a traffic

network that is susceptible to failure ‘only’ during peak hours, in case of traffic incident

occurrence. Or city electric energy system that is prone to failure during seasonal extreme

weather conditions (such as specific week of summer or winter) as a result of domestic

cooling/heating energy overconsumption. Hazard has duration which is function of the lifecycle

of instigator threat. An incident has probability of occurrence and duration. While an impact has

duration only, characterized by being short or long term, immediate or latent.

4.6.3 Spatial Attributes

For natural threats, spatial attributes describe location-related to threat occurrence, e.g. epic

center of an earthquake, thunderstorm location. This sort of spatial attributes are described in

terms of geographic coordinates. Man-driven threats spatial attributes are expressed on the

resulting incident occurrence location, e.g. map address, geographic coordinates, highway

kilometric length…etc. Vulnerability, hazard and incident have location attributes. Impact

concept has an area of extent and center attributes.

4.6.4 Concept Specific Attributes

As previously mentioned some attributes are only used to describe specific concepts, these

attributes are summarized in the following:

§ Intention: is specific to intentional man-driven threats, defining the end goal threat agent,

e.g. property damage, human casualty, psychological effect …etc. Since the probability of

107

intentional threats is hard to predict, this attribute aid in estimating an attacker’s intent to

exploit a specific vulnerability. For example, a terrorist intending a psychological impact is

very likely to target CI asset having a psychological impact such as status of liberty, golden

gate bridge…etc. Thus the probability of those assets having a terrorist threat is very likely.

§ Affiliation: is specific to intentional man-driven threats, describing the affiliation to specific

group/cult. Thus helping to assess factors related to that threat, such as: ideology and moral

framework.

§ Method: is specific to threat concept, describing the way by which a threat exploits the

vulnerability of CI asset, such as: shockwaves for earthquakes, pressure wave or

hydrothermal explosions for volcano, static/dynamic force of vehicle collisions, conventional

weapons or improvised explosives (e.g. airplane kinetic energy and fuel) for terrorist threats,

contamination by chemical/biological threat, obstruction by snow dunes, slipperiness of ice

or rain…etc.

4.6.5 Attributes Modalities

Orthogonal to the before mentioned attributes taxonomy, attributes are further grouped into the

following five modalities:

§ Variability Modality: characterizes attribute behaviour over time. Attributes that do not

change over the life time of concept are termed as being fixed. For example, a bridge having

‘high severity’ vulnerability to 6.5 Richter scale earthquakes; represents fixed severity

attribute. It does not change with time and is always there. On the other hand, the severity

(intensity) of the earthquake threat itself varies with time and distance, i.e. changeable.

§ Expression Modality: attributes are seen as either qualitative (i.e. represented using a number

ranking or linguistic terms/expressions) or quantitative (represented in numeric value).

§ Physical Modality: attributes can be classified as being physical/tangible (e.g. shape,

stress/strain value, location …etc) and non–physical (e.g. performance, dependency,

intention…etc).

108

4.7 RELATIONSHIPS MODEL

Relationships describe the association between ontology concepts, enriching concepts definition

and clarifying context. A vital role that relationships play is that they semantically tie the

ontology concepts together, allowing automated reasoning and deduction of new knowledge

from existing ones (Gruninger, 2004). Within the proposed ontological model, relationships are

classified under three main concepts groups subsumptions (is-), partonymy (part-of), and cross-

concepts relationships. All of relationship concepts underneath these categories are extended

from DOCK (El-Diraby, 2009).

However, the proposed ontological model adds extra six relationship concepts to DOCK

cross-concept relationships, depicted in Table 4-5 below. Cross-concept relationships are usually

context-dependent and application specific. The semantic representation of cross-concept

relationships could be further enriched through the provision of semantic flavours to the naming

of relationships and the introduction of more details. However, within this ontological model

scope only the above mentioned relationships are used, in order not to limit the generalization of

the ontology and to avoid the introduction of fuzziness in the representation of relationships.

As a concluding remark for this section, the causal relationship cause acknowledges the

fact that some concepts may evolve as result of others. For example tsunami hydrological threat

is caused by earthquake geophysical. Similarly, man-driven non-intentional threats are subject to

factors that significantly influence their occurrence. Such factors pose a stress on the human

actor, affecting his/her judgment or behaviour leading to the occurrence of non-intentional errors

or faults. For example, age of driver, extreme temperature, loud noise…etc. Adding the causal

dimension to the conceptual model, will allow assessing the source of threat agents, i.e. an

avalanche may be caused by global warming or a skier error or a terrorist attack. This is

important to understand the threat incident and analyze its causes for future prevention or

required system modification and adaptation.

109

Table 4-5: Newly Introduced Cross-Concept Relationships to DOCK

Relationship Concept Type Description

exasperate (x, y) Contingency cross-concept

The binary predicate refers to situational factor ‘x’ exasperate threat or vulnerability ‘y’

control (x, y) Functional cross-concept

The binary predicate refers to concept ‘x’ control concept ‘y’ in some specific fashion.

exploit (x, y) Contingency cross-concept The binary predicate refers to threat ‘x’ to exploit vulnerability ‘y’.

cause (x, y) Contingency cross-concept

The binary predicate refers to threat or vulnerability ‘x’ to cause hazard ‘y’.

The binary predicate refers to hazard ‘x’ to cause incident ‘y’.

The binary predicate refers to incident ‘x’ to cause impact ‘y’.

augment (x, y) Functional cross-concept

The binary predicate refers to countermeasure ‘x’ to augment coping capacity ‘y’.

inverse (x, y) Contingency cross-concept

The binary predicate refers to resiliency ‘x’ is the inverse of vulnerability ‘y’.

4.8 ONTOLOGY AXIOMS

Axioms define the semantics associated with ontology concepts and relationships. Formalizing

axioms using formal coding languages (e.g. first order logic) to restrain the ontology

interpretation, assuring that no two interpretations exist for the same concept (Gómez-Pérez,

2004). In domain ontologies, axioms should provide minimum ontological commitment; defining

most fundamental rules and concepts. Such minimum commitment assures ontology

generalization. At application level, domain-level axioms are extended to define application

specific behaviour and conducts.

The notion of minimum ontological commitment was introduced by Uschold and

Gruninger (2004). They stated that ‘an ontology should make as few claims as possible about the

world being modeled, giving parties committed to the ontology the freedom to specialize and

instantiate the ontology as need’. Including minimum set of axioms does not limit the

expressiveness of the ontology. Ontologies are evolutionary by nature and application specific

axioms can be added depending on application ontology implementation context and scenario.

The ontological model domain axioms are classified based on module they describe or

type of constrained relation defined. The core module represents general axioms defining the top

level taxonomy concepts. Inheritance and partonymy axioms are not presented herein as the

110

ontology concepts are automatically restrained in taxonomic hierarchies by the implementation

software (i.e. Protégé). As previously mentioned the Spatial-Physical and Temporal-Business

models of the ontology extend DOCK ontology (Section 4.3.1 and 4.3.2). Axioms restraining

their core concepts are already defined in DOCK (El-Diraby, 2009), and will not be repeated in

this section. Thus, DOCK axioms can be used within the newly developed ontology for

automated reasoning and knowledge processing. The developed ontology extends by turn these

models.

The core module contains axioms that are generic to all Risk Model concepts, with the

rest of modules containing axioms that are specific to each concept defined in the Risk Model. In

adherence to the rule of minimum ontological commitment only axioms defined in the core

module are defined. The axioms presented herein were tested for consistency as indicated in

Appendix-D.

Axiom CA-1: Threat is an external action.

∀x threat(x) ⊃ external(x) ∧ action(x)

Axiom CA-2: Vulnerability is an asset attribute, which an asset may or may not have.

∀y ∃a vulnerability(y) ∧ asset(a) ∧ has(a, y) ⊃ has_attribute (a, y)

- has_attribute (a, y): binary predicate indicating concept y is an attribute of concept a.

Axiom CA-3: Situational factor is an entity and/or an asset attribute.

∀x situational_factor (x) ⊃ entity (x) ∨ [∃a asset(a) ∧ has_attribute (a, x)]

Axiom CA-4: Situational factor exasperate a threat or vulnerability.

∀x ∃(s, v) situational_factor (x) ∧ threat (s) ∧ vulnerability(v) ⊃ exasperate (x, s) ∨

exasperate (x, v) ∨ [exasperate (x, s) ∧ exasperate (x, v)]

- exasperate (x, v): binary predicate indicating concept x exasperate concept v.

Axiom CA-5: Hazard is an asset state, which an asset may or may not have.

∀h ∃a hazard(h) ∧ asset(a) ∧ has(a, h)⊃ has_state (a, h)

- has_state (a, h): binary predicate indicating concept h is a state of concept a.

Axiom CA-6: An incident is the materialization of specific hazard state into an event.

∀x incident(x) ⊃ ∀h event(x) ∧ hazard(h) ∧ cause(h, x)

111

Axiom CA-7: Impact is an outcome of incident occurrence.

∀x impact(x) ⊃ ∀i incident(i) ∧ cause(i, x)

Axiom CA-8: An impact (may or may not) disturbs asset, service, and/or stakeholders.

∀x ∃(a, s, st) incident(x) ∧ service(s) ∧ stakeholder(st) ⊃

[disturb(x, a) ∧ disturb(x, s) ∧ disturb(x, st)] ∨

[disturb(x, a) ∧ disturb(x, s)] ∨ [disturb(x, a) ∧ disturb(x, st)] ∨

[disturb(x, s) ∧ disturb(x, st)] ∨ disturb(x, a) ∨ disturb(x, s) ∨ disturb(x, st)]

Axiom CA-9: Threat, vulnerability, hazard, incident, impact, and countermeasures are all

disjoint sets.

- ∀x threat(x) ⊃ ¬ (vulnerability(x) ∨ hazard (x) ∨ incident(x) ∨impact(x) ∨ countermeasure(x))

- ∀x vulnerability(x) ⊃ ¬ (threat(x) ∨ hazard (x) ∨ incident(x) ∨impact(x) ∨ countermeasure(x))

- ∀x hazard(x) ⊃ ¬ (threat(x) ∨ vulnerability (x) ∨ incident(x) ∨impact(x) ∨ countermeasure(x))

- ∀x incident(x) ⊃ ¬ (threat(x) ∨ vulnerability (x) ∨ hazard (x) ∨impact(x) ∨ countermeasure(x))

- ∀x impact(x) ⊃ ¬ (threat(x) ∨ vulnerability (x) ∨ hazard (x) ∨incident(x) ∨ countermeasure(x))

- ∀x countermeasures(x) ⊃ ¬ (threat(x) ∨ vulnerability (x) ∨ hazard (x) ∨ incident(x) ∨ impact(x))

Axiom CA-10: Vulnerability is correlated to threat by specific constraint and/or mechanism ‘thresholds’. - ∀(x, y) threat(x) ∧ vulnerability(y) ∧ exploit (x, y) ⊃ ∃c constrain(c) ∧

control (c, x) ∧ control(c, y)

- ∀(x, y) threat(x) ∧ vulnerability(y) ∧ exploit (x, y) ⊃ ∃m mechanism(m) ∧

control (m, x) ∧ control(m, y)

Axiom CA-11: Hazard results from mere coexistence of threat-vulnerability pair, imposing potential source of harm/danger on asset. ∀(a, x , y, z) asset(a) ∧ threat(x) ∧ vulnerability(y)∧ has(a, y) ∧ exploit(x, y) ⊃

∃h hazard(h) ∧ cause(x, h) ∧ cause(y, h) ∧ has_state(h, a)

112

Axiom CA-12: Risk is equal to the multiplication of possibility and probability for each of the following five concepts: threat, vulnerability, hazard, incident, and impact.

- ∀x ∀ (r, p, s) threat(x) ∧ risk(r) ∧ probability(p) ∧ possibility(s) ∧ has(x, r) ∧ has(x, p) ∧ has(x, s) ⊃ (r = p × s)

- ∀x ∀ (r, p, s) vulnerability (x) ∧ risk(r) ∧ probability(p) ∧ possibility(s) ∧ has(x, r) ∧ has(x, p) ∧ has(x, s) ⊃ (r = p × s)

- ∀x ∀ (r, p, s) hazard (x) ∧ risk(r) ∧ probability(p) ∧ possibility(s) ∧ has(x, r) ∧ has(x, p) ∧ has(x, s) ⊃ (r = p × s)

- ∀x ∀ (r, p, s) impact (x) ∧ risk(r) ∧ probability(p) ∧ possibility(s) ∧ has(x, r) ∧ has(x, p) ∧ has(x, s) ⊃ (r = p × s)

- ∀x ∀ (r, p, s) incident (x) ∧ risk(r) ∧ probability(p) ∧ possibility(s) ∧ has(x, r) ∧ has(x, p) ∧ has(x, s) ⊃ (r = p × s)

Axiom CA-13: Probability of hazard is equal the intersection causing threat and vulnerability probability.

∀x ∀ (t, v, pt, pv, ph) hazard(x) ∧ probability(ph) ∧ has(x, ph) ∧ threat(t) ∧ vulnerability(v) ∧ probability(pt) ∧ has(t, pt) ∧ probability(pv) ∧ has(v, pv) ∧ exploit (t, v) ∧ cause(t, x) ∧ cause(v, x) ⊃ (ph = pt × pv)

Axiom CA-14: A countermeasures can be process/resource/mechanism.

∀x countermeasure(x) ⊃ ∃ mechanism(x) ∨ process(x) ∨ resource(x)

Axiom CA-15: Coping Capacity is an asset attribute.

∀c ∀a coping_capacity(c) ∧ asset (a) ∧ has(a, c) ⊃ has_attribute (a, c)

Axiom CA-16: Coping Capacity controls incident related impacts on an asset.

∀(a, c) ∀ (i ,m) coping_capacity(c) ∧ asset (a) ∧ has(a, c) ∧ incident (i) ∧ impact (m) ∧ cause(i, m) ∧ disturb (i, a) ⊃ control(c, m)

Axiom CA-17: Countermeasures are may be used prior/post incident occurrence to augment coping capacity.

∀ (a, c) ∃ (y, z) asset (a) ∧ coping_capacity (c) ∧ has(a, c) ∧ incident(y) ∧ impact(z) ∧ disturb (y, a) ∧ cause(y, z) ⊃ ∃x countermeasure(x) ∧ [prior(x, y) ∨ post(x, y)] ∧ augment (x, c)

113

4.9 DEVELOPING IMPACTS

The fundamental relationship in this model is the relationship ‘exploit(x, y)’, i.e. threat ‘x’

exploits vulnerability ‘y’ and as such creates a hazard which may evolve into an incident. But not

every threat-vulnerability pairs are relevant. To elaborate, a sharp horizontal curve on a highway

is not vulnerable to a cyber-attack. However, the relationship of sharp horizontal curve

(geometric vulnerability) to inattentive driver (ambient threat) is quite relevant. Table 4-6 marks

some of the threat-vulnerability pairs correlations, discussed in more details in Table 4-7.

Table 4-6: Examples of Hazard Correlation to Threat-Vulnerability Pairs

T1: Snow Storm

T2: Earthquake

T3: Flood

T4: Inattentive Driver

T5: Terrorist Attack

V1:Mechanistic Q12 Q13

V2:Geometric Q23 Q24

V3: Resource Q31 Q35 Qij designates the Threat-Vulnerability relationship.

The civil engineering literature is abundant with developed analytical models correlating threat-

vulnerability pairs in one-way or another; aiming to assess resulting hazards and accordingly

evaluate associated risks. Table 4-7 summarizes examples of these models for some solicited

threat and vulnerability pairs, indicated in Table 4-6. However, the majority of these models are

tailored towards specific situations, conditions and highly dependent on data availability;

limiting their wide scale of use. In addition, these models assess hazard/risk from single

stakeholder perspective only, e.g. assessment of bridge structural vulnerability against flood,

ignoring the geometric vulnerability perspective. The bridge might be structurally stable against

the flood, but the deck will be flooded by water due to the bridge short columns (geometric

vulnerability). Thus during an emergency evacuation situation, though structurally stable, the

bridge is obsolete.

The geographic disperse, complex, multi-agency, multi-jurisdictional and interdepend

nature of civil infrastructure systems dictates the use of qualitative rather than quantitative

models in large scale hazard assessment. Decision makers need to have handy hazard/risk maps

defining vulnerable locations for adequate resource allocation and design of emergency

countermeasures. These maps must use compatible underlying models that define hazards/risks

using same metrics, irrespective of the causing threat and vulnerability.

114

Table 4-7: Description of Solicited Threat-Vulnerability Relationships

Relation Description

Q12 Seo (2010) studied the mechanistic vulnerability of steel bridges under earthquake threats using probabilistic model.

Chung (2008) studied the mechanistic vulnerability of concrete bridges structural elements against earthquakes using seismic simulation model.

Q13

Laursen (1984) studied the relationship between bridges piers mechanistic properties against floods (Structural Vulnerability Domain) using scour progression prediction model.

Federico (2003) studied the correlation between bridge pier shape, bearing capacity of foundation, against floods using an analytical model; function of scour and foundation depths.

Tzu-Kang Lin (2002) studied the anticipated damage of bridges after earthquakes using neural network model, incorporating the bridge mechanistic property as an input.

Q23 Webster (2006) presented the vulnerability of the geometric design of road network to storm water surge in New Brunswick, Canada. He used a high resolution LIDAR model implemented as GIS DEM.

Q24

Abdel-Aty and Radwan (2000) studied the correlation between roadway geometric design and human driver attributes to predict incidents using binomial modeling techniques.

Sayed et al., (1997) studied the correlation between highway geometric design and traffic incidents causes using fuzzy pattern recognition.

Abdel-Aty and Abdelwahab studied the relation between driver’s inattentiveness due to alcohol intake and motor vehicle accidents on freeways using log-linear models.

Q31

Berdica (2004) studied network link redundancy vulnerability against snowstorms using a framework of sensitivity analysis and meso-scoping simulation.

Jenelius (2007) link redundancy (resource vulnerability) as well as network scale, road density, population density (situational factor) against snow storms meteorological threats using micro-scoping simulation and regression modeling.

Q35 Holmgren (2006) used to graph models to analyze the vulnerability of electrical power networks; defining vulnerability to be insufficient number of critical electrical power networks redundancy.

In hazard/risk assessment frameworks, two main key features were found to be highly required:

use of fuzzy sets to accommodate the lack of objective data and concurrency (Cooper el al.,

1987). Concurrency allows various domain experts inputs, assessing hazard from multi-facet

perspective. Such two features will allow decision makers to quickly develop risk maps for civil

infrastructure based on subjective inputs by domain experts. Although subjective, these maps

will cover the various aspects of hazard and risk as it accommodate for various stakeholders’

inputs.

115

To simplify the problems of incompatibility and limitation of hazard assessment analytical

models, the proposed ontological model subjectively assess the relationships between threat and

vulnerability indicated in Table 4-6. In doing so, the ontology utilizes the hazard probability and

possibility relationships previously defined in section 4.3.3.7.

4.9.1 Representing Hazard Risk

The general rule for generating the Qij relationship indicated in Table 4-6 is as follows:

- PH= PT ® PV (4.1)

- SH= ST ® SV (4.2)

- RH= PH × SH (4.3)

Where ‘P’ is probability, ‘S’ is possibility, ‘T’ threat, ‘V’ vulnerability, ‘H’ is hazard, and ‘R’ is

risk. The sign ‘®’ indicates some sort of relationship. One simple way to represent the ‘®’

relation is to use multiplication. Other means is to use the wealth of fuzzy logic relationships.

The fuzzification aims to transform a domain expert linguistic input into a fuzzy number. For

example, very high vulnerability possibility or very low threat probability. One of the interesting

general fuzzy relations is the Hamacher formula (Dobis et al., 1980), which is a sinusoidal fuzzy

number in the following format:

- μi = [Sin(mx)]n (4.4)

Where ‘i’ is threat (T) or vulnerability (V)

Two dimensions are used to change qualitative descriptions of threat and vulnerability

possibility/probability into the fuzzy input, which are:

§ Level: is a qualitative variable representing an expert assessment for

probability/possibility level. It takes one of the following three forms: high, medium, low.

Mathematically it takes the form of a fuzzy number.

§ Hedge: is used to fine-tune the ‘level’ dimension. Taking one of the following qualitative

terms: strongly, moderately, fairly, and slightly. Mathematically represented as an

operation (square, root, etc.) on the fuzzy number through the parameter n in equation

(4.4).

116

Hamacher formula is one of several ways to augment two fuzzy set. It provides the user with

more leeway to express the exact degree of augmentation desired (Li et al., 1990). If T and V

have qualitative representations based on domain experts assessment (e.g. strongly high

geometric vulnerability), then this representation can be changed to fuzzy number using equation

(4.4). Then the combined probability/possibility of threat and vulnerability, expressing hazard

probability/possibility, can be calculated as follows:

- μPH = μ(PT ∩ PV) (4.5)

- μSH = μ(ST ∩ SV) (4.6)

- (4.7)

Where: μXY indicate a fuzzy membership function, λ and γ are modifiers used to adjust the

formula for specific user needs. However, it should be emphasized that each viable cell in table

should be filled by experts or as a result of extensive research. The above two techniques are just

used for illustration purposes. Focusing on risk hazard to develop risk maps rather than the

conventional risk (probability of threat × expected scale of impact) make sense from practical

point of view.

The scale of impacts is quite complicated and expensive (cost and time) to assess before

the actual threat occurrence. It relies heavily on intensive input data to have credible evaluations

of the anticipated impacts. Such resources are not usually available and most of the time hard to

justify in developing countermeasures (Macaulay 2009). In this case, qualitative hazard risk

maps pose itself as quite reliable and relatively fast to develop mean to assess risks associated

with civil infrastructure. As long as the qualitative assessment is done by the correct experts who

are familiar with the topography of civil infrastructure in a certain society or community.

117

4.9.2 Assessment of impacts

The assessment of risks must be based on well-defined goals, i.e. thematic focus (Birkmann,

2007). The thematic focus may be based upon defined array of anticipated threats, e.g.

earthquakes, flooding, tsunamis …etc. Or it may be based on specified risk assessment goals,

e.g. safety, security, and/or service interruption risks. This later is more of a backward analysis

approach, where undesired impacts are listed first, and accordingly the threats causing them are

then figured out.

Following the thematic focus, the required level of aggregation is determined, setting the

spatial and temporal boundaries of the analyzed civil infrastructure system. Using generic threat-

vulnerability relationships, similar to that defined in Table 4-6, the corresponding vulnerabilities

to be examined are identified. This step utilizes DOCK ontology to model infrastructure systems

topology. DOCK models main component entities (process, product, and actor) forming the CI

system as well as governing constraints and mechanisms. The governing constraints and

mechanisms correlate the thematic focus elements to system attributes. They determine the

system internal degree of vulnerability, i.e. vulnerability possibility (SV).

Examining the vulnerability possibility (Sv) against the anticipated threat possibility (ST);

identifying the hazard possibility (SH). If the hazard possibility passes a certain threshold, then it

is likely to materialize into an incident. The more critical the hazard possibility (severity), the

more severe is the incident severity. However, the scale (possible severity) of the impacts is

function of the infrastructure system coping capacity and existing countermeasures that augment

this capacity. The more severe is the incident (possibility), the low coping capacity and the

absence of countermeasures lay the way of severe to catastrophic impacts.

For example, in assessing the vulnerability of a bridge (CI system/asset) to earthquake

threats (thematic focus), DOCK ontology will be used to model the bridge structural components

(topology), such as beams, footings, columns…etc. A design code of practice (governing

mechanism) can be used to identify thresholds for components minimum flexural strength

(attribute) in response to various earthquake intensities. Failure to meet any of these thresholds

will indicate the existence of mechanistic vulnerability to earthquake threats. Figure 4-10 depicts

the suggested risk assessment approach.

118

Figure 4-10: Impact Assessment Logical Procedure

119

In assessing vulnerability, the ontological model follows logical procedure that determines first

the asset threat-vulnerability correlation relationship followed by the asset susceptibility.

Susceptibility is considered to be the primary component that decides upon asset vulnerability. In

case of ecological threats, it is a function of the spatial and temporal attributes of the asset. For

example, a bridge that cannot sustain the dynamic load as a consequence of an earthquake threat

is not vulnerable unless it is located in an earthquake prone area. Similarly, a building located in

an area prone to active volcanic eruptions every 100 years, is not vulnerable unless the building

service life span is estimated to be likely crossed by a volcanic eruption. At another perspective,

any civil infrastructure system that has a human-system interaction is exposed to man-driven

threats. Also systems with high psychological, economical, or strategic value are considered to

be always exposed to man-driven threats such as sabotage, terrorism …etc.

120

5 TRAFFIC INCIDENT MANAGEMENT ONTOLOGY

5.1 SUMMARY

The Traffic Incident Management Ontology (TIM-Onto) extends the ontological model and

DOCK (El-Diraby, 2009) discussed in Chapter 4. It defines the types and attributes of traffic-

related threats, vulnerabilities and incidents. TIM-Onto emphasizes on three main relationships

defining its cores concepts. The first is the threat-vulnerability relation ‘exploit’ emphasizing the

parity between the two concepts, i.e. not all threats are relevant to all vulnerabilities and vice-

versa. Secondly, the relationships ‘exasperate’ that correlate situational-factors and threats as

well as situational-factors and vulnerability. The third main relationship is the ‘cause’

relationships that relate threat-vulnerability pairs to resulting incidents (with situational-factors

in the background).

The ontology also discusses how threats and vulnerabilities are to be assessed as well

how to predict incidents and estimate their impacts. Finally, the ontology lists some of the major

relevant axioms. The ontology lays the foundation for decision support tools through

encapsulating an abstract view of traffic incidents, their root causes, adequate countermeasures,

and information flows. In achieving such objectives, TIM-Onto adopts the dual but

complementary approaches of incident management and vulnerability assessment.

5.2 MOTIVATING SCENARIO

Each agency involved in traffic incidents response has different roles and responsibilities that

sometimes conflict. Such multiple and intermixed objectives require clear understanding and

identification of key TIM processes and actors in order to determine trade-offs necessary for

coordinated response. Developing formalized response plans that stems from well-defined,

coordinated cross-agency policies and procedures will provide timely response and efficient

resource utilization; improving safety, reducing congestion and pollution efficiently (Ozbay

1999). In addition, understanding incidents root causes will help to minimize or even eliminate

incident future occurrence (Ng et al. 2002).

121

TIM-Onto motivating scenario is aligned with the requirements analysis outlined in Chapter 3.

As previously mentioned this requirement analysis is derived from information compiled from

traffic incident and emergency management literature, best practice guides, operations manuals,

and personal interviews with the Ontario Ministry of Transportation traffic operators.

Accordingly, the following motivating scenario was developed:

“Upon the occurrence of a traffic incident, the incident must be detected and verified

through well-defined channels. The incident is then classified, identifying its severity and

anticipated impacts on the traffic network performance. Based on the incident identified type and

associated attributes, appropriate response resources are dispatched to the incident scene

according to predefined protocols. Each involved stakeholder overtakes her/his formally

predefined responsibilities and roles in evacuating the incident victims, clearing the scene and

restoring normal traffic operation conditions. All of this is performed in the minimum possible

time, through efficient utilization of available resources, and no duality in response efforts.”

Based on the above mentioned scenario, the competency questions that were used to

develop TIM-Onto concepts, relationships, and axioms were formulated. These competency

questions decide on the application ontology capabilities for urban TIM. The following

competency questions were formulated:

CQ-1: What are the different types of incidents in the traffic network?

CQ-2: What are possible threats causing incidents in the traffic network?

CQ-3: What are the vulnerabilities if exploited might lead to traffic incident occurrence?

CQ-4: What are the situational factors exasperating identified threats/vulnerabilities?

CQ-5: What are the source threat-vulnerability pairs for each identified incident type?

CQ-6: How a traffic incident alert is verified in the highway traffic network?

CQ-7: What are the traffic incidents response-related attributes?

CQ-8: What are the measures of traffic incident impact?

CQ-9: What are the countermeasures taken for each incident type occurrence?

CQ-10: Who will perform these countermeasures?

CQ-11: What are the required resources for these countermeasures?

CQ-12: What is the organizational hierarchy of actors performing these countermeasures?

CQ-13: What are the rules to prioritize response to multiple incidents?

CQ-14: What are the response countermeasures performance measures?

122

Each of the before mentioned competency questions correspond to one or more of TIM strategic

requirements (institutional and/or operational), previously outlined in Table 3.7 of Chapter 3.

Table 5.1 lists TIM-Onto competency questions together with the corresponding requirement/s

being satisfied.

Table 5.1 TIM-Onto Competency Questions vs. Strategic Requirements

1.

1 Fo

rmal

ly d

efin

e do

mai

n co

re c

once

pts

1.2

Ado

pt v

ulne

rabi

lity

asse

ssm

ent a

ppro

ach

1.3

Form

al d

efin

ition

of a

ctor

s’ r

oles

hie

rarc

hy

1.4

Stan

dard

cri

teri

a fo

r in

cide

nt c

odin

g

2.1

Form

ally

def

ine

resp

onse

pro

cess

es

2.2

Def

ine

resp

onse

con

stra

ins/l

iabi

litie

s

2.3

Def

ine

resp

onse

per

form

ance

mea

sure

s

2.4

Iden

tify

resp

onse

pro

cess

es/ r

esou

rces

/act

ors

2.5

Cor

rela

te r

espo

nse

proc

ess

w/ i

ncid

ent t

ypes

CQ-1

CQ-2

CQ-3

CQ-4

CQ-5

CQ-6

CQ-7

CQ-8

CQ-9

CQ-10

CQ-11

CQ-12

CQ-13

CQ-14

123

5.3 TIM-ONTO TAXONOMY OF THREATS

TIM-Onto threat taxonomy extends the ontological model threat taxonomy presented in Chapter

4 and Appendix-B, creating instances that are specific for the traffic engineering domain. Table

5-2 and 5-3illustrate the abstract TIM-Onto taxonomy with example of threat sub-classes. The

tables classify threats from the causal, domain, and intention modalities defined in Chapter 4,

presenting specific instance of each threat. For complete taxonomy refer to Appendix-B.

Table 5-2: TIM-Onto Act of God Threat Taxonomy

Threat Domain Modality

Sample Sub-class

Example of Threat Instance

Relevant Level Attributes

Com

pone

nt

(min

i-lev

el)

Sub

com

posit

ion

(min

or-le

vel)

Com

posi

tion

(maj

or-le

vel)

Pred

icta

bilit

y

Tem

pora

l ev

olut

ion

Geophysical Earthquake

6.0 Richter scale earthquake affecting network bridges and tunnels.

A A A M S

Soil Particles Move Soil Erosion under bridge footings. A NA NA M E

Hydrological Flood Riverine Flood destroying several

links. A A NA M E

Snow Avalanche Snow Avalanche closing mountainous link. A A NA L S

Chemical

Flammable Forrest fires closing several links. A A NA L E

Poisonous Chemical (industrial) leakage of high dispersible chemical material. A A NA N S

Explosive Industrial chemical explosion A A NA N S

Meteorological

Rainstorm Rainstorm impacting city network A A NA M E

Snow Storm Snow storm impacting city traffic network. A A NA M E

Tornado Tornado impacting city traffic network A A NA M E

Animal Wild-animal Wild bison crossing rural link A NA NA L S

Cyber Communication Failure of traffic emergency

dispatch system A A A N S

Control Failure of single signal traffic light A NA NA N S

Radioactive Radioactive Radioactive industrial contamination A A A N S

Legend: A: applicable, N/A: not applicable, L: limited, M: moderate, H: high, N: none, E: evolves, S: sudden.

124

The three levels of relevance presented in the Table 5-2 define the level of threat outreach in the

traffic network. The component level of relevance represents the minimum level of outreach, i.e.

network individual link; while sub-composition represents part of the network (e.g. freeway

neighboring arterials sub-network). The composition represents the major level of relevance, e.g.

the whole freeways network. For example, an earthquake threat is more likely to outreach the

whole traffic network (composition level) compared to driver-error which is confined by the link

the driver is currently driving on (component level). An earthquake, if occurred, is likely to

create hazard states in all relevant vulnerable locations in the network, while a driver error

creates a hazard state on only one link. As the single driver-error threat cannot concurrently exist

on multiple links at the same time.

Threats differs in their degree of predictability, a snow storm and an earthquake threats

are moderately predictable, while a deer crossing a high speed highway in Manitoba is low

predictable threat. A snow storm is predicted meteorologically few days in advance. A country

like Japan is expected to have 1500 seismic activities (earthquakes) per year (Guidi, 1987). But

no one can say when is the next industrial chemical explosion is likely to happen (Steffy, 1994)!

Table 5-3: TIM-Onto Man-Driven Threat Taxonomy

Threat Intention Modality

Sample Sub-class

Example of Threat Instance

Relevant Level Attributes

Com

pone

nt

(min

i-lev

el)

Sub

com

posit

ion

(min

or-le

vel)

Com

posi

tion

(maj

or-le

vel)

Pred

icta

bilit

y

Tem

pora

l ev

olut

ion

Intentional

Isolated Individual Suicide Attempt on highway bridge A NA NA N S

Activism Public wrights, which may lead to road blockage A A NA L E

Criminal Actions Theft of roadway feature A NA NA L S

Terrorist Attack Chemical explosive attack A A A L S

Non Intentional- External Error Conceptual Faulty Code/law/regulation (off-

system error) A A A L NA

Non Intentional- Internal Error (Ambient Threat)

Cognitive bias Misperception of sensory inputs from surrounding stimuli, e.g. mirage on pavement surface

A NA NA L S

Behavioral Reckless driver A NA NA L S

Operational Communication error between human parties A NA NA L S-E


125

Conceptual threats relates to code error that is outside the system being considered. If it is within

the system, then it is an operational error and classified as an ambient threat. Each of the man-

driven threats can take any of the domain modalities. For example, a terrorist attack can be

biological, chemical, or radioactive. All man driven threats are classified with mini-level

relevance (except for conceptual and terrorist threats) and low predictability (Luiijf, 2006).

5.4 TIM-ONTO TAXONOMY OF VULNERABILITIES

Similar to TIM-Onto threat taxonomy, the vulnerability taxonomy is extended from the

ontology presented in Chapter 4; creating instances that are specific for the traffic engineering

domain. Table 5-4 illustrates TIM-Onto vulnerability taxonomy with the extended first level

sub-classes. The table classifies vulnerabilities tangibility and resource modality, indicating the

associated level of vulnerability aggregation and default attributes.

Similar to threat the vulnerability relevance level indicates the possible degree of

diffusion of the vulnerability in the traffic network system. For example, a cyber-attack on the

traffic control communication infrastructure is likely to affect all traffic signals in the network. A

link with downgrade steep slope (geometric-vertical alignment vulnerability) has component

level of relevance, since it creates localized hazard state. In case it was exploited by snow or rain

storms threats. Some vulnerabilities are highly predictable, e.g. a steep downgrade link is

obviously a vulnerability. However, it is more challenging to determine how the lack of

sufficient maintenance budget (resource vulnerability) will create a hazard state, and which

specific threats will exploit this vulnerability. But no argue, it is still a critical vulnerability.

Some vulnerabilities evolve with time, while the majorities have no temporal evolution.

For example, low skid resistance of pavement surface propagates with the pavement service life

as more and more traffic wears of the pavement surface. However, it is not that easy to tell the

evolving nature of a poor management process. The final attributes presented in Table 5-4 is the

controllability. This again varies with the situational factors of the entity. For example, a sharp

horizontal curve has low controllability. All what can be done is the placement of a warning sign

or enforcing speed limit. However, the vulnerability cannot be eliminated; unless the roadway

link is completely replaced by a better designed one.

126

Table 5-4: TIM-Onto Vulnerability Taxonomy

Vulnerability Modality

Level-1 Sub-class Example Instance

Level Attributes

Com

pone

nt

(min

i-lev

el)

Sub

com

posi

tion

(min

or-le

vel)

Com

posi

tion

(maj

or-le

vel)

Pred

icta

bilit

y

Con

trolla

ble

Tem

pora

l ev

olut

ion

Physical

Physiochemical Chemical reactivity of signal post. A A NA H H NA

Mec

hani

stic

Pavement related

Skid resistance of pavement surface (low coefficient of friction).

A NA NA H H E Pavement serviceability index (cracks, bumps, depressions, rutting, and potholes)

Structure related Low compressive strength of bridge column A NA NA M M E

Geo

met

ric

Intersection Type, geometry, turning and through lanes, pedestrian consideration A NA NA H L NA

Geometric Alignment

Vertical alignment (slope, curvature) A NA NA H L NA Horizontal alignment (curvature, length of straight segments) A NA NA H L NA

Vertical-horizontal alignment consistency A NA NA H L NA

Sidewalks A NA NA H L NA

Geometric Cross section Elements

Travel way: Lane width/No. Lanes, passing lanes, left turn lanes, x-slope A NA NA H L NA

Shoulder: Type/Width, cross-slope A NA NA H L NA Curb attributes Channelization (medians, islands) A NA NA M L NA

Virtual

Cyber Security hole in the traffic control system communication network A A A L H E

Logical

Management- Poor maintenance process and procedures. A A A M M E

Legal- Weak law enforcement policies and processes. A A A M M E

Technical- Improper signals timing, Lighting and illumination A A A M M E

Resource

Physical Resource Insufficient number of police cruisers

Human Resource Lack of trained personnel

Knowledge Resource Lack of the know how A A A L M NA

Financial Insufficient budget for network maintenance A A A L L NA


127

5.5 TIM-ONTO TAXONOMY OF SITUATIONAL FACTORS

As previously mentioned in Chapter 4 situational factors are boundary of entities/attributes that

exasperate threats and/or vulnerabilities. TIM-Onto classification of situational factors is

depicted in Table 5-5 below. Situational factors are the catalysts that trigger hazard states but not

the source. The highway safety literature is ample of studies correlating situational factors to

traffic incidents occurrence.

One can argue that some of the concepts presented in Table 5-5 are vulnerabilities.

However, in the author’s point of view the factors in the table are not internal system attributes,

but rather external attributes and ‘conditions’ that if did not exist might not had led to an

incident. For example, consider an inattentive driver (threat) on sharp horizontal curve

(vulnerability). If the driver was driving on a rural highway segment, a possible outcome would

be vehicle side-drift off the roadway. If the very same situation was in a tunnel that has the same

sharp curve as rural highway segment, a more probable outcome would be the vehicle side-

drifting and crashing against the tunnel walls. In this case the roadway type represented a

condition that exasperated the sharp curve vulnerability and inattentive drive threat.

To further add, the outcome of the very same inattentive driver and on the sharp

horizontal curve varies by the type of vehicle being driven. Consider the performance of a

Porsche versus 4×4GMC Yukon on sharp horizontal curve. Arguably, the Porsche would exhibit

more stability and safer performance by virtue of its superior mechanical and aerodynamic

design. In all cases, it cannot be said that the GMC Yukon, a bridge or a tunnel represents

vulnerabilities in the traffic network. But rather they are catalyst entities that will exasperate

relevant threats and vulnerabilities.

A similar argument can be given for logical situational factors. For example an undivided

(vulnerability) rural multilane in Egypt is strongly correlated to traffic incident occurrence

(Abbass, 2004). However, less correlation was indicated by similar study in the United States

(Karlaftis, 2002). One of the explanations for the stronger correlations in Egypt was that drivers

were tempted to use traffic gaps in the opposite direction to overtaking slower vehicles. Such

attitude is not expected in the United States due to greater sense of individual social

responsibility, level of education, and of course law enforcement practices.

128

Table 5-5: TIM-Onto Situational Factors Taxonomy

Situational-factors Classification Attributes

(default values) Predictability Controllability Variability

Art

ifici

al E

nvir

onm

ent

Technical/ Tacit

Traffic Factors

Traffic volume

M M H

Traffic density Average Speed Crossing Pedestrians Volume Traffic mix (i.e. trucks)

Synthesized/ Explicit

Vehicle Factors

Electromechanical M M M

Aerodynamic M M M

Service life M M H

Network Factors

Freeway M H M Arterial M M H

Local streets L L M

Roadway Type Factors

Standard Link L L H

Bridge/Tunnel M L H

Exit/Entrance Ramp L L H

Roadside Features

Guardrails, barriers, posts, parking bays A NA NA

Traffic Control Devices

Signage, delineators and marking. A NA NA

Land Use Factors

Rural H H H

Urban commercial L L H

Urban residential L M H

Nat

ural

E

nvir

onm

ent Visibility Bright, satisfactory, dim, complete dark

L L L Temperature Cold, moderate, warm, hot

Noise Level High, moderate

Log

ical

Political/ Governance Good governance structure

L L L Economic Economic development

Social Social cohesion, driving habits, travel patterns, social development

Hum

an

Physical Impairment

E.g. Handicap or eyesight weakness(visual impairment) M M M

Behavior Drinking, drug-use, risky use of cellular phone, sleepy driving, violation of traffic laws.

L L H Gender Male vs. female drivers

Age Senior, middle age, young, and teenage drivers

129

In the highways safety literature, factors such as poor marking (traffic control devices) or

absence or guardrail (guardrail) are clear source of vulnerability (Sawalha, 2001). But rather they

can be seen as exasperating factors. For example, an intersection with sharp turning curve

(vulnerable horizontal alignment) that results in poor sight distance (hazard). If the intersection

was equipped with proper marking and warning signs the probability of threat exploiting the

poor curvature will definitely decrease, and vice-versa.

Some sources in the literature refer to gender and age as threats (Tavris, 2001). Chipman

et al. (1992) scale the difference between the genders showing that male drivers have the double

number of crashes compared to their female counterparts. This difference was explained in a

report published by the Social Issues Research Centre in UK (2004) due to the aggressive nature

of males and tendency to deviant behavior (rule-breaking) compared to females. On the other

hand, Matthews and Moran (1986) found that young male drivers involvement in traffic

accidents to be higher compared to other age groups.

It is in the author’s point of view that both age and gender are situational rather being

specific threat category. The overestimation in certain group (age or gender) involvement in

accidents rate is mainly related to data misrepresentation. As reported by Kim et al. (1995) and

Richardson et al. (1996), it should be comparing the relative frequency of each driver age and

gender group rather than the total number of traffic incidents involvement of each group. Garber

and Srinivasan (1991)indicated that senior drivers’ involvement in traffic incident is higher at

suburban intersections and more prevailing during evenings. However, a more in-depth analysis

would reason this due to the fact of higher concentration of senior drivers in the suburbs and to

their avoidance of morning rush hours and preference to commute during the evenings.

Evans (1991) describes the age involvement in traffic incidents to be situational, which

complies with Abdel-Aty et al. (1998). Senior drivers are probable to be involved in angle and/or

turning incidents, mainly due to their slower perception-reaction time and declined ability to

judge speed and gaps of approaching traffic. However, they are less prone to incidents at high

traffic volumes compared to young drivers due to their tendency to be more cautious. Similarly

they are less likely to speed or to commit drunk-driving (Kim, 1995).

In summary, it is in the author’s point of view that the age and gender are situational

factors, if mixed with other conditions in the traffic network they are likely to exasperate existing

130

vulnerabilities and anticipated threats. Driver’s age exasperate vulnerabilities at certain

situations, e.g. at turning intersections. However, it decreases the probability of incident at other

situations, e.g. during rush hour high traffic volume. A similar argument can be made for the

gender factor as well.

5.6 TIM-ONTO TAXONOMY OF INCIDENTS

In the traffic management literature an incident is defined as: undesirable temporary event

reducing roadway serviceability, degrading safety and impeding normal traffic flow conditions

(Ozbay 1999). The ontological model presented in Chapter 4 defines an incident as the

materialization of CI system hazard state into an undesirable event. The occurrence of this event

(incident) is the result of the success of specific threat/s in exploiting certain corresponding asset

vulnerabilities. Figure 5-1 illustrates the traffic incident taxonomy.

Figure 5-1: Traffic Incident Taxonomy

131

TIM-Onto extends the concepts defined in ontological model, applying it to the traffic incident

management domain. It models a highway traffic incident as an event resulting from the

materialization of a hazard state created on the highway network as result of the success of a

certain threat in exploiting corresponding vulnerabilities in the highway network system. For

example, a rain storm (meteorological threat) exploits low skid resistance of pavement surface

(physical vulnerability) leading to slippery pavement state (safety hazard), which may lead to a

vehicle related incident.

Table 5-6 enumerates for each incident class shown in Figure 5-1, the probable source of

threats, vulnerabilities and relevant situational factors. The source vulnerabilities and threats

presented in the table are not the only possible sources. However, they are the ones to be the

more common for these types of incidents as discussed in more details in section 5.7. The table

presents the vulnerabilities and threats associated with road-structure incidents in a brief manner.

TIM-Onto incident taxonomy subclasses were carefully chosen to match the same

terminologies used by various stakeholders in the traffic management domain to describe traffic

incidents. These terminologies were extracted by the author thorough investigating traffic

incident management and highway safety literature and supported by multiple interviews with

domain experts. TIM-Onto traffic incident taxonomy subclasses and incident associated

attributes.

The presented incident subclasses are specialization of the incident modalities presented

in Chapter 4. In specific four modalities can be used to describe incident subclasses described in

Figure 5-1, which are: domain, environmental, material-, human (health/life)-, and property-

related modalities. For example, both vehicle-related and road-structure incidents are

specialization of property-related and safety (domain) modalities. It worth mentioning that TIM-

Onto supports multiple inheritances of incident concepts, i.e. those concept forms a joint set. For

example an incident can be a vehicle-related incident and road structure incident concurrently.

Thus the event of a vehicle hitting a crossing pedestrian and then crash into a road barrier is both

collision with pedestrian and collision with fixed object incident.

132

Table 5-6: Traffic Incident Source Threat, Vulnerabilities and Relevant Situational Factors

Incident Source Vulnerability Threat Situational Factors

Vehicle Collision

Geometric Vulnerability - Restricted sight distance due to

horizontal/vertical alignment configuration. - Inadequate shoulder design (case of ran-off

road and sideswipe collisions) - Improper channelization (case of ran-off

road)

Logical Vulnerability - Inadequate roadway lighting system - Improper signal timing plan - Absence of enforcement

- Driver Error - Animal threat (animal-

collision) - Meteorological

(case of loss of skid resistance)

- Cyber (case of malfunction of traffic signals)

Technical: - Excessive approach speed - High through/turning traffic

volume - Crossing pedestrian - Large parking turnover (case of

collision with parked vehicle/s) Traffic Control Devices: - Improper signage - Poor delineation (case of ran-off

road) Human related: - Visual physical impairment - Age& Behavior

Environment related: - Visibility (e.g. night time) Vehicle related: - Loss of brakes Land Use: - Urban area, i.e. residential,

commercial, school (case of pedestrian collision)

Roadside feature related: - Absence of guardrail/barriers

(case of ran-off road) - Illegal/improper parking

Vehicle Fire

Physiochemical Vulnerability - Low ignition point of vehicle components Mechanical (Domain) Vulnerability

- Act of God, Chemical Threat – Flammable

- Driver Error (collision leading into fire crash)

- Vehicle Design Error

Vehicle related: - Service life Environment related: - Extreme weather temperature

(Very hot temperatures)

Vehicle Disablement

Physiochemical Vulnerability - Defective vehicle physical/electrical

components. Mechanical (Domain) Vulnerability

- Vehicle Design Error - Cyber- breakdown of

electronic control unit - Natural threat (sudden

breakdown)

Vehicle related: - Service life Environment related: - Extreme weather temperature

-

Material Spill

Security (Domain) Vulnerability Safety (Domain) Vulnerability *All vulnerabilities that may lead to collision of a vehicle and might affect a truck counts as well.

- Natural Chemical Threat - Man-driven Chemical

Threat (Intentional and Non-intentional)

Vehicle related: - Electromechanical system - Service life

Technical: - Percentage of trucks in traffic

stream. *All situational factors that may lead to collision of a vehicle and might affect a truck counts as well.

Weather

Resource Vulnerability - Insufficient number of snow blower Logical Vulnerability - Poor snow clearance process

- Natural Meteorological threat

Environment related: - Extreme weather temperature

Road Structure

- Physiochemical Vulnerability - Mechanistic Vulnerability - Resource Vulnerability - Logical Vulnerability

-Natural/Man-driven Threats- Chemical, Meteorological, Geophysical, Hydrological, Radioactive, Cyber

Environment related: Extreme weather temperature

133

5.7 MEASURING INCIDENT IMPACTS

Impact measures are essential for traffic incident management. The number of injured personnel

and damaged vehicle define the type and number of response units. Further, these measures are

used to determine the incident duration as the degree of impact determines clearance time.

Incident duration is essential for traffic control measures such as diversion routes initiation. The

following paragraphs describe the measure of impact tailored for the traffic incident management

domain, illustrated Table 5-7 as well:

§ Health/life Impact: refers to number and degree of injuries (minor, serious, critical) as well as

number of fatalities, if any, among the roadway travelers. The term health is used to indicate

that the impact beside injury can be infection, toxication, and/or poisoning.

§ Property Impact: is categorized as either being road-structure/facility or vehicle

damage/contamination, with the damage level being categorized as either full, partial or

minor. Depending of the type of road-structure/facility (i.e. mission, critical utility, support

and auxiliary) the extent of operational impact on the traffic network is defined.

§ Operational Impacts: two traffic network performance measures are used to assess traffic

incidents operational impacts, travel time delay and accessibility. Travel time delay is the

total increase in travel time for all the trips in the traffic network, due to the occurrence of a

traffic incident (Austroads, 2007). Accessibility is the partial or full denial of transportation

service using the traffic network due to traffic incident occurrence (Sohn, 2006).

Accessibility can be expressed in terms of number of unsatisfied trips, due to access denial

(Sohn, 2006). TIM-Onto quantifies passenger trips and freight trips separately,

acknowledging the fact that they have different operational monetary costs.

§ Ecological Impacts: are classified into four sub-concepts: increase in emissions, noise level,

energy use, hazardous spill. Hazardous spills contamination can be air, water, soil, or living

organisms.

Each of the before mentioned measures is transferred into one or more of the impact measures,

described in Table 4-3 of Chapter 4. For example, number of minor injury is transferred in a

short-term, indirect monetary impact defined in terms of value of required medical care.

Number of lost trips can be used as a Macroeconomic measure of loss in productivity or

economic activities and so forth.

134

Table 5-7: TIM-Onto Impact Measures

Impact Type Impact Possibility Measuring Quantity

Health Minor, Serious, Critical Integer value representing number of injuries.

Life NA Integer value representing number of fatalities.

Property Damage

Passenger Vehicle Minor damage Partial damage Full damage

Integer value representing number of vehicles involved.

Truck Integer value representing number of vehicles involved.

Travel Delay Time duration value representing total delay of travelers involved.

Operational Accessibility NA Integer value representing number of declined trips

Ecological

Air Minor contamination Serious contamination, Critical contamination Fatal contamination

Area of impact Water

Soil

Living Organisms

5.8 MODELING THE TRAFFIC INCIDENT

The literature is ample with case studies investigating the different facets of transportation

infrastructure vulnerabilities. Although valuable, these studies represent disjointed cases;

investigating specific vulnerabilities and threats. TIM-Onto provides a coherent and

comprehensive framework that can be used to assess risks associated with civil infrastructure

against full array of possible threats and vulnerabilities. Creating a decision-making tools for risk

assessment; where decision makers can assess network vulnerability against a thematic focus of

anticipated threats.

The before mentioned case studies provided the insights used to develop TIM-Onto

underlying concepts taxonomies and identifying concepts cross-relationships. For example,

justifying why driver’s age is considered situational-factor rather than threat or vulnerability.

Table 5-8 dwells on previous work from the literature for selected threats, vulnerabilities and

situational-factors from TIM-Onto taxonomy. It identifies the analytical models correlating

these concepts; explaining the influence of these models in TIM-Onto underlying logic. The

table lay specific emphasize on ‘driver-error’ threats and road geometric vulnerabilities; as they

are identified for being the primary source of traffic incidents (Bahar and Parkhill, 2006).

135

Table 5-8: Correlation between Threat, Vulnerability, Situational Factors, and Incidents

s Driver Errors& Situational Factors

Rain Snowstorm Flood Earthquake Animal Threat

Alcohol Age Fatigue Social/

Cultural Gender

1a 1b 1c 1d 1e 2 3 4 5 6

Mec

hani

stic

Pavement 1 Q1-2

Structural 2 Q2-4 Q2-5

Geo

met

ric

Intersection 3 Q3-1b

Horizontal Alignment 4 Q4-1a Q4-1b

Q4-1c

Q4-6 Vertical Alignment 5

Cross Section Elements 6 Q6-1 Q6-1e

Logi

cal Technical 7 Q7-1b

Legal 8 Q8-1d

Physical Resource 9 Q9-3 Q9-4

Legend Qij: sample relationship between threat and vulnerability in the transportation network.

136

Table 5-9 briefly outline the analytical models used to derive the relationships identified in the previous table.

Table 5-9: Examples of Incident Correlation to Threat-Vulnerability Pairs Relation Description

Q1-2

Chan et al. (2010) conducted a negative binomial regression analysis to investigate the relationship between pavement PSI and traffic incidents frequency. A strong inverse correlation was found between pavement PSI and traffic incident frequency on USA interstate highways, specifically during rainy weather (source threat). One unit of PSI deterioration increased the incidents frequency by 1.412 (e0.345). Night time and peak hour traffic conditions (situational factors) were found to even exasperate this relation.

The effect of night time on incidents rates was emphasized as well by Herd et al. (1980); correlating the pavement distresses to rainy weather and driver’s speed. It was concluded that imposing a speed limit of 55mph would significantly decrease traffic accidents. The author used linear regression analysis to synthesis these conclusions.

Aside from hindering visibility the rainy weather was found to be responsible for vehicles hydroplaning and windshield splash for opposite direction traffic. Rizenbergs et al. (1977) found a strong relation between pavement skid resistance, rainstorms and incidents frequency. The analysis was conducted on 2350km of interstate highways in Kentucky, US.

Q2-4

Laursen (1984) studied the relationship between bridges piers mechanistic properties against floods (Structural Vulnerability Domain) using scour progression prediction model.

Federico (2003) studied the correlation between bridge pier shapes, bearing capacity of foundation, against floods using an analytical model; function of scour and foundation depths.

Q2-5

Tzu-Kang Lin (2002) studied the anticipated damage of bridges after earthquakes using neural network model, incorporating the bridge mechanistic property as an input.

Hsu (2000) studied the collapse of Wushi bridge in Taiwan due to an earthquake of magnitude of 7.3 Richter scale. Aside from the unanticipated scale of earthquake the damage was correlated to error in bridges design code. The design codes underestimated the horizontal ground acceleration due to earthquakes making the cap 1/3 of that was experienced by the earthquake.

Q3-1b

Stamatiadis et al. (1991) used probabilistic statistics to indicate strong correlation between senior drivers and incidents are intersections. Senior drivers have tendency of being involved in angle and turning accidents possibly due to their slower perception and reaction times, and their declined ability to judge the speed of, and gaps between, oncoming vehicles. His observations were evident at intersections having approaches meeting with acute angles (since they hinder visibility).

Q4-1a

Abdel-Aty and Abdelwahab (2000) developed a log-linear regression model correlating driver alcohol intake and highway horizontal alignment characteristics. They indicated a strong correlation between roadway horizontal curvature and driver-error incidents. A strong correlation was also made with race, gender, and age. White drivers were found to be more probable to be involved in alcohol related accident, senior were found to be less, females are half the probability of men.

Q4-1b Abdel-Aty et al. (1998) developed a log-linear regression model correlating driver’s age and highway horizontal alignment characteristics. It was indicated that compared to straight segments, the odds of an incident on a curved segment are higher for teenage and young drivers. Middle age and senior drivers tend not to speed; thus incidents on curves are less likely to occur.

137

Table 5-9, (Cont’d): Examples of Incident Correlation to Threat-Vulnerability Pairs


Q4-1c

McGwin and Brown (1999) proved a statistical correlation between roadway geometry and driver’s age. Older drivers were more likely to experience crashes on straight roadway segments compared to steep grades or curved segments. However, at situations involving constraint sight distance either due to vertical/horizontal curvatures or intersections; they were more likely to be involved in traffic incidents.

Abdel-Aty and Radwan (2000) analyzed the sensitivity of driver’s age to degree of horizontal curve using negative binomial regression models. They confirmed previous work in the literature finding out that younger drivers are more prone to incidents on horizontal curves due to their tendency to speed.

Q4-6

Rowden et al. (2008) studied animal-vehicle collisions on Australian rural highways between 1990 and 1997. The excessive straight segments (horizontal alignment) in the Australian highways horizontal alignments were found responsible for tempting drivers to exceed speed limits and thus unable to avoid animal crashes. In addition lack of animal underpasses (vertical alignment) and roadside fences (situational factors) in animals densely populated areas were found to be among the major causes.

Caro et al. (2000) blamed cross section side clearance and roadside bushes for animal vehicle collisions. The author claimed that maintain a sufficient cross section side clearance will provide drivers with sufficient sight distance to observe crossing animals. Lao (2011) developed an inflated bivariate Poisson regression model to correlate animal-vehicle collision to road alignment attributes. He found strong correlations between the vertical alignment, speed limit, annual daily traffic and shoulder width.

Q6-1

Rengarasu et al. (2009) used negative binomial regression model to drive the correlation between the roadway cross section elements and traffic incidents. They found that incidents frequency is inversely correlated to increase of shoulder width beyond maximum allowable length. Inverse correlation between number of lanes.

Hadi et al. (1995) used negative binomial regression analysis to estimate the relation between roadway cross section elements and traffic incidents on rural and urban highways at different traffic levels. The results indicated that, depending on the highway type, increasing lane-, median-, and inside/outside shoulder-width reduces frequency of traffic incidents. The results also indicated urban highways with raised median are safer than undivided ones.

Abdel-Aty and Radwan (2000) indicated that shoulder and median widths affect negatively the frequency of traffic incidents using negative binomial analysis. However, the sensitivity analysis values indicate that these results are higher for older drivers. The interaction between lane width to no. of lanes was also found to affect negatively the incidents frequency.

Q6-1e Abdel-Aty and Radwan (2000) indicated that female drivers are more sensitive to median width and lane width with positive correlation, and a negative correlation to number of lanes.

Q7-1b

Garber and Srinivasan (1991) developed statistical models relating driver error to the traffic and geometric characteristics of the intersection. The primary conclusions are as follows: (a) the senior drivers are more prone to perform a traffic violation when it is necessary for them to yield to opposing traffic compared to younger age groups drivers; (b) the provision of a protected left-turn phase with left-turn lanes will help in reducing the accident rates for senior drivers at signalized intersections; and (c) longer amber times will be beneficial to senior drivers.

138

Table 5-9, (Cont’d): Examples of Incident Correlation to Threat-Vulnerability Pairs


Q8-1d

Factor et al. (2007) conducted an extensive literature analysis on the effect of culture on driving, behaviour and frequency of traffic incidents. The authors developed a social model to investigate what they termed the social incident. They referenced a study by Stanford University (1985) on driving characteristics in Egypt and the study by Edensor (2004) examining driving habits in Britain and India. Both of these two studies related the traffic incidents to different countries cultures and code of driving behaviours. In addition, they referenced the high incident rates in these two countries compared with countries in the West, due to the fact that both Egypt and India have a low level of legislation and formal enforcement, a fact that necessitates informal agreements and driving rules among drivers.

Gaygisiz (2010) correlated the incident frequency with the governance quality, cultural and road traffic incidents fatality rates in a sample of 46 countries. Governance quality was measured using the World Governance Indicators (WGI) published by World Bank. The the cultural dimension of a society was investigated using Hofstede's and Schwartz empirical scale. Poor governance countries with low cultural development indicated strong correlation with incident fatalities rates. It was concluded that the quality of governance and institutions would result in improvements in traffic safety.

Q9-3

Sohn (2006) investigated the effect of the component on the composition (part to the whole) assessing the vulnerability of State of Maryland highway links under flood damage using GIS base map to simulate the effect of flood plains on the highway network. Individual links were removed and the whole network vulnerability was assessed based on accessibility denial (number of unsatisfied trips due to links elimination), using shortest path algorithm. The author claimed that if the network had enough reserved capacity (physical resources); it should be able to sustain the strain from the flood damage.

Q9-4

Berdica (2004) studied network link redundancy vulnerability against snowstorms using a framework of sensitivity analysis and meso-scoping simulation. Berdica claimed that for a network not to be vulnerable; it must have enough numbers of redundant links so that none of them would represent single point of failure.

Jenelius (2007)link redundancy (resource vulnerability) as well as network scale, road density, population density (situational factor) against snow storms meteorological threats using micro-scoping simulation, graph theory and regression modeling.

139

5.9 MODELING THE TRAFFIC INCIDENT MANAGEMENT SYSTEM

Traffic incidents have impacts that are mitigated or reduced by countermeasures. These

countermeasures are incorporated in a traffic incident management system framework. Upon the

detection of the traffic incident, an Incident Management System deployed on the freeway

corridor on which the incident took place is triggered. Such system utilizes appropriate resources

and countermeasure processes that corresponds to the type of the occurring incident.

This system provides traffic incident management service, encompassing set of

sequential and cross related processes such as detection, response, and clearance. Modeling the

incident management system as a set of cross-related processes is consistent with incident

management literature (Ozbay, 1999). TIM-Onto focuses primarily on modeling TIM

processes, actors, actor-roles, and products. In doing so, TIM-Onto extends IC-PRO-Onto to

model incident management processes, AR-Onto to model involved actors and their roles, and

IPD-Onto to model TIM Urban Highways system. Figure 5-2 depicts TIM-Onto incident

management conceptual model, which is describes in details in the following sections.

Figure 5-2: TIM-Onto Components and Extended Ontologies

140

5.9.1 Traffic Incident Management Processes

As previously mentioned, incident management is formed of set of subsequent, overlapping, and

cross-related processes. Aprocess is formed of activities that are broken down into tasks. Each

activity/task is performed by designated actor and each process has input resource/s and output

product/s. Much of the costly delay due to traffic incidents is accounted to poor processes

engineering and integration within the TIM framework. As such, the process is the core context

in TIM-Onto as well as other extended parent ontologies. TIM-Onto utilizes two major

modalities for process taxonomy defined in IC-PRO-Onto to describe the incident management

processes, which are phase and the function modalities.

The phase modality of a process describes the incident management process from a

temporal context, i.e. phases of sequential processes performed in specific order. On the other

hand, the functional modality classification clusters processes that require similar expertise

together based on the process designed function. The following two sections illustrate the

taxonomy of each of these process modalities within TIM domain.

5.9.1.1 Incident Management Processes Taxonomy: Phase Modality View

From temporal perspective, TIM is formed of five main subsequent processes, previously

illustrated in Figure-2.1 of Chapter 2. The following summarizes these five processes phases:

1. Incident Detection Process: is the process of defining the spatial and temporal coordinates as

well as classifying a traffic incident (Ozbay, 1999).

2. Incident Verification: is the process of verifying the detected incident by an authorized actor,

confirming its location, impacts, and assuring that the detection is not a false alarm.

3. Incident Response Process: is process of utilization, coordination and management of

appropriate actors and resources to minimize and recover the incident impacts.

4. Incident Clearance Process: is the process of safe and timely removal of traffic incident

physical impacts from the incident-scene and the termination of the hazard state/s that had

resulted in or from the incident.

5. Incident Recovery Process: is the process of restoration of pre-incident operating conditions,

preventing impacts propagation to other parts of the traffic network.

141

5.9.1.2 Incident Management Processes Taxonomy: Functional Modality View

Each of the processes mentioned in different TIM phases incorporates multiple sequential/

overlapping sub-processes. For example, traffic management is an ongoing process throughout

all TIM processes phases. In addition, these sub-processes differ in objectives, functions,

resources, actors’ type and expertise, etc. To accommodate to the before mentioned another

aspect (modality) in classifying TIM processes was incorporated within TIM-Onto, which is the

functional modality. Functional classification bears specific importance. It specifically identifies

required TIM response processes for each detected incident type, as discussed in details in

section 5.9.1. The functional modality classifies TIM processes into three groups, described in

the paragraphs below and shown in Figure 5-3.

§ Core Processes: are technical processes and usually reflect the core competences of various

stakeholders (actors) involved in TIM. The tasks involved in each of those processes vary

with the attributes of the traffic incident. TIM-Onto classifies core processes into six main

sub-concepts, which are: traffic, safety/rescue, environment protection, construction/repair,

clearance/recovery and law enforcement processes. Those processes are performed both on

and off the incident scene.

§ Management Processes: enables core processes and ensure that each process products are

delivered according to the intended TIM objectives. TIM-Onto adopts the approach in [ref],

classifying management processes into incident inner-cordon and outer-cordon management.

Inner-cordon (scene) is the management of onsite resources and actors to remove the

incident impacts and minimize the traffic disruption. Outer-cordon refers is extended into

two sub-concepts of media/logistics and traffic network management.

Media/logisticsencompasses managing a wide range of processes that involves dispatch,

coordinate, route and clear various agencies and responders to/from the incident scene. In

addition to dissemination of the incident information through various media to notify road

travelers.

§ Support Processes: are necessary to support other processes, which include administration,

communications, information management processes…etc. They are vital for the success of

TIM system mission, but they do not provide or serve primary TIM objective/s. They are

key enablers and indirect influencer of core/management processes outcome; characterized

142

by being highly repetitive. Example of such processes is finance and administration

processes that track incident costs and account for reimbursements.

Figure 5-3: TIM-Onto Process Functional Modality

5.9.1.3 Other Incident Management Process Modalities

In addition to the before mentioned process modalities; TIM-Onto further extends four

additional modalities from IC-PRO-Onto. Asidefrom enriching the semantics, these modalities

support the reasoning capabilities of TIM-Onto. For example, software agents use TIM-Onto

accessibility modality to grant public access to some TIM processes, e.g. incident detection is

publicly-accessible process where public are encouraged to report traffic incidents. However, the

incident verification process is privately accessible, i.e. incident occurrence can only be verified

by authorized actors. Figure 5-4 illustrates the extended modalities from IC-PRO-Onto (El-

Gohary, 2008).

143

Figure 5-4: TIM-Onto Process Modalities

5.9.1.4 Incident Management Process Attributes

Similar to process modalities, TIM-Onto extends IC-PRO-Onto to define traffic incident

processes attributes. The process attributes are defined and classified to answer the following

competency questions, depicted in Figure 5-5:

§ What is the process function?

§ What is the performance of the process?

§ When is the process performed?

§ What is the operational state of the process?

§ Who has the right to get involved in the process?

§ How does the process depend on other entities?

§ Where is the process performed?

§ What is the risk posed by the process?

144

PROCESS ATTRIBUTES

Time Performance

PERFORMANCE ATTRIBUTE

TIM PROCESS

has

Cost Performance

Quality Performance

Safety Performance

Sustainability Performance

DEPENDENCY ATTRIBUTE

Logical Dependency

Cyber Dependency

Geographic Dependency

Physical Dependency

FUNCTIONALATTRIBUTE

Function

CONTROLATTRIBUTE

ACTOR RIGHTS

Operational State

TEMPORAL ATTRIBUTE

Lifecycle Stage

Dormant

Executing

Stopped

Resuming

Suspended

Completed

Initiating

Planning

Execution

Monitoring &Control

Closing

Operational Center Location

LOCATION ATTRIBUTE

Incident Scene Location

Virtual Location

Safety Risk

RISK ATTRIBUTE

Time Risk

Environmental Risk

Economic Risk

Schedule

Planned

Actual

Start Time

End Time Figure 5-5: TIM-Onto Process Attributes

5.9.2 Traffic Incident Management Actors/Roles

TIM-Onto extends both DOCK (El-Diraby, 2009) and AR-Onto (Zhang, 2009)to define

involved TIM actors (stakeholders) and actor-roles together with their associated attributes. AR-

Onto defines an actor as person- or organization-oriented concept having distinct characteristic

based on core qualifications or skills. Role is context-oriented concept describing the actor

external attributes (functions or responsibilities) based on specific context. This context is either

a process or an event. For example, the same actor may take the role of process-executer in one

context and manager in the other. On the other hand, the actor concept is limited to the most

basic attributes and legal characteristics of an entity, i.e. law enforcement official will always be

a law enforcement official regardless of the context. Based on the classified traffic incident,

proper actors are identified together with their required processes roles.

145

5.9.2.1 Taxonomy of Traffic Incident Management Actors

TIM-Onto extends the abstract taxonomy of the actor concept in AR-Onto to classify actors

involved in the incident management process. Based on this taxonomy, the actors are grouped

into three categories, depicted Figure 5-6:

§ Individual Actor: refers to a human being having pre-defined task/responsibility in a TIM

process and belonging to an involved organizational entity. AR-Onto classify actors into

professionals, technicians, skilled, and unskilled individuals. However, such classification

was found to be irrelevant from TIM perspective and instead individual actors are classified

based on the affiliated organizational entity within TIM-Onto framework. TIM-Onto

further classifies individual actors based on ranking and level of authority in their affiliated

organization, as illustrated in Figure 5-6.

§ Organizational Actor: refers to an established social and legal framework encompassing

group of individuals performing set of specified tasks. TIM-Onto classifies organizational

actors into eight organizational groups (Figure 5-6). In addition, organizational actors are

defined to have three level of hierarchy of Federal, Provisional, and Municipality.

§ Other Actor: refers to actors passively involved in TIM; receiving only output

decisions/information from TIM system and react accordingly. TIM-Onto classifies these

actors into passenger, pedestrians, and driver-vehicle unit. Driver-vehicle unit acknowledges

the fact that neither the vehicle nor the driver can be considered as separate entities and thus

the driver-vehicle interaction must be realized in describing the vehicle behaviour (El-Diraby

and Kashif, 2005).

5.9.2.2 Taxonomy of Traffic Incident Management Roles

Roles are vital to identify during TIM. They are key determent in dispatching incident

responders and defining who is responsible of what. Accordingly, different response actors need

to operate under clearly structured hierarchy that defines mutual expectations of onsite actions

and interactions. DOCK provides multiple classifications of roles based on the context, among of

which the following two classes of roles were extended in TIM-Onto:

§ Seniority: refers to the role of seniority among actors belonging to the same organization, e.g.

director, team leader, and operator.

146

§ Incident Management Domain: used to reflect the chain of command during the incident

management process. TIM-Onto adopts the classification of the Incident Command System

defined in NIMS to define organizational roles, outlined in Figure 3-4 of Chapter 3. In

addition to the top four roles of Incident Commander, Communication Officer,

Media/Liaison, and Safety Officer, and Communication Officer.TIM-Onto added the

Specialized Role concept which encompasses other organizational actors working under the

Incident Commander hierarchy. This specialized role can be traffic operator, fire/rescue, law

enforcement …etc. The specialized role concept is further extended into five sub-concepts, as

depicted in Figure 5-6, reflecting the chain command within each organizational actor

concept during the TIM. In some specific situations, organizational actors may over take

each other specialized roles. For example, traffic management role being carried out by law

enforcement official or firefighting crew takes the role of HAZMAT team.

Figure 5-6: TIM-Onto Actors and Roles Taxonomy

147

5.9.3 Traffic Incident Management Products

As explained in Chapter 4, TIM-Onto extends DOCK to define civil infrastructure products.

The following are the three major manifestation of the product concept used in TIM-Onto:

§ Decision: refer the outcome of a process that leads to a selection of one of alternatives or

decision options. TIM-Onto formally identify number of terms to form its decisions library.

These decisions represent the outcome of FIPA-Interaction Protocols between software

agents, as will be demonstrated in Chapter 6. Example of this decision terms are: accept,

reject, confirm…etc.

§ Knowledge Item: is the physical or symbolic manifestation of knowledge. Examples of

knowledge items used in TIM-Onto are: incident alert report, incident response plan,

incident investigation report, signal timing plan and variable signs messages.

§ Physical product: refers to tangible physical assets in civil infrastructure domain. Road

product is the umbrella that describes all topological features in the roads. Figure 5-7

presents a schematic representation of road product along with its associated components and

entities, which are explained briefly in the following paragraphs.

Figure 5-7: TIM-Onto Road Product

148

The following paragraphs describe each of the classes illustrated in the figure above, while figure

5-8 illustrates the classification of the road product components in compliance with DOCK

taxonomy.

§ Road: represent a route between any number of origin and destination nodes. It is composed

of set of connected links which are further broken down into segments. Example of road

class would be the Gardiner Highway in Ontario.

§ Route: is the virtual manifestation of the road, formed of set of links belonging to one or

more road. For example route to Mississauga from down town Toronto.

§ Segment: is a one way longitudinal roadway section having constant number of lanes. A

roadway with variable number of lanes is broken down into several segments, each having

the same number of lanes. A segment can be a bridge, tunnel, ramp or an open land roadway

section. It has dimension attributes, including: length, width, horizontal (cross) and vertical

slopes as well as curvature (horizontal and vertical). Each segment has a start and end node

as well as associated cross section elements.

§ Links: represent a longitudinal roadway section formed of one or more connected segments.

A link has cost attribute (defined in terms of length or travel time) and performance attribute

defined in terms of speed, flow, and density. Each link has a start and end node.

§ Cross Section Element: are the roadway features forming the roadway segments, such as

lanes, shoulders, median…etc. Similar the roadway segment entity they have dimension

attributes as well as material attribute. In addition, the lane entity has traffic volume (vehicle

per hour) and one or more travel direction (through, left, and right).

§ Node: represent the joint point between two or more segments. They can be origin,

destination, merge, diverge, union (point of connect of two segments), and weaving (crossing

point of traffic flow streams). A node has spatial attributes, i.e. x, y, and z coordinates. A

node has intersection control attribute taking one of the following enumerating constants:

yield, stop, and signalized. Signalized nodes have an associated signal or ramp metering

device.

§ Device: are mechanical or electronic objects used to fulfill specific purposes. Each device in

TIM-Onto has spatial (coordinates) and dimension attributes. They are classified into:

vehicle detection stations (VDS), CCTV, emergency phones, signals, ramp meters, and

variable signs. Signals and ramp meters have one or more phase attribute, representing the

149

duration of signal/ramp meter phases. Variable signs have associated knowledge item

representing a message the operator wants to show on them as a result of current traffic

situation. These message can be: 1) Exposure messages showing general information not

necessarily related to current traffic status (e.g. do not drink and drive), 2) Information

messages that advise drives on downstream incidents and showing traffic recommendations

(e.g. congestion ahead or road ahead is clear), 3) Mandatory messages that enforce specific

behaviour on the drivers (e.g. reduce maximum speed limit due to an incident), and 4) Force

message that containing information the operator want to show (e.g. amber alert of child

missing case).

Figure 5-8: Road Product Modalities as Extended from DOCK

150

5.10 INCIDENT MANAGEMENT BEST PRACTICES

The dictionary of business (2002) defines best practices as “methods and techniques that

consistently have shown results superior to those achieved through other means, and can be used

as benchmarks to strive for”. TIM-Onto best practices identify required incident

countermeasures based on previous successful experiences gleaned from well-established traffic

incident management frameworks, deployed both locally and internationally. TIM-Onto best

practices are extracted from multiple guides, operational manuals, analysis toolboxes as well as

personal interviews with domain experts and field operatives.

The above-mentioned resources address primarily the areas of: field safety, response

operations performance efficiency, and area-wide traffic management. Table 5.10 depicts the

various resources used to compile TIM-Onto best practices. Within TIM-Onto, best practices

are coded using first order logic axioms. TIM-Onto best practices fully address strategic and

level requirements previously defined in Chapter 3. More precisely, strategic best practices

primarily cover institutional and operational requirements. In addition, some of the process level

requirements are addressed by TIM-Onto as well, as previously indicated in Table 5-1. The

following sections illustrate TIM best practices as coded in TIM-Onto.

5.10.1 Institutional Best Practices

Institutional Best Practices refer to inter-agency formal coordination, cooperation policies and

procedures for traffic incident management. It answers the sort of questions of who do what and

with which resources of each specific incident type occurrence. Institutional Best Practices are

classified under one of the following four categories:

5.10.1.1 Identify Required Response Processes for Each Incident Type

Based on incident classified type, a set of appropriate response processes are defined. Table 5-11

illustrates required functional processes for each incident type, as defined in TIM-Onto. The

incident-process correlation was realized through interviewing TIM domain experts and field

operatives, and later verified with TIM literature by the author, illustrated in more details in

Chapter 7. The processes presented in Table 5-11 represent primary or essential processes.

However more processes may be gleaned necessary based on the evolution of the incident.

151

Table-5.10: TIM-Onto Best Practices Sources and Their Underlying Design Objectives

Source Strategic Level

Process Level

Institutional Operational

AUSTROADS AP-R304/07: Traffic Incident Management: Best Practices

FHWA HOP-10-013: Traffic Incident Management Handbook

Homeland Security: National Incident Management System

NCHRP Synthesis 318: Safe and Quick Clearance of Traffic Incidents

US DoT - ITS Standards Advisory: Traffic Incident Management Standards

FHWA-HOP-08-060: Traffic Incident Management Resource Management Primer

AASHTO: Highway Safety Manual

UK Department of Transport: Incident Management Study

Institute of Transportation Engineers: Traffic Management Data Dictionary

IEEE: Common Incident Management Messages Sets for Use by EMC

152

Table 5-11: Required Functional Processes for Each TIM Type

5.10.1.2 Identify Organizational Hierarchy for Actors Involved in TIM

Each incident type requires specific responders. For example, a truck cargo spill involving

corrosive material would require HAZMAT team in addition to other responders. These

responders must operate under clear organizational hierarchy that identifies organizational-roles

and allows the realization of mutual expectations and interactions during TIM. As a general rule,

all involved actors have the responsibility to support one another to ensure safety and a sense of

urgency in getting traffic moving. Table 5-12 summarizes TIM organizational-roles versus

incident type, as defined in TIM-Onto.

153

Table 5-12: Organizational-roles versus Incident Type

5.10.2 Operational Best Practices

TIM-Onto defines operational best practices as: decision rules and criteria regarded by domain

experts to be effective in improving incident response processes efficiency, when applied to a

particular condition or circumstances. Process efficiency is improved if targeted performance

measures are achieved. For each process defined in TIM-Onto a set of performance measures

and are defined. Operational best practices (decision rules) are classified based on TIM-Onto

process phase modality, i.e. detection, verification, and response. This classification follows the

logical flow of decisions from one process to other through the incident lifecycle. Table 5-13

illustrates the competency question used to drive the best practice for each TIM-Onto process.

154

Table- 5-13: Competency Questions for TIM-Onto Operational Best Practices

1. Detection & Verification

1.1. In what case should the detected incident be verified?

1.2. What are the essential incidents attributes to collect on incident detection?

1.3. What are the attributes that should be included in the generated incident report?

2. Response

2.1. What are the components of the initial response plan?

2.2. What is the optimal number of response units?

2.3. How to prioritize responders dispatch in case of multiple incidents?

3. Traffic Management

3.1. What is the estimated incident duration?

3.2. In what case the traffic diversion should be warranted?

The following subsections describe TIM-Onto operational best practices; classified three phase

modality processes of detection, verification and response, indicated above.

5.10.2.1 Detection and Verification Best Practices

§ Upon receiving the incident alert, and prior of dispatching any response resource to the

reported scene, the incident actual occurrence must be verified. TIM-Onto classify incident

detection resources as either trusted or un-trusted. Trusted alerts are only reported by police

patrols (law enforcement actor). Hence, if the incident is detected from untrusted source

(including automated detection), the incident occurrence needs to be verified.

§ Irrespective of the detection resource, each incident alert should at least indicate the incident

location attribute.

§ Prior to verifying the incident occurrence, the verification process should generate a report

that at least includes incident type classification and some critical incident-impact attributes.

Incident type and critical attributes are key determinants in identifying required response.

Critical incident attributes are location and occurrence time. While critical impact attributes

include number of involved vehicles, trucks, injuries, fatalities, and lanes blocked.

155

5.10.2.2 Response Best Practices – Determine Optimal Number of Response Units

TIM-Onto supports the determination of ‘optimal’ number of response units dispatched from

each actor, based on reported incident attributes. The resource allocation information compiled in

TIM-Onto is extracted from interviews with field operatives and deployed best practice guides

(illustrated in details in Appendix-J). Table 5-14 illustrates the incident attributes used as

decision criteria to determine required number of response units.

In the survey forms given in the interviews, it was up to each domain expert to pick up

the incident attributes that represents the key decision criteria in determining the required

number of response units. The most prominent incident attributes were found to be: number of

fatalities, injuries, type and number of involved vehicles. This explains why these attributes were

considered critical to log upon incident verification, as early mentioned.

Table 5-14: Required Number of Response Units vs. Incident Attributes

If Then Send No. of Fatalities 1 2 3+

Ambulances 1 2 3+

Police Cruisers 2 2 3

No. of Injuries 1 2 3 4 5+

Ambulances 1 2 2 3 3

Police Cruisers 2 2 2 3 3

Vehicles Involved 1 Passenger Car (PC) 1 Truck 2 PC – PC 2 PC-Truck 2 Truck-Truck 3 PC-PC-PC 3 PC-PC-Truck 3 PC-Truck-Truck 3 Truck-Truck-Truck 4+

Fire Engines 1 2 2 3 3 2 3 4 4 4+

Number of Vehicles Involved 1 2 3 3+

Towing Vehicles 1 2 3 3+

Police Cruisers 2 2 2 2

156

An important point to emphasize is the meaning of the word ‘optimal’. The information used to

determine the required number of incident type has been built over years by experienced

operators and decision makers who have developed a close to optimal (i.e. best practice) decision

making process for resource allocation. Thus their knowledge for resource allocation can be used

as the best known and hence considered optimal (i.e. optimal but not in the strict mathematical

sense). Algorithmic models can also be used to optimize resource allocation, but most of the time

these models are case and location specific.

In addition, there is no guarantee that algorithmic models will produce the optimal

resource allocation guidelines, and even so they must be tested thoroughly in real life scenarios

before being implemented. Thus this might be left as an area for future research and

development. Instead, the author has decided to solely use expert knowledge and historical data

to capture valuable domain knowledge used for response resource allocation. The approach of

capturing expert tacit/explicit knowledge is consistent with the philosophy of ontologies being

knowledge capturing tools rather than anything else.

5.10.2.3 Response Best Practices – Components of the Initial Response Plan

When the incident commander receives the incident report from the communication officer, an

incident response plan is generated. In addition to the above-mentioned attributes, the incident

response plan should include the following situational factors of the incident scene: number of

responders, land-use, and environmental. Such attributes will be used to estimate required time

for incident clearance time and thus duration as well as additional resources or precautionary

actions that might be needed. For example, if the surrounding is light condition is dark;

responders will be advised to bring over light torches to incident scene. Furthermore this

information can be stored in database and used in the future for understanding the response needs

for different incidents. Table 5-15 illustrates the various attributes of the incident generation

report, while a sample axiom from this table is depicted below.

157

Table 5-15: Incident Response Plan Components

Operational Attributes

POLICVEH FIRENG AMBUL WRECKER ALTROUT

Number of police vehicles on the incident scene Number of fire engines on the incident scene Number of ambulances units on the incident scene Number of wreckers used Alternative route established: Binary (Y/N)

Situational Factors-Synthesized Environment RWTYPE: Roadway Type RWTYPE= 1 RWTYPE=2 LANDUSE: Land Use LANDUSE=1 LANDUSE=2 LANDUSE=3 LANDUSE=4

Freeway Non-freeway Open Land Urban/Building Bridge Tunnel

Situational Factors - Environmental

WEATHER: Weather Conditions WEATHER=1 WEATHER=2 WEATHER=3 WEATHER=4 WEATHER=5 LIGHT: Light Condition LIGHT=1 LIGHT=2 LIGHT=3 TEMP: Temperature TEMP=1 TEMP=2 TEMP=3 TEMP=4

Clear/cloudy Rain Foggy/misty Snow Sleet/ice Bright Satisfactory Dark <0o Celsius 0o>&<10o Celsius 10o >&<20o Celsius 20o > Celsius

Closure Attributes

LANCLOSED Ratio of lanes closed to total number of lanes

5.10.2.4 Response Best Practices – Prioritize Response for Multiple Incidents

Responders are usually faced by multiple incidents to handle; some of which are more critical

than other and require priority response. Moreover, these incidents differ in the required response

resources based on each incident attributes. TIM-Onto adopts the Saaty’s priority theory to

158

prioritize response to multiple incidents by assigning weights to different incident attributes,

based on each attribute importance (Saaty, 1982). A fundamental problem in decision theory is

how to assign weights to multiple decision criteria.

A straightforward procedure is ranking the decision criteria in ascending order of

significance. A further refinement would be assigning to each criterion a numerical value

between predefined upper and lower bounds. However, using a single score factor for ranking is

one-dimensional scaling and deemed to be an oversimplification. Saaty’s priority theory

mathematical foundation is simple. Its purpose is to make contribution toward unity in modeling

real world problems, away from existing fragmentations where each problem tends to have its

specialized model and terminology. Its major assumptions are that the methods we use to pursue

knowledge, to predict, and to control our world are relative and that the goals that we seek are

themselves relative.

Such approach is well consistent with ontological engineering approach of

standardization of domain concepts and terminologies and to focus on semantics and shared

understandings rather than rigorous mathematical algorithms. The decision criteria weights are

assigned using domain experts and operatives knowledge. This knowledge is either derived from

experience, measurement, or other models. The objective is to fulfill the requirements and

purposed of people concerned rather than to legislate an outcome based on principles set forth by

outsiders to the problems.

Saaty’s Priority Theory:

The priority theory considers n-factors (decision criteria), which are significant in decision

problem; however their significance may be unequal based on the situation on hand. The theory

starts with the idea that it is easier to consider each pair of decision criteria separately, and decide

their relative degree of importance. Quantification of relative importance for each pair of

decision criteria can be used to produce a matrix from which suitable priorities can be extracted

using an eigenvalue analysis.

The theory starts by selecting a set of decision factors(C1… Cn), and assigning them

positive priorities (w1 …wn). Thus a matrix A of priority ratios aij= wi/wj can be written as in

Table 5-16, where aij denotes the relative importance of Ci to Cj. If Ci denoted to be more

significant than Cj then aij is assigned a value greater than 1, and vice-versa. Note also that aij=

159

1/aji.The below matrix is reciprocal matrix of rank one, since all of its rows are multiples of the

first row. The sum of any column j is equal to wj and the inverse column sums immediately

provide the vector w. While the sum of row sums provides a multiple of vector w.

Table 5-16: Matrix A of Relative Priority Ratios

Factors C1 C1 ………………. Cn

C1 ……………….

. . . . .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

Cn ……………….

If the matrix A was multiplied by the column vector (w1,w2,….wn), the vector nw is obtained and

the relationship holds true. As early mentioned, the priority theory deals with relative

priorities between each pair of factors, and does not assume that the weights to be known in

advance. Thus aij is to be assigned by domain experts and decision makers, and the matrix w can

be recovered by solving the system .Thus matrix A has only one non-zero

eigenvalue .The relationship denotes the non-zero eigenvalue of dimension (i.e.

.) and w corresponding to the eigenvector, where w is 1 × n weights matrix.

The solution w of this problem is any column of A. These solutions differ by a

multiplicative constant. However, it is desirable to have any chosen solution (column)

normalized, so that its components sum to unity. The result is a unique solution no matter which

column is used. Thus we can recover the scale from the matrix of ratios, by simply normalizing

any columns. To illustrate on the priority theory, assume a decision maker who estimated the

relative significance of each pairs of factors. Taking a12=1, and a13= a23=2, the matrixA can be

expressed in the following form:

A=

160

The reader may verify that the sums of columns yield the desired eigenvector. Therefore, the

priorities 0.40, 0.40, and 0.20 are assigned to C1, C2, and C3 respectively. In addition, the largest

absolute eigenvalue of matrix A is equals to 3.

Dealing with Inconsistencies in Assigned Weights:

A major problem that may evolve is inconsistency in assigning relative priority factors. For

example, C1 may be deemed important relative to C2 and similarly C2 to C3. However,

inconsistency rises when C3 is assigned higher priority than C1 within the same framework. This

is a realistic representation of the situation in preferences comparisons that accounts for

inconsistency in human judgment. This is due to the fact that even though their best efforts,

people’s preferences and judgment remain inconsistent and intransitive.

In a positive reciprocal matrix A, small perturbations in the coefficients imply small

perturbations in the eigenvalues. Hence, the eigenvector is insensitive to small changes in

judgment and is stable, relative to larger changes. Thus the problem Aw=nw becomes

A’w’= w’. The theorem of Perron-Frobenius states that for a matrix with positive entries,

there is a unique real positive eigenvalue whose modulus exceeds those all other eigenvalues

(Lootsma, 1980) Thus the closer is to n and w’ to w the more consistent the relative

weights are. Otherwise, the estimates of the relative priority must be revised.

Improving the inconsistency does not mean getting close estimates of real life values of

the priority criteria weights. It rather means that the relative priority factors in matrix A are closer

to being logically related rather than being randomly chosen. And still the obtained relative

priority should be validated and approved by focus groups formed of domain experts and

practitioners. Inconsistency in matrix A can be derived as follows:

for any i,

Putting and reducing this equation to the form:

Using the property that functions of the type X+ are convex for positive X, with global

minimum at X=1 and minimal value of 2.If (i.e. full consistency), the sum in the

parentheses must be attained to its minimum at However, in case of inconsistency

161

is always greater than . An appropriate measure for the degree of inconsistency appears to

be the expression:

The Relative Weights Scale:

The numbers used to express the relative weights must be sensible, and must not be left to

arbitrary judgment. Saaty proposed a scale out of nine to define relative priorities between each

pair of factors. Psychological experiments showed that an individual cannot compare more than

7±2 objects without being confused (Saaty and Ozdemir, 2003). Table 5-17 illustrates the

intensity of importance scale suggested by Saaty (1982). The numerical ratios in the table are

formed of nearest-integer approximations scaled in such a way that the highest scale corresponds

to nine, i.e. the most significant. In order to further justify the order of nine scale; Saaty

conducted several experiments comparing the one-to-nine scale with twenty eight other different

scales with the eigenvalue formulations. Evidence of these experiments favors the use of the one-

to-nine scale as a reflection of the human mental ability to discriminate different degrees of

strengths of dominance among few objects (Doumont, 2002).

TIM-Onto Priority Criteria:

TIM-Onto supports multiple incidents prioritization, based on set of criteria related to the

incident impact, classification and attributes. Specifically, a traffic incident that has human injury

impact is classified to have the highest priority. Four incident types were also included as priority

criteria, while one temporal and two spatial attributes were found to be a key determinant in

incident response priority. Table 5-18 summarizes the incident response priority criteria. The

priority criteria were selected by domain experts and field practitioners, and were defined to be

the most relevant in the decision criteria when prioritizing traffic incidents.

In Table 5-19, columns 2 to 9 and the rows 2 to 9 contain the matrix-A of relative

significance, based on the values determined by the domain experts. Columns 9 shows the rows

sums, column 10 is for normalized rows sums, and column 11 provides the eigenvector z

corresponding to the absolute largest eigenvalue of A. Both the eigenvector and value are

calculated using numeric subroutine in MATLAB, where was found to be equal to 8.87.

Both column and row 10 are rough approximation for the vector of weights w, while column11

is the most accurate calculation.

162

Table 5-17: Intensity of Relative Weights Importance

Relative Importance (aij) Definitions Explanation

1 Equal importance Two factors contribute equally to the objective

3

Weak relative importance Experience and judgment slightly

favor one factor over another

5 Essential or strong importance Experience and judgment strongly favor one activity over the another

7

Demonstrated importance

An activity is strongly favored and its dominance is demonstrated in practice

9

Absolute importance

The evidence favoring one activity over another is of the highest order of affirmation

2,4,6,8 Intermediate values between two adjacent judgments. When compromise is needed

163

Table 5-18: Traffic Incidents Priority Attributes Index Value

No. Criteria Possible Variations Comments

C1 Injuries Critical Injury Severe Injury Mild Injury

Incidents involving injuries take the highest response priority, which varies with the severity of the injury.

C2 Incidents involving Fire/Recue Urban Non-urban

Incidents that involve fire/rescue operations might severely propagate into catastrophic events if not immediately responded.

C3 HAZMAT Spill Urban Area Non-urban

Incidents involving HAZMAT spill in urban area are more critical to respond as they represent an imminent threat to public masses.

C4 Road Facility Collapse Full Partial

Partially collapse facilities are even more dangerous than fully collapsed one. In 2007, a woman was killed in Montreal because concrete blocks from a cracked bridge beam smashed her car while she was passing underneath.

C5 Road Facility Dysfunction Urban Non-urban

The dysfunction of roadside facility can have severe impact on motorists and pedestrian safety, e.g. traffic light malfunction. Of course, the severity of the incident impact is higher in urban areas.

C6 Time of Occurrence Peak Off-peak

Time of Occurrence, the time of occurrence of an incident affects the response priority significantly. If an incident occurs during or will last into peak hour, a higher priority is given to the incident.

C7 Location

Freeway- Bridge/Tunnel- Ramp- Arterial-

The location of the incident affects the response process in two ways. The priority of the clearing an incident varies with location of the incident. An incident on a freeway or a bridge in most cases would have a higher priority than one on a local route. Second the location of the resource center from which the resources are to be dispatched depends on the location of the incident.

C8 Ratio of lanes closed to total number of lanes

<25%- <50%- <75%- 100%-

The number of lanes blocked helps to determine the expected traffic delay. Delay is the key in making decisions regarding diversions since one of the most efficient ways of reducing delay is decreasing demand by diverting traffic away of the incident.

164

Table 5-19: Matrix of Relative Significance of Priority Response Criteria

Criteria C1 C2 C3 C4 C5 C6 C7 C8 Row Sum Normalized Eigenvector

C1 1 2 5 5 7 8 8 9 45 0.29 0.36

C2

1 3 3 6 7 7 8 35.50 0.23 0.23

C3

1 1 4 6 5 6 23.53 0.15 0.15

C4

1 1 5 7 7 9 30.53 0.20 0.12

C5

1 1 2 3 7.76 0.05 0.05

C6

1 1 2 1 5.58 0.03 0.03

C7

1 2 4.61 0.03 0.04

C8

1

1 3.35 0.02 0.02

Columns Sum 2.40 4.24 10.78 10.60 24.83 31.50 32.50 39.00

Inverted, Normalized 0.43 0.24 0.096 0.098 0.042 0.033 0.032 0.027

165

The relative priority values in Table 5-19 were modified through trial and error to satisfy Saaty’s

consistency index. The value of was determined by solving the determinant |A-nI|=0, for

‘n’, which resulted in a polynomial equation in terms of ‘n’ in the 8th degree. In addition, the

priority theory defined consistency ratio (C.R.) that represents a bar line to accept inconsistency

in relative weights. The C.R. is equal to the C.I. value divided by random consistency number,

and the output should be around 10% or less to be acceptable. The random consistency number is

function of the size of square matrix-A (1.41 for a matrix of size 8×8) [ref]. Thus for the case of

Table 5-11, C.R. is calculated as follows:

=0.088<0.10 à acceptable

Assigning Priorities to Different Incidents:

In case of concurrent multiple traffic incidents occurrence, each incident may possess on or more

of the above mentioned priority criteria with different degree of variation. For example, a traffic

incident involving severe injury, fire/rescue, HAZMAT spill, and located in an urban area. TIM-

Onto assigns weight to each priority criteria separately, which is further adjusted to

accommodate for possible variations within each criteria (e.g. critical, severe, and mild injury).

The summation of different priority criteria of an incident reflects the incident overall priority.

Table 5-20 illustrates the relative significance in the possible variations for each priority criteria,

defined earlier in Table 5-18.

Note that in Table 5-20, the relative weights between possible variations for fire/rescue

incidents are not included; this is due to the fact that both are found to be equally significant. The

HAZMAT incident type and the time of occurrence priority criteria are merged in the same

section in the table because the relative significance between their variations was equal. The final

table that decides upon different traffic incidents priorities is shown in Table 5-21. In the above

table the incident priority score is calculated by multiplying the criteria weight (Ci) by the

criteria variation attribute relative significance (Fi), and the incident priority (final score) is equal

to the summation of incent scores. The incident with the highest final score will have the first

response priority.

166

Table 5-20 Relative Significance between Possible Variations of Priority Criteria

INJURY INCIDENT F1 F2 F3 Row Sums R. Weights

CRITICAL F1 1 5 9 15 0.73 SEVERE F2 1 5 6.2 0.20

MILD F3 1 1.31 0.07 Inv. Normalized Column Sum 0.67 0.28 0.05 /C.R.= 0.10

HAZMAT INCIDENT/TIME OF OCCURRENCE F1 F2 Row Sums R. Weights

Urban/Peak F1 1 7 8 0.875 Non-urban/Off-peak F2 1 1.14 0.125

Inv. Normalized Column Sum

ROAD FACILITY COLLAPSE INCIDENT F1 F2 Row Sums R. Weights

Urban F1 1 3 4 0.75 Non-Urban F2 1 1.33 0.25

Inv. Normalized Column Sum 0.75 0.25

ROAD FACILITY DYSFUNCTION F1 F2 Row Sums R. Weights

Full F1 1 5 6 0.83 Partial F2 1 1.2 0.17

Inv. Normalized Column Sum 0.83 0.17

LOCATION F1 F2 F3 F4 Row Sums R. Weights

Freeway F1 1 3 5 7 16 0.40 Bridge/Tunnel F2 1 5 7 13.33 0.40

Ramp F3 1 3 4.40

0.11 Arterial F4 1 1.61 0.09

Inv. Normalized Column Sum 0.45 0.38 0.12 0.05 /C.R.= 0.09

RATIO OF LANES CLOSED F1 F2 F3 F4 Row Sums R. Weights

25% F1 1 1.875 0.05 50% F2 2 1 3.375 0.10 75% F3 4 4 1 9.25 0.25 100% F4 8 8 4 1 21 0.55

Inv. Normalized Column Sum 0.05 0.10 0.26 0.54 /C.R.= 0.0

167

Table 5-21 Final Priority Criteria Score

No. Criteria Possible Variations Criteria

Weight (Ci) Score

F1 F2 F3 F4

C1 Injuries 0.73 0.20 0.07 - 0.36 C2 Fire/Recue Incidents - - - - 0.23 C3 HAZMAT Spill 0.88 0.12 - - 0.15 C4 Road Facility Collapse 0.75 0.25 - - 0.12 C5 Road Facility Dysfunction 0.83 0.17 0.05 C6 Time of Occurrence 0.88 0.12 0.03 C7 Location 0.40 0.40 0.11 0.09 0.04 C8 Lane Closure Ratio 0.05 0.10 0.25 0.55 0.02

FINAL SCORE

5. 11 ESTIMATION OF INCIDENT DURACTION BEST PRACTICES

TIM-Onto is not designed to provide traffic control using ramp metering or signal timing

optimization measures, but rather to supplement these within and integrated traffic incident

management. These traffic control measures are primarily developed using algorithmic and

computational optimization models and hence are out of TIM-Onto scope. These encoded best

practices can provide as a decision support tool for traffic operators or used by intelligent

software agents or some other similar application to automatically reason and generate diversion

routes. The logic underlying the initiation of route diversion strategy is depicted in Figure 5-9.

Based on the verified incident report; incident duration is calculated using either

algorithmic formulas or historic estimates. Algorithmic models are an outcome of the regression

analysis of incident attributes that are key contributors to the incident delay. In case of absence

of reliable incident duration formulas, agencies can rely on historic data to predict incident

duration. Such estimates are derived approximations based on incident type and associated

attributes. Chapter-6 describes the adopted incident duration model. The incident duration is used

then to calculate incident delay using real time simulation. If delay is bigger than a certain

threshold, diversion is warranted.

168

Figure 5-8: Traffic Diversion Decision Rule

Figure 5-9 illustrates the decision tree for determining approximate incident duration based on

historical estimates. These values are derived in North American operational environment and

are compiled from the sources previously mentioned in Table 5-10 and verified by the Ontario

Ministry of Transportation incident response operatives. Figure 5-10 estimates the incident

duration based on the incident type and involvement of human injuries. If the incident

classification satisfied more than one criterion, the maximum duration should be used.

These values are abstract and should be only used as guideline. However, when more

data is received during the incident life cycle; the incident duration prediction should be updated

accordingly using more accurate computational model (as shown in Chapter 6). One other

advantage of having these estimates is that they act as an initial estimate to evaluate the necessity

to trigger subsequent processes. For example, a vehicle disablement incident that is located on

the shoulder is known for sure to last less than 15minutes. Thus there is no need to run the

computationally expensive network simulation process estimate the delay and decide on

diversion need.

169

Figure 5-10 (a): Decision Tree for Estimation of Incident Duration

170

InvolvesTrucks

Yes

No

RequireTowing

Require Towing

No

Yes

Avg: 45 min.

Avg: 100 min.

NoAvg: 45 min.

Avg: 80 min.Yes

No. of Vehicles = 5+

Require Towing

No

Yes

Avg: 45 min.

Avg: 70 min.

No. of Vehicles = 4

Require Towing

No

Yes

Avg: 40 min.

Avg: 60 min.

No. of Vehicles = 3

Require Towing

No

Yes

Avg: 35 min.

Avg: 45 min.

No. of Vehicles = 2

Collision

Figure 5-10 (b): Decision Tree for Estimation of Incident Duration

171

6 A FRAMEWORK FOR TRAFFIC INCIDENT MANAGEMENT

6.1 SUMMARY

This chapter presents the design and implementation of traffic incident management framework

that addresses the issues outlined in the conducted literature and requirement analysis presented

in Chapters 2 and 3, respectively. The developed framework acts as a proof of concept to

demonstrate how ontologies can be used to build an intelligent, integrated traffic incident

management system. The Semantic Web Incident Management System (SWIMS) uses TIM-

Onto as its core knowledge model; and is utilized by the developed multi-agent software system

for reasoning about the domain. SWIMS agents reason about the incident management domain,

query information and infer new facts from existing ones using TIM-Onto coded rules and

axioms. In addition, TIM-Onto provides the contents of Agents Communication Language

(ACL) (Bellifemine, 2007) encoded in the messages exchanged between communicating agents

in order to achieve integrated incident management plans. The chapter begins by illustrating the

SWIMS design considerations and rationale. This is followed by presenting the design

methodology that defines the required software agents and their roles. The system

implementation architecture and tools then thoroughly outlined. Finally, an incident management

scenario using the developed software system is presented.

6.2 INTRODUCTION

SWIMS framework supports group decision making among various actors involved in the

incident management process. The major objectives underlying its design are: 1) capturing the

domain of traffic incident management, 2) assisting involved actors to determine appropriate

response countermeasures, and 3) supporting the implementation of these countermeasures.

Furthermore, the evolutionary nature of traffic incidents dictates the ability to handle massive

flows of dynamic and timely critical data/information. To support such objectives, the following

considerations were incorporated in SWIMS design:

1. Model incident management actors, their associated roles and interaction dynamics as an

integral part of the framework design.

172

2. Incorporates incident management best practice knowledge side by side with traffic

engineering knowledge. In addition to the ability to apply this knowledge for real time

decision making with high level analysis and recommendation.

3. Provide the utilities to selectively query, analyze, and manipulate information in response to

different traffic incident situations.

4. Possess high level visualization capabilities that can be used to present large amount of

information in a cohesive and context related manner.

5. Provide shared databases that support the storage and retrieval of static and dynamic

information pertaining to the road network and incidents. In addition the remote and

common access of software application used in the incident response operations.

6. Spatial and temporal data analysis functionalities and mechanisms for interactions between

different responding agencies.

SWIMS design supports organizing incident management relevant knowledge in way that is

readily accessible by involved stakeholders, irrespective of their location. This knowledge

incorporates both software algorithms and heuristic procedures. Achieving such capabilities

enables SWIMS to act as a platform for cooperative decision making process among various

involved stakeholders, reflecting the multi-disciplinary and multi-jurisdictional nature of traffic

incident management. It does not only address the response plans creation but also supports the

various individual and agency-level interactions that take place.

6.3 SWIMS COMPONENTS UNDERLYING RATIONALE

Each participating agency is represented in SWIMS by one or more web-based software agent,

resembling one or more functionality provided by the represented agency. Upon the occurrence

of traffic incident, an ad-hoc virtual framework is formed between autonomous software agents

representing each agencies (actors) participating in the incident management process. This ad-

hoc framework serves as a global space for searching and identifying response strategies.

Algorithms and other functionalities needed for incident management (duration

estimation, emergency vehicles route guidance, traffic control applications…etc.) forming a

group decision support platform. The components of SWIMS decision support platform are

deployed as separate Web-service entities. Upon demand, software agents invoke required Web-

173

service/s using designated integration gateways, sending required parameters and receiving data.

Each participating agency access the system through designated portal, remotely invoking

required web-based services and monitoring agent/s performance.

Embedded in each agent is an instance of rule-based reasoning engine, endowed with the

incident management rules representing the agent specific functionalities business logic. Those

inference rules are built upon the TIM-Onto ontology defined in Chapter 5. The communication

between agents is based on asynchronous message passing. Each agent send/receive messages in

requesting/delivering service/s. The particular format of exchanged messages in the developed

system is compliant with FIPA-ACL (Bellifemine, 2007). The content language of those

messages is based on the TIM-Onto ontology. Committing the content language of agent

communicative message to domain ontology is a FIPA requirement (Bellifemine et al., 2001). It

assures the same understanding of the message concepts and symbols, between communicating

agents irrespective of programming languages and heterogeneity of implementation platforms.

Tim-Onto represents the core knowledge model of agents reasoning and behaviour

definition, which also support the generic nature of the developed application. Figure 6-1 depicts

an abstract representation of SWIMS main component elements. The following two subsections

discuss the rationale for each SWIMS underlying components. However, the discussions given

in the previous chapter on advantages of ontology in knowledge enabled system is considered

sufficient and will not be presented herein to avoid unnecessary iteration.

§ Dynamic collaboration§ Decision support§ Ad-hoc architecture§ Information flow

management

SWIMSOntology

§ Common conceptualization§ Domains interoperability§ Computers understanding§ Automated reasoning§ Extendibility

Web ServicesTechnology

§ Resource sharing§ Pervasive reliability§ Platforms interoperability§ Web 2.0 integration

Multi-agentSystem

Figure 6-1: Abstract Representation of SWIMS Main Components

174

6.3.1 Underlying Rationale of Using Web-services

Web-services represent the functionalities the system provides to enable dynamic group decision

making, in addition to enhancing participation and information exchange among various

involved actors. Web-services provide the platform to assemble computational capabilities

required to support traffic incident management; including interfaces for supported hardware,

legacy software applications, algorithms, heuristics…etc. Within SWIMS, Web-services provide

standardized interfaces to support essential incident management capabilities such as: spatial and

conventional databases, real-time data grabbers (video captures and vehicle detection stations),

duration/delay prediction models, and traffic control algorithms.

A major advantage of using web-services is the emphasis on modularity, where different

components can be easily replaced or extended based on evolving demands and needs. In

addition, web-services enable distributed resource sharing among involved actors, provide

pervasive reliability, heterogeneous platforms interoperability, and support integration of Web

2.0 applications (e.g. twitter) in the incident management framework. Visualization, spatial data

management, analysis and querying are implemented through GIS web-services. In addition,

GIS databases are used to store relevant information about traffic network and available physical

resources. This information may be static (e.g. network geometry, lane capacities or lengths,

ambulances/wreckers locations …etc.) or dynamic (current link volumes, weather conditions

…etc.).

6.3.2 Software Agents Underlying Rationale

Those agents alleviate the burden of handling the massive information and data flows from the

human operator. There are multiple characteristics of traffic incident management frameworks

that make them suitable candidate for multi-agent system approaches, including:

1. Distributed problem that requires various individual and agency-level interactions to

coordinate response and achieve collaborative decision making process (Ozbay, 1999).

2. Composed of complex alliance of distributed, heterogeneous and autonomous software

entities that requires high level of modularity and abstraction.

3. Decision making with incomplete information, involving autonomous actors.

175

4. The evolving nature of the incident management process requires highly reactive actors, who

are on continuous alert monitoring the traffic network behavior. With the world wide web

being the most dominant mean of communication between modern information system, there

is a need for each agency to have a ‘representative’ continuously monitoring the network for

incidents alerts.

5. Recent progress in pervasive software systems design from information exchange to role and

relationships modeling; addressing aspects of responsibilities, capabilities distribution

(Sycara et al., 2010). MAS design is inherently based on agents’ roles and interaction

relationships. The lifecycle phases of incident management frameworks formation dictate the

necessity to continuously select involved actors, distribute tasks and negotiate response

needs.

6. The dynamic nature of incident management where new actors are required to join, while

others to leave or exchange roles. More flexibility than conventional client-server paradigm

is required to support this dynamic exchange of actors and roles. For which the flexible

interacting paradigm of MAS is more suitable.

7. Incident management supporting functionalities need to interact with local environment (i.e.

legacy software applications and human operators). Interaction with the local environment is

one of the defining attributes of MAS.

8. Scalability property of MAS seems particularly adequate to support the dynamic nature of

MAS. In which, different level of cooperation among different number of involved actors are

established based on the incident management lifecycle phase requirements.

On the other hand, the design of MAS frameworks encourages the development of each agent

independently to reflect individual user’s roles and tasks. It is quite challenging to guarantee

coordination unless the interacting agent adopted a common language in their communications.

In SWIMS this common language is built upon TIM-Onto.

176

6.4 SWIMS CONCEPTUAL ARCHITECTURE

SWIMS is formed of multilayered architecture, depicted in Figure 6-2, which are: physical

resources, basic services, advanced services, multi-agent system middleware, and presentation

layers. The functionalities provided by each layer are augmented by the services provided by the

layer underneath. Software agents are delegated, in cooperative manner, on behalf of human

operators to invoke and monitor required services; performing one or more specific incident

management task. The output is then presented to the human operator for input or verification.

Agents update and coordinate continuously with each other based on new decisions and data, in

order for them to react accordingly.

SWIMS architecture will break the currently centralized workflow of the decision

making process within the incident management system; achieving faster and more adaptive

decision making process that fits the evolutionary nature of traffic incident management. The

proposed implementation logic changes the incident management systems development

approach, from algorithm implementations to services discovery and composition.

Figure 6-2: SWIMS Abstract Architecture

The real power behind using service oriented architecture lies in providing novel applications in

response to changes in application requirements in a flexible and scalable manner, making the

system able to respond efficiently to changes in incident response procedures and technologies.

177

An administrator within the system can replace one service with another that was recently

developed or discovered. Such flexibility allows the system users to handle substantial changes

in their IT infrastructure with relative ease and at low cost.

6.4.1 SWIMS Conceptual Architecture vs. Requirement Analysis

Each component in TIM-Onto architecture serves one or more of SWIMS design requirements

presented Chapter 3. In specific, SWIMS was design to target the process level requirements

presented in Table 3-7 of Chapter 3. Table 6-1 presents the design requirements versus SWIMS

components. SWIMS architecture layers are described in the following subsection.

6.4.2 Physical Resources Layer

This layer provides the data resources consumed by upper service layer including databases and

hardware data grabber middleware. Resources are divided into three major groups, with the data

flow either sent or received by the layer above it. The components of this layer are:

§ Hardware Data Grabber, real-time data grabbers are implemented as web services providing

live feed of 183 CCTV cameras image and video captures and 981 vehicle detection stations

(VDS) covering the Greater Toronto Area (GTA) provincial freeway network. The VDS

feeds record GTA freeway network speed, density, and flow at 30 seconds interval.

§ GIS Databases providing transportation network topology spatial and non-spatial metadata

including road geometry, intersections layout, response units’ resources location, and other

infrastructures that might affect traffic route diversion plans like hospitals, schools … etc.

6.4.3 Basic Resources Layer

This layer incorporates legacy software applications that are necessary for the traffic incident

management environment. In addition to utilizing standalone services from the web, e.g. Google

geo-coder or augment group of physical resources to provide specific service/s in the basic layer.

All the services provided in this layer are implemented as web services as well. The components

of this layer are:

178

Table 6-1: SWIMS Architecture Components versus Design Requirements C

orre

spon

ding

Pro

cess

Lev

el R

equi

rem

ent

Soft

war

e A

gent

s Mid

dlew

are

TIM

-Ont

o O

ntol

ogy

Adv

ance

d Se

rvic

e L

ayer

Inci

dent

Det

ectio

n an

d V

erifi

catio

n

Res

pons

e U

nits

Ass

ignm

ent a

nd D

ispa

tch

Res

pons

e U

nits

Rou

te G

uida

nce

Impa

ct A

rea

Estim

atio

n

Traf

fic C

ontro

l Pla

ns

Div

ersi

on R

oute

s

Bas

ic S

ervi

ce L

ayer

Web

2.0

App

s

Dyn

ust T

raff

ic S

imul

ator

ALI

NEA

Traf

fic S

igna

l Opt

imiz

atio

n W

EBST

ER

GIS

RES

T W

eb S

ervi

ce

SOA

P W

eb S

ervi

ce

Phys

ical

Res

ourc

es L

ayer

VD

S an

d V

ideo

Cap

ture

Dat

abas

es

GIS

Dat

abas

es

1.1 1.2 1.3 1.4 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8

179

a) Legacy software applications, this layer includes meso-scopic traffic simulator Dynust,

traffic signal design algorithm (Webster), and ramp metering algorithm (ALINEA). The

mesoscopic simulator is used by the advanced service layer to calculate the incident delay

and estimate the traffic incident impact area. Webster and ALINEA are used to adjust the

timing plans of the traffic control devices falling within the impacted area.

b) GIS Web-services provide various services such as: 1) retrieving locations of fire service and

police units and provide supporting functionalities to route them to/from incident scene;

based on request from advanced service layer, 2) allocate CCTV cameras closest to the

traffic incident scene, 3) augment the 30 seconds VDS speed feeds with the GTA freeway

network GIS map to provide real time speed updates and calculate the travel time on the

traffic network links. These services are in turn used in the advanced layer to perform

specific process in the incident management framework, which is emergency vehicle route

guidance in this case. All the GIS web services are implemented using the REST protocol.

c) SOAP Web Services represent the duration estimation module. SWIMS use the FHWA

(2010) clearance model to estimate the incident duration, described in Appendix-C. This

model is implemented using the SOAP protocol.

d) Web 2.0 Apps refer to third party web apps used to build more complex applications in the

advanced services layer. For example, Google geo-coder is used to transfer the reported

incident address into coordinates, which is then used by shortest path algorithm to route

emergency vehicle to the incident scene and motorists away of it. Twitter and Google

Panoramio are used as a proof of concept only to illustrate the capability of SWIMS to

integrate social web apps in the incident management framework.

A dedicated agent is continuously monitoring the Twitter public users’ accounts for accident

in the GTA, it scans using Twitter Java API looking for terms such as accidents, incidents,

collision …etc. Similarly another application scans Google Panoramio looking for images

with the same terms tag. Upon finding probable indication of incident occurrence, an alert is

sent to the Communication Officer agent. Both of these applications require further work to

validate their accuracy as well as provide a solid statistical model that can correlate number of

alerts from these applications (which might be in hundreds) to actual incident occurrence.

180

6.4.4 Advanced Resources Layer

The advanced resources layer provides core functionalities within SWIMS incident management

framework through the utilization of the resources and services provided by the underlying

layers. This layer provides six core functionalities, which are:

a) Incident Detection & Verification: this service integrates TIM-Onto decision rules for

incident verification, reporting and actors’ roles assignment to respond to incidents alerts

from various sources (e.g. Twitter or 911 Web notifications). It also log the reported incident

attributes in a shared database that is accessible by other agents in the system.

b) Response Units Assignment & Dispatch: this functionality utilizes GIS web services for

locating emergency response units, in addition to decision rules from TIM-Onto to

determine required number of response units as well as prioritizing response in case of

multiple incidents. It includes publish and subscribe protocols between interacting agents

(discussed in details in Section 6.5.7).

c) Response Units Route Guidance: utilizes the GIS web services for locating emergency

response units and updating the network links travel times using real time VDS feeds.

d) Impact Area Estimation: using Dynust the mesoscopic traffic simulator, links experiencing

drop in travel speed more than 50 and 75%, respectively, are identified. Using a delay

contour service (GIS-based), the impact area is identified. The output of the simulator and

delay contour service are presented on Google Maps for the operator, and impacted

intersections and ramps are identified.

e) Traffic Control Plans: this service acts as a placeholder for more advanced traffic control

algorithms to be implemented within SWIMS. Currently WEBSTER and ALINEA

algorithms are used for updating signal timing and ramp meters for impacted intersections,

respectively. These two algorithms solve timing traffic control devices independently, i.e. in

absence of any coordination, and are considered primitive. Their integration has been only as

a proof of concept to demonstrate the ability of SWIMS for incorporating traffic control

algorithms as part of the framework. However, more advanced tools can be seamlessly

integrated utilizing SWIMS modular plug-and-play design.

181

6.4.5 Software Agents and Presentation Layer

The system relies on intelligent software agents to compose the functional services, using

services and resources from lower layers. The output of the functional services is presented by

each software agent to it corresponding human operator for input, e.g. Traffic Operation Center

Agent to traffic operator, incident commander to law enforcement….etc. The software agent

layer will be discussed in details in Section 6.5. Ontology service is orthogonal to SWIMS basic

and advanced services layer. TIM-Onto plays a key role in building an ad-hoc, virtual traffic

incident control center by improving the knowledge sharing level among various stakeholders.

The Presentation Layer is where the users interact with the system, allowing them to

validate outputs provided by the designated software agent, explore various SWIMS services

and monitor specific functionalities and services performance. A web browser with an interactive

graphical user interface is provided to each human operator, which includes specific sets of

visual interaction tools that monitor the services resembling the user’s functionalities within

SWIMS.

182

6.5 SWIMS PROCESS WORKFLOW

Figure 6-3 depicts SWIMS process model workflow using Business Process Modeling Notation

(BPMN, 2010); where the horizontal swim-lanes represent incident management roles as

identified in TIM-Onto, each corresponding to specific software agent. The process workflow

depicted in the figure is described in the following paragraphs:

§ A typical incident management scenario starts with receiving of an incident alert. Currently,

SWIMS supports receiving incidents alerts through two sources. The first is through

emergency operators (e.g. 911-Emergency center, freeway or police patrol) who log incident

alert on a dedicated Web-portal. The second source is by using either Twitter or Google

Panoramio Social Web applications.

§ Alert sources are classified as either trusted or un-trusted source. Except for incidents

reported through a trusted source (e.g. police or freeway patrol), the incident alert is verified

for actual occurrence. Based on the reported incident location, authorized personnel can use

CCTV, installed to monitor freeway traffic, to verify the incident. If the incident location is

not covered by CCTV, a police officer or freeway patrol is dispatched to the reported

incident scene to verify actual occurrence.

§ The verification process ends either by false alarm notification or by logging the reported

incident into the system. Based on the reported incident attributes, the incident management

roles are assigned to the designated actors based on TIM-Onto best practice rules. For

example, in case of car collision the incident commander might be law enforcement agency.

However in case of hazardous material spill, fire service or HAZMAT team operatives would

be more suitable candidates.

§ An incident report is generated and forwarded to the incident commander. Based on the

reported anticipated and actual impacts of the incident, required type and number of response

units are determined. In case of multiple incidents, priority criteria provided by TIM-Onto

are used to optimize resource allocation. Response units that are closest to the incident scene

are dispatched. If the dispatch request is accepted, the response unit is guided to the incident

scene using shortest path algorithm (implemented as GIS web service).

§ The generated incident report and response plan are forwarded to the traffic operator. Based

on incident attributes, incident duration and associated impact area are estimated.

183

Figure 6-3: SWIMS Traffic Incident Management Process Workflow Using BPMN

184

§ Adequate traffic management responses are taken; including updating VMS, signal

timing and ramp metering plans. If the incident duration is bigger than a certain

threshold, traffic diversion is warranted.

Each of the activity depicted in Figure 6-3 has supporting resources (e.g. legacy

applications, databases….etc.) and execution rules (coded as TIM-Onto axioms). For

example, a log incident data task requires a supporting underlying MySQL server. An

incident verification task requires a GIS server that contains spatial database storing

CCTV cameras locations and closest facility GIS web services that receives the incident

coordinates as an input and returns closest CCTV camera ID to be used for incident

verification. Table 6-2 identifies supporting resources and execution rules for various

activities indicated in the Figure 6-3.

Table 6-2: Supporting Resources and Execution Rules for SWIMS Tasks Activity Supporting Resources/Execution Rules

§ Incident Alert Source § Twitter § Google Panoramio § Google geo-coder and maps for visualization

§ Incident Verification

§ CCTV camera image/video captures § Google geo-coder and maps for visualization § GIS server (map and camera proximity service) § TIM-Onto axioms defining incident verification rules

§ Log Incident Data § MySQL database

§ Determine Actors Roles § TIM-Onto incident-actors’ roles assignment axioms

§ Incident Report Generation § TIM-Onto incident report components axioms

§ Initial Response Plan Generation § TIM-Onto response plan components axioms

§ Assign Response Units § TIM-Onto incident-actors and prioritize response axioms § GIS server (closest facility service and spatial database) § Google geo-coder and maps

§ Route Guidance

§ Shortest path algorithm § VDS real time feeds § GIS (Shortest path service and spatial database) § Google maps for visualization

§ Estimate Duration § FHWA incident duration prediction model

§ Simulate Traffic /Impact Area Determination

§ Dynust traffic meso-simulation application § GIS Server (Delay contour web services and spatial database) § TIM-Onto impact area estimation axioms § Google maps for visualization

§ Signal Timing/ Ramp Metering

§ Webster signals optimization algorithm § ALINEA ramp metering algorithm § GIS Server (Impact area buffer service and spatial database) § Google map for visualization

§ Traveller Information § TIM-Onto VMS update axioms § GIS Server (Closest facility service and spatial database)

185

6.6 SWIMS SOFTWARE AGENTS

SWIMS classifies agents to be either actor or role based, role-based agents refers to one

of the four roles in traffic incident management organizational hierarchy presented in

Section 3.3.2. Each role is played by specific agency during the incident management

process based on the reported incident attributes. For example an incident commander

role is usually taken by the law enforcement officer agency, unless the incident involves

HAZMAT spill which is then taken by Environment Protection Agency Officer.

Similarly, communication officer agent is usually carried out by traffic operator; however

in case of major high severity incidents, this role is carried out by high rank joint

emergency control center operator. The rules for incident management roles assignment

are defined in TIM-Onto ontology presented in Chapter 5.

Actor-based agents refer to technical stakeholders, i.e. their duties and tasks do

not change with the incident type or attributes. For example emergency medical services

operator tasks cannot be carried out by any other stakeholder or a traffic operator cannot

be replaced by firefighter officer …etc. Table 6-3 illustrates the initial list of

responsibilities associated with each agent type (both actor and role based). Agent

responsibilities are derived from the literature and interviewing domain experts as

outlined in Chapter 3.

It should be mentioned that SWIMS agents were designed with the following

considerations in mind: 1) minimum data duplication, if there are two or more agents

sharing the majority of information resources, they are merged, 2) agents are simple,

avoiding them to be too big or complex, thus difficult to design or maintain, and 3)

minimum number of agents; too many agents increases the overall system complexity

and decreases system efficiency since unnecessary communication between agents will

possibly take place.

186

Table 6-3: SWIMS Software Agents Responsibilities and Designated Stakeholders

Agent Possible Stakeholders Responsibilities

Communication Officer

§ Traffic Control Center § Law Enforcement Officer § 911-Emergency Call Center

Operator

§ Receive incident alerts/notifications § Locate incident notification on a map (GIS/Google) § Check incident source and determine need for

verification § Identify closest camera to incident location and

verify occurrence § Allow user to log/update incident data § Determine hierarchy roles in the incident

management process § Send incident report to incident commander and

traffic operations center

Incident Commander

§ Law Enforcement Officer § Firefighter Officer § HAZAMAT Team Leader § Joint Emergency Control Center

(major high severity incidents)

§ Receive incident report from communication officer § Send incident response plan to safety officer for

approval § Analyze incident characteristics § Identify required services, who and how many § Allocate resources § Send dispatch requests § Receive dispatch requests confirmations § Track responders and verify arrivals § Update GIS/Google maps with arrivals, response

plan components and clearance status

Emergency Responder

§ Law Enforcement § Firefighter § Emergency Medical Services § HAZMAT Teams § Towing/Recovery § Contractors

§ Receive dispatch requests § Send dispatch requests confirmation § Update utilization status § Route guidance

Safety Officer § Law Enforcement § Firefighter § Emergency Medical Services § HAZMAT Teams § Structural/Safety Engineer

§ Receive initial response plan § Prompt user to modify response plan § Send modified response plan to incident

commander

Liaison Officer § Traffic Operations Center/Operator § Law Enforcement Officer § Other

§ Update traffic conditions website

Traffic Control Center/Operator


§ Receive incident report from communication officer § Receive incident response plan from incident

commander § Estimate incident duration and calculate delay § Identify Diversion warranty § Estimate incident impact area § Simulate traffic network § Devise traffic response plan including signal timing,

ramp metering and VMS update

187

6.6.1 SWIMS Agent Acquaintances

Agent acquaintances identify agents’ interaction with each other, human operators,

external resources and legacy software systems. SWIMS agents diagram depicted in

Figure 6-4, includes four types of elements: agents, human operators, external resources,

and acquaintances between, agents. SWIMS interact either directly with external/legacy

software application if these applications performs atomic functionalities (simple single

functionality), or through a transducer agents for application requiring complex

interactions.

IncidentReport

ResponsePlan

TrafficData Traffic

Data

Rou

t e D

ata

Loca

tion

Dat

a Route Data

Dispatch Data

Dispatch R

equest

Dispatch R

esponse

Incid

ent/T

raffi

c Re

port

Control Plans

Incident Data

Impact Area

Incident Data

Estimates

Incident/Traffic

Messages

Figure 6-4: SWIMS Agent Acquaintance Diagram

188

6.6.2 SWIMS Management Platform

In addition to acquaintance identification, the second fundamental aspect of SWIMS is

the platform management. SWIMS is FIPA compliant and it follows the same FIPA

logical model for creation, registration, location, communication, migration and operation

of agents. The agent management reference model consists of the components depicted in

Figure 6-5.

Figure 6-5: SWIMS FIPA Compliant Management Platform

SWIMS software agent layer provides the physical infrastructure in which agents are

deployed. This layer is spread across multiple hosts, i.e. software agents are not usually

located on the same host. The software agent layer hosts multiple autonomous component

agents providing different services based on their role/s within the traffic incident

management. The computational capabilities of these agents are not mandated by FIPA,

which only mandates the structure and encoding of messages used to exchange

information between agents. Each agent must resemble at least one actor or role in the

incident management process and is given unique notion of identity which can be

described using the FIPA Agent Identifier (AID) that labels an agent so that it may be

distinguished unambiguously by other agents in the system.

189

Each agent subscribe to a yellow page registry, which allows subscribing agents to

publish the services they provide. Upon the occurrence of traffic incident, agents use the

yellow page service to easily discover and exploit each other services. Agents search and

discovery is performed during the life span of the incident management, where new

agents are allowed to join the virtual ad-hoc group while others may leave, in accordance

to the incident management lifecycle phase requirements. The Directory Facilitator (DF)

agent is the component providing yellow pages services to other agents. To avoid single

point of failure, FIPA recommends having multiple copies of the DF hosted on the agent

platform (Bellifemine, 1999).

The Agent Management System (AMS) is mandated by FIPA (Bellifemine,

1999). The AMS is responsible for creation, deletion, and overseeing migration of agents

to/from different platforms. Upon initialization, each agent registers with the AMS and

obtain a unique AID, which is retained throughout the agent lifecycle. The lifecycle of an

agent terminates with through deregistration from the AMS. Message Transport Service

(MTS) is the service provided by the agent platform to transport FIPA-ACL messages

between interacting agents. Agents’ communication will be discussed in details in section

6.5.5. Both the AMS and DF are provided by Jade middleware used to code SWIMS

agents.

6.6.3 SWIMS Agents Internal Architecture

Agent architecture represents fundamental mechanisms underlying the agent autonomous

behavior. SWIMS agents follow the BDI (Belief, Desire, and Intention) architecture

(Bellifemine, 2007). Beliefs represent the agents’ knowledge of the domain and the way

they perceive their surrounding environment. Desires represent objectives/goals the agent

has to accomplish. For example, upon receiving an incident alert; the communication

officer agent is incorporated with set of rules to examine the need to verify the incident

actual occurrence (based on the reporting source). These verification rules represent the

agent goals.

Intentions represent the deliberate state of the agent, i.e. what the agent has

decided to do. In case of the before mentioned example it represents the course of actions

taken in response of the verified incident, i.e. sending dispatch messages to other agents,

190

invoking supporting legacy systems, prompting user for input…etc. Figure 6-6 depicts

the generic architecture of SWIMS agents.

Figure 6-6: SWIMS Agents Single Pass Vertical Layered Architecture

As depicted in Figure 6-6, the agents’ internal architecture is composed of three stacks of

layers. Each layer represents composite agent behavior that executes agent’s beliefs,

desires, or intentions. The uppermost layer receives a stimulus from the external world.

This stimulus is a message from another agent requesting certain service or notifying an

event. The top layer fires the agent beliefs, creating its knowledge of the environment and

passes the stimulus to the desires behavior layer.

Based on the stimuli and the created knowledge, the desire behavior decides upon

required intention. The intention layer represents a composite behavior that executes set

of operations to achieve the intention goal. This might be invoking multiple basic

services to reach specific outcome/s. The actuator represents the output action, which

might be a message to another set of agents, prompt for operator’s input, invoking a

legacy software application…etc.

The knowledge in the belief layer is mainly TIM-Onto OWL classes extracted

from Protégé Ontology Editor. SWIMS belief knowledge ranges from simple OWL

191

axioms that define TIM-Onto taxonomic hierarchies up to axioms constraining the

concepts definition along with their associated relationships and attributes. For example:

§ The following OWL axiom defines Train Collision Incident (collision between a vehicle

and train) to be a subclass of Single Vehicle Incident and to be disjoint from other

subclasses defined under Single Vehicle Incident. Class: TrainCollision Declaration(Class(TrainCollision)) SubClassOf(TrainCollision SingleVehicleCollision) DisjointClasses(CollisionWithAnimal

CollisionWithBicycle CollisionWithFixedObject CollisionWithParkedVehicle CollisionWithPedestrian OverTurned RanOffRoad TrainCollision) § On the other hand, the following OWL axiom defines hasControlLevel relationship,

which is used to express the degree of controllability of a threat, vulnerability or a

situational factor (vulnerability in this example). Object property: hasControlLevel Declaration(ObjectProperty(hasControlLevel)) SubObjectPropertyOf(hasControlLevel hasAttribute) FunctionalObjectProperty(hasControlLevel) ObjectPropertyDomain(hasControlLevel Vulnerability) ObjectPropertyRange(hasControlLevel ControlAttribute)

§ The hasControlLevel relationship is defined in terms of Control Attribute, which is a

value partition OWL Class defined in terms of being either one of the following

subclasses: LowControl, HighControl, and ModerateControl. The excerpt below

shows the OWL definition of the LowControl subclass. Class: LowControl Declaration(Class(LowControl)) SubClassOf(LowControl ControlAttribute) DisjointClasses(HighControl LowControl ModerateControl)

TIM-Onto OWL representation is automatically generated by the Protégé ontology

editor. In order for these axioms to be utilized by SWIMS agents; they must be

transformed into Java programming language (SWIMS coding language). As previously

192

mentioned, SWIMS agents are implemented using JADE middleware (Java based).

JADE provides a Protégé plugins called the Ontology Bean Generator, which provides

the functionality of mapping and transforming OWL classes and relationships into Java

classes and methods. More information on JADE Ontology Bean Generator plugin is

provided in Appendix-D and Bellifemine (2004).

Upon receiving an external stimulus, which is usually a message from other agent,

JADE agent maps the received message content to the ontology Java classes using an

embedded codec and accordingly interpreting the message intended meaning. More

explanation about JADE agents messaging structuring and decoding is presented in

section 6.5.6.

Desires are not part of TIM-Onto core knowledgebase, but rather are JESS rules

coded using TIM-Onto OWL classes through using Protégé-JESS plugin. JESS is a

forward chaining reasoner that allows the creation of new rules from existing ones. JESS

reasoner has been incorporated with SWIMS agents using third party API. The reasoner

selects from the set of currently active desires some subset to act as intentions. Finally,

the reasoner select a plan of action to perform based on the agent’s current intentions.

The following represent an excerpt that from the verification rules used to verify incident

occurrence: (defrule aRule (Incident ?x)(SourceAlert ?y)(ComOfficer Z) (hasSource ?x ?y)(test ( ?y “LawEnforcement”)) => (assert (verify ?z ?y))

The above rule states that if the incident alert source is not law enforcement, the

communication officer agent should verify the incident occurrence. The verification

procedure represents the agent current intentions. Unlike the beliefs and desires behaviors

that use semantic knowledge representations, intention behavior is implemented as plain

Java code. SWIMS implementation will be discussed in more details in section 6.5.

6.6.4 SWIMS Rules

As described in the previous section, SWIMS agents share the same beliefs on the

domain of discourse. These beliefs are extracted from TIM-Onto OWL knowledgebase

and represent core ontology classes and their attributes. These classes mainly describe the

193

traffic incidents long with associated risk elements (threats, vulnerabilities,

hazards…etc.), road network, incident management resources and processes.

However, agent’s desires vary based on the agent role in the traffic incident

management process. Desires are knowledge expressed in the form of declarative rules

defined in terms of TIM-Onto classes and their properties. Table 6-4 describes the rules

representing SWIMS agents’ desire knowledge. Appendix-D contains samples from each

agent rules.

Table 6-4: SWIMS Software Agents Desire Knowledge Rules

Agent Rules

Communication Officer § Attributes describing an incident alert. § Rules for incident verification. § Attributes of incident report. § Rules for determining actors’ roles in the incident management process based

on the incident attributes.

Incident Commander § Rules for determining required process and actors for incident response based on received incident report § Rules for determining optimum number of response units based on received

incident report. § Attributes of incident response plan § Rules for prioritizing response to multiple incidents

Traffic Operation Center

§ Rules for estimation incident duration § Traffic diversion decision rule § Rules for impact area delineation § Rules for displaying VMS

Desire rules are separated both logically and physically from the TIM-Onto core

knowledge base. Thus operators can modify the rules to adapt the system to evolving

need and demands without impacting the ontology core knowledge representation. The

rules are coded using JESS rule engine. JESS allows coding the knowledge in a semi-

common language that does not require any prior programming knowledge from the

human operators, i.e. easy to modify and adapt. The adopted approach creates rules in

syntax that is independent of the application and technology as well as being fairly

intuitive and simple to understand. SWIMS rules are evaluated for consistency as

indicated in Appendix-D.

194

6.6.5 SWIMS Agent Communication

Arguably, the most important feature in SWIMS is the agent communication paradigm.

As previously mentioned, SWIMS agent are implemented using JADE middleware,

which in turn is compliant with FIPA specification outlined in (Bellifemine, 1999). The

communication paradigm is based on asynchronous message passing, where each agent

has messages queue representing messages sent by other agents. Whenever a message is

posted in the queue, the agent is notified. However, it is up to the agent internal design

(desires) to answer the message. The process is depicted in Figure 6-7.

Figure 6-7: The JADE asynchronous message passing paradigm

The format of the exchanged messages is compliant with FIPA-ACL message structure

described in Table A-1 of Appendix-A. Below is an excerpt from a message coded in

FIPA-ACL. The message is for an incident alert that is sent to the Communication

Officer agent through 911 emergency alert webpage. (alert :sender (agent-identifier: name localhost:8080/SWIMS-WEB/IncidentReport.com) :receiver (agent-identifier :name localhost:[email protected]) : ontology TIM-Onto : language FIPA-SL : protocol IncidentAlert : content (action (agent-identifier :name localhost:[email protected]) (receive-alert (incident “Vehicle_Collision” : location “Gardiner Expy, Toronto, ON, Canada” : longitude “-79.384389” : latitude “43.640166”) (impact : nVehicles “3” : nFatality “null” : nInjury “1” : nTrucks “0”)))

mailto:localhost:[email protected])

195

The first line ‘alert’ in the message defines the communicative act. The FIPA-ACL

defines communication in terms the purpose of the message. This purpose is defined by

the communicative act; in this case it is an ‘alert’ for incident occurrence. FIPA defines

standard library for communicative acts. In addition to standard communicative acts,

additional acts were tailored to fit specific situations within SWIMS workflow. These

additional communicative acts are described in section 6.4.4.

The second and third lines indicate the message sender (a dedicated web portal for

incidents alerts) and receiver (the Communication Officer agent). The language line

refers to the semantic language used to encode the ontology; in this case it is FIPA

Semantic Language (FIPA-SL). FIPA-SL is considered to be the most stable encoding

language supported by JADE (JADE also support OWL) (Bellifemine, 2004). In order to

able to process the message content expressions, they must be classified according to

their semantic characteristics in the domain of discourse. This classification if performed

by the ontology that models the domain, which TIM-Onto in SWIMS case.

Protocol defines the interaction protocol of the message, which will be defined in

more details in the Section 6.4.7. The action slot in the message defines the content of the

sent message. It defines the action required by receiving agent, which is ‘receive-alert’,

and the contents of the message. The contents are the incident and incident-impact

measures classes along with their associated attributes as defined in the Protégé ontology

editor. The following sections drill on each component of SWIMS FIPA-ACL messages.

6.6.6 SWIMS Messages Ontologies and Content Languages

Inter agent communications, whether natural or artificial is characterized by a mutually

understood Agent Communication Language (ACL). This is an external language and is

distinct from whatever the agent uses internally to represent and process knowledge. As

humans, the languages we use for communication is completely different of what the

brain’s inner processing mechanism. Thus the ACL must be translated into the internal

language for processing. To do this the agents must implement complex coding and

decoding mechanisms, and also agree on mutual ontologies if the words in the

communication are to mean anything. JADE supports ontologies created by standard

tools such as Protégé through what the JADE team calls schemas. Schemas are Java

196

classes designed to represent the static structure of ontology. This structure is supported

by wither Java classes or abstract descriptors associated with each schema.

As describes in the previous section, the actual information is transferred in the

message is contained in the content slot. When representing complex information such as

traffic incident report or response plan, it is necessary to adopt a well-defined syntax so

that the contents of the message can be parsed by the receiver to extract specific piece of

information (e.g. the location, impacts measure, time of occurrence…etc.). This syntax is

known as message content language. The most widely used and supported agent message

content language is FIPA-SL (Bellifemine, 2004).

In addition, interacting agents must share same understanding of the exchanged

concepts (e.g. incident and impact) and the associated attributes used to express the

content slot structure. These shared concepts are of course provided by the TIM-Onto

ontology. Content language is standard and domain independent, unlike ontologies which

are domain specific. Each time a message is sent the following two tasks take place: 1)

the sender needs to code the gathered data into corresponding ACL content expression,

while the receiver needs to perform the opposite conversion. 2) The receiver should

perform a number of semantic checks to verify the received information complies with

the TIM-Onto rules, e.g. number of injuries is expressed numerically or terms defined in

the message content have corresponding ontology classes.

As early mentioned, SWIMS multi-agent framework is implemented using JADE

middleware. The support for content languages and ontologies provided by JADE

automatically performs the above coding and semantic check operations, as depicted in

Figure 6-8. This allows the manipulation of the exchanged information as Java objects

within the agents. The content syntax and TIM-Onto ontology are used to structure the

exchanged data into Java object rather than using conventional Java serialization

technique. Java serialization convert exchanged data into sequence of bytes to Java

objects directly.

However, Java serialization has several disadvantages. First, it is only applicable

to Java environment. If SWIMS agents were to communicate with other remote FIPA-

compliant platform that is not using Java or even the JADE middleware, there is

197

absolutely no guarantee that the receiver can understand a message whose content slot

was encoded using Java serialization. Second, Java serialization produces a non-human-

readable format. In many cases being able to read the content slot of a message is very

helpful when investigating various debugging problems. Finally, an agent receiving a

message has no means of determining the kind of object it will obtain when decoding the

content slot – any serializable object could be received in principle. However using

ontology, the semantic checks guarantees that an incident location must be string, while

latitude or longitude might be a real number and undefined terms that do not have

corresponding classes in TIM-Onto cannot be received.

Figure 6-8: Transferring between ACL Message Format to Java Classes

Each SWIMS agent embeds a content manager that provides all the methods needed to

transform Java objects into string and semantically structure them in the content slot of

the FIPA-ACL message, and vice versa. The content manager object is JADE Java class.

It delegates the semantic check operations to the ontology and utilizes content language

codec to perform the translations from/to strings (or sequences of bytes) according to the

syntactic rules of FIPA-SL content language. In order for the content manager to be able

to perform the semantic check, each ontology OWL class must be changed into

corresponding Java class format.

JADE provide a plugin (Ontology Java Bean Generator) to the Protégé Ontology

Editor, which perform the required transformation. Every time a message is received by

an agent, the embedded content manager extracts each concept in the content slot along

198

with its associated attributes. The concept is then matched against the corresponding

Ontology Java Bean internal variables and methods, if discrepancy was found between

the concept and any of its attributes; the message will be flagged for rejection. The

implement of JADE content language and ontology support is described in more details

in Appendix-D.

6.6.7 SWIMS Interaction Protocols

As early mentioned, FIPA-ACL provides standardized set of primitives (communication

acts) each one with a well-defined semantics. In addition to identifying the purpose of the

message, it provides the possibility to specify predefined sequences of messages that can

be applied in multiple situations that have the same communication pattern regardless of

the application domain. Such interactive messaging sequence is known as interaction

protocols.

Consider for instance the process of emergency response-units dispatch; the

incident commander requests the closest units to the incident scene to respond to specific

incident. Based on their availability and the resources underhand, the response units may

decline, fully, or partially respond to the incident commander proposal. Some units may

respond partially to the incident, for example by sending 3 instead of 5 fire engines

because the other engines are occupied in somewhere else. Such interactive

communication can be well represented by FIPA-ContractNet-Protocol, depicted in

Figure 6-9.

FIPA specifies several standard interaction protocols that address various

common interaction patterns between software agents. Some of the standard interaction

protocols that have been incorporated within SWIMS are: FIPA-Request protocol which

is used to request one or more agents to perform a given action and collect results. This

protocol is used by the Communication Officer agent to assign incident management

roles to other actors in the system based on the incident attributes. FIPA-Subscribe

protocol can be used to establish a notification agreement with another agent to send an

inform alert each time a given condition becomes true. This is done protocol is used

between incident alert sources and the communication officer to report traffic incidents

occurrence.

199

In addition to the standard interaction protocols, JADE middleware provide the ability to

define customized interaction protocols that best fit specific situation. SWIMS

framework is incorporated with 8 interaction protocols. Three of them are standard FIPA

interaction protocols, while the rest are customized to fit SWIMS case specific

interactions. Table 6-5 illustrates the various SWIMS interactions protocols. Each

protocol has an initiator (message source) and participant/s (message recipients).

Figure 6-9: FIPA Contract Net Interaction Protocol

In the sequence diagram depicted above is the FIPA-Contract-Net interaction protocol

allows one agent, the initiator, to call for proposal to another agent, the participant, to

200

perform an action (dispatched to the incident scene). In the above example, the initiator

asks for 5 fire engines. The participant process the request, e.g. through examining

available resources in the system and makes the decision whether to accept, refuse, or

propose a different number of fire engines based on the available resources. In the above

example, the participant proposes to deliver only 3 fire engines. If the incident

commander agrees on the proposed number, the participant must communicate either:

failure (failed to fill the CFP), inform done (successful), or inform-result if it wishes to

indicate both that it is done and notify the interaction initiator of the results.

An interaction protocol defines unique conversation-id parameters, assigned by

the initiator and tagged in initiated ACL messages. For example, during incident response

dispatch, the conversation-id between the incident commander and the response-units

agents will be FIPA-Contract-Net. The responding agents must as well tag their reply

messages with the same tag. However, the communicative act will be one of the protocol

interactions, e.g. Call for Proposal, Agree, Refuse, Inform….etc. The conversation-id tag

enables the interacting agents to manage their communication strategies and activities.

For example, it allows an agent to identify individual interactions during messages

exchange and to reason across historical records of conversation.

At any point in through the interaction protocol lifecycle, the receiver agent can

inform the sender of a communication can inform the sender that it did not understand the

communicated message. This is done by returning a Not-Understood communicative act.

The above does not depict a not-understood communication but it can occur at any point

in the interaction protocol. However the Not-Understood communicative act may

terminate the entire interaction protocol and implies that any commitments made during

the interaction are null and void. Similarly, at any point, the initiator may cancel the

interaction by initiating the Cancel tag. The semantics of cancel is interpreted as that the

initiator is no longer interested in continuing the interaction and that it should be

terminated.

Aside from defining the semantics of the conversation and provide the ability to

trace or reason about the conversation history. Standardizing interaction protocols free

the programmer from the burden of implementing all the checks related to the flow of

201

messages when two or more agents interact through following a standard interaction

protocol. These classes provide a number of callback methods that programmers are

expected to redefine by inserting logic associated with the specific domain that cannot be

generalized. For example, in a dispatch request refuse implies the semantics that there are

no available response resources. Arguably, this can be considered the most important

feature of interaction protocols, which is the ability to standardize the semantics of the

conversation structure. Thus interacting agents can follow a pre-specified pattern of

interaction, knowing the meaning of each step, irrespective of their platform

programming languages.

202

Table 6-5: SWIMS Interaction Protocols

Protocol Initiator Agent/s Participant Agent/s Description

FIPA Contract Net Incident Commander

Traffic Incident Management Organizational Actors

Request responders dispatch to the incident scene

FIPA Subscription

Incident Alert Sources Communication Officer

Subscribe to the communication officer to become a source of incidents alerts


Communication Office Incident Commander

Subscribe to the communication officer and incident commander agents to receive incident alerts and dispatch requests


Directory Facilitator

Subscription between different actor and the system yellow pages services

FIPA Request Communication Officer Traffic Incident Management Organizational Actors

Request by the communication officer for various actors to overtake specific incident management roles. Example, law enforcement actor to take the role of incident commander.

IncidentAlert Incident Alert Sources Communication Officer

Notify the communication officer regarding the occurrence of traffic incidents

Incident Info Communication Officer Incident Commander Traffic Operation Center

Send an incident report containing traffic incident basic attributes to the incident commander and traffic operator agents to react accordingly

PlanMeasure Incident Commander Communication Officer Traffic Operation Center

Send the response plan to the traffic operator and communication officer

ValidateScenario Incident Commander Safety Officer Agent

Ask assigned safety officer to validate the suggest response plan. For example a structural engineer to approve response plan for bridge partial collapse

ForceSignal Incident Commander Traffic Operation Center

Request protocol between the incident commander agent and the TOC agent to show the message to be put in a variable signal.

203

6.7 SWIMS IMPLEMENTATION ARCHITECTURE

Figure 6-10 illustrates SWIMS implementation architecture. The web interfaces

represent the point of interaction between the human operators and the software agents.

Operators provide inputs to software agents prompts, monitor performance, and if

necessary intervene to invoke some services. The web interfaces are implemented using

J2EE framework and deployed on Apache Tomcat application server (Version 6.0).

Figure 6-10: SWIMS Implementation Components

As previously mentioned, SWIMS software agents are implemented using JADE

middleware. JADE (Java Agent DEvelopment framework) is the most widespread agent-

oriented middleware (Bellifemine, 2007). It is completely distributed middleware that

facilitates the development of complete agent-based applications. JADE run-time

environment implements the life-cycle support features required by agents including the

core programming logic along with rich suite of graphical tools. JADE is written

completely in Java and was developed by the Research & Development department of

Telecom Italia. But now it is an open source community project; distributed as under the

LGPL license.

The ontology is coded using Protégé ontology editor in OWL language (depicted

in Appendix-D). The ontology model of Protégé consists of classes, object and data

properties. Classes are concepts in the domain of discourse with which a taxonomic

204

hierarchy can be constructed. Object properties describe interrelationships and/or

attributes of these classes. A data object is an object property that has a type. This can be

a primitive class, such as String, Integer and Float, or an instance of another class that has

a value. The rules representing software agents’ beliefs and desires are coded in JESS

format using TIM-Onto classes and properties. This coding is done using JessTab.

JessTab is a plug-in for the Protégé ontology editor and knowledge-engineering

framework that allows you to use the Java Expert System Shell (Jess) and Protégé

together.

The bean generator supports creating message content ontologies compliant with

JADE environment to support managing agents’ messages content expressions. The bean

generator is used to generate FIPA/JADE compliant ontology Java classes from OWL

ontologies and is implemented as a Protégé Tab plugin. Every class in TIM-Onto

Protégé OWL file is the base for generation of corresponding JADE compliant Java class.

The taxonomic hierarchy of TIM-Onto is mapped on the inheritance capabilities

of Java. For example, the incident concept is a super-class in OWL and has set of

associated properties. Vehicle collision is a child class, and will inherit the attributes of

the parent class by Java inheritances. Properties of a class are associated with data

members of the Java Bean associated with the class. If the type of the slot is a primitive

class, such as String, Integer or Float, then the Bean Generator maps them onto their Java

equivalents, otherwise the member of the class is defined as an instance of the

corresponding Java class. If the cardinality is higher than one, a class of type Collection2

is used.

JESS rules are integrated with JADE middleware through JESS API class called

Rete, which implements the rule-based inference engine. The implementation embeds an

instance of the Jess engine inside each agent desire behaviors. Upon agent initializing or

receiving external stimuli, each behavior constructor loads rules coded in JESS language,

using JESS parser. The JESS engine consecutively fire applicable rules, and will return

only when there are no more rules to fire, that is, when the engine stops. After the JESS

engine stops, a procedure for collecting specific types of facts that represent the output of

205

the reasoning process is executed, and those facts are then used to perform specific plans

(intentions), e.g., to create a reply message.

JADE Integration Gateway is a JADE plugin devised specifically to seamlessly

connect external applications (e.g. databases, web services) with JADE platforms by

offering bidirectional discovery and remote invocations of this services by JADE agents

and vice versa. In SWIMS, it is deployed in the Apache Tomcat application server and is

executed within the JVM of the servlet container.

ArcServer is the core server geographic information system (GIS) software made

by ESRI Corporation. It supplies SWIMS mapping and GIS capabilities for client

applications. Within SWIMS, ArcServer applications are deployed as Web services that

are accessed through REST API. The ArcGIS Server REST API, short for

Representational State Transfer, provides a simple, open Web interface to services hosted

by ArcGIS Server. All resources and operations exposed by the REST API are accessible

through a hierarchy of endpoints or Uniform Resource Locators (URLs) for each GIS

service published with ArcGIS Server.

ArcObjects is the development platform for the ArcGIS suite. Within SWIMS,

the functionality of ArcObjects is accessed using Java API. SWIMS uses ArcObjects API

to update the GTA spatial maps with 30 second live feeds from VDS installed on the

GTA freeway networks. Google Maps API is used to provide the mapping GUI at the

client side, however the core functionalities are provided by the underlying ArcGIS

services. SWIMS uses ArcGIS Google Maps API to provide the seamless and interactive

integration between Google maps and the underlying ArcServer services.

All the necessary static and dynamic incident management related data and

information are stored in MySQL database, accessed through J2EE JDBC API. The

software agents interact with the database using the integration gateway and the JDBC

API. The AJAX API is used in case of failure of communication between interacting

agents. Upon receiving an incident alert message, the message is forwarded to the

communication officer agent and simultaneously forwarded to the database. In order to

avoid missing any of the incidents alerts due to agents’ communication failure, the AJAX

API continuously scans the database and matched the most recent incident id with one

being in the agents’ exchanged messages.

206

6.8 DEMONSTRATION SCENARIO

The Gardiner Expressway connects downtown Toronto with its western suburbs.

Running adjacent to the shore of Lake Ontario, it extends from the junction of Highway

427 and the Queen Elizabeth Way (QEW) at its west end and to the foot of the Don

Valley Parkway (DVP) in the east. The roadway is elevated, running above Lake Shore

Boulevard east of Bathurst Street. A major accident involving multiple cars and trucks

occurs on the Gardiner during a peak hour. Two of the three lanes and shoulder of

Gardiner are closed due to the incident. The communication officer (traffic operator in

this case) starts to receive alerts through 911 Emergency call centers as well as Twitter

and similar social web applications. The following snap shots show the handling of such

traffic incident within SWIMS framework. The execution steps underlying the

demonstration scenario are outlined in detail in Appendix D.

Figure 6-11(a): Preliminary Incident Attributes collected through Dedicated Webpage

207

Figure 6-11 (b): Incident Alert is sent to Communication Officer and Closest Cameras to

the Incident Scene are identified to verify the Incident

Figure 6-11 (c): Detailed Incident Report is prepared and sent by the Communication

Officer

208

Figure 6-11 (d): Detailed Incident Report sent by the Communication Officer is received

by various Emergency Responders (Medical Services in above Figure)

Figure 6-11 (e): The Emergency Medical Service Agent utilize the ‘Route Guidance’ and

‘Real Time Network Links Travel Time’ to guide Emergency Units to Incident Scene

209

Figure 6-11 (f): Traffic Operation Center Agent receives the Incident Report and a

‘Mesoscopic Traffic Simulation’ Web-service is triggered to determine Impacted Area

Figure 6-11 (g): Impacted Area is calculated along with Impacted Intersections and

suggested Traffic Signal Plans

210

Figure 6-12 (a): SWIMS Agents Interaction Diagram

Figure 6-12 (b): SWIMS underlying GIS Web-services deployed on ESRI ArcServer

211

7 EVALUATION

7.1 SUMMARY

This chapter presents the work performed to evaluate the developed ontology (TIM-

Onto) and semantic incident management system (SWIMS). TIM-Onto was evaluated

using: automated consistency checking, conformance to the design competency

questions, and assessment through interviewing domain experts. On the other hand,

SWIMS evaluation was performed through testing with actual case studies. The overall

objectives of the evaluation process were to demonstrate the developed ontology

competency, completeness, coverage, and reusability as well as the practical usability of

the developed incident management test-bed.

7.2 EVALUATION OF TIM-ONTO ONTOLOGY

TIM-Onto evaluation criteria is extracted from the work conducted by El-Diraby et al.

(2005) and the evaluation methods summarized by Gomez-Perez et al. (2004). In this

regard, the following four criteria were selected:

1. Representation: refers to the developed ontology level of abstraction, i.e. on what

level of detail did the ontology capture the subject domain.

2. Coverage: refers to the completeness of ontology in covering the subject domain, in

terms number of modeled entities, associated relationships and necessary axioms.

Coverage can be seen as the horizontal dimension of the ontology, while

representation looks in the vertical one.

3. Consistency: refers to the existence of more than one interpretation for the same

concept in the ontology.

4. Ease of Use: describes how easy to navigate the ontology and it is not too difficult to

locate a concept within the ontology taxonomic hierarchies.

The above mentioned criteria are assessed using two evaluation techniques: technical-

and user-based evaluation. Technical evaluation is performed by the ontology developers

to assure that the ontology design requirements has been met, and no contradictions exist

212

within the ontology concepts intended interpretations. User-based evaluation is used to

assess the ontology from the potential users’ perspectives. In this research, technical

evaluation was carried out through ontology competency questions requirements

conformance assessment and automatic consistency check using software ontology

reasoners. On the other hand, users’ evaluation was conducted through interviewing

domain experts. Table 7-1 summarizes the TIM-Onto evaluation criteria and the

associated methods that were used to assess them.

Table 7-1: Ontology Evaluation Criteria and Tools

Evaluation Tools Evaluation Criteria

Representation Coverage Consistency Ease-of-Use

Technical Evaluation

Competency Question

√ √

Automatic Consistency Check

√

User Evaluation Expert Interview √ √ √

7.2.1 Review of Design Competency Questions

As early mentioned in Chapter 2, competency questions are the ontology design

requirements formulated in questions format. These questions have to be ultimately

answered by the developed ontology (Grüninger and Fox 1995). In this sense, the

competency questions serve as a reference framework that specifies the ontology

requirements; against which the ontology could be evaluated for its representation and

coverage. The review of design competency questions is conducted either by the

ontology developers, potential users, domain experts, or ontology development experts.

TIM-Onto was checked for conformance with the design competency questions

manually by the developer (the author). In the author’s point of view, it has been

concluded that TIM-Onto is compliant with the targeted ontology design scope.

However, there is still a need to validate the ontology from the perspective of potential

users.

213

7.2.2 Automated Consistency Check

As discussed in Chapter 6, TIM-Onto concepts and their associated relationships are

coded in OWL-DL (DL stands for descriptive logic) using Protégé. Ontologies that are

coded in OWL-DL can be translated into Description Logic representation, and thus

processed for inconsistencies using Description Logic semantic reasoners. An ontology

concept is said to be inconsistent, if it cannot have any instances (Horridge et al. 2004).

For example, TIM-Onto defines Law-Enforcement and EMS (Emergency-Medical-

Service) as two disjoint classes (i.e. no actor can be law enforcement and emergency

paramedic in the same time). Consistency check will return an error if a subclass is coded

as both Law-Enforcement and Emergency-Medical-Service.

Another common use of reasoners is to test a class taxonomic hierarchy, i.e.

whether the class is subclass of another superclass. By checking all the classes in the

ontology for new superclass-subclass relationship, it is possible to infer new hyponymy

relationships from existing ones. Recall that one of the major advantages of ontologies,

compared to other knowledge modelling techniques, is to infer new knowledge from

existing ones.

Several Description Logic reasoners such as: RACER, Pellet, and FACT++, can

be used for automated reasoning of OWL-DL ontologies. All of the before mentioned

reasoners are available as Protégé plug-ins. They all perform very similar reasoning

functionality and picking any of them is a matter of user convenience. However, within

the context of this research Pellet (version 2.0) was employed. Pellet is an open-source

Java-based OWL-DL reasoner, available as Protégé OWL plug-in. It is an open source

reasoned that is widely used with demonstrated system stability. The consistency of the

ontology was tested throughout the development lifecycle, and the results indicated that

that ontology is consistent.

214

7.2.3 Expert Evaluation Interviews

In order to evaluate TIM-Onto from the perspective of potential users, a series of in-

person interviews with traffic incident management domain experts has been conducted.

Fourteen domain experts have been visited individually and their responses have been

collected and carefully analyzed. The structure of the interviewing process is based on the

work carried out by EL-Diraby et al. (2005). This section describes the following aspects

of the interview process: 1) interviewee selection, 2) interview procedure and data

collection, 3) questionnaire design, and 4) interviews results analysis.

7.2.3.1 Interviewee Selection

Purpose-based sampling method was used in selecting the ontology evaluation

respondents. The purpose-based method is special sampling technique employed when

the targeted study population is rare, highly specialized and difficult to allocate (Black

1993). Accordingly, this sampling method was found to be best fit for validating the

developed ontological model for the following reasons: 1) the evaluation method requires

highly specialized professionals having specific areas of expertise, 2) requirement of

broad domain representation, and 3) research time constraints.

In order to provide appropriate and countable evaluation, selected respondents

should be experienced with the transportation engineering domain in general and have

comprehensive understanding of the traffic incident management requirements. In

addition, they should be knowledge intensive workers, and aware of information flow

requirements in the traffic management process. Thus, they will be able to assess that

their information and knowledge modelling needs are well represented by/in ontologies.

Furthermore, they should exhibit basic understanding of information and communication

technology. Such point is specifically important to increase the effectiveness of the

evaluation process. The before mentioned criteria has made allocating the study

population quite challenging.

The selection of the interview respondents covers major stakeholders involved in

traffic incident management throughout its different lifecycle phases. This include: 1)

engineering professionals involved in transportation infrastructure planning and design,

2) researchers and academics in transportation safety and traffic engineering domain, and

215

3) emergency responders involved in traffic incident response. These selection criteria are

considered more important and critical than the respondents sample size. In addition,

there was not enough time to perform large scale investigations, which lead to limiting

the number of selected respondents.

Combining the before mentioned facts of required expertise, skills, broad

coverage of involved stakeholders, and research time constraints requires that the

choosing of evaluation respondents to be very selective and purpose-oriented. Fourteen

experts have been selected to be interviewed for TIM-Onto evaluation. Table 7-2

illustrates the selected respondents along with their area/s of expertise,

professional/academic designation and years of experience.

Table 7-2: Respondents for TIM-Onto Evaluation

Designation Primary Expertise Secondary Expertise Yrs. of Experience

Respondent-1 Senior Manager – MTO1 Road Safety Analysis & Research

Incident Data Analysis & Documentation 27

Respondent-2 University Professor – UBC2

Transportation Planning &Design Traffic Control 10

Respondent-3 University Professor- Carelton University

Road Safety Analysis & Research

Transportation Planning &Design/Traffic Control 8

Respondent-4 Transportation Engineer – Delcan Consulting Traffic Control Transportation Planning

&Design 6

Respondent-5 Transportation Engineer – AECOM Consulting


Transportation Planning &Design 11

Respondent-6 Transportation Engineer – City of Toronto

Road Safety Analysis & Research Traffic Control 3

Respondent-7 Post-doctoral Fellow –University of Toronto

Transportation Planning &Design

Incident Data Analysis & Documentation 13

Respondent-8 Chief - Toronto Fire Emergency Response Detection &Verification 20 Respondent-9 Captain – Toronto Fire Emergency Response Detection &Verification 16 Respondent-10 Captain – Toronto Fire Emergency Response Detection &Verification 20

Respondent-11 Fire Fighter 1st Class – Toronto Fire Emergency Response Detection &Verification 10

Respondent-12 Emergency Planner – Toronto Fire Emergency Response Detection &Verification 15

Respondent-13 MTO Burlington COMPASS TOC3

Supervisor

Detection &Verification

Traffic Control/Emergency

Response 10

Respondent-14 MTO Burlington

COMPASS TOC Senior Project Manager

Traffic Control Emergency

Response/Emergency Response

8

1 Ontario Ministry of Transportation (MTO) 2 University of British Columbia (UBC)

3 Traffic Operation Center (TOC)

216

7.2.3.2 Questionnaire Design

Following the evaluation methodology proposed by El-Diraby et al. (2005), TIM-Onto

evaluation questionnaire used in this research consists of five sections. These sections are

summarized in the following paragraphs; while the complete questionnaire is provided in

Appendix-F:

§ Section One: aims to collect respondent information, including name, position,

areas of expertise, years of experience, and contact information.

§ Section Two: confirms that the interviews comply with the selection criteria

outlined in the previous section. Assess the interviewee opinion about the main

research premise; i.e. need to define semantics associated with concepts defining

risks associated with transportation infrastructure. In addition to need for semantic

representation and integration in the traffic incident management domain to

enhance communication, coordination, and collaboration among various involved

stakeholders.

§ Section Three: evaluates the abstraction and categorization of the ontology.

Adequate abstraction and categorization indicates the consistency and the sematic

correctness in categorizing the ontology concepts. Twenty concepts were to the

respondents who were asked to rate their agreement with the given categorization.

§ Section Four: assess the ease of navigating the ontology. Fifteen concepts were

given to the respondents and were asked to locate them using the Protégé ontology

editor and rate how easy it was to find these concepts. In other words, assess the

ease of locating concepts in the ontology taxonomic hierarchy. Navigational ease of

the ontology is crucial for facilitating knowledge access, retrieval, reuse and

maintenance.

§ Section Five: respondents were asked to provide their overall evaluation as well as

any comments they might have on the ontology.

For sections two to five, a Likert six-point scale was used to measure the respondents’

evaluation, with 1 for the most favourable.

217

7.2.3.3 Interview Structure and Data Collection

The evaluation interviews were conducted in three stages. First the respondent was

introduced to knowledge management domain in general and ontological engineering in

specific; and the motivating scenario underlying this research ontology. This process took

10-15 minutes.

Second, a high level view of the ontology concepts taxonomy and architecture

that contained around 150 concepts was presented to the responded on 11×7 page. The

respondent then was given the option of viewing the entire ontology on a large A1 size

drawing or by navigating the ontology using Protégé ontology editor. This process

consumed nearly 15-20 minutes. Finally, in the third part of the interview, the respondent

was requested to fill out the evaluation questionnaire, described in the previous section.

This part of the interview took between 30-40 minutes.

It should be noted that the evaluation interviews covered only the ontology

concepts and relationships. The ontology axioms are coded in Protégé OWL or expressed

in SWRL; using FOL (First Order Logic) language. Due to the limited widespread of

these two coding languages, none of the interviewee was familiar with them. Thus they

were removed from the interview and checked using automated techniques as outlined in

section 7.3.2.

7.2.3.4 Interview Results and Data Analysis

As early mentioned, Likert six-point scale was used for sections 2-5 of the questionnaire.

Likert is a psychometric scale commonly used in questionnaires where respondents have

to specify their level of agreement with a statement. Within the scope of this research, a

six-point scale was used, with 1 representing most favourable (i.e. strong agreement). It is

considered to be an ordinal scale, due to the fact that respondents cannot perceive all pair

of adjacent level as equidistant. In this case the central tendency of the data is measured

by the median, which is the approach adopted by this research.

It is important to note that it is not appropriate to apply statistical analysis to

samples selected using non-random samples (N-Trochim 2001). And the Likert scale is

only used to analyse the collected interviews data rather than for the inference of the

whole population, i.e. cannot be used to generalize the results beyond collected samples.

218

The four questions of section 2 of the questionnaire aimed to confirm that the interviewee

comply to the respondents selection criteria. The selected respondents were found to fully

cover the required areas of expertise that were deemed to necessary to evaluate the

ontology from multifaceted perspectives. All the correspondents demonstrated full

competency in at least one of the required areas of expertise, i.e. median value of one

(very familiar).

On the other hand, the average overall familiarity of each respondent to the full

spectrum covered by TIM-Onto was found to range between ‘Familiar’ to ‘Moderately-

Familiar’. This was found to be justified given the broad coverage within TIM-Onto to

the transportation engineering domain. Further no single respondent was expected to be

aware of every single area of expertise being evaluated within the ontology.

Questions 2.2 results indicate that 50% of the respondents are ‘Moderately

Familiar’ with risk assessment requirements in the transportation domain. This support

the underlying causes of developing TIM-Onto as a tool for knowledge sharing that

allows different stakeholders to understand and assess risks associated with transportation

systems they operate within. 80% of the responded indicated to be ‘Moderately Familiar’

or less with data/information flow patterns and need within the traffic incident

management lifecycle. In addition, 60% indicated the same for awareness of key

processes, involved actors and their roles within the traffic incident management

lifecycle.

These results augment the requirement analysis conducted by the author for the

ontology development that is presented in Chapter 3. It further supports findings in

traffic incident management literature that was pointed out in Chapter 2. These findings

states that involved stakeholders operate, most of the time, unaware of each other mutual

interactions and expectations during traffic incident response. Results of Section 2 of the

TIM-Onto validation survey are presented in Table 7-3.

Section 3 aims to evaluate the abstraction and categorization effectiveness of the

ontology. Twenty concepts were randomly selected from the ontology and their

corresponding taxonomical hierarch paths were listed. Respondents were asked to rate

their level of agreement with the taxonomic hierarchy for each concept within TIM-

219

Onto. Respondents’ agreement with TIM-Onto categorization ranged from ‘Strongly

Agree’ to ‘Agree’, with median value of 1.58. The median value indicates an overall

‘Strong Agreement’ with TIM-Onto concepts abstraction and categorization by most

stakeholders involved in traffic incident management. Table 7-4 summarizes the results

of this section.

Section 4 assesses the respondents’ evaluation of the ontology navigational.

Respondents were asked to locate 15 concepts that were randomly selected from TIM-

Onto. For each concept in this section, respondents were asked to navigate through the

taxonomy to find the concepts, and subsequently rank the ease of accessing this concept

from TIM-Onto hierarchal taxonomy. Results of this section are summarized in Table 7-

5. Respondents’ rating of TIM-Onto navigational ease ranged from ‘Very Easy’ to

‘Moderately Easy’ with median of 1.76. The results indicate that, in general, respondents

find the taxonomy navigation to be ‘Easy’ to navigate.

It worth mentioning that stakeholders with significant experience in their area

were the ones in general that had the most difficulty in navigating the ontology. In

specific users 1, 8, 9, and 14 with a median value of 3 indicating ‘Moderately Easy’

navigation. This can be contributed to the fact of that with age, navigating through quite

unfamiliar software application like Protégé becomes more challenging. The only

exception to this observation was respondent number ‘10’ who decided to navigate the

ontology using an A1 map.

The last section of the questionnaire provides an overall evaluation of the TIM-

Onto in terms of ease of use, representation, and coverage. Results of this section are

summarized in Table 7-6. The results indicated that respondents find the navigation

through the ontology in general to be ‘Easy’ with median value of 2.0. This conclusion

coincides with findings in the previous paragraph.

80% of the respondents indicated to be ‘Very Familiar’ with the ontology

concepts, while the remaining percentage indicated to be ‘Familiar’. 80% of the

respondents believe that that ontology ‘Strongly Representative’ of the traffic incident

management domain. 70% of the respondents assess that the ontology ‘Strongly Cover’

the traffic incident management domain. This indicates that TIM-Onto adequately

220

represent the traffic incident management throughout its lifecycle; since the respondents

were chosen to cover the whole spectrum for the traffic incident management lifecycle.

An important issue was recognized by the author during the interviews. Even

though most of the respondents agreed with the ontology taxonomy and level of

abstraction, they had different understanding of some concepts and their categorization.

This can be contributed to the fact that they are involved in managing traffic incident at

different lifecycle phases. Some were transportation designers and roadway safety

researchers who are involved more during the proactive phase. Others were involved in

the reactive response phase, e.g. emergency responders and traffic operators. Each of

these stakeholders has her/his own slightly different work environment and knowledge

backgrounds. This is exactly why the creation of ontology for traffic incident

management domain was seen to be imminent.

221

Table 7-3: Respondent Compliance to Selection Criteria and Familiarity about Research Premise

No Question Respondents’ Response Response Analysis

R1

R2

R3

R4

R5

R6

R7

R8

R9

R10

R11

R12

R13

R14 Median Interpretation

1

Inci

dent

Life

cycl

e Ph

ase

Transportation Infrastructure Planning &Design

2 2 2 2 3 1 1 3 2 3 3 3 4 - 2 Familiar

Road Safety Analysis & Research 1 1 1 3 2 1 3 3 2 3 4 4 4 - 3 Moderately

Familiar

Detection & Verification 2 - 4 3 5 4 - 4 3 3 4 5 1 3 3 Moderately Familiar

Emergency Response 3 2 3 2 - - - 1 2 1 1 3 2 2 2 Familiar

Traffic Control 1 1 2 1 4 2 3 3 3 4 2 4 2 1 2 Familiar

Incident Data Analysis & Documentation 2 6 3 2 4 1 4 3 3 4 4 4 3 3 3 Moderately

Familiar

2

Are you aware with safety analysis and risk assessment requirements in transportation engineering domain?

1 2 2 2 2 1 3 3 3 3 4 4 4 - 3 Moderately Familiar

3

How familiar are you with data/information flows patterns and needs within the scope of traffic incident management lifecycle?

2 3 3 3 4 2 - 3 3 4 4 4 3 3 3 Moderately Familiar

4

Are you familiar with traffic incident management key processes, actors and their designated roles?

3 2 3 4 4 3 4 3 2 4 2 4 2 1 3 Moderately Familiar

Overall 3 Moderately Familiar

222

Table 7-4: Respondent Compliance to Selection Criteria and Familiarity about Research Premise

No Concept Respondents’ Response Response Analysis

R1

R2

R3

R4

R5

R6

R7

R8

R9

R10

R11

R12

R13


1 Landslide 1 2 1 2 1 1 1 1 2 2 1 2 1 2 1 Strongly Agree

2 Flooding 1 2 1 1 1 1 1 1 2 2 1 2 1 1 1 Strongly Agree

3 Driver Error 2 1 2 1 3 1 2 2 3 1 2 3 1 2 2 Agree

4 Facility Sabotage 1 1 2 2 1 2 1 1 3 1 2 2 3 1 1.5 Strongly Agree/Agree

5 Sharp Curve 5 1 3 1 2 3 2 2 2 2 2 2 2 3 2 Agree

6 Low Ignition Point 4 2 3 2 2 1 2 1 2 2 2 2 2 2 2 Agree

7 Low Yield Strength 4 2 3 1 2 3 2 2 2 2 2 2 2 2 2 Agree

8 Collision Incident 1 1 2 2 4 1 1 2 2 2 1 2 2 1 2 Agree

9 Bridge Collapse 1 1 1 1 1 1 2 1 2 2 3 2 2 2 1.5 Strongly Agree/Agree

10 Snow Blockage 2 1 3 1 1 1 2 2 2 1 1 2 1 1 1 Strongly Agree

11 Roadside Facility Damage 1 1 3 1 2 3 2 2 2 2 2 2 2 2 2 Agree

12 Visibility Loss 1 1 2 3 3 1 1 1 3 2 3 2 1 1 1.5 Strongly Agree/Agree

13 Sleet/Ice Skidding 3 5 4 2 2 1 2 1 2 1 2 12 1 1 2 Agree

14 Personal Injury 1 1 2 1 1 1 2 1 2 2 1 2 2 2 1.5 Strongly Agree/Agree

15 Total Travel Delay 1 1 2 3 3 4 2 2 2 2 2 2 2 3 2 Agree

16 Occurrence Time 1 1 1 1 1 1 2 1 2 2 2 2 2 2 1.5

17 Scene Protection 1 1 1 1 1 1 2 1 2 1 1 2 2 1 1 Strongly Agree

18 Traffic Management 1 1 1 1 1 1 2 1 2 2 1 2 2 1 1 Strongly Agree

19 Roadway Debris Removal 1 1 1 2 1 4 2 1 2 2 2 2 1 2 2 Agree

20 Ontario Provisional Police 1 1 1 1 1 1 2 2 2 2 1 2 2 1 1 Strongly Agree

Overall 1.58 Strongly Agree/Agree

223

Table 7-5: Respondent Evaluation of TIM-Onto Navigational Ease

No Concept Respondents’ Response Response Analysis

R1

R2

R3

R4

R5

R6

R7

R8

R9

R10

R11

R12

R13


1 Slope Failure 4 4 2 1 2 1 1 2 5 1 3 2 2 3 2 Easy

2 Waterspout 6 2 2 2 1 1 1 3 5 2 5 5 1 3 2 Easy

3 Rear end collision 3 1 3 1 1 1 1 2 3 1 3 2 1 2 1.5 Very Easy/Easy

4 Recovery Time 3 3 3 1 2 1 2 2 5 1 2 3 3 4 2.5 Easy/Moderately East

5 Detour Management 2 1 1 1 2 1 3 3 5 1 4 3 3 4 2.5 Easy/Moderately East

6 Design Error 4 1 4 2 3 1 2 4 5 1 4 2 3 6 3 Moderately East

7 Emotional Stress 5 1 3 1 3 1 3 4 5 2 5 5 2 5 3 Moderately East

8 Verification Time 3 1 5 1 2 1 1 4 2 1 2 2 1 5 2 Easy

9 HAZMAT Team 4 1 1 2 1 1 1 2 2 2 1 2 1 1 1 Very Easy

10 EMT-Basic 1 1 2 1 1 1 2 2 2 1 1 2 1 2 1 Very Easy

11 Trooper Officer 1 1 1 1 1 1 1 2 3 1 1 2 1 2 1 Very Easy

12 Fire/Rescue 1 1 1 1 1 1 3 2 2 1 1 2 1 2 1 Very Easy

13 Run-off-road 6 1 2 2 1 1 2 4 1 1 5 6 2 5 2 Easy

14 Fatality 1 1 1 1 1 1 4 3 1 1 2 2 4 3 1 Very Easy

15 Communication Officer 1 1 1 1 1 1 1 3 3 1 1 2 2 3 1 Very Easy

Overall 1.77 Very Easy/Easy

224

Table 7-6: Respondent Overall Evaluation of TIM-Onto

No Concept Respondent’s Response Response Analysis

R1

R2

R3

R4

R5

R6

R7

R8

R9

R10

R11

R12

R13


1 How easy was it to navigate through ontology? 3 2 2 1 2 2 2 2 4 2 3 3 2 2 2 Easy

2 How familiar were the

concepts used? 2 2 2 2 2 2 3 2 3 2 3 2 3 2 2 Familiar

3

How representative were the

concepts used? 2 1 2 1 2 1 2 2 3 2 3 2 3 3 2 Easy

4

Did the ontology cover the

main concepts pertaining to

traffic incident

management?

2 1 1 2 2 1 2 2 4 1 3 2 3 3 2 Easy

Overall 2 Easy

225

7.3 SWIMS FRAMEWORK PERFORMANCE EVALUATION

Ideally, a framework similar to that of SWIMS would have been evaluated through

comparing its performance to historical prerecorded scenarios. In such case, several

historical incident scenarios would be used; where the exact upon-dispatch location of

response units along with their to-scene arrival time is known. The framework would

then be tested to in terms of improvements in verification, response time and ultimately

the overall impact on incident recovery time.

However, none of the found incident records that were investigated kept hold on

such data and thus this sort of comparison was unfeasible. In addition, comparing

SWIMS traffic control capabilities is obsolete, as the framework provides an ad-hoc

platform for integration rather than adopting specific traffic control algorithms.

Accordingly, only the following three criteria were used in evaluating SWIMS

framework, which are: 1) requirement conformity, 2) automated reasoning capabilities

and 3) focus groups.

7.3.1 Requirement Conformity Assessment

The defined requirements Chapter 3 serve as the frame of reference and requirement

specifications against which SWIMS could be evaluated. As illustrated in Chapter 6

these requirements were used to develop SWIMS. Hence the framework was checked for

conformance to these defined requirements. This assessment was conducted qualitatively

by the author. All SWIMS functionalities were examined and indicated conformity

against the system defined services and requirements.

7.3.2 Automated Reasoning

One of the most important features SWIMS provides is ability to use TIM-Onto

ontological rules (axioms) to support the incubated software agents’ automated

reasoning. As previously mentioned in Chapter 6, TIM-Onto concepts and relationships

are coded in OWL-DL. Protégé ontology editor is able to support simple axioms that

constrains on cardinality or concepts relationships ranges and domains. However, the

ontology editor does not have the capacity to express complex rules similar to those

226

defined in Section 6.5.4 and Appendix-D. Accordingly, SWRL rules were used to code

TIM-Onto complex rules through combining OWL-DL and Unary/Binary Datalog

RuleML languages. These rules were coded in the Protégé SWRL-Tab.

The consistency of core TIM-Onto axioms has been checked for consistency using

Pellet reasoner (Section 7.2.2). In order to ensure that the software agents in SWIMS

exhibit the desired design behavio, there is a need to evaluate the automatic reasoning

capabilities of the rules coded in SWRL and used by software agents for reasoning.

As previously mentioned in Chapter 6, there are several available reasoners that either

fully or partially support SWRL rules (e.g. Hoolet, KAON2, JESS, RacerPro…etc.).

However, JESS has been selected as the reasoned of choice for the following reasons:

§ JESS is the most mature SWRL engine that has been implemented widely in many

knowledge-based systems (Zhang, 2010).

§ JESS is fully integrated with JADE through a dedicated API. This API is widely

supported by the knowledge engineering research community and has been

successfully implemented in multiple applications. The author utilized this API to

enable software agents to reason using the ontology concepts; saving extra coding

efforts in developing this sort of agent-reasoner integration.

§ JESS provides Protégé-OWL integration plugin (‘JESS Tab), allowing to validate the

SWRL rules in the development environment before implementation.

Each rule coded in SWRL was verified and validated by the JESS reasoning engine, any

errors in the rules was detected and corrected. Example of SWRL rules validation process

is provided in Appendix-D.

7.3.3 Focus Group

A focus group is a qualitative research technique aiming to assess a representative

people sample perception, opinion, and believes towards certain product or service. It is

conducted in an interactive manner, where each participant is encouraged to share her/his

views regarding the product/service freely with other members. A focus group is formed

of a group of targeted users, evaluating the usability of a new product or service

prototype (Edmunds 1999).

227

The focus group approach was selected as a tool for SWIMS evaluation for several

reasons, as pointed by Kontio et al. (2004):

§ It is widely used common method of evaluation in software engineering.

§ Fast and cost-effective method in assessing targeted users’ evaluation.

§ It can capture qualitative feedback and insight that are difficult capture compared to

other methods.

§ It helps to understand the motivation behind the thinking of the group members

unlike questionnaire results, which cannot provide this answer.

7.3.3.1 Focus Group Preparation

The purpose of the focus group in this research was to evaluate SWIMS from three main

aspects. The first was to examine the services and functionalities the SWIMS system can

provide. Secondly, is to assess the recognition of traffic operators and emergency

responders of such information system and the role it can play in facilitating information

exchange and knowledge sharing. Finally, is to study the usability of the system in terms

of its user-friendliness.

In general, a focus group is ideally formed of 6 to 8 participants, selected to be a

representative sample (using purposive sampling method) of the targeted

users/consumers (Fabiano-Lederman 2002). The focus group was selected to represent

the traffic management operative at the Ministry of Transportation of Ontario (2

members) and emergency responders at the City of Toronto (5 members). They were

carefully solicited to have the required technical capability and field experience to

evaluate a software system of this type. All selected members of the focus group had

more than 8yrs of professional experience.

Emergency responders were primary senior officers in the dispatch and

communication division of their organizations. All of the selected members had

participated in the ontology evaluation, which leveraged their previous exposure to the

research topic and helped to increase the efficiency of the focus group. The focus group

was split into two halves, the traffic operatives and the emergency responders, in order to

have similar backgrounds and facilitate free discussion.

228

A two page introduction was sent to each respondent to provide details on the research

background and the developed software application. A questionnaire was also prepared to

collect quantitative feedbacks on SWIMS. The first session of the focus group was held

at the MTO Burlington COMPASS program traffic operations center. The second session

was held at the City of Toronto Fire Services Emergency Planning Division headquarters.

Each session lasted for 90 minutes, and was conducted at a sufficiently quiet board room.

7.3.3.2 Execution of the Focus Group

The session started with the introduction of all focus group participants. A brief agenda

rundown was given by the group facilitator (the author), including an explanation of the

following items:

§ The purpose of the focus group.

§ The information and the software system to be presented.

§ The requested inputs from the participants and how this input will be documented and

used.

The session facilitator then gave a 20 minutes presentation; introducing the SWIMS

framework. The presentation covered the following items: 1) the information flow and

communication needs during traffic incident management process, 2) existing problem

and challenges, and 3) two application scenarios, together with the proposed technical

approach and proposed functionalities of the SWIMS system. The design of 4 key

software agents along with their web page interface was given to the participants. Each of

SWIMS functionalities along with its key tasks were introduced in full detail.

After the presentation, participants were allowed to have 45 minutes free

discussion period, during which participants asked the facilitator clarifying questions

regarding the presentation. The discussions included comments and remarks regarding

SWIMS services and functionalities, including system advantages and room for future

improvement. All comments and feedback were collected and analyzed, as listed at the

end of this section. All the participants in the focus group filled out a questionnaire after

the discussion. The questionnaire took nearly 20 minutes to complete followed by a brief

wrap up discussion.

229

7.3.3.3 Questionnaire Design

SWIMS framework evaluation questionnaire was formed of two sections: respondent’s

information and the overall evaluation of the system, respectively. The first section was

similar to that used in the ontology evaluation questionnaire. The second section of the

questionnaire was used to solicit measurable response from the participants in addition to

the information collected during the free discussion. This section is formed of 11

questions. Appendix-G provides the full SWIMS evaluation questionnaire.

The questionnaire evaluates the main functionalities and services that SWIMS

can provide to the users, from the author’s perspective. Each question or group of

questions in the questionnaire was designed with specific intent. Similar to the ontology

evaluation questionnaire, a Liker six-point scale was used for section 2 to record the

focus group participants’ evaluation, with one being the most favorable. Table 7-7

illustrates the objective underlying each question in SWIMS questionnaire.

Table 7-7: Underlying Objectives of SWIMS Evaluation Questionnaire

No. Objective

Q1 Assess the resemblance between SWIMS workflow and the currently deployed incident response workflow in the respondents’ organizations.

Q2 Assess whether or not all major stakeholders are well represented within the context of SWIMS multi-agent system, i.e. is a there a software agent that performs each respondent role/s in the incident management process.

Q3 Assess if major information flows requirements between the respondents agencies is well met by SWIMS.

Q4,5 Measure the validity of the rules encoded in each software agent, and whether or not the output of these rules do match real life scenarios.

Q6,7

Determine the acceptance of the domain operatives to the system through evaluating the benefits induced by SWIMS in terms of timely response and whether the solution imposed is a correct solution for the traffic incident management problem from the respondents’ perspective.

Q8 Evaluate the respondents’ perspective of integrating social web application as a valuable tool for incident detection and reporting.

Q9, 10 Assess the friendliness of SWIMS graphical user interface and possibility of its integration in the respondents’ organizations.

Q11

Approach a core the premise by assessing respondents’ perception on SWIMS usefulness in modeling the traffic incident management process semantics and thus supporting the seamless integration of different stakeholders of enhanced communication, coordination, and collaboration.

230

7.3.3.4 Focus Group Discussion Results

During the focus group discussion session, no sort of media recording was used due to

information sensitivity and liability. Participants’ initial evaluation of SWIMS through

the focus group discussion indicates that the framework is regarded as a potentially useful

tool in supporting the following:

§ Automated coordination between heterogeneous IT platforms belonging to different

emergency response agencies. Accordingly the system was seen by the participants as

a great tool that harmonize incident management cross-organization workflow.

§ In addition providing the ability to communicate using standardized terminology. The

Toronto Fire Services operatives indicated that their organization is the third biggest

in size in the whole world that is formed of 82 geographically dispersed agencies and

the importance of communicating using standardized shared terminologies cannot be

overstated. This can be seen as a direct major advantage of SWIMS underlying

ontology (TIM-Onto).

§ The incubated decision rules, in addition to capturing incident management best

practices, allow consistent coordination where different responders can operate with

complete awareness of mutual expectations and interactions during incident

management process.

§ The integrated database for incident attributes log, allows different parties to monitor

their processes performance and identify room for future improvement.

§ Shared access to software resources, implemented as Web-services, allows different

stakeholder to fully utilize each other capabilities and optimize incident response.

§ The Fire Service operatives emphasized the advantage of having the 30 second

updated link travel times coming from the MTO VDS feeds, as indicated in Chapter

6. Such functionality optimizes their travel time to and from the incident scene,

helping to minimize incident duration and more importantly save human lives.

§ The functionality of sharing the response plan among involved stakeholders and the

ability to edit it as well as forwarding it to specialized experts (if needed) help to

231

achieve coordinated decision making process and reaching the best possible favorable

outcome.

§ The use of ontology as an interoperability tool that provides a platform for a learning

system was praised by the participants. However, they indicated that keeping the

system underlying ontology at the backend was a good design choice.

The above mentioned points support SWIMS intended design objectives and rationale, as

well as its underlying ontology (TIM-Onto). However, participants in the focus group

indicated the need for further extensions and add-ons that they would like the system to

provide based on their operational experience. These concerns can be summarized in

three main points.

Some participants raised the concern of how to integrate SWIMS into the current

incident management process workflow. They indicated that incident response agencies

have their own particular work processes and their staff are already used to the routine

work procedures of these processes. Getting their buy-in to use this system will be quite

challenging and they requested the author to develop a change management framework to

be incorporated with SWIMS implementation plan.

The second concern was the security issue. The security of the system was

discussed from two perspectives. The first is the immunity of the system against

breaches and hacking attempts. The second perspective was the fact that every exchanged

information and knowledge item during the incident management process must be

encrypted. However, the effect of such encryption on the ability of the software agents to

interpret the exchanged message content using the system underlying ontology was quite

unclear.

Other concerns were also discussed, such as: the bases on which the privilege to

change/edit the system execution rules will be granted, the need to incorporate more

functionalities regarding traffic signals and ramp metering algorithms variety, the ability

to provide different traffic control plans and choose among them based on anticipated

performance.

232

The author’s input on the focus group participants raised issues is that SWIMS is an

academic prototype. It is developed as a proof of concept to demonstrate TIM-Onto

ability to integrate cross organization incident management processes, incubated in

heterogeneous IT system. In addition to support coordinated response and collaborative

decision making process. The success of SWIMS to achieve such objectives was

acknowledged by the focus group participants.

Developing an application that fully satisfies the whole array of emergency

management functionalities is out of this research scope. In fact it is the work of several

ontological engineers and software developers rather than a single person, especially

within a research context. The primary aim was to gain traffic incident management

operatives recognition and acceptance for this prototype and for ontology as an enabling

tool for cross agency and platform collaboration.

7.3.3.5 Questionnaire Data Analysis

Similar to the interpretation of the ontology evaluation results was on the median of the

Likert six-point evaluation scale. The respondents’ answer to Section 2 of SWIMS

evaluation questionnaire provide and overall evaluation of the framework. Table 7-8

summarizes the results, which indicated the following:

§ Fire Service participants indicate that SWIMS workflow is ‘Representative’ of the

incident management response pattern within their organization. However, traffic

operators at the MTO indicated ‘Somewhat Representative’. This is due to the fact

that the adopted workflow within SWIMS resembles an ideal one and was drawn

from the traffic incident management literature. This result comply with the outcome

of the focus group discussion as MTO respondents indicated that more should be

done in order to enhance their incident response capabilities.

§ All respondents confirmed that all major stakeholders were represented in the system

(‘Agree’) and ‘Somewhat Agree’ for the information flow needs. As explained in the

previous section, incorporating all possible information flows during incident

management is unfeasible within research context. However, the scenario covered the

major information flow patterns during the incident management and this is why the

participants ‘Somewhat Agree’ of its representation.

233

§ The participants indicated to ‘Somewhat Agree’ that SWIMS decision rules along

with their outcome do resemble the one used within their organization during traffic

incident management. SWIMS decision rules were solicited from incident

management literature best practice guides. They were expected to be different than

those used within the MTO or the City of Toronto Fire Service. However, on

question 6, the same participants agreed that these rules aided SWIMS to prompt

timely and optimized response in addition of being ‘Useful’ in integrating traffic

incident response. It should be mentioned that SWIMS decision rules were validated

by the incident response operatives at the City of Toronto. Upon the validation time,

only the fire service responders indicated to have decision rules to respond to traffic

incidents (Appendix-E). The rest of the responding parties indicated to have more of

an ad-hoc decision making criteria that is gleaned from individual previous

experiences, rather than formal organizational response rules.

§ Responders ‘Strongly Agree’ that this sort of system will prompt timely and

optimized response (Question 6).

§ Respondent see an added value in integrating social web tools in the incident

management response process. Respondents perceive it as being ‘Somewhat Useful’,

(Question 8).

§ Respondents indicated that they find SWIMS graphical user interface to be

‘Friendly’ and indicated that the portal is ‘Easy’ to use (Question 9 and 10).

§ Overall, this type of software multi-agent is found to be ‘Very Useful’ be in

supporting semantic process representation and integration in the traffic incident

management domain for enhanced communication, coordination, and collaboration

among various involved stakeholders.

The questionnaire results conform to the outcome of the focus group discussions. Both

results indicate the majority of the respondents believe that SWIMS framework would be

very useful tool if integrated with the traffic incident management system. However, they

believe that more functionalities should be added to make the framework stand out

against existing systems.

234

Table 7-8: Respondents’ Inputs on SWIMS Evaluation Questionnaire

No Question Respondents’ Response Response Analysis

R8

R9

R10

R11

R12

R13

R14

Median Interpretation

1 How representative the workflow deployed by this application to real life scenarios carried out within the context of your organization? 2 2 2 2 2 3 3 2 Representative

2 Do you agree that all major stakeholders involved in the incident management process were well represented in the system? 2 3 2 3 2 2 2 2 Agree

3

Do you agree that all incident-related information needs from your organization perspective is well covered by the system? 3 3 2 3 3 3 3 3 Somewhat Agree

4 Do you agree with the decision rules encoded in the software agent the best represent your organization? 3 3 2 3 2 3 3 3 Somewhat Agree

5 Do you agree with the outcome (i.e. Is it reasonable and represent reality?) of the decision rules encoded in the software agent the best represent your organization?

3 3 2 3 2 3 2 3 Somewhat Agree

6 Do you agree that this system prompt timely and optimized response compared to currently deployed systems? 3 2 2 2 2 2 3 2 Agree

7 How useful do you think this type of software multi-agent portals will be as a tool for supporting the creation of integrated traffic management system?

2 2 2 2 2 3 2 2 Useful

8 Based on the given incident scenario, how necessary is the social web applications integration to the incident management system from your organization perspective?

3 3 2 2 3 2 2 2 Somewhat Useful

9 How friendly was the user interface of SWIMS, compared to other information systems used in your organization? 2 3 2 3 2 3 2 2 Friendly

10 Overall, how easy to use do you think this type of portal will be? 2 3 3 3 2 3 2 3 Easy

11

Overall, how useful do you think this type of portal will be in supporting semantic process representation and integration in the traffic incident management domain for enhanced communication, coordination, and collaboration among various involved stakeholders?

2 2 3 2 2 2 3 2 Useful

Overall 2.36

235

8 SUMMARY, CONCLUSIONS AND RECOMMENDATIONS

This thesis presents the outcome of a research project that resulted in the development of

an informatics software system. (SWIMS) The developed system acts as a platform for

supporting seamless information flows and integrated knowledge sharing in the traffic

incident management domain. Such objective is achieved through the integration of

software agent technology, ontological engineering knowledge modeling techniques, and

web-based distributed software systems (Web Services). The main premise of the

research is to provide proof of concept that knowledge models that promote

interoperability and knowledge sharing represent a promising approach in improving the

overall efficiency and performance of the traffic incident response processes.

It has been widely agreed that, due to the multidisciplinary and distributed nature

of traffic incident management, inaccurate and untimely information exchange among

various responders has caused costly delays; and in some cases has jeopardized the safety

of human lives. Responding agencies are operating under their individual response

policies and procedures, using self-contained legacy software systems and databases. In

addition, due to the dynamic nature of incident response, knowledge and experiences

gleaned in the course of various responses are not shared in a way that favours future

learning and reuse.

Based on the literature conducted by the author and the feedbacks collected

during the evaluation stage of this research, most of the currently deployed and widely

recognized incident management systems primarily address traffic operators. They did

not provide adequate means to integrate various stakeholders in the decision making

process. Furthermore, they captured the domain knowledge in fragmented, localized

manner and relied on outdated software implementation technologies.

Therefore there is a need for new generation of incident management systems that

are built using advanced knowledge modeling techniques. Such systems capture

knowledge pertaining to incident response best practices as well as adequately modeling

organizational integration elements using well structured and cross-domain shared

concepts. Those systems should harness the advancement in agent and distributed

236

software systems to build highly modular and flexible systems. Furthermore, they should

fully capture the dynamics of traffic incident management domain and being capable to

respond to its evolving demands and requirements.

8.1 PROPOSED SOLUTION

This research developed traffic incident management framework that adopts an

informatics view of integration (SWIMS). Informatics systems focus on knowledge

sharing and human communication as means for achieving synchronized integration of

processes workflow. Ontology is considered the core of establishing a knowledge-

enabled system for informatics. The developed framework is committed to traffic

incident management domain ontology.

To illustrate the value of ontology-based systems, a layer of software agents was

developed on top of the framework domain ontology. Each agent resembles different

stakeholder in the incident management domain; and uses the underlying domain

ontology for reasoning about the incident response measures using formally coded rules

and explicitly constrained domain knowledge. Based on different scenarios, involved

software agents build an ad-hoc framework resembling involved responding agencies.

Incident response services and resources are implemented using Web Services

paradigm. Those services and resources encompasses wide array of software entities,

including: traffic hardware data grabbers, GIS and non-spatial databases, legacy software

applications (e.g. simulators and other traffic control algorithms), web applications such

as geo-coders, mapping and routing applications …etc. Each group of services/resources

perform specific set of tasks corresponding to one or more response process within the

incident management framework. The real power behind using the Web Services

paradigm lies in providing novel applications in response to changes in requirements in

flexible and scalable manner.

Software agents bridge the gap between end users and various services provided

by the system. They assure integration of data, flow of information, processes

synchronization and provide decision support to human operators. Based on the incident

characteristics, each software agent will be responsible for allocating, composing, and

237

managing a set of resources and services that resemble its agency core competencies.

This will break the currently centralized workflow of the decision making process within

the incident management system, achieving a faster decision making and more adaptation

to the evolutionary nature of traffic incidents.

8.2 RESEARCH CONTRIBUTIONS

The contribution of this research can be viewed from two perspectives. The first is

knowledge management perspective, which lies in the modeling, capturing and

supporting interoperability of knowledge within the traffic incident management domain.

The developed ontology acts as an enabler of knowledge sharing and supports seamless,

interoperable flow of information across various responding agencies. The second

perspective is orthogonal to the first and can be broken as follows:

8.2.1 The Ontology

1. Creating a generic ontological model representing knowledge pertaining to civil

infrastructure associated threats and vulnerability: the developed ontological model

conceptualizes threat events along with the vulnerabilities that these events might

exploit in civil infrastructures. It is generic in nature covering all major civil

infrastructure sectors. Owing to it modular architecture and top-down modeling

approach, the ontological model can be extended to address specific sector/s in any

required level of detail.

2. Creating traffic incident management ontology: the developed ontology models

incident response agencies organizational integration elements using shared

terminologies and concepts, thoroughly defining binding and constraining relations

between these concepts.

3. Formally capturing the knowledge belonging to different response agencies: the

ontology formally captures the explicit knowledge pertaining to response policies

and procedures belonging to various response agencies; creating a consistent and

unique interpretation for those rules among various responders.

238

8.2.2 The Multi Agent System

1. Integrate various response agencies in traffic incident decision making process:

each responding agency is resembled with one or more software agents. Agents

work collaboratively to respond to traffic incidents, forming an ad-hoc framework

of collaborating response agencies. The agents infer the required response actions

using formally and constrained ontology axioms; each agent is responsible for

allocating, composing, and managing resources and services corresponding to

specific response process. The framework architecture adopts distributed

knowledge sharing paradigm to support collaborative decision making, replacing

the conventional centrally controlled paradigm.

2. Creating a prototype portal for distributed response resources and services sharing:

the response resources/services are implemented as Web Services; promoting

flexibility and modularity in the software system. Any service can replaced was

more recently developed or discovered one; allowing the system to handle changes

in its IT infrastructure with relative ease and at low cost.

3. Building ad-hoc framework of responding agencies: based on incident attributes,

responding agencies are invited to join or leave an ad-hoc framework of response

agencies. Such distributed environments is the true contribution of modern

informatics systems, where semantic software systems (ontology-based) help

establishing seamless flow of information and workflow synchronization. In

addition, it will link decision makers; establishing virtual teams that are based on

exchange of knowledge rather than just information.

8.3 CONCLUSIONS

One of the primary objectives of this research is to demonstrate how a formal ontology

for representing traffic incident management domain can be used to facilitate knowledge

representation, reuse and interoperability within the domain of traffic incident

management. The analysis, design, implementation, and evaluation of the ontology

support this objective in the following ways:

239

§ By building common, unified model for representing response agencies

organizational integration elements (products, processes, and actors) along with

incident response procedures best practices. This common model is used as the

underlying foundation for achieving knowledge interoperability and seamless flow of

data/information among various responding agencies.

§ Domain expert evaluations proved the ontology to be comprehensive and

representative to the main concepts pertaining to the traffic incident management

domain. Furthermore, it encompasses sufficient and essential concepts to describe

threat-vulnerability concepts associated with urban freeway networks and identify

root causes underlying incidents that may occur on them.

Subsequently, this research demonstrated that an ontology (as a flexible model of

knowledge) can serve as the core component of traffic incident management knowledge-

based decision support systems. In addition to serving as common framework for

information interoperability; ontology knowledge-based systems can support

collaborative decision-making processes as well. This was demonstrated through the

multi agent software system built on top of the ontology to provide decision support to

the human operators belonging to various response agencies.

The main objective of this research was not to create an ontology that captures in-

depth the traffic incident management domain. But rather to build a comprehensive

ontology and demonstrate how it can be used to support the creation of collaborative

decision support software systems. Hence, the developed ontology can be fairly judged

on the ‘breadth’ rather than ‘in-depth’ of capture of the traffic incident management

domain. Such approach was supported by the following facts:

§ The developed ontology is the first of its kind in the traffic incident management

domain. The lack of comparable ontologies in the domain should attest to the value of

this ‘first-cut’. It is intended for the developed ontology to act as a ‘first-step’ towards

creating more in-depth set of ontologies that fully captures the domain.

§ The domain of traffic incident management is huge. Creating an extensive, in-depth

ontology for this domain would be a large undertaking for any single research project.

240

§ Ontologies are inherently evolving in nature. The ontologies presented in this research

are by no means the ‘for-all’ and ‘end-all’ within the domain of traffic incident

management.

8.4 RECOMMENDATIONS

This section discusses recommendations for future research work on ontology

development and the implementation of SWIMS system. These recommendations are

direct results from issues identified and raised during the course of this research, but were

beyond scope and could not be fully addressed due to the constrained time frame. These

issues are mentioned in the next subsections to demonstrate areas of future improvement

in the conducted research.

8.4.1 Recommendations Related to Ontology Development

In general, ontology development is an iterative process that goes through several cycles

of improvements to fine tune the ontology modeling of the targeted domain. Both of the

developed ontological model and domain ontology were evaluated within the context of

City of Toronto traffic and emergency operators. These two knowledge models should be

evaluated on broader terms, in order to collect more feedbacks that can be used as

reference for the next improvement iteration. This research presented the first-cut in the

ontologies development iterations, and other iterations are expected to follow to further

enhance the developed knowledge models.

The threat-vulnerability ontological model was developed with the objective of

extending it to address different civil infrastructure sectors and/or applications. In the

course of this research, it was used to define traffic incidents underlying causes and

required response processes. When extended to address different sectors and applications,

the ontological model can aid to identify cross-sector response measures using backward

reasoning. This is due to the fact that incident management ontologies belonging to

different infrastructure sectors will be sharing same root concepts. However, the validity

of such objective should be tested through extending the ontological model to address

other sectors and application as part of future work.

241

The domain ontology TIM-Onto could be extended to expand its level of

granularity and cover more concepts and relationships. The current version of TIM-Onto

fully covers at high-level all organizational integration elements pertaining to traffic

incident agencies (actors and roles), proactive and response processes and their associated

products. However, it is still needed to further cover additional concepts that are related

to traffic incident response resources. The resource concept is fully defined in DOCK (El-

Diraby, 2009) and was not adequately covered in the context of TIM-Onto.

The developed ontology has been evaluated using two qualitative techniques: self-

assessment and domain expert interviews. It’s coding structure and formulation was

tested using semantic reasoners that checked the ontology consistency and reclassified

concepts, if necessary. However, the ontology axioms and rules were not tested.

Checking ontology axioms and rules assures that the ontology fully captures the targeted

domain within the defined scope. Constructing formal competency questions in (First

Order Logic) FOL and conducting a formal validation is the approach suggested by

Gruninger & Fox (1995) in this regard. However, this approach requires fully defining

the ontology in FOL using a theorem prover. Although necessary, such task is tedious

and could not be carried out due to the constrained time frame but it is recommended as

part of the future work.

8.4.2 Recommendations Related to SWIMS

One of the main issues that were raised during the evaluation of SWIMS is the ability to

change the system design workflow and modify its rules. Which actor (agency) will get

the privilege to modify the system? Although the system was designed with collaborative

coordination in mind, allowing modifications in an unregulated manner may result in

undesired results and possible conflicts. Whoever will undertake this task must have

semantic coding competency along with thorough understanding of system workflow and

functionality. This matter was identified and decided to be left to involved stakeholders to

determine.

Another important suggestion was the ability to rate the existing response best

practice rules and identify criteria to promote good rules and eliminate poor ones.

242

Havinga rating system will be advantageous. However, criteria should be established to

differentiate the quality of rating votes, as it does not make sense to rate simply by

counting number of positive votes. Performance criteria should be established and the

rules should be rated against them. Accordingly, establishing the rating criteria and

technique was left as a matter of future research.

An important issue that was identified by the evaluators was the need to have

‘semantic process modeling tool’. Such tool would allow modifying the system

workflow, while still maintaining its underlying semantics. The development of such tool

can be undertaken in the course of separate research project, extending the work

developed by El-Gohary (2007) in semantic process modeling.

As mentioned earlier, SWIMS development philosophy is to act as an integration

platform rather than an optimization framework. It allows the incorporation of different

traffic management functions into the framework in a simple plug-and-play manner. The

currently incorporated functionalities act as a placeholder for more sophisticated ones

that should be added as part of future research. For example, there is a need to

incorporate SWIMS with more advanced and sophisticated traffic control algorithms.

SWIMS uses simple traffic control algorithms, ALINEA and WEBSTER for ramp

metering and signal control, respectively. These two applications serve as placeholders

and were incorporated in the system to demonstrate its capability to interact with legacy

traffic software systems. Incorporating and testing advanced traffic control algorithms

within SWIMS is a matter of future research.

Furthermore, SWIMS was tested using only one case scenario. Multiple testing

scenarios should be performed prior to the system deployment for real life use. An

important addition to SWIMS should be the ability to process natural language messages

from Web 2.0 applications (e.g. Twitter) in order to be able determine the occurrence of

traffic incidents from hash-tagged messages sent by travelers. Another aspect that should

be emphasized that SWIMS is designed as an integration framework for collaborative

multi-agency decision making. The incorporation of optimization tools (e.g. game theory)

that would further enhance the system performance should be thoroughly studied.

243

Finally, the system performance needs to be compared against real life incident

scenario. This was not done, because detailed incident logs that identify responders’

locations and number of response units dispatched to the incident scene is not recorded in

the City of Toronto. Accordingly, measuring the system temporal performance against

actual real life case was not feasible. However, it is highly advised to test the system

performance given the required data will be granted by the City of Toronto traffic and

emergency response agencies.

244

REFERENCES

1. Abbas, K. A. (2004). "Traffic safety assessment and development of predictive

models for accidents on rural roads in Egypt." Accident Analysis and Prevention,

36(2), 149-163.

2. Abdel-Aty, M.A., Chen, C.L. and Schott, J.R. (1998). “An assessment of the effect

of driver age on traffic accident involvement using log-linear models.” Accident

Analysis and Prevention, 30 6, 851–861.

3. Abdel-Aty, M., and Radwan, A. E. (2000). "Modeling traffic accident occurrence

and involvement." Accident Analysis and Prevention, 32(5), 633-642.

4. Abdel-Aty, M., and Abdelwahab, H. T. (2003). "Configuration Analysis of Two-

Vehicle Rear-End Crashes." National Research Council, 140-147.

5. Abdel-Aty, M., and Abdelwahab, H. T. (2000). "Exploring the relationship between

alcohol and the driver characteristics in motor vehicle accidents." Accident Analysis

and Prevention, 32(4), 473-482.

6. Al-Aidaroos, H., and Shuang-Hua Yang. (2005). "Using JADE for the development

of multi-agent systems." Measurement and Control, 38(10), 299-303.

7. Alberts, C., Dorofee A., Killcrece, G., Ruefle, R., Zajicek, M. (2004) Defining

Incident Management Processes for CSIRTs. Software Engineering Institute,

Carnegie Mellon University. Technical Report CMU/SEI-2004-TR-015 ESC-TR-

2004-015

8. Austroads (2007). "Improving Traffic Incident Management – Literature Review" .

AP-R296/07, Austroads, Sydney.

9. Bellifemine, F., and Poggi, A. (2004). "FIPA-compliant agent infrastructures."

Methodologies and Software Engineering for Agent Systems. The Agent-Oriented

Software Engineering Handbook, Kluwer Academic Publishers, Dordrecht,

Netherlands, 259-72.

10. Bellifemine, F., Poggi, A., and Rimassa, G. (2001). "Developing multi-agent

systems with a FIPA-compliant agent framework." Software Pract Exper, 31(2),

103-28.

245

11. Bellifemine, F. (1999). "FIPA-standards for agent technologies." CSELT Technical

Reports, 27(3), 391-401.

12. Bellifemine, F. L. (2007). Developing multi-agent systems with JADE. John Wiley,

Hoboken, NJ.

13. Berdica, K. (2002). "An introduction to road vulnerability: What has been done, is

done and should be done." Transp.Policy, 9(2), 117-127.

14. Bertsch, V., and Geldermann, J. (2008). "Preference elicitation and sensitivity

analysis in multicriteria group decision support for industrial risk and emergency

management." International Journal of Emergency Management, 5(1-2), 7-24.

15. Birkmann, J. (2006), Measuring vulnerability to natural hazards: towards disaster

resilient societies. United Nations University, New York.

16. Black, T. R. (1993). Evaluating social science research: an introduction. Sage

Publications. Chicago, USA.

17. Bohle, H.-G. (2001) “Vulnerability and Criticality: Perspectives from Social

Geography.” IHDP Update 2/2001, Newsletter of the International Human

Dimensions Program on Global Environmental Change: 1-7.

18. Caro, T. M., Shargel, J. A., and Stoner, C. J. (2000). "Frequency of medium-sized

mammal road kills in an agricultural landscape in California." Am.Midl.Nat.,

144(2), 362-369.

19. Castelfranchi, C. (1998). "Modelling social action for AI agents." Artif.Intell.,

103(1-2), 157-182.

20. Charles, P., Dunn, K, Fitzgerald, P., Peters, N. and Reardon, G. (2003).

"Establishing inter–agency regional incident management in Brisbane Australia."

10th World Congress and Exhibition on Intelligent Transport Systems and Services.

Paper 3045. Madrid, Spain.

21. Cuena, J., Hernandez, J., and Molina, M. (1996). "Knowledge oriented design of an

application for real time traffic management: the TRYS system." ECAI '96, Wiley,

Chichester, UK, 308-12.

246

22. Cuena, J., Hernandez, J., and Molina, M. (1995). "Knowledge-based models for

adaptive traffic management systems." Transportation Research Part C: Emerging

Technologies, 3(5), [d]311-337.

23. Chakrabarti, A., and Manimaran, G. (2002). "Internet infrastructure security: a

taxonomy." IEEE Network, 16(6), 13-21.

24. Chan, C. Y., Huang, B., Yan, X., and Richards, S. (2010). "Investigating effects of

asphalt pavement conditions on traffic accidents in Tennessee based on the

pavement management system (PMS)." Journal of Advanced Transportation, 44(3),

150-161

25. Chipman, M. L., MacGregor, C. G., Smiley, A. M., and Lee-Gosselin, M. (1992).

"Time vs. distance as measures of exposure in driving surveys." Accident Analysis

and Prevention, 24:6, 679 – 684.

26. Cooper, F. and Chapman, C. B. (1987) “Risk analysis for large projects-models,

methods and cases.” John Wiley, Hoboken, NJ.

27. Davenport, T.H. (1993). "Process innovation: reengineering work through

information technology." Harvard Business School Press, Boston, MA.

28. Dobis, D., and Prade, H. (1980). “Fuzzy sets and systems – theory and

applications.” Academic Press: Elsevier Science & Technology Books.

29. Dos, S. M., Fondazzi Martimiano, L.A., Dos, S. B., and Bernardes, M.C.

(2008)."Ontologies for information security management and governance."

Information Management and Computer Security, 16(2), 150-165.

30. Doumont, J. (2002). "Magical numbers: The seven-plus-or-minus-two myth." IEEE

Transactions on Professional Communication, 45(2), 123-127.

31. Edensor, T. (2004). "Automobility and national identity—representation, geography

and driving practice." Theor. Cult. Soc. 21 (2004), 101–120.

32. Edmunds, H. (1999). The Focus Group Research Handbook. NTC Business Books,

Chicago.

33. El-Diraby, T. E. (2009). “A domain ontology for construction.” submitted to

Journal of Construction and Management.

247

34. El-Diraby, T. E., and Briceno, F. (2005). “Taxonomy for outside plant construction

in telecommunication infrastructure: supporting knowledge-based virtual teaming.”

Journal of Infrastructure Systems, Vol. 11(2), 110-121.

35. El-Diraby, T. E., Lima, C., and Feis, B. (2005). “Domain taxonomy for construction

concepts: toward a formal ontology for construction knowledge.” Journal of

Computing in Civil Engineering, Vol. 19(4), 394–406.

36. El-Gohary, N. (2008). Semantic Process Modeling and Integration for Collaborative

Construction and Infrastructure Development. PhD Dissertation, Department of

Civil Engineering, University of Toronto.

37. Evans, L. (1991). "Older-driver risks to themselves and to other road users".

Transportation Research Record, 1325.

38. Fabiano, P. M., Lederman, L.C. (2002). "Top ten mispercetions of focus group

research." Working paper#3: the report on social norms, PaperClip

Communincations.

39. Factor, R., Mahalel, D., and Yair, G. (2007). "The social accident: A theoretical

model and a research agenda for studying the influence of social and cultural

characteristics on motor vehicle accidents." Accident Analysis and Prevention,

39(5), 914-921.

40. Fensel, D. (2002). "Ontology-based knowledge management." Computer, 35(11),

56-9.

41. Fernandez-Lopez, M., and Gomez-Perez, A. (2002). "Overview and analysis of

methodologies for building ontologies." Knowledge Engineering Review, 17(2),

129-56.

42. FHWA (2010). "Traffic Incident Management Handbook. Prepared for US Federal

Highway Administration Office of Travel Management." FHWA

43. Finin, T., and Joshi, A. (2002). "Agents, trust, and information access on the

semantic web." SIGMOD Record, 31(4), 30-5.

44. Garber, N. J. and Srinivasan, R. (1991). "Characteristics of accidents involving

elderly drivers at intersections." Transportation Research Record 1325, 8–16

248

45. Gaygisiz, E. (2010). "Cultural values and governance quality as correlates of road

traffic fatalities: A nation level analysis." Accident Analysis and Prevention, 42(6),

1894-1901.

46. Genesereth, M. R., and Ketchpel, S. P. (1994). "Software agents." Commun ACM,

37(7), 48-53.

47. Gheorghe, A.V., Masera M., Weijnen, M., and De Vries, L. Critical infrastructures

at risk: securing the European electric power system. Springer, Great Britain.

48. Giorgini, P., Kolp, M., Mylopoulos, J., and Pistore, M. (2004). "The Tropos

methodology: an overview." Methodologies and Software Engineering for Agent

Systems. The Agent-Oriented Software Engineering Handbook, Kluwer Academic

Publishers, Dordrecht, Netherlands, 89-106.

49. Giuffrida, L. O. (1985). "FEMA information systems: key to effective emergency

management." Signal, 39(9), 147-56.

50. Gómez-Pérez, A., Fernández-López, M., and Corcho, O. (2007). “Ontological

engineering: what are ontologies and how can we build them?” in J. Cardoso (ed.)

Semantic Web Services: Theory, Tools and Applications, IGI Global, Hershey, PA.

51. Gómez-Pérez, A. (2004). Ontological engineering : with examples from the areas

of knowledge management, e-commerce and the semantic Web / Asunción Gómez-

Pérez, Mariano Fernández-López, and Oscar Corcho. Springer-Verlag, New York.

52. Gómez-Pérez, A. (2001). “Evaluation of ontologies.” International Journal of

Intelligent Systems, Vol. 16(3), pp. 391-409.

53. Gómez-Pérez, A. (1994) “Some ideas and examples to evaluate ontologies”,

Stanford University, Knowledge Systems Laboratory. Accessed: July 23, 2008.

http://www-ksl.stanford.edu/KSL_Abstracts/KSL-94-65.html

54. Gorman, S. P., Schintler, L., Kulkarni, R., and Stough, R. (2004). "The revenge of

distance: Vulnerability analysis of critical information infrastructure."

J.Contingencies Crisis Manage., 12(2), 48-63.

http://www-ksl.stanford.edu/KSL_Abstracts/KSL-94-65.html

249

55. Gruninger, M. Integrated Ontologies for Enterprise Modelling. In International

Conference on Enterprise Integration and Modeling Technology. Springer-Veralg,

Berlin, Germany, 1997, pp. 368-77.

56. Grüninger, M. and Fox, M. S. (1995). “Methodology for the design and evaluation

of ontologies.” In D. Skuce (ed.), IJCAI95 Workshop on Basic Ontological Issues in

Knowledge Sharing, 6.1-6.10.

57. Guidi, A., and Marty, B. (1987). "Forecasting earthquakes in Japan." Recherche,

18(184), 124-35.

58. Gupta, M. and Yamakawa, T. (1988) “Fuzzy logic in knowledge-based systems,

decisions and control.” North-Holland Publ.

59. Hadi, M. A., Aruldhas, J., Chow, L., and Wattleworth, J. A. (1995). "Estimating

safety effects of cross-section design for various highway types using negative

binomial regression." Transportation Research Record, (1500), 169-177.

60. Hall, R.W. (2001). Incident Management: Process Analysis and Improvement.

California PATH Research project UCB-ITS-PRR-2001-41. University of Southern

California, Los Angeles.

61. Horridge, M., Knublauch, H., Rector, A., Stevens, R. and Wroe, C. (2004) A

PracticalGuide to Building OWL Ontologies Using the Protégé-OWL Plugin and

CO-OED Tools. The University of Manchester.

62. Herd, D. R., Agent, K. R., and Rizenbergs, R. L. (1980). "Traffic Accidents: Day

Versus Night." Transportation Research Record, (753), 25-30.

63. Hernandez, J. Z., Ossowski, S., and Garcia-Serrano, A. (2002). "Multiagent

architectures for intelligent traffic management systems." Transportation Research

Part C: Emerging Technologies, 10(5-6), 473-506.

64. Holmgren, A. J., Jenelius, E., and Westin, J. (2007). "Evaluating strategies for

defending electric power networks against antagonistic attacks." IEEE Trans.Power

Syst., 22(1), 76-84.

250

65. Holmgren, A. J., and Molin, S. (2006). "Using disturbance data to assess

vulnerability of electric power delivery systems." Journal of Infrastruct Systems,

12(4), 243-251.

66. Hsu, Y. T., and Fu, C. C. (2000). "Study of damaged Wushi Bridge in Taiwan

earthquake." Pract.Periodical Struct.Des.Constr., 5(4), 166-171.

67. Hu, X., and Shen, X. (2009). "Mining biomedical literature to identify viruses and

bacteria as potential bioterrorism weapons." IEEE Intelligent Systems, 24(6), 73-77.

68. Jenelius, E., Petersen, T., and Mattsson, L. (2006). "Importance and exposure in

road network vulnerability analysis." Transportation Research Part A: Policy and

Practice, 40(7), 537-560.

69. Kalpic, B., and P. Bernus. Business Process Modelling in Industry - the Powerful

Tool in Enterprise Management. Computers in Industry, Vol. 47, No. 3, 2002, pp.

299-318.

70. Karlaftis, M. G., and Golias, I. (2002). "Effects of road geometry and traffic

volumes on rural roadway accident rates." Accident Analysis and Prevention, 34(3),

357-365.

71. Kontio, J., Lehtola, L., and Bragge, J. (2004). “Using the focus group method in

software engineering: obtaining practitioner and user experiences.” Proceedings of

the 2004 International Symposium on Empirical Software Engineering (ISESE’04),

Los Angles, California, USA, 271-280.

72. Kim, H. (2002). "Predicting how Ontologies for the Semantic Web Will Evolve.

Communications of the ACM, Vol. 45, No. 2, 48-54.

73. Kim, K., Nitz, L., Richardson, J. and Li, L. (1995). "Personal and behavioral

predictors of automobile crash and injury severity." Accident Analysis and

Prevention 27(4), 469–481.

74. Landwehr, C. E., Bull, A. R., McDermott, J. P., and Choi, W. S. (1994). "A

taxonomy of computer program security flaws." ACM Computing Surveys, 26(3),

211-54.

251

75. Lao, Y., Wu, Y., Corey, J., and Wang, Y. (2011). "Modeling animal-vehicle

collisions using diagonal inflated bivariate Poisson regression." Accident Analysis

and Prevention, 43(1), 220-227.

76. Li, D. and Liu, D. (1990) “A fuzzy PROLOG database system.” John Wiley,

Hoboken, NJ.

77. Logi, F., and Ritchie, S. G. (2002). "A multi-agent architecture for cooperative

inter-jurisdictional traffic congestion management." Transportation Research Part

C (Emerging Technologies), 10C(5-6), 507-27.

78. Lootsma, F. A. (1980). "Saaty's priority theory and the nomination of a senior

professor in operations research." European Journal of Operation Research, 4(6),

380-8.

79. Luiijf, E. A. M., and Klaver, M. H. A. (2006). "Protection of the Dutch critical

infrastructures." International Journal of Critical Infrastructures, 2(2-3), 201-214.

80. Lukasik, S. J. (2003). "Protecting critical infrastructures against cyber-attack."

Oxford University Press for the International Institute for Strategic Studies, New

York.

81. Macaulay, T. (2009). "Critical infrastructure: understanding its component parts,

vulnerabilities, operating risks, and interdependencies." CRC Press, Boca Raton,

FL.

82. Matthews, M. L. and Moran, A. R. (1986). "Age differences in male drivers'

perception of accident risk: the role of perceived driving ability." Accident Analysis

and Prevention 18 (4), 299–311

83. McFarlane, D., Marik, V., and Valckenaers, P. (2005). "Intelligent control in the

manufacturing supply chain." IEEE Intelligent Systems, 20(1), 24-26.

84. Mcguinness, D. L., Fikes, R., Hendler, J., and Stein, L. A. (2002). "DAML+OIL: an

ontology language for the Semantic Web." IEEE Intelligent Systems, 17(5), 72-80.

85. McGwin, G. J., and Brown, D. B. (1999). "Characteristics of traffic crashes among

young, middle-aged, and older drivers." Accident Analysis and Prevention, 31(3),

181-198.

252

86. Morse, S. (2004). "Indices and Indicators in Development: An Unhealthy Obsession

with Numbers", London: Earthscan.

87. Ng, K., Hung, W., and Wong, W. (2002). "An algorithm for assessing the risk of

traffic accident." Journal of Safety Research, 33(3), 387-410.

88. Noy, N. F. and D. L. McGuinness. (2002) “Ontology development 101: A guide to

creating your first ontology”, Knowledge System Laboratory, Stanford.

89. Noy, N. F., Fergerson, R. W., and Musen, M. A. (2000) “The knowledge model of

Protege-2000: Combining interoperability and flexibility.” In R. Dieng and O.

Corby (eds.), 12th International Conference in Knowledge Engineering and

Knowledge Management (EKAW'00), Berlin: Springer-Verlag.

90. Osman, H. (2007). A knowledge-enabled system for routing urban utility

infrastructure. PhD Dissertation, Department of Civil Engineering, University of

Toronto.

91. Ossowski, S., Hernandez, J. Z., Belmonte, M. V., Maseda, J., Fernandez, A.,

Garcia-Serrano, A., Triguero, F., Serrano, J. M., and Perez-De-La-Cruz, J. L.

(2004a). "Multi-agent systems for decision support: a case study in the

transportation management domain." Appl.Artif.Intell., 18(9-10), 779-95.

92. Ossowski, S., Hernandez, J. Z., Belmonte, M. V., Maseda, J., Fernandez, A.,

Garcia-Serrano, A., Triguero, F., Serrano, J. M., and Perez-De-La-Cruz, J. L.

(2004b). "Multi-agent systems for decision support: A case study in the

transportation management domain." Appl.Artif.Intell., 18(9-10), 779-795.

93. Ossowski, S., Hernandez, J. Z., Belmonte, M., Fernandez, A., Garcia-Serrano, A.,

Perez-de-la-Cruz, J., Serrano, J., and Triguero, F. (2005). "Decision support for

traffic management based on organisational and communicative multiagent

abstractions." Transportation Research Part C: Emerging Technologies, 13(4),

272-298.

94. Ozbay, K. (1999). Incident management in intelligent transportation systems.

Artech House, Boston.

253

95. Pfleeger, S. L., Predd, J. B., Hunker, J., and Bulford, C. (2010). "Insiders behaving

badly: Addressing bad actors and their actions." IEEE Transactions on Information

Forensics and Security, 5(1), 169-179.

96. Pitt, J., and Mamdani, A. (1999). "Some remarks on the semantics of FIPA's agent

communication language." Auton.Agents Multi-Agent Syst., 2(4), 333-56.

97. Rao, A. S., and Georgeff, M. P. (1991). "Embedded multi-agent and distributed

reasoning research at the Australian Artificial Intelligence Institute." AISB

Quarterly, (76), 25-7.

98. Rengarasu, T. M., Hagiwara, T., and Hirasawa, M. (2009). "Effects of road

geometry and cross-section variables on traffic accidents." Transportation Research

Record, (2102), 34-42.

99. Richardson, J., Kim, K., Li, L. and Nitz, L. (1996). "Patterns of motor vehicle crash

involvement by driver age and sex in Hawaii." Journal of Safety Research 27 (2),

117–125

100. Rindt, C. R., McNally, M.G (2007). Field Deployment and Operational Test of an

Agent-based, Multi-Jurisdictional Traffic Management System. California PATH

Working Paper, UCB-ITS-PWP-2007-1

101. Rizenbergs, R. L., Burchett, J. L., and Warren, L. A. (1977). "Relation of Accidents

and Pavement Friction on Rural, Two-Lane Roads." Transportation Research

Records, (633), 21-27.

102. Rowden, P., Steinhardt, D., and Sheehan, M. (2008). "Road crashes involving

animals in Australia." Accident Analysis and Prevention, 40(6), 1865-1871.

103. Stamatiadis, N., Taylor, W. C. and Mckelvey, F. X. (1991). "Older drivers and

intersection traffic control device." Journal of Transportation Engineering 117 (3),

311–31

104. Stanford, G.W. (1985). "Auto traffic in Egypt as a verdant grammar." Social

Psychol. Quart. 48 (1985), 337–348.

105. Saaty, T. L., and Ozdemir, M. S. (2003). "Why the magic number seven plus or

minus two." Math.Comput.Model., 38(3-4), 233-44.

254

106. Saaty, T. L. (1982). The logic of priorities: applications in business, energy, health,

and transportation. Hingham, Mass.

107. Sawalha, Z., Sayed, T. (2001) “Evaluating the Safety of Urban Arterial Roadways”,

Journal of Transportation Engineering, ASCE, Vol. 127(2), 151-158.

108. Sayed, T., Abdelwahab, W., and Navin, F., (1995) “Identifying Accident Prone

Locations Using Fuzzy Pattern Recognition”, Journal of Transportation

Engineering, ASCE, Vol. 121(4).

109. Social Issues Research Centre. (2004). Sex differences in driving and insurance

risk. An analysis of the social and psychological differences between men and

women that are relevant to their driving behaviour. The Social Issues Research

Centre, Oxford England.

110. Steffy, J. (1994). "Accessing industrial fire and explosion information in the CA

files on STN." Elsevier Science Publishers B.V, Amsterdam, Netherlands, 165-176.

111. Sycara, K., Norman, T. J., Giampapa, J. A., Kollingbaum, M. J., Burnett, C.,

Masato, D., McCallum, M., and Strub, M. H. (2010). "Agent Support for Policy-

Driven Collaborative Mission Planning." Comput.J., 53(5), 528-40.

112. Tavris, D. R., Kuhn, E. M., and Layde, P. M. (2001). "Age and gender patterns in

motor vehicle crash injuries: Importance of type of crash and occupant role."

Accident Analysis and Prevention, 33(2), 167-172.

113. Taylor, M. A. P. (2008). "Critical transport infrastructure in urban areas: Impacts of

traffic incidents assessed using accessibility-based network vulnerability analysis."

Growth Change, 39(4), 593-616.

114. Trochim, W. (2001). The research methods knowledge base, 2nd edition, Atomic

Dog Publishing, Cincinnati, Ohio, USA

115. Tsoumas, B., Dritsas, S., and Gritzalis, D. (2005). "An ontology-based approach to

information systems security management." Proceedings, Springer-Verlag, Berlin,

Germany, 151-64.

255

116. Tweedale, J., Ichalkaranje, N., Sioutis, C., Jarvis, B., Consoli, A., and Phillips-

Wren, G. (2007). "Innovations in multi-agent systems." Journal of Network and

Computer Applications, 30(3), 1089-1115.

117. Uschold, M., and Gruninger, M. (2004). "Ontologies and semantics for seamless

connectivity." Association for Computing Machinery, 58-64.

118. Uschold, M., and Gruninger, M. (1996). "Ontologies: principles, methods and

applications." Knowl.Engineering Review, 11(2), 93-136.

119. Uschold, M. and King, M. (1995) “Towards a methodology for building

ontologies.” In D. Skuce (ed.), IJCAI'95 Workshop on Basic Ontological Issues in

Knowledge Sharing, 6.1-6.10.

120. Vidal, J. M., Buhler, P. A., and Huhns, M. N. (2001). "Inside an agent." IEEE

Internet Comput., 5(1), 82-86.

121. Washington Department of Transportation. (1998). Seismic Zonation for Highway

Bridge Design. Report WA-RD 172.1, WA USA.

122. Wisner, B.P. Blaikie, T. Cannon and I. Davis (2004). “At Risk: Natural hazards,

Peoples’Vulnerability, and Disasters.” 2nd Edition, London: Routledge.

123. Zipkes, E., 1976, "The Influence of Grooving of Road Pavement on Accident

Frequency," TRRL Report LR623.

124. Zhang, J. (2010). A Social Semantic Web System for Coordinating

Communication in the Architecture, Engineering and Construction Industry. PhD

Dissertation, Department of Civil Engineering, University of Toronto.

125. Zhang, H., and Ritchie, S. G. (1994). "Real-time decision-support system for

freeway management and control." J.Comput.Civ.Eng., 8(1), 35-51.

126. Zografos, K. G., Androutsopoulos, K. N., and Vasilakis, G. M. (2002). "A real-time

decision support system for roadway network incident response logistics."

Transportation Research Part C (Emerging Technologies), 10C(1), 1-18.

256

APPENDIX A

OVERVIEW OF ONTOLOGIES AND SOFTWARE AGENT

TECHNOLOGIES

A.1 Ontology The origin of ontologies in computer science goes back to 1991, in the context of the

Defense Advanced Research Projects Agency (DARPA) Knowledge Sharing Effort

(Mcguinness et al., 2002). The aim of this project was to devise new ways of constructing

new knowledge-based systems from reusable knowledge components rather than starting

from scratch. These components are modeled by mean of ontologies, which represent

reusable and sharable pieces of domain knowledge. Ontologies are now considered as

commodity that is used for the development of large number of applications in different

fields, such as knowledge management, natural language processing, e-commerce,

information integration and retrieval, database design and integration, bio-informatics,

education, and so forth.

The use of ontologies in knowledge engineering, natural language processing and

knowledge representation began in the 1990s and has since extended into intelligent

information integration, co-operative information systems, information retrieval,

electronic commerce and knowledge management. In practise, ontology provides a

shared and common understanding of a domain that can be communicated between

people and heterogeneous and widely spread application systems (Fensel, 2002).

Ontology represents the knowledge of a certain domain by defining a set of

representational terms (concepts) in declarative formalism, providing a mechanism to

categorize these terms into inter-related concepts (taxonomies) and describable

relationships. It structures those terms into taxonomic hierarchies of concepts and uses a

defined set of axioms to constrains the model interpretation and assure well-formed use.

All of this is done through using the representational vocabulary to represent system

domain knowledge. In brief, ontology builds a semantic model of a certain domain

formed of concepts, concepts hierarchies, taxonomic and non-taxonomic relations; using

axioms that constrain the model behaviour and provide domain reasoning capabilities.

257

Ontology development may be motivated by various objectives, the complexity and the

extent of the developed ontology is based on the expected usage; some of which may be

(Gómez-Pérez, 2004):

§ Standardization of terminology, meaning of concepts, components of target objects

and tasks in a certain domain. Thus creating shared common understanding of the

structure of information among people or software agents; allowing them to

communicate more effectively relying on their common access and same

understanding of underlying semantics.

§ The taxonomic concepts, their interrelationships, and the ontology axioms enable

software reasoners to draw logical conclusions based on the ontological model,

extracting new knowledge from exiting one as well as to proof and trace the steps

involved in their logical reasoning.

§ Providing interoperability among databases and software systems even if they have

schematic or syntactic heterogeneity, through achieving an agreement on the

semantics of their elements.

§ Increase databases query efficiency by capturing the semantics of the query and

mapping it to the semantically equivalent concepts in the database structures.

Ontology Hierarchy

Ontologies are created in a layered architecture, where more specific extends concepts

from the more general ontologies. In this regard ontologies can be classified into three

main levels, depending on their knowledge use point of view (Gómez-Pérez, 2004):

1. Fundamental/Top Ontologies: they include the primitive concepts that are common

among all domains of knowledge, e.g. Cyc and SUMO ontology.

2. Domain Ontologies: They extend the core concepts defined in Fundamental

Ontologies to define new concepts and relationships addressing a specific domain of

knowledge, e.g. DOCK ontology for construction domain (El-Diraby, 2009).

3. Application Ontologies: They build on the concepts defined at the domain level but

are intended for use in a particular use-case scenario. Examples of application

ontologies related to transportation could include ontologies in the fields of highway

geometric design, regional transportation planning, and traffic incident management.

258

Methodologies for Building Ontologies

Research initiatives that focused on methodologies or methods for building ontologies

started in the early 1990’s. As a result of this research work various methodologies for

ontology development were produced. However, a common agreement between the

authors of those methodologies that there is no single correct way and the process of

ontology development is usually iterative (Fernandez-Lopez and Gomez-Perez, 2002).

This section briefly summarizes the most prominent methodologies for ontology

development.

Uschold and King Methodology

This methodology evolved based on the experience gained in developing the

Enterprise Ontology, ontology for enterprise modeling processes. The guidelines of

the methodology as defined by the authors are:

1. Identify purpose and scope and intended use of the developed ontology.

2. Build the ontology using the following three steps:

§ Ontology Capture: includes identifying core concepts and relationships in the

domain of interest then clearly define those concepts and identify terms to

refer to such concepts and relationships.

§ Ontology Coding: refers to coding the knowledge acquired in the previous

step using a formal language.

§ Ontology Integration: decide upon whether to extend existing ontologies in

the newly developed one.

3. Evaluate the ontology with respect of pre-defined requirements, pre-defined

competency questions, and/or real world. Competency questions are a set of

requirements that are defined in a form of questions, which the ontology should

be able to answer.

4. Document the ontology.

Gruninger and Fox Methodology

This methodology is based on the experience in developing the Toronto Virtual

Enterprise (TOVE) project within the domain of business processes and activities

modeling. It builds a logical model of the knowledge that is specified by the ontology

(Gómez-Pérez, 2004). This model is first constructed by informal description of the

259

specifications to be met by the ontology and the formalizing this description. The

steps as outlined by the authors are as follows:

1. Capture of motivating scenarios: the development of ontologies is motivated by

scenarios that arise in the application. The motivating scenarios narrates a case

problem, specify objective outcomes and justification of using ontologies. The

motivating scenario must justify the development of new ontology, i.e. prove that

no other ontology in the literature can adequately address this problem. In

addition, it should describe the intended solutions of problems presented in the

scenarios.

2. Formulation of informal competency questions: these questions are formulated

based on the scenarios obtained in the first step, expressing the case problem

solution requirements. The ontology must be able to represent these questions

using its terminology, and be able to characterize the answers to these questions

using the axioms and definitions. Competency questions evaluate the ontological

commitments that have been made to see whether the ontology meets the

requirements.

3. Formal specification of the ontology terminologies: this step includes the

following:

§ Getting informal terminology involves extracting terms that will be used in the

ontology from the informal competency questions; which will be later defined

formally.

§ Specification of formal terminology; formally define the ontology

terminologies. The interpretation of these terminologies will later be

constrained using axioms.

4. Formulation of formal competency questions: using the formal terminology

from the previous step, the competency questions are defined using a formal

language.

5. Defining Ontology Axioms using formal language: axioms define and constrain

the interpretation of the ontology concepts and relationships; assuring that no term

is having double interpretations. Axioms provide the semantics and meanings of

260

ontology terms. They must be capable of answering all of the ontology defined

competency questions.

6. Assure the ontological model completeness, once the competency questions

have been formally stated, the conditions under which the solutions to the

questions are complete must be defined.

Noy and McGuinness Methodology

This is not a formal method of ontology development, but rather guidelines developed

from the authors experience, it includes the following steps (Gómez-Pérez, 2004):

1. Determine the domain and scope of the ontology, use competency questions as a

mean to determine the scope.

2. Consider extending existing ontologies.

3. List the core terms that should be included in the ontology

4. Define the ontology taxonomy.

5. Define the properties of the taxonomy concepts, value type, and cardinalities

6. Create ontology instances.

Ontology in Agents Communication

FIPA defines agents’ ontologies as: “common vocabulary of agreed upon definitions and

relationships between those to describe a particular subject domain” (Bellifemine et al.,

2001). FIPA compliant software agents communicate using communication ontology

formed of standard speech acts and interaction protocols, Figure A-1. In order to

efficiently communicate agents must also share an ontology of their domain; formed of

the terminology that they use to describe this domain. In an open environment, agents are

designed around various ontologies, either implicit or explicit, although explicit

ontologies, together with a standard mechanism for accessing them and referring to them,

are necessary in order to allow communication (Bellifemine et al., 2001).

261

Figure A-1: Agent Ontology-Based Communication Model

A.2 SOFTWARE AGENTS TECHNOLOGY

Agent-based technologies have emerges from a convergence of distributed object and

artificial intelligence systems. Software agents are seen as autonomous computational

entities capable of effective problem solving and operating in dynamically open

environment (Bellifemine, 2007). The full potential of software agents becomes evident

when several agents are deployed together in the same environment forming Multi-Agent

System (MAS) (Hernandez, 2002). MAS Agents interact together in cooperative or

competitive manner to achieve set of defined goals and objectives.

This thesis approached agent taxonomy according to the approach defined in to

define agents based on their task, i.e. task-specific agents. Thus from the author

perspective agents are not seen as ‘intelligent’ but rather a task-oriented entities that

behave in response of stimulus from surrounding environment based on pre-defined

internal rules. The four main characteristics possessed by a software agent are:

§ Autonomous: operate without direct human intervention of human and have some

kind of control over actions and internal state based on predefined rules or

implemented algorithms (Castelfranchi, 1998).

§ Social: capable of addressing versatile problems through interact with other agents or

humans via some predefined agent-communication language (Genesereth and

Ketchpel, 1994).

262

§ Reactive: perceive the surrounding environment; perform action/s in response using

its effectors, in a timely manner. Agents senses surrounding environment via

graphical user interface inputs, receive of an input message from other agent/s, and

change is system certain state or condition. An agent effector can be as simple as

sending a message or performing set of defined computational tasks. Figure-x

represents a simple agent-environment interaction (Vidal et al., 2001).

§ Proactive: do not simply act in response to their environment, but are able to exhibit

goal-directed behavior by taking initiatives.

Characteristics of Agent-based Solutions

Agent technology is suitable for solving problems in complex, open and reactive systems,

where the structure of the system is capable of dynamic change. An example of open

systems is the internet, where the software system must be able to operate autonomously.

Complex software systems require modularity and abstraction. Agents solve complex

problems by partitioning them into subcomponents handled individually by interacting

agents. They are suitable for problems where data, control, expertise or resources are

distributed and need to interact with one another in order to solve the problem (Finin and

Joshi, 2002).

MAS are also capable of integrating legacy software systems either by directly

interacting with them or by creating wrapper/transducer agent (Genesereth and Ketchpel,

1994). In addition, agent-based systems are robust since there is no central element and

no central decision making, i.e. the loss of one entity does not cause the system to

completely fail. They can be easily reconfigured by changing, adding or removing

hardware/software modules, i.e. they support plug and play approach. Interoperability is

another important characteristic; as long as agents exchange messages that follow

standard structure and commit to specific shared ontology, agents belonging to

heterogenic software systems can understand and reason seamlessly (Bellifemine, 2007).

263

Types of Software Agents Architecture

Agent architecture can be divided into one of the three main groups (Rao and Georgeff,

1991):

§ Logic-based: draw their foundation from traditional knowledge base system, in which

the surrounding environment is symbolically represented and manipulated using

reasoning mechanisms.

§ Reactive: maps stimuli from the surrounding environment into response mechanisms.

This architecture defines finite state machine that receive real time data from the

surrounding environment and react using goal-directed behavior. The advantage of

this architecture is that it reacts faster to dynamic environment and simpler to design

than logic-based models. However, the fact that reactive agents do not possess a

model of their environment makes the agent unable to learn from experience, the

agent prone to failure when perceived with undefined condition.

§ Belief-Desire-Intention (BDI): is based on four key data structures: beliefs, desires,

intentions, plans, and an interpreter. Beliefs represent the information an agent has

about its environment; desires are the complete set of tasks allocated to the agent, i.e.

objectives and goals. Intentions represent the specific desires that the agent has

committed to achieving based on surrounding environment status, while plans specify

the course/s of action followed by the agent to achieve its intentions/objectives. Those

four data structures are managed by the agent interpreter, which is responsible for

updating beliefs from environment stimulus, generating new desires from updated

beliefs, and selection subset of desires to act as intentions. Finally, the interpreter

selects an action to perform on the basis of the agent current intentions and procedural

knowledge.

264

Agents Communications

The primary importance of software agents lies in their ability to communicate and to

share knowledge (Finin and Joshi, 2002). Agents need to be able to communicate with

users, system resources, and each other to coordinate their decisions/actions. The

Foundation of Intelligent Physical Agents (FIPA) supports a set of standards for message

communication between interacting agents, expressed using special communication

languages, Agent Communication Languages (ACL), the most common of which is the

FIPA ACL (Bellifemine and Poggi, 2004). FIPA was founded in 2003 to provide a set

of universally accepted standards that defines agent interaction protocols, supporting

interoperability between different systems (Bellifemine et al., 2001). The payload or

content of FIPA ACL is formed of common terms and vocabularies representing

concepts describing a system belonging to a certain domain and referenced to domain-

specific conceptual model (ontology). A major advantage of using such terms as the

message content is that the agents will be interacting in a human readable format, i.e.

better understanding of their resulting actions/decisions by operators. In addition, other

MAS can be integrated or interact with the system by committing to the same conceptual

model.

Table A-1: FIPA-ACL Message Structure Primitives (Bellifemine, 2007)

Primitive Description

- communicative act - sender - receiver - reply-to - content - language - ontology - interaction protocol

- conversation-id - reply-with

- in-reply-to - reply-by

- Type of the communicative act of the message - Identity message sender agent - Identity of intended recipient agent/s of the message - Which agent to direct subsequent messages to within a

conversation thread - This slot holds the message content - The semantic language expressing the message content, e.g.

KIF, OWL …etc. - Reference to an ontology to give meaning to symbols in the

message content - Interaction protocol used to structure the conversation

sequence - Unique identity of a conversation thread, e.g. Incident-Alert - An expression to be used by a responding agent to identify

the message - Reference to an earlier action to which the message is a

reply - A time/date indicating by when a reply should be received

265

In FIPA-ACL, the most important primitive is the communicative acts; which represent

the purpose of the message, i.e. inform, refuse, propose, accept…etc. One of the major

advantages of this primitive is the possibility to specify predefined sequences of

messages which can be applied in several situations that share the same communication

pattern regardless of the application domain. Such sequences of messages are known as

Interaction Protocols. Examples of widely used Interaction Protocols are: Contract-Net,

Publish-Subscribe, Inform ...etc. Communicative acts are usually defined in terms a BDI

model, comprising beliefs (what the agent knows), desires (what the agent wants) and

intentions (what the agent is doing).

The actual information that is transferred from the sender to the receivers of an

ACL message is included in the content slot of the message. In order to parse and

understand the contents of exchanged messages, the concepts and symbols (i.e. the

semantics) forming the message content must follow a well-defined syntax. This syntax

is referred to as content language; KIF, SL, RDF and OWL are examples of language

used to express messages content (Bellifemine et al., 2001). In addition to the before

mentioned, all agents in the MAS must have the same shared understanding of the

concepts and symbols forming the language syntax. The set of concepts and the symbols

used to express the content language is known as ontology. In agent-based applications a

common ontology defines the vocabulary and associated relationships that the agents use

to interact with each other and reason about the domain of interest. Finally, exchanged

messages are transported using standard transfer protocols such as SMTP, TCP/IP, IIOP

or HTTP (Bellifemine et al., 2001).

Software Agents Development Tools

Agent-based systems require a significant infrastructure, as they provide several layers of

functionality. Therefore, MAS are usually developed and deployed using specialized

toolkits that provide basing building block to support agent-based systems. A brief

description is given in this section for three MAS development toolkits that were

considered for this thesis, which were: JACK, JADE and Zeus. However the final

decision was in favour of JADE development toolkit.

266

1. JACK Intelligent Agents: developed by the University of Melbourne-Australia, is

an environment for building, running and integrating commercial-grade multi-agent

systems using a component-based approach. It has its own agent language that

extends Java with agent-oriented concepts such as agents, capabilities, events, plans,

agent knowledge bases, and resource and concurrency management. When

developing an agent solution with JACK, users need only to select the required

components from the JACK component library, which contains the following

components: run time environment, compiler, BDI agent model, simple team model,

development environment, agent debugger and the object modelling framework. The

editors allow developers to define agents, capabilities, plans, events and agent

databases, in addition to which the object modeller provides facilities for integrating

with other processes or existing applications, including support for inter-process data

transport based on object-oriented data modelling. JACK provides libraries to support

this inter-process connectivity in Java and C++. JACK is a commercial product but is

free for evaluation purposes (Tweedale et al., 2007).

2. JADE (Java Agent DEvelopment Framework): developed by Telecom Italia Lab.

It provides the implementation of multi-agent systems using a software middleware

in compliance with FIPA and set of tools that uses debugging and deployment. The

MAS paradigm is distributable across multiple machines (i.e. platform dependent).

The middleware is equipped with a Graphical User Interface (GUI) which allows

MAS remote control and configuration. The configuration can even be changed

during run time by moving agents from one machine to another one as and when

required. JADE is implemented completely in the Java. In addition, JADE is

integrated with LEAP, which a Java based lightweight agent middleware for small

handheld computer devices such as PDAs and smartphones (Bellifemine, 2007).

3. ZEUS Toolkit: developed by British Telecom Intelligent Systems Group. It is based

on the visual programming paradigm and supports an open design to assure

extensibility. It consists of a set of libraries written in Java and composed of: agent

component library, agent building tool and a suite of utility agents comprising name

server, facilitator and visualizer agents. The agent component library enable the

construction of application independent generic ZEUS agent that can be customized

267

for specific applications by imbuing it with problem-specific resources, competences,

information, organizational relationships and co-ordination protocols (Tweedale et

al., 2007).

There are significant differences between different agent development toolkits, and there

are no standard and clear measures for the suitability of one approach on the other. Those

tools are under continuous developments and improvements; it is completely up to the

developer to pick a tool over the other. Each approach has its benefits in low-level

services, but the current trend is towards more lightweight approaches (i.e. JADE). It is

important for the agent middleware to allow development in generic code language;

JACK has its own coding language which make it unsuitable candidate. There are clear

management benefits in having agents developed within dedicated applications; ZEUS

provides ontology support using its own ontology editor which might be awkward for

developers used to Protégé ontology development environment (Tweedale et al., 2007).

Applications and Characteristics of Agent Based Solutions

Multi-agent systems are used in wide variety of applications, such as process control,

system diagnostics, manufacturing, transportation logistics, and transportation networks

management. The Internet has been shown as an ideal domain for MAS due to its

intrinsic distributed nature and massive volume of information. In fact the internet has

pushed the use of agent technologies in the e-commerce and business process

management domains. Agent technologies significantly improve the way in which the

different entities involved in the business process interact.

They have been shown to be both suitable for the modeling business processes

management as well as being a key systems component for the automation of some or all

the business process steps. Traffic and transportation is also an important field, where the

distributed nature of traffic management processes and the strong independence among

the entities involved in such processes make MAS multi-agent systems a valuable tool

for realizing genuinely effective solutions (Camarinha-Matos and Afsarmanesh, 2004).

Software agent technology is suitable for solving new types of problems in

reactive systems. A capability for solving new problems is required in open systems,

where the structure of the system is capable of dynamic change. One example of an open

268

system is the Internet, where the software system must be able to operate autonomously

and without guidance. Complex software systems require modularity and abstraction,

which can be provided by agents. MAS can solve a complex overall problem by

partitioning it into sub-problems handled by interacting agents. Furthermore, intelligent

agents may provide a means for human-computer interaction in ubiquitous computing

systems. Agent-based solutions are suitable for problems where data, control, expertise or

resources are distributed and need to interact with one another in order to solve the

problem. They are also the most appropriate metaphor for representing a given software

functionality when the system is naturally regarded as a community of cooperating

autonomous components. Agents can also be used for making legacy components interact

with each other, or with new software components, by building an agent wrapper

(Genesereth and Ketchpel, 1994).

To summarize, the benefits of agent-based solutions are: robustness and

flexibility, re-configurability and ease of deployment (McFarlane et al., 2005). Agent-

based systems are robust since there is no central element and no central decision

making, so that the loss of one subsystem does not cause a fatal failure in any other

subsystem. Agent systems can be reconfigured by changing, adding or removing

hardware or software modules, as they support a plug-and-operate approach. The same

agent-based system can be redeployed in different subsystems of the manufacturing

facility and company, using the same communication standards and negotiation

scenarios. There are also several barriers that need to be confronted before widespread

adoption. These are the costs, the guarantee of operational performance, scalability,

engineering education, design methodologies, standards and the performance of the agent

system. Research community has published case studies on the successful agent

technology deployment in order to provide guidance to potential adopters in (McFarlane

et al., 2005).

269

APPENDIX B

DESCRIPTION OF THREAT CONCEPT TAXONOMY

B.1 Threat Domain Modality

1. Geophysical materialized through geo-medium, i.e. earth terrestrial layers and/or

physiochemical minerals. Under this modality, the natural threat concept is

categorized into the following sub-concepts: earthquakes, landslides, volcanic

eruption, and soil particles movement. Landslides refer to soil blocks slide (e.g.

mudflow, rock fall …etc), while soil particles movement refer to threats resulting from

extensive movement of soil particles, e.g. erosion, settlement, piping, clay

consolidation …etc. On the other hand, a slope failure due to human error, e.g. design

error is a sort of geophysical human error threat.

2. Meteorological materialized through the interaction of atmospheric-medium

component elements (gases and water vapours). Six major concepts are defined under

Meteorological Natural Threat, which are: wind gale (moderate, fresh, strong and

whole), storms (blizzards, snowstorm, thunderstorms, firestorms ...etc), cyclone

(hurricane, tornado, waterspout…etc.), aerosols (fog, mist, haze…etc), water

precipitation (rain, sleet, snow, hail, dew, and frost) and temperature (cold and hot

waves). Meteorological forms are not applicable to man-driven threats.

3. Hydrological materialized through terrestrial water bodies. Four concepts were

defined under this category as Natural Hydrological Threat, which are: snow

avalanche (slab and powder), ice (iceberg, black ice…etc), flooding (riverine, coastal,

muddy…etc), tidal waves (tidal bore and rogue waves) and tsunamis. An example of

a man-driven hydrological threat would be a terrorist attack on a water dam.

4. Biological materialized through micro-organisms infections/contaminations (fungus,

bacterial, viral, and parasites).

5. Animal refers to threats materialized through animals (e.g. birds flock leading to bird-

strike at airports, animal-vehicle collision …etc).

6. Chemical is categorized into five sub-concepts based on the chemical threat agent

reaction with the impacted entity, which are: corrosive, flammable, explosive,

270

poisonous, and carcinogens. It is the outcome of the reaction of naturally existing

physiochemical elements, e.g. coastal facilities are prone to atmospheric corrosion as a

result of the chemical reaction between airborne salt particles, air molecules and water

vapour. 911-attacks are a form of chemical explosive/flammable man-driven threats.

7. Radioactive/electromagnetic, Natural threats of this form refer to background

radiations emitted from natural sources. Natural sources are divided into: terrestrial

sources (i.e. radioactive material found in/on the earth terrestrial surface), cosmic (i.e.

emissions derived from sources inter or intra our solar system), and atmospheric

(airborne radioactive atoms or upper atmospheric high energy ray emissions). On the

other hand, man-driven threats of this form sources refer to radiations from man-made

sources (e.g. global radioactive contamination, nuclear power stations, emissions of

disposed or recycled radioactive material).

8. Cyber This form of threats modalities are materialized only as Man Driven threats,

with the most common type being a cyber-attack on software system.

B.2 Man-Driven Threat Taxonomy

Man-driven Threats are divided into two main sub-concepts intentional and non-

intentional.

1. Non-intentional: is synonymous to Human-Error or Fault. It is defined as specific,

identifiable, and unexpected outcome based on unusual and unintended action which

occurs in a particular time and place, without apparent or deliberate cause but with

marked effects. It can take one of the following six forms:

§ Cognitive-bias Error which results from misperception of sensory inputs from

surrounding stimuli. For example a mirage on pavement surface, may be

misinterpreted by a driver resulting in a car accident.

§ Operational Errors which results from input information/data bias or due to used

human-machine systems flaws and defects. An example of human-machine systems

error is a machine calibration error resulting in biased output. It also includes

errors due to misinterpretation and misunderstanding between communicating

parties.

271

§ Behavioural error as a result of carelessness, forgetfulness, and irresponsible and

unsafe actions in general. For example over speeding leading to vehicle collision

incident.

Errors can be random or systematic. Systematic errors follow a trend and they can be

traced or determined by algorithmic and mathematical modeling. For example, by

calibrating a defected machine, the amount of systematic residual error in the produced

items can be determined. Sources of systematic errors may be defects in production or

measurement equipment or interfering elements in the surrounding environment, such as

extreme heat changes causing material excessive expansion or contraction. An example

of systematic error is: steel welding machine that has a defect in its internal parts, which

produces steel weld 10mm less than their required length impose an Error Threat on the

steel structure which may lead to structure failure.

On the other hand, random errors are unpredictable fluctuations producing

inconsistent outcomes when repeated actions of constant attributes or magnitudes are

performed. The word random indicates that they are inherently unpredictable, and have

null expected value, namely, they are scattered about the true value, and tend to have null

arithmetic mean when repeated several times. Any outcome of any action is prone to

random error. Random errors are significantly affected by human factors as well as to

interference from the surrounding environment.

Each of the identified errors/faults concepts can be linked to a set of contributing

situational-factors, knowing them will help to provide the necessary proactive and

mitigation measures to avoid their future occurrence. For example, behavioral errors are

affected by human factors such as age, state of mind, physical health, attitude,

emotions…etc. In addition to human factors, cognitive bias faults are induced by

surrounding environment stressing elements such as temperature, visibility, noise …etc.

Communicative errors can be contributed to organizational structures, interoperability of

communication acts…etc.

2. Intentional Threat: this type of threats poses a challenge when trying to place them

under taxonomic hierarchy, as they are dynamic, and keep on exploiting potential

threats in novel ways. Accordingly, CIV-Onto categorizes intentional threats based

272

on the core motivation behind the threat action. Classifying intentional threats based

on motivation helps to assess the anticipated threat-impact and the expected scale of

damage. For example the expected number of lives loss resulting from a terrorist

threat is far beyond the expected number from a criminal activity. The following are

the five major Man-driven Intentional Threats sub-concepts:

§ Isolated Individual refers to threat that stems from personal actions and law

breaking, posing hazard to CI system/asset such as road suicide, vandalism,

aggression, drunk driving …etc.

§ Activism can be described as intentional actions aiming to bring social, political,

economic, or environmental changes. Activism might be accompanied by actions

such as: sabotage, labor conflicts, wrights, or demonstrations, pose threat to CI

systems/assets products and services. Activism span a broad scale of intensity and

violence from peaceful delaying and blocking of CI such as highways to militant

sabotage and destruction of CI.

§ Criminal Actions refers to any actions of criminal nature and orientation aiming

to achieve illegal financial gain and might cause disruption or destruction of CI,

such as theft of installed or spare parts, transport route danger (i.e. hijacking or

piracy of transportation carriers), illegal tapping of gas or oil lines...etc.

§ Terrorism is the systematic use of violent actions against governments, public, or

individual to terrorize them in order to attain a political objective. Terrorism is far

the most critical Man-driven Intentional Threat, and its occurrence has

devastating impacts financially, psychological, and most importantly human lives

loss.

§ Political/Military are danger imposed on CI due to state of war, however this

concept is out of scope of the developed ontology and it is only placed for

classification purposes.

§ Vandalism willfull destruction or spoiling of civil infrastructure by socially

irresponsible or reckless individuals.

§ Conceptual refers to errors in design codes, faulty system constraints and

mechanisms.

273

APPENDIX C

INCIDENT DURATION ESTIMATION

C.1 Incidents Duration Estimation Module

Duration estimation is one of the most important steps in the overall incident

management. Real-time decisions regarding resources allocation for incident clearance

and management, type and location of information to be disseminated to network

travelers and traffic control actions all depend by far on the expected duration of the

verified incident. Incident duration estimation models should be developed keeping in my

mind real-time considerations, i.e. factors that are unrealistic to collect in real-time

should not be incorporated (e.g. driver’s age). In addition, the model should be fast

enough to satisfy real-time constraints. According to Ozbay (1999), about 50% of the

incidents take 10 minutes or less to clear, 20% last more than 40 minutes to hour, and

10% for more than one hour.

SWIMS adopts two models for estimating incident duration, each is used based

on the availability of incident related data. The first model was developed at

Northwestern University, based on 121 incidents records extracted from Illinois State-

USA department of transportation. The study started by examining 22 variables, among

which 9 were found to be statistically significant for incident duration (Ozbay, 1999).

The model developed in this study is depicted below.

Clearance Time (minutes) = 14.03 + 18.44 XNumber of Trucks + 35.57 XHeavy Load Truck

+ 32.76 XCargo Spill +16.47 XExtreme Weather + 35.81 XRoad Facility Damage + 22.90 XSevere Injuries +

8.34 XWreckers + 0.69 XResponse Time + 18.84 XSand/Salt on Pavement + 27.97 XOther Responders

With the exception of Number of Trucks and Response Time (expressed in minutes), the

rest are binary (0 or 1) dummy variables expressing the involvement in the incident. In

addition, this model only estimates the clearance time, excluding the time till response

arrives, which should be added to the model. The other model is developed by the FHWA

[ref] and is depicted below. Again, with the exception of Number of Vehicles Involved

and Police Response Time (in minutes), rest are binary dummy variables.

274

Log Duration (in minutes) = 0.87 + 0.027 XNumber of Closed Lanes XNumber of Vehicles Involved +

0.200 XTruck Involvement – 0.170 XAfternoon Peak + 0.680 XLog Police Response Time + XRainy Weather

Traffic incident duration estimation is an active area of research and is subject to

continuous development and improvement. The duration prediction models incorporated

in SWIMS framework are not claimed to be the best, but rather was picked based on the

statistical sufficiency of the incident record data used in their development and according

to their citation in the literature conducted by the author. However, the distributed and

loosely coupled architecture of SWIMS, where the duration estimation models are

implemented as a Web-Service application, allows new applications to be easily plugged-

in and older ones being replaced based on new improvements and evolving demands.

In addition, SWIMS incident data-log stores both the reported incident attributes

along with the actual incident duration the framework incident database. Later on, this

data can be used to develop an accurate incident duration prediction model, specifically

tailored for the City of Toronto. In case of absence of enough incident related data to use

any of the above mentioned models, SWIMS framework provides a set of heuristic rules

(coded in JESS language) to estimate the duration of verified incidents. These data is

shown in Figure 5-11 in Chapter 5. In general, it is expected that the incident duration

estimation will continuously improve as more data is stored in the framework database.

275

APPENDIX D

SWIMS FRAMEWORK COMPONENTS

D.1 Ontology Coding

Taxonomy and Relationships Coding

TIM-Onto concepts and relations are coded using Protégé ontology editor. Protégé

supports ontology coding using either Ontology Web Language (OWL) or semantic

frame language. The former was used in this research due to its popularity and suitability

for web deployment. Among the three available versions of OWL (Lite, DL, and Full),

OWL-DL was chosen. OWL-DL is based on Descriptive Logic and accordingly supports

the capability to automated reasoning and automated consistency checks.

TIM-Onto concepts are coded as Protégé-OWL classes and structured into

taxonomic hierarchy. At the top of the Protégé TIM-Onto, the class owl: Thing, which

represents the set containing all classes and their instances. TIM-Onto relations are

represented through Protégé-OWL through ‘existential property restrictions’ and

‘necessary conditions.’ Properties are binary relations on classes that relate them.

In Protégé-OWL, properties are used to create restrictions. For a given class

instance, an existential restriction specifies the existence of a (i.e. at least one)

relationship along a given property to another instance belonging to a specific class.

‘Necessary conditions’ are used to state that if something is a member of this class, then

it is necessary to fulfill these conditions. Properties are also represented in a hierarchy.

Protégé-OWL allows properties to have sub-properties, in order to allow for the

formation of hierarchies of properties.

Ontology Axioms Coding

TIM-Onto axioms are either coded in JESS (described in a next section) or expressed in

Protégé-OWL, namely disjoint and modality axioms. Partition (disjoint) axioms are

represented in Protégé-OWL through the use of disjoint classes. Making two classes

276

disjoint ensures that one class member cannot be member of another class. For example,

threat and vulnerability classes are disjoint classes. An entity cannot be threat and

vulnerability at the same time.

Modality axioms are represented into Protégé-OWL through the use of

‘existential property restriction’ and ‘necessary and sufficient conditions.’ ‘Necessary and

sufficient conditions” state that for an instance to be member of class then it must satisfy

the ‘necessary and sufficient condition.’ If the instance satisfies the condition then the

individual must be member of that class. Figure D-1 shows TIM-Onto concepts in

Protégé interface; indicating an example of the disjoint classes and concepts associated

with ‘existential property restrictions.’

Figure D-1: TIM-Onto Coding in Protégé-OWL

277

D.2 Using JADE Content Language Support As explained in Chapter 6, the actual information that is transferred from the sender to

the receiver is included in the content slot of the message. According to the FIPA

specifications, the value of this slot is either a string or a raw sequence of bytes.

However, agents often need to communicate more complex information. When

representing complex information, it is necessary to adopt a well-defined syntax so that

the content of an exchanged message can be parsed by the receiver and extract relevant

information. According to FIPA terminology this syntax is known as content language.

FIPA does not mandate a specific content language but defines and recommends

the SL language, which is used in the context of this research. When receiving a

message, the receiver agent must be able to parse the SL syntax in order to actually

understand the information it represents. Additionally, it must have some shared

understanding with the sender regarding the terminology and symbols used to express the

message structure. This set of terminology and symbols used to express the message

content is nothing more than an ontology of the domain the agents interacting within.

Unlike the content language, which is domain independent, ontology is domain

dependent. For example, traffic incident management domain in case of TIM-Onto.

The importance of ontology in the content language cannot be overstated. While

string representation of complex information is suitable for embedding the information

inside the ACL message, it is rather inconvenient when an agent has to process it. Every

time a message is exchanged, agents need to extract the concepts it needs to parse the

entire content expression. However, as JADE agents are Java-based, content information

can conveniently be represented using Java objects. Even though, this eases information

handling inside an agent, each time a message is exchanged:

§ The sender needs to convert its internal representation into the corresponding ACL

content expression representation, and the receiver needs to perform the opposite

conversion.

§ The receiver should perform a number of semantic checks to verify that the received

information complies with the rules of the ontology shared by the communicating

agents.

278

The support for content languages and ontologies provided by JADE is designed to

automatically perform all the above conversions and checks. This allows the

manipulation of the information within the agent as Java objects without the need for any

additional marshalling or un-marshalling work.

Although Java serialization is a very simple and powerful mean to convert Java

objects into sequence of bytes, it is not enough to perform the before mentioned tasks.

JADE agents are just pieces of Java code, and serialization can be used to insert Java

objects into the content slot of the ACL messages. However, Java serialization does have

some disadvantages: 1) it is only valid in Java environment, i.e. agents cannot

communicate with another agents living in a FIPA-compliant platform but are not built

with JADE middleware. Furthermore, there is no guarantee that even if the receiver agent

is coded in Java environment that it would be able to understand a message whose

content is encoded with Java serialization. 2) Java serialization produces non-human

readable format. Being able to read the content of the message is very useful when

debugging or trying to understand sequence of messages logic. 3) An agent receiving a

message has no mean of determining the kind of object it will obtain when decoding the

content slot- any serializable object could be received in principle.

D.3 Using JADE-Ontology Support The support for ontologies provided by JADE is available as an option to ease the burden

of dealing with complex content. Exploiting JADE content language and ontology

support allows agents to discourse and reason about facts and knowledge related to a

given domain and is achieved by the following steps:

1. Define an ontology that is compliant with JADE schema. This schema structures the

ontology concepts and relationships in JADE specific format. The ontology is

pertinent to the domain of discourse (TIM-Onto in the context of this research).

2. Develop Java classes corresponding to all concepts and relationships in the ontology

schema.

3. Select suitable content language among those directly supported by JADE, FIPA-SL

in the context of this research.

4. Register the defined ontology and the selected content language with the agents.

279

1. Defining an Ontology

Any ontology defined in JADE is an instance of the jade.content.onto.Ontology

class which defines the schemas of the concepts and relationships (predicates) pertinent

to the addressed domain. Each of these classes has methods with which it is possible to

declare the slots associated with each class defined in Protégé-OWL. Since ontology does

not evolve during an agent lifecycle, it is good practice to declare ontologies as singleton

objects and define ad-hoc classes (that extend jade.content.onto.Ontology) with

static methods to access this singleton object. This allows the same ontology to be shared

among different agents in the same Java Virtual Machine (JVM).

The following shows an excerpt from TIM-Onto Java code. It mainly illustrates

the incident, impact, and actor concepts along with the dispatch relationship (predicate).

Only incident location attribute is shown in this excerpt as well as number of fatalities,

injuries, trucks and vehicles involved for the impact concept. The dispatch relationship

takes the actor and incident location as arguments. package TIM_ONTO.ontology import jade.content.onto.*; import jade.content.schema.*; public class TIM_Onto extends Ontology { //the name identifying the ontology public static final String ONTOLOGY_NAME = “TIM-Onto”; public static final String INCIDENT = “Incident”; public static final String INCIDENT_LOCATION = “location”; public static final String IMPACT_MEASURE = “Impact”; public static final String IMPACT_NVEHICLE = “nvehicle”; public static final String IMPACT_NTRUCKS = “ntrucks”; public static final String IMPACT_NFATALITY = “nfatality”; public static final String IMPACT_NINJURY = “ninjury”; … … … public static final String ACTOR = “Actor”; public static final String DISPATCH = “Dispatch”; public static final String DISPATCH_ACTOR = “actor”; public static final String DISPATCH_Location = “location”; // the singleton instance of the ontology private static Ontology theInstance = new TIM_Onto; //retrieve the singleton TIM-Onto ontology instance

280

Public static Ontology getInstance(){ return theInstance } // Private constructor private TIM_Onto () { // The TIM-Onto ontology extends the basic ontology Super (ONTOLOGY_NAME, BasicOntology.getInstance()); try { add(new ConceptSchema(INCIDENT), Incident.class); …

add(new ConceptSchema (ACTOR), Actor.class); add(new PredicateSchema (DISPATCH), Dispatch.class);

//Structure the Schema for the Incident Concept ConceptSchema cs = (ConceptSchema) getSchema(); cs.add (INCIDENT, (PrimitiveSchema)getSchema(BasicOntology.String)); cs.add (LOCATION, (PrimitiveSchema)getSchema(BasicOntology.String)); //Structure the Schema for the Dispatch Relationship PredicateSchema ps = (PredicateSchema) getSchema(); ps.add (DISPATCH_ITEM, (ConceptSchema)getSchema(ACTOR)); ps.add (DISPATCH_ITEM, (ConceptSchema)getSchema(INCIDENT_LOCATION)); } catch(OntologyException oe) { oe.printStackTrace ( );}}}

Each schema added to the ontology is associated with a Java class, e.g. the schema for the

INCIDENT concept is associated with the Incident.java class. While using the defined

ontology, expressions indicating incidents will be instances of the Incident class. These

Java classes must have a proper structure as described in the next section. Each slot in a

schema has a name and a type, i.e. values for that slot must comply with a given schema.

For example a slot that has the value String must take only string values.

A slot can be declared as OPTIONAL meaning that its value can be null.

Otherwise a slot is considered MANDATORY. If a null value for a MANDATORY slot

is encountered in the validation of a content expression, an OntologyException is thrown.

A slot can have cardinality >1, i.e. values for that slot are aggregates of elements of a

given type. For example, the number of vehicles slot in the schema for the

IMPACT_MEASURE concept can contain 0 or more elements of type Integer. A schema

automatically inherits all slots included in its super-schemas. Super-schemas are added by

means of the addSuperSchema() method of the ConceptSchema class.

281

2. Developing Ontological Java Classes

Each concept and relationship included in the ontology must be compliant with its

corresponding JADE schema. As noted in the before presented code, each concept and

relationship is associated with a Java class, which must in turn implement the

corresponding JADE schema. For example, a concept must implement JADE concept

schema, while a relationship must implement JADE predicate schema.

JADE schemas are nothing more than a simple Java class with setter and getter

methods. In case of concept schema the setter and getter methods define the attributes

associated with the concept by has- relationship. While for the predicate schema the

setter and getter methods define the domain and range associated with the relationships.

Examples of an ontology concept and relationship (predicate) Java class are given below:

//Class associated with the Incident Concept Schema package TIM_ONTO.ontology; import jade.content.Concept; public class Incident implements Concept { private String location; public String getLocation(){ return location;} public void setLocaton (String location){ this.location = location;} }

//Class associated with Dispatch Relationship Predicate Schema package TIM_ONTO.ontology; import jade.content.Predicate; public class Dispatch implements Predicate { private Actor actor private String location public Actor getActor() {return actor;} public void setAgency (Actor actor) {this.actor = actor;} public String getLocation() {return location;} public void setLocation (String locaton) {this.locatoin = location;} }

When dealing with large ontologies similar to TIM-Onto, manual coding of the ontology

concepts and predicates into Java classes becomes a tedious task. A JADE add-on tool

called Bean Generator was developed to support the creation of message content

282

ontologies that are compliant with the JADE support for managing content expressions.

The ontology bean generator plugin is a Protégé Tab widget which generates JADE

compliant Java classes representing an ontology that can be used with

the JADE environment. With the bean-generator tool FIPA/JADE compliant ontologies

from Protégé projects can be generated.

3. Selecting a Content Language

JADE middleware provides support for two types of content languages, the SL language

and the LEAP language. The SL content language is human-readable string-encoded

content language that is based on S-Expression syntax. It is recommend to adopt SL for

open agent-based applications where agents produced by different developers and

running on different communicating platforms. The LEAP content language is a non-

human-readable byte-encoded content language. It has been defined specifically for

JADE and thus can be used only among JADE agents. The used content language is

defined in the content slot of the message as previously defined in Chapter 6, section

6.6.5.

4. Registering Content Languages and Ontologies with an Agent

Before an agent can actually use JADE ontology and associated content language, it must

register them with its content manager. The following code shows an excerpt from this

registration assuming that the SL language is selected as the content language

public class CommunicationOfficer extends Agent { ... private Codec codec = new SLCodec(); private Ontology ontology = TIM_Onto.getInstance(); ... protected void setup() { ... getContentManager().registerLanguage(codec); getContentManager().registerOntology(ontology) ... }}

283

From now on the content manager will associate the registered Codec and Ontology

objects to the strings returned by their respective getName() methods.

D.4 SWIMS Underlying Semantic Model

As early mentioned in Chapter 6, SWIMS underlying semantic model is completely

derived from TIM-Onto ontology defined in Chapter 6. Figure D-2 illustrates the

semantic model underlying SWIMS framework. The figure shows the interrelation

between the different classes within the ontology. These relations are used by the

software agents to classify the incident and determine the required response measures as

well as actors to be dispatched on the incident scene. The classes/concepts that are

correlated by the relations indicated are thoroughly defined in the tables and figures

defined in Chapter 5 and illustrated in Figure D-2.

D.5 Executing the Ontology within SWIMS Framework

The ontology execution within SWIMS framework can be summarized as shown in

Figure D-3 below. Using the Protégé ontology editor and JADE Bean-generator plug-in,

the ontology OWL classes are mapped into Java classes that are compliant with JADE

ontology schema, as described in the previous section. JADE ontology schema maps

Protégé ontology classes and their attributes into Java classes where attributes are defined

as Java class inner objects (nested class), variables and constants. Relationships between

OWL classes and their attributes are defined in terms of Java class access methods (i.e.

getters and setters).

Upon the initialization of JADE middleware, the system declares the ontology as

a singleton object and defines an ad hoc class with static method to access this singleton

object. This will allow the same ontology object to be shared among different agents in

the same Java Virtual Machine. Similarly, using JESS tab plug-in the rules defining

different patterns of SWIMS agents’ execution logic are coded in JESS language. Each

set of rules represent specific SWIMS agent desires. For example, incident verification

rules are desires of a communication-officer agent.

284

Figure D-2: SWIMS Underlying Ontological Model Schematic Diagram

285

JESS inference mechanism follows declarative paradigm, where it continuously applies a

collection of rules to a collection of facts through pattern matching process. One of the

major advantages of JESS is that it can be directly used to manipulate and reason about

Java objects using knowledge supplied in the form of declarative rules. JADE and JESS

are integrated through a third party API, allowing JESS rules to be used on JADE

ontological Java classes to make inferences. The semantic model underlying the system is

shown in Figure D-3, while the following subsections describe the execution of the

ontology in SWIMS along with illustrative diagrams and code snippets.

Figure D-3: Mapping from Protégé OWL to JADE Ontology Compliant Schema within

JADE Agent

1. Detecting Traffic Incidents:

As previously mentioned in Chapter 6, SWIMS supports the detection of traffic incidents

from various sources, e.g. Web interface, twitter, smart phone apps….etc. When a traffic

incident is being reported from any of the supported sources, the system initializes a

temporary agent (Notifying-Agent) having a life span equals to incident detection process

duration.

286

The Notifying-Agent creates an instance of the incident ontology singleton Java class and

populates it with the received data. This incident class is then populated with the reported

incident data (attributes). The incorporated JESS rules in the Notifying-Agent perform

required semantic checks to assure that the reported incident data are sufficient to

generate an incident alert. Furthermore, the agent use its inner rules to verify that the

provided incident data types are compliant with the types originally defined in TIM-

Onto. For examples number of fatalities must be integer, otherwise an error message will

be generated.

Each reported incident must at least have a location and time of occurrence. In

case of missing location, the alert is sent back to the source and incident location is

prompted to be entered. However, if the incident does not have an associated occurrence

time, the incident alert receive time is used in instead. In addition, if the incident location

is provided in geo-address format, the agent incorporated JESS rule generates get-

address-coordinates agent action. This action triggers internal intention behaviour in the

Notifying-Agent agent, invoking Google geocode web service to change the geo-address

into longitude and latitude coordinates format.

After performing the required semantic checks and data conversions, the reported

incident attributes are coded in FIPA-ACL compliant message and forwarded to the

Communication-Officer agent for further processing. Figure D-4 Illustrates a schematic

diagram of the tasks performed by the Notifying agent.

Figure D-4: Incident Data Processing in a Notifying Agent

287

The following illustrates the Notifying agent JESS rules. These rules are executed on the

populated ontological Java class. If the data (facts) in the Java class matches the rules

pattern, the rules are fired. The output represents an agent action defined in a string

format and corresponding to a coded behaviour in the software agent. For example, the

“Get-Address-Coordinates” action causes the execution of a Google geo-coder

web service, transforming the reported incident geo-address to geo-graphical coordinates.

Rule-1: (defrule aRule (Incident ?x)(Location ?l)(haslocation ?x ?l) (Action ?a) (test (= ?l Null)) => (assert ( ?a “Missing Location Error”)) Description: Check if the incident alert has location. Output Agent Action: Error Message

Rule-2: (defrule aRule (Incident ?x)(Location ?l)(haslocation ?x ?l) (Action ?a) (test (= ?l Null)) => (assert (?a “Get-Address-Coordinates”)) Description: Check if incident location is geo-address and invokes Google geo-coder web service if true. Output Agent Action: Get-Address-Coordinates

(alert :sender (agent-identifier: name localhost:8080/SWIMS-WEB/IncidentReport.com) :receiver (agent-identifier :name localhost:[email protected]) : ontology TIM-Onto : language FIPA-SL : protocol IncidentAlert : content (action (agent-identifier :name localhost:[email protected]) (receive-alert (incident “Vehicle_Collision” : location “Gardiner Expy, Toronto, ON, Canada” : longitude “-79.384389” : latitude “43.640166”) (impact : nVehicles “3” : nFatality “null” : nInjury “1” : nTrucks “0”)))

Figure D-5: FIPA-ACL Compliant Message Carrying an Incident Alert

288

2. Verifying Traffic Incidents:

The incident alert messages are all received by the Communication-Officer agent. For all

incident alerts, other than the ones being reported by law enforcement officer, the

incident occurrence must be verified. Rule-3 below is the JESS rule incorporated in the

Communication-Officer agent to verify the occurrence of the traffic incident.

Rule-3: (defrule aRule (Action ?a) (Incident ?x)(SourceAlert ?y)

(ComOfficer Z)(hasSource ?x ?y)(test ( ?y “LawEnforcement”) => (assert (?a “Verify Incident”)) Description: Prompt the verification of all traffic incidents except one reported by police. Output Agent Action: Verify detected traffic incident occurrence.

The JESS rule immediately shows the closest CCTV to the detected incident

location, notifying the operator with the incident occurrence alert. It is up to the operator

to use another camera to further assess the incident occurrence and impacts. Figure D-6

illustrates the GUI of the Communication-Officer agent.

Figure D-6: GUI of the Communication-Officer Agent

289

If the occurrence of the incident is verified, the operator generates a new web form where

she/he enters any additional incident related data. The full range of incident data that can

be entered in the incident report form is shown in Table 5-15 of Chapter 5. Upon pressing

the submit button on the incident report form, the newly entered data are populated in the

incident ontological Java beans as new facts.

Figure D-7: Communication-Officer Agent GUI after submitting verified incident data

The Communication-Officer agent uses its inner JESS rules to identify the roles of

different response agencies in the traffic incident management process. This is done using

the incident type-actors roles relationships defined in Table 5-12 of Chapter 5. Rule-4

below is a sample of response agencies roles determination rules.

Rule-4: (defrule aRule (Incident ?x)(LawEnforcement ?y) (test (= ?x “Collision”)) => (assert (assign_command ?y ?x)) Description: Check if incident type is collision, and if true assign the incident command to the law enforcement officer. Output Agent Action: Assign the incident command to the Law Enforcement.

290

The assign_command action results in a message being sent to the law enforcement

operator, notifying her/him having the role of the incident commander. A similar message

is sent to the traffic operator and other responding agencies operators notifying them of

their roles and carrying the full elements of the incident report. Figure D-8 shows a

schematic diagram of the tasks performed by the Communication-Officer agent.

Figure D-8: Processing of the incident data by the Communication-Office Agent

3. Responding to the Traffic Incidents

Upon receiving the incident report message from the Communication-Officer, the

Incident-Commander agent decodes the received message and fires its internal JESS rules

on the newly received data. Based on the incident associated impacts, i.e. number of

injuries, fatalities, vehicles and truck involvement; the required type of response units are

determined. Rule-5 below shows a sample of the rules used to determine whether or not

medical service units need to be dispatched to the incident scene.

Rule-5: (defrule aRule (dispatch ?d)(Incident ?x)(Injury ?y)(hasImpact ?x ?y) (test (> ?y 0)) => (assert (?d “Emergency Medical Service”)) Description: Check if incident has any associated human injury and if so dispatch emergency medical services. Output Agent Action: Dispatch action sending a dispatch request to the emergency medical services operator.

291

Rule-6: (defrule aRule (dispatch ?d)(Incident ?x)(nVehicle ?y)(hasImpact ?x ?y) (test (> ?y 0)) => (assert (?d “Towing Service”)) Description: Check if incident has any associated impacted vehicles and if so dispatch towing and recovery services. Output Agent Action: Dispatch action sending a dispatch request to the towing services operator.

Similarly, based on the incident attributes the full array of required responders is

determined as defined in Table 5-11 of Chapter 5. The exact number of response units to

be dispatched to the incident scene is defined in Table 5-14 of Chapter 5. These specific

rules related to the required number of response units are coded in pure Java code rather

than JESS rules. They are not considered to be part of the ontology as they are case

specific, derived from the experience of emergency response operators at the City of

Toronto. These rules are coded in the intention behaviour of the Incident-Commander

agent as simple If-Then Java code. Figure D-9 below illustrates a schematic diagram of

the tasks performed by the Incident-Commander agent.

Figure D-9: Schematic Diagram of Incident-Commander Agent Tasks

Upon determining the required type and number of response units the agent allocates the

closest response units to the incident scene using the provided incident coordinates as

well as underlying GIS maps storing the location of response facilities covering the City

292

of Toronto. The Incident-Commander agent sends a dispatch request to each response

unit, upon approval the Incident-Commander utilizes real-time response units routing

service. The dispatch request interaction between the Incident-Commander and the

response units is compliant with the Contract-Net standard interaction protocol shown in

Figure D-10.

Figure D-10: The Interaction Protocol between Incident-Commander Agent and

Responding Units Agents

293

The Incident-Commander sends a request to the emergency response operator (Call for

Proposal), which usually a request to dispatch certain number of response units to the

incident scene. The emergency response agent may either refuse, or propose responding

to the incident with a number equal than or more/less than the suggested number. The

number of response units suggested by the emergency operator is function of the

available resource at that time and/or number seen by the operator to be more appropriate

for response based on the incident attributes.

It is up to the Incident-Commander to accept or reject this proposal, and the

emergency response operator has to inform the Incident-Commander by the result of the

dispatch process (i.e. success to deliver, failure, and otherwise). The routing service

utilizes real time data provided by 972 VDS (Vehicle Detection Stations) deployed on the

City of Toronto surrounding freeway networks. The data from each VDS is captured

using real time data grabbers implemented as web services. Real time VDS data are

integrated with GIS map of the City of Toronto freeway networks and built on it is a

routing web service that utilizes the shortest path algorithm. Figure D-11 illustrates the

routing of an ambulance unit to the incident location.

Figure D-11: The Routing of an Emergency Medical Services Unit from the Closest

Location to the Incident Scene

294

In case of multiple incidents, the Incident-Commander can prioritize the response based

on the criteria defined in Tables 5-20 and 5-21 of Chapter 5. Table 5-20 define the

weights associated with the modalities of various incidents types and impacts. For

example a traffic incident that involves a critical injury is given the weight of 0.73

compared to 0.20 for an incident with severe (less critical) injury. These rules are

implemented using Java Hash-Tables in the intention part of the agent behaviour.

4. Managing the Impacted Traffic: The Traffic-Operator agent receives the incident report with the Incident-Commander

agent simultaneously. Based on the incident attributes, the Traffic-Operator agent

estimates the incident duration using the models provided in Appendix-C. These models

only estimates the clearance time. Thus in order to estimate the full incident duration, the

Traffic-Operator needs to add the response time (time taken by response units to arrive to

incident scene). Response time is estimated from the output of the real time routing

services discussed in the previous subsection.

Incident Duration = Incident Clearance Time + Response Time

In case of absence of sufficient data to estimate the incident duration, the agent utilizes

the incident duration estimation trees provided in Figure 5-9 of Chapter 5. The incident

duration estimation is provided as an input for a mesoscopic simulation model which is

used to estimate the overall incident travel delay, impacted area and come up with

modified traffic signal and ramp metering timing accordingly. Table D-1 summarizes the

main data and processes inputs/outputs for the whole semantic model underlying

SWIMS.

The table illustrates the input/out data and information along with the source for

each entry. Some data requires solely human manual entry, e.g. number of injuries, while

others are deduced through automated means, e.g. traffic incident impact area. However,

some data sources may provide the possibility for human modification for the generated

automated data, e.g. number of response units. The last two columns of the table indicates

the ontology rules utilizing/producing this data/information along with the associated

agent actions as discussed in the previous sections.

295

Table D-1: Main Data and Process Inputs/Outputs for SWIMS

Source Possible Values Process Rule/s Action/s Human Automated

Att

r. Location Manual Entry Smartphone GPS Coordinates Detection Rules Get Coordinates

Time of Occurrence Manual Entry Smartphone Clock Time in HH:MM:SS Detection Rules

Situ

atio

nal F

acto

rs

Roadway Type Manual Entry GIS Service Freeway/Non-freeway Verification Rules Generate Report

Land Use Manual Entry GIS Service Rural, Urban, Bridge and Tunnel Verification Rules Generate Report

Weather Manual Entry Weather Web Service Clear, Rain, Foggy, Snow, and Sleet Verification Rules Generate Report

Temperature Manual Entry Weather Web Service Qualitative Measure Verification Rules Generate Report

Visibility Manual Entry Weather Web Service Qualitative Measure Verification Rules Generate Report

Impa

ct

No. of Injuries Manual Entry NA Integer Value Response Rules Dispatch EMS

No. of Fatalities Manual Entry NA Integer Value Response Rules Dispatch EMS

No. of Vehicles Manual Entry NA Integer Value Response Rules Dispatch Towing

No. of Trucks Manual Entry NA Integer Value Response Rules Dispatch Towing

Facility/Structure Damage Manual Entry NA Qualitative Measure Response Rules Dispatch Public Works

Travel Delay NA Traffic Simulation Model Total Travel Delay in hrs Diversion Rules Initiate Diversion

Ecological Manual Entry NA Impact Area Diversion Rules Initiate Diversion

Out

put D

ecis

ions

Incident Responders Possible Manual Entry Ontology Rules Ontology Roles Response Rules Assign_role

Response Process Possible Manual Entry Ontology Rules Ontology Processes Response Rules Determine_actors

No. of Response Units Possible Manual Entry Ontology Rules Integer Value Response Rules Interaction Protocol

Routing of RU NA GIS Shortest Path Alg. Route + Travel Directions NA NA

Priority Response Possible Manual Entry Ontology Rules Priority Response Weight Response Rules NA

Traffic Impact Area NA Customized GIS Service Speed/Delay Contours Traffic Management Rules NA

Signal/Ramps Timing Plans NA Webster and ALINEA Algorithms Timing Plans NA NA

296

APPENDIX-E

SURVEY ON TRAFFIC INCIDENT MANAGEMENT BEST PRACTICES AT CITY OF TORONTO

INVESTIGATROS

TAMER EL-DIRABY ASSOCIATE PROFESSOR

MAHMOUD OSMAN ABOU-BEIH PHD CANDIDATE

297

1. BACKGROUND

One of the major challenges identified during traffic incident management process, is the efficient

coordination between various agencies involved in the incident response. Traffic incident

management is multi-agency, multi-jurisdictional problem, which requires careful planning and

coordination among various involved parties. It is formed of set of sequential and interrelated

processes, performed both on incident scene and at jurisdictional control centers.

Incident management systems found in the literature focus only on developing traffic

response plans, ignoring other important response measures such as determining optimum

type/number of required response units. In addition, none of these systems addressed the

development of integrated multi-agency management plans that cover the coordination between

various incident responders. Coordination between incident responders has been mediated by

intra-disciplinary tradition and experience, rather than well-organized coordination. An integrated

incident management system that provides coordinated multidisciplinary response plans will lead

to decrease in fatalities, increase responders’ safety, and significantly decrease incident response

and relief time. Such system should optimize responding units’ arrival to/of the incident scene;

define responders’ roles, and mutual expectations.

2. PURPOSE OF SURVEY

The scope underlying this survey is to understand the current traffic incident management process

workflow at the Greater Toronto Area. Identify major the role of major incident responders and

the criteria for prioritizing traffic incident response.

3. INFORMATION CONFIDENTIALITY

All the information provided by respondents will be used only for the purpose of this research.

Personal information will remain fully confidential, except that the final report may list the names

of people responding to this survey in appreciation for their participation. Please inform us if you

do not wish to publish your information.

298

4. THE SURVEY

The survey should take approximately 20 minutes to complete. It is comprised of 5 sections:

Section 1: Respondent Information

Section 2: Traffic Incident Management Process Model Evaluation

Section 3: Traffic Incident Attributes Evaluation

299

SECTION ONE: RESPONDENT INFORMATION

Please fill out the following respondent data log.

RESPONDENT DATA LOG

Name:

Title/Position:

Organization Name:

Years of Experience:

Field of Experience:

Phone:

E-mail:

Interview Date: / /

Do you wish to have your name published in recognition of your efforts in this study?

Yes No

300

SECTION TWO: TRAFFIC INCIDENT MANAGEMENT PROCESS MODEL

PART ONE:

Figure-1 on the following page represents a model for the processes involved in the traffic

incident management processes.

1. Do you this this model is representative of the process you employ? If not how is it different?

…………………………………………………………………………………………………...

…………………………………………………………………………………………………...

…………………………………………………………………………………………………...

…………………………………………………………………………………………………...

…………………………………………………………………………………………………...

…………………………………………………………………………………………………...

2. Which of the roles presented in Figure-1 best represent you? (can pick more than one)

Traffic Operation Center Incident Commander

Communication Officer Response Unit

3. What are the best practice guides, codes, etc… relating to traffic incident management that are used within your organization?

…………………………………………………………………………………………………...

…………………………………………………………………………………………………...

…………………………………………………………………………………………………...

…………………………………………………………………………………………………...

4. Do you think that these guidelines and constraints are frequently updated or have remained the same over the years?

…………………………………………………………………………………………………...

…………………………………………………………………………………………………...

…………………………………………………………………………………………………...

5. Do you rely on regular coordination meetings with other organization involved in the traffic incident management process? If yes, how frequent they are conducted?

…………………………………………………………………………………………………...

…………………………………………………………………………………………………...

…………………………………………………………………………………………………...

301

Figure -1: Traffic Incident Management Process Model

302

PART TWO: The following table lists different traffic incident management sub-processes, please indicate the role of

your organization in the following processes (you may indicate no involvement), and special conditions

that MAY be associated with this role type.

PROCESS SUB-PROCESS ROLE CONDITON/S

DETECTION & VERIFICATION

Incident Detection

Incident Verification

EMERGENCY RESPONSE

Response Plan Generation

Dispatch Coordination

Site Management

Scene Protection

Fire/Rescue

Medical Care

Spill Mitigation/Cleanup

Debris Removal

Vehicle Towing

Facility Emergency Repair

303

PROCESS SUB-PROCESS ROLE CONDITON/S

LIAISON/ COMMUN. Media Management

TRAFFIC MANAGEMENT

Duration/Delay Estimation

Traveller Information

Network wide Traffic Control

On-scene Traffic Control

Route Diversion Plan Gen.

SUPPORT Documentation/ Report Filing

304

PART THREE: The following table lists different traffic incident management sub-processes, please indicate

data/information for each process from your organization perspective. You may select NOT

APPLICABLE (NA).

PROCESS SUB-PROCESS INPUT DATA/INFORMATON

OUTPUT DATA/INFORMATION


Incident Detection


EMERGENCY RESPONSE



Site Management

Scene Protection

Fire/Rescue

Medical Care


Debris Removal

Vehicle Towing


305

PROCESS SUB-PROCESS INPUT DATA/INFORMATON

OUTPUT DATA/INFORMATION


TRAFFIC MANAGEMENT







306

PART FOUR: The following table lists different traffic incident management sub-processes. Please indicate the

business rules/decision criteria along with associated risks for each of the shown processes from

your organization perspective. You may select NOT APPLICABLE (NA).

PROCESS SUB-PROCESS BUSINESS RULES/ DECISION CRITERIA


Incident Detection


EMERGENCY RESPONSE



Site Management

Scene Protection

Fire/Rescue

Medical Care


Debris Removal

Vehicle Towing


307

PROCESS SUB-PROCESS BUSINESS RULES/ DECISION CRITERIA


TRAFFIC MANAGEMENT







308

SECTION FOUR: TRAFFIC INCIDENT ATTRIBUTES & RESPONSE PRIORITIES

PART ONE: For each of the incidents listed in the table below, please indicate the most important attributes in deciding the required response resource and

mention why (e.g. number of injuries).

INCIDENT ATTRIBUTE/S RESOURCES WHY?

COLLISION

DISABLEMENT

VEHICLE FIRE

CARGO SPILL

HAZMAT

FACILITY/STRUCTURE COLLAPSE

FACILITY/STRUCTURE DYSFUNCTION

FACILITY/STRUCTURE FIRE

EMERGENCY ROAD WORK

WEATHER INCIDENT

309

PART TWO: Please indicate the role of involvement of your organization along with any special management rules in the incident types listed in the table

below:

INCIDENT ROLE MANAGEMENT RULES

COLLISION

DISABLEMENT

VEHICLE FIRE

CARGO SPILL

HAZMAT

FACILITY/STRUCTURE COLLAPSE

FACILITY/STRUCTURE DYSFUNCTION

FACILITY/STRUCTURE FIRE

EMERGENCY ROAD WORK

WEATHER INCIDENT

310

PART THREE: Please rank the relative importance between the incidents criteria indicated in the table on the

next page, using the criteria outlined in the table below.

No. Criteria Description

C1 Injuries Incidents that involves multiple injuries with varying degrees of severities.

C2 Incidents involving Fire/Recue

Incidents that involve fire/rescue operations might severely propagate into catastrophic events if not immediately responded.

C3 HAZMAT Spill

Incidents involving HAZMAT spill in urban area, this includes incidents that may lead to contamination of the public storm water system, surrounding environment. In some extreme cases may cause public harm.

C4 Road Facility Collapse

Partially collapse facilities are even more dangerous than fully collapsed one. In 2007, a woman was killed in Montreal because concrete blocks from a cracked bridge beam smashed her car while she was passing underneath.

C5 Road Facility Dysfunction

The dysfunction of roadside facility can have severe impact on motorists and pedestrian safety, e.g. traffic light malfunction. Of course, the severity of the incident impact is higher in urban areas.

C6 Time of Occurrence

Time of Occurrence, the time of occurrence of an incident affects the response priority significantly. If an incident occurs during or will last into peak hour, a higher priority is given to the incident.

C7 Location

The location of the incident affects the response process in two ways. The priority of the clearing an incident varies with location of the incident. An incident on a freeway or a bridge in most cases would have a higher priority than one on a local route. Second the location of the resource center from which the resources are to be dispatched depends on the location of the incident.

C8 Ratio of lanes closed to total number of lanes

The number of lanes blocked helps to determine the expected traffic delay. Delay is the key in making decisions regarding diversions since one of the most efficient ways of reducing delay is decreasing demand by diverting traffic away of the incident.

311

Please Fill the CLEARED section of the Table

Intensity of Relative Weights of Importance

Relative Importance Definitions

1 Equal importance 3 Weak relative importance 5 Essential or strong importance 7 Demonstrated importance 9 Absolute importance

2,4,6,8 Intermediate values between two adjacent judgments.

Criteria C1 C2 C3 C4 C5 C6 C7 C8

Injuries C1

Incidents involving Fire/Recue

C2

HAZMAT Spill C3

Road Facility Collapse

C4

Road Facility Dysfunction

C5

Time of Occurrence C6

Location C7

Ratio of lanes closed to total number of lanes

C8

312

APPENDIX-F: ONTOLOGY VALIDATION SURVEY

TRAFFIC INCIDENT MANAGEMENT ONTOLOGY (TIM-ONTO)

VALIDATION INTERVIEW

INVESTIGATROS



313

1. BACKGROUND

One of the major challenges identified during traffic incident management process, is the efficient

coordination between various agencies involved in the incident response. Traffic incident

management is multi-agency, multi-jurisdictional problem, which requires careful planning and

coordination among various involved parties. It is formed of set of sequential, cross-related

processes; performed both on incident scene and at jurisdictional control centers.

Incident management systems found in the literature focus primarily on the traffic

response, ignoring other involved stakeholders needs for information and knowledge sharing.

Furthermore, these systems can be seen as reactive systems, unequipped with appropriate tools to

analyze root causes of traffic incidents for future mitigation measures. In brief, based on the

author’s best knowledge, none of the incident management system in the literature addressed the

development of integrated multi-agency management plans that covers the coordination between

various responders and fully assesses the risks associated with traffic impacts.

An integrated incident management system that provides coordinated multidisciplinary

response plans will lead to decrease in fatalities, increase responders’ safety, and significantly

decrease incident response and relief time. Such system should optimize responding units’ arrival

to/of the incident scene; define responders’ roles, and mutual expectations.

In order to develop an efficient integrated incident management system, various involved

parties and stakeholders should share a knowledge model/s that prompts accurate detection,

reporting, and verification of incidents and accordingly coordinate the required competencies

together with the appropriate traffic management operations based on the incident characteristics.

This system should allow access to specific resources and databases available at involved

agencies through an adequate underlying communication infrastructure. The major challenges in

developing such system can be summarized in the following points:

§ Information Flow and Management, handling the enormous, continuous flow of data

and updating the decisions and coordination across various parties accordingly.

§ Information and Data Interoperability, overcoming the heterogeneity of data syntax,

schema, and semantics. Interoperability has been identified as a key challenge in

achieving an integrated incident management system.

§ Sharing and Integrating Knowledge Models, any proposed system should have a clear

knowledge representation, so that the tasks of various involved parties can be easily

delivered and understood.

314

§ Software Interoperability and Resources Access, ability of authorized access of shared

software systems/applications. Remotely invoking required services, transferring

input/output data in compatible format in seamless manner, regardless of service location.

2. OBJECTIVE

This research utilizes the powerful combination of semantic web technologies, ontologies, web

services, and software multi-agent paradigms to produce seamlessly integrated-loosely coupled

incident management system. This combination of new technologies can potentially address the

challenges in data, information and knowledge sharing, process modeling and deployment, and

interagency interoperability, all in the context of real-life incident management.

Using open portals and interfaces, software agents exchange data, information,

knowledge, resources, expertise and services through the distributed dynamic nature of the

semantic web. This will allow the linking of processes, data, output plans, and decision makers in

a synchronized and integrated manner. The range of the framework’s targeted users includes

researchers, decision makers, local operators, media officials, police, fire fighters, emergency

services responders, related transportation industry organizations, all the way down to the

transportation system users.

The workflow will include managing multiple cross-agency processes in spite of software

platforms heterogeneities. Ontology is responsible for resolving the system data, information, and

software applications semantic, schematic, and syntactic heterogeneities. Software agents provide

the human administrators with decision support mechanisms based on the inferences they make

using the system knowledge models (ontologies).


This survey is intended to validate the knowledge model that was created to capture traffic

incident management domain. The knowledge model was created using ontological engineering

tools and models cross organizational process and best practices that are deployed in response to

traffic incident management occurrence. The knowledge model has the ability to assess incident

route causes through analyze risk associated elements in the traffic network (i.e. threats,

vulnerability, impacts …etc.).

315






5. THE SURVEY

The survey should take approximately 30 minutes to complete. It is comprised of 5 sections:


Section 2: Familiarity with survey scope

Section 3: Abstraction and categorization effectiveness

Section 4: Navigational Ease

Section 5: Overall Evaluation

316



RESPONDENT DATA LOG

Name:

Title/Position:

Organization Name:



Phone:

E-mail:

Interview Date: / /


Yes No

317

SECTION TWO: FAMILIARITY WITH SURVEY SCOPE

2.1 Please indicate which of the following phases you are familiar with/involved in the traffic

incident management lifecycle.

Phase

Select only ONE option Very Familiar

Familiar Moderately Familiar

Moderately Unfamiliar

Unfamiliar Very Unfamiliar

1 2 3 4 5 6

Transportation Infrastructure Planning &Design


Detection & Verification

Emergency Response

Traffic Control

Incident Data Analysis & Documentation

2.2 Are you aware with safety analysis and risk assessment requirements in transportation

engineering domain?

Very Familiar




2.3 How familiar are you with data/information flows patterns and needs within the scope of

traffic incident management lifecycle?

Very Familiar




318

2.4 Are you familiar with traffic incident management key processes, actors and their designated

roles?

Very Familiar




319

SECTION THREE: ABSTRACTION AND CATEGORIZATION EFFECTIVENESS

The following concepts are abstracted/categorized in the ontology. Please indicate if you agree

with the categorization. The super classes of each concept are listed for convenience.

Concept

Select only ONE option

Strongly

Agree Agree

Somewhat

Agree

Somewhat

Disagree Disagree

Strongly

Disagree

1 2 3 4 5 6

Landslide

Threat, Natural, Geophysical

Flooding

Threat, Natural, Hydrological

Driver Error

Threat, Man-Driven, Non-intentional, Human-error

Facility Sabotage

Threat, Man-Driven, Intentional, Vandalism

Sharp Curve

Vulnerability, Physical, Geometric

Low Ignition Point

Vulnerability, Physiochemical

Low Yield Strength

Vulnerability, Mechanistic

Collision Incident

Incident, Driver-vehicle Unit, Collision

Bridge Collapse

Incident, Road-Facility, Collapse (Partial, Full)

Snow Blockage

Incident, Weather-related, Roadway-Blockage (Full, Partial)

Roadside barrier damage

Impact, Direct, Physical, Facility Damage (Minor, Full, Partial)

320

Concept


Strongly

Agree Agree

Somewhat

Agree

Somewhat

Disagree Disagree

Strongly

Disagree

1 2 3 4 5 6

Personal Injury

Impact, Direct, Health/Life, Injury

Total Travel Delay

Impact, Direct, Operational, Travel Delay

Occurrence Time

Incident Attribute, Temporal, Occurrence Time

Scene Protection

Incident Management Process, Core, Law Enforcement Process, Scene Protection

Traffic Management

Incident Management Process, Core, Traffic Management,

Roadway debris removal

Incident Management Process, Core, Clearance, Debris Removal

Ontario Provisional Police

Actor, Organizational, Law Enforcement

321

SECTION FOUR: NAVIGATIONAL EASE

The following 15 concepts are categorized under different classes. Please indicate how easy you

can locate these concepts in class taxonomy?

Concept


Very Easy Easy Moderately Easy

Moderately Difficult

Difficult Very Difficult

1 2 3 4 5 6

Slope Failure

Waterspout

Rear end collision

Recovery Time

Detour Management

Design Error

Emotional Stress

Verification Time

HAZMAT Team

EMT-Basic

Trooper Officer

Fire/Rescue

Run-off-road

Fatality

Communication Officer

322

SECTION FIVE: ABSTRACTION AND CATEGORIZATION EFFECTIVENESS The following concepts are abstracted/categorized in the ontology. Please indicate if you agree

with the categorization. The super classes of each concept are listed for convenience.

Question Rating Scale (best to worst)

1 2 3 4 5 6

How easy was it to navigate through ontology?

How familiar were the concepts used?

How representative were the concepts used?

Overall, did the ontology cover the main concepts

pertaining to traffic incident management?

323

APPEDNIX-G: SWIMS FOCUS GROUP QUESTIONNAIRE

SEMANTIC WEB INCIDENT MANAGEMENT SYSTEM EVALUATIO QUESTIONNAIRE

FOCUS GROUP

INVESTIGATROS



324


The scope underlying this survey is to evaluate the developed multi-agent system for traffic

incident management. Expert opinion is crucial for the initial evaluation of the prototype.






7. THE SURVEY

The survey should take approximately 5-10 minutes to complete. It is comprised of 5 sections:


Section 2: Evaluation

325



RESPONDENT DATA LOG

Name:

Title/Position:

Organization Name:



Phone:

E-mail:

Interview Date: / /


Yes No

326

SECTION TWO: EVALUATION

Based on the information provided during the focus group, please answer the following questions,

in the context of collaborative, integrated, and coordinated incident management response.

6. How representative the workflow deployed by this application to real life scenarios carried out within the context of your organization? Strongly Representative (1)

Representative (2)

Somewhat Representative (3)

Somewhat Unrepresentative (4)

Unrepresentative (5)

Strongly Unrepresentative (6)

7. Do you agree that all major stakeholders involved in the incident management process were well represented in the system? Strongly Agree (1)

Agree (2)

Somewhat Agree (3)

Somewhat Disagree (4)

Disagree (5)

Strongly Disagree (6)

8. Do you agree that all incident-related information needs from your organization perspective is well covered by the system? Strongly Agree (1)

Agree (2)

Somewhat Agree (3)


Disagree (5)


9. Do you agree with the decision rules encoded in the software agent the best represent your organization? Strongly Agree (1)

Agree (2)

Somewhat Agree (3)


Disagree (5)


10. Do you agree with the outcome (i.e. Is it reasonable and represent reality?) of the decision rules encoded in the software agent the best represent your organization? Strongly Agree (1)

Agree (2)

Somewhat Agree (3)


Disagree (5)


327

11. Do you agree that this system prompt timely and optimized response compared to currently deployed systems? Strongly Agree (1)

Agree (2)

Somewhat Agree (3)


Disagree (5)


12. How useful do you think this type of software multi-agent portals will be as a tool for supporting the creation of integrated traffic management system? Very Useful (1)

Useful (2)

Somewhat Useful (3)

Somewhat Un-useful (4)

Un-useful (5)

Very Un-useful (6)

13. Based on the given incident scenario, how necessary is the social web applications integration to the incident management system from your organization perspective? Very Useful (1)

Useful (2)

Somewhat Useful (3)


Un-useful (5)

Very Un-useful (6)

14. How friendly was the user interface of SWIMS, compared to other information systems used in your organization? Very Friendly (1)

Friendly (2)

Somewhat Friendly (3)

Somewhat Unfriendly (4)

Unfriendly (5)

Very Unfriendly (6)

15. Overall, how easy to use do you think this type of portal will be?

Very easy (1)

easy (2)

Somewhat easy (3)

Somewhat Uneasy (4)

Uneasy (5)

Very Uneasy (6)

16. Overall, how useful do you think this type of portal will be in supporting semantic process representation and integration in the traffic incident management domain for enhanced communication, coordination, and collaboration among various involved stakeholders? Very Useful (1)

Useful (2)

Somewhat Useful (3)


Un-useful (5)

Very Un-useful (6)

semantic web based multi-agent framework for real … › bitstream › 1807 › 32645 › 5 ›...

Documents