Intelligent Road Emergency Response System using GAIA and JADE

Intelligent Road Emergency Response System using GAIA and JADE

Igulu, Kingsley Theophilus Dept of Computer Science, Ken Saro-Wiwa Polytechnic Bori-Nigeria

Eke. B.O.

Dept of Computer Science, University of Port Harcourt Port Harcourt-Nigeria

Ogheneovo. E. E Dept of Computer Science, University of Port Harcourt

Port Harcourt-Nigeria

Abstract Emergency or crisis never occurs with earlier intimations and signs. In the real world and practical life, detecting and perceiving emergencies or mishap and reporting them are a genuine test and tough challenge. The spate of lethal street mishaps in Nigeria is extraordinary. Pattern examination of lethal street mishaps between June 2006 and May, 2014 utilizing Nigeria Watch database demonstrates that 15,090 lives were lost to deadly auto collisions in 3,075 occasions. The most elevated casualty happened in 2013 (2,061 incidents) and a 2.8% expansion from 2012 record of 1,652 incidents[1]. Most Response Systems seen in literature take into consideration of the peculiarity of the locations and there exist none for Nigerian situation. This work Intelligent Road Emergency Response System is developed to aid rapid emergency response. The system adopts a new paradigm of software engineering- The Agent-oriented software engineering (ABSE). Through real-time location and status updates using integrated sensors of a mobile phone, the system has significantly decreased emergency response times and improve the overall effectiveness of emergency responses and at large emergency management.

Keyword:- Emergency; crisis; disaster; management; agent; MAS; jade; gaia; intelligent; system

1. INTRODUCTION

   Emergency does not start with earlier warnings and indications. Practically, identifying emergencies and adequately reporting the emergencies are a true test and tough job. Crisis management organizations (either private or government) have a common goal-i.e. to implement emergency plans and make provisions for rescuing of those who are involved crises[2]. However, the difficult challenge as reported by many emergency and disaster rescue teams is that they scarcely receive the right data in right time. It implies that often, emergency response teams will be unable to retrieve the right data for the period of disaster. Hence, delay in information acquisition about crisis as the incident happens results to delay of the rescuing process and saving lives. Now-a-days faster technology and real intelligent systems have made humans live more comfortably. Smartphone is one out of such technologies that has different functionalities of users benefits and use [3][4].

   While largescale disasters/crisis present huge response complexity, even less casualty emergencies need a better way

   for exchange of information between emergency management personnel. Aside from direct communication, radio transmissions are commonly used medium for communication during emergencies. However, this form of data distribution have problems that are almost impossible to deal with on a scene. Most of these issues include poor quality of sound, poor transmissions, the inaccessibility to a radio microphone, and the transient condition of messages from radio.

   Most systems that collect and present response data have been implemented lack interoperability and some do not possess a full array of relevant services for emergency management. Moreover, most of the systems run on software and hardware that are generally poorly designed for emergency response circumstances. Pervasive devices, which might transmit information with less or no human interaction, and applications that use open communication procedures designed for variation of platforms with form factors constitute the two critical elements.

   In emergency instances, a person who is already in crises will be unable to report his/her condition to an emergency response team. This is a most stranded situation where persons in such critical emergency situation need help but disadvantaged to search for it. It is believed that using latest sophisticated tools and emerging technologies like smart devices powered with highly sophisticated sensors, any disaster or emergency can be detected and automatically reported to an emergency response team[2]. Emergency response individuals or teams can easily be of help to the individuals in such emergency situation. To accomplish this goal of automated response, the proposed system will rely on embedded sensor hardware technologies. At this stage of the research, we intend to produce a mobile application to handle this problem.

2. LITERATURE REVIEW

   1. Historical Background to Emergencies

      Numerous researchers state that catastrophes happened in mankind's history from the earliest starting point. For instance, the flooding occurrence associated with the scriptural story of Noah's Ark is asserted by numerous individuals as been precisely and dependably depicted in the

      Bible. Notwithstanding contentions and fantasies, calamities were first recorded in mankind's history as per most recent logical guidelines in 430 B.C., when Athens (Greece) encountered the cataclysmic impacts of a typhus scourge. While the data accessible is now and again both dubious and uncertain, catastrophes (either common or man-made) have been consistently hurting social orders all through written history[5]. reports a broad rundown of the world's most noticeably awful catastrophes experienced by humankind. The rundown involves in excess of 200 occasions, stretching out from 430 B.C. to 2008, and incorporates debacles, for example, given in table 1.

      S/n	Disaster	Country	Year
      1	Famines	Japan	1181
      2	volcanic eruptions	Italy	1631
      3	yellow fever	Cuba	1648
      4	Plagues	Russia	1654
      5	Cholera	Russia	1830
      6	cyclones	India	1864
      7	Smallpox	France and Germany	1870
      8	typhoons	China	1881
      9	influenza pandemics	worldwide	1957
      10	river floods	Vietnam	1971
      11	sea floods	Bangladesh	1970
      12	heat waves	USA	1995
      13	earthquakes	Japan	1995
      14	meningitis	West Africa	1996
      15	Tsunamis	Asia	2004
      16	hurricanes	USA	2005
      17	Earthquake	China	2008
      18	Earthquake	Haiti	2010
      19	Heat wave	India	2015

      S/n	Disaster	Country	Yar
      1	Famines	Japan	1181
      2	volcanic eruptions	Italy	1631
      3	yellow fever	Cuba	1648
      4	Plagues	Russia	1654
      5	Cholera	Russia	1830
      6	cyclones	India	1864
      7	Smallpox	France and Germany	1870
      8	typhoons	China	1881
      9	influenza pandemics	worldwide	1957
      10	river floods	Vietnam	1971
      11	sea floods	Bangladesh	1970
      12	heat waves	USA	1995
      13	earthquakes	Japan	1995
      14	meningitis	West Africa	1996
      15	Tsunamis	Asia	2004
      16	hurricanes	USA	2005
      17	Earthquake	China	2008
      18	Earthquake	Haiti	2010
      19	Heat wave	India	2015

      Table 1. Historic Disasters

   2. Emergency Management

      Despite the fact that dissimilarities and similitudes between such terms as crisis, calamity and emergency could be examined in detail. At first, a methodology will be taken here of demonstrating basically that crises, emergencies and calamities/disasters are for the most part distressful circumstances in which arrangement of occasions have or can have exceptionally negative ramifications for individuals, societal capacities or principal human qualities. The course of events then is such that they result in loss of human lives and/or in harm to health and/or property and/or to the environment as well as lead to immediate existential difficulties and/or in the neglect of legal or constitutional rights to name various types of consequences that can ensue. Emergency Management (EM) is an area which involves a number of actors and dimensions. The actors could be government institutions, non-government or academic institutions. Although there is a general understanding of emergency management, each actor has its own way of defining emergency management and hence it can become a confusing concept.

      As per [6], the 9/11 attack can be considered as a disaster due to the figure of deaths recorded and the widespread destruction, although response support was not requested from other countries, as it was the case with the Asian disaster. However, the term emergency is also viewed as an incidents which can or do cause disruption to the community, and various countries have similar definitions of an emergency. According to the UKs Civil Contingency Act

      (CCA)[7], an emergency is seen to be an event or any situation that threatens huge damage to the welfare of humans in a given geographical locality and to the surrounding of the place, or war, or terrorist act that threatens huge damage to security requiring execution of distinctive arrangements by either one or additional category 1 responders [7]. This definition is similar to that used in Australia, where emergency is considered as an event either actual or imminent, that threatens to endanger or endangers property or the environment, life and which needs a huge quantity and coordinated response[8]. So hazardous events may be known as 'accidents', 'incidents', 'emergencies', and 'disasters'; according to the scale of the event, the number of organizations involved and their capacity to survive using their normal resources [2]. In addition, there is another overlap between the terms emergency management and disaster management.

      As indicated by FEMA, the goal of EM incorporates sparing of lives, aversion of harm and security of property as well as the environment when and if an emergency ensues. Some academic definitions of EM also consider it as the complete process of preparing for, planning and intervention to rescue and liberate to reduce the effect of emergencies and generally the response and also the recovery mechanisms that are meant to be taken in with the view to mitigate significant effects for the nation and its people, which could include economic, social, or environmental, often via an Emergency Operation Centre (EOC)[9]. This definition focuses on the potential impacts (economic, social and environmental consequences) of emergencies on the community, and helps to emphasize the importance of planning and requisite preparedness framework for mitigating these and any potential impacts.

      Michigan Department of State Polices definition of EM will be adopted: an all-inclusive system of policies, practices, and procedures intended to protect people and property from the results or impacts of emergencies or disasters. This comprises programs, means, and abilities to mitigate against or moderate, get ready to, respond to, as well as recuperate from impacts of all hazards [10].

      This definition is embraced since it gives a thorough, clear and viable comprehension of what EM is from an all encompassing point of view of practice and theory. Furthermore, it provides a general framework for virtually all kinds of hazards and the four (4) phases of EM.

   3. Phases of Emergency Management

      Emergency management is commonly seen in four phases viz-a-viz- mitigation, preparedness, response as well as recovery [11][12]. These phases are closely related to each other and are sometimes difficult to draw a dichotomy. [11] posited that the word phases may be misleading and could be substituted with for example functional activities. These phases are explained as the comprehensive principle of EM which is widely used across the world for emergency management or disaster management[12]. Although a wide variety of terminologies are often used to describe them, effective emergency management utilizes each component in the following manner:

      Mitigation: has to do with mitigating, reducing or eliminating either the likelihood or the impacts of a hazard, or both. Mitigation tries to treat the peril such that it does not impact society to a higher degree. Mitigation involves non- structural and structural measures[13]. [14] formally defines mitigation as sustained actions engaged to eliminate or lessen risks and affects well before a given emergency or disaster takes place.

      Numerous frameworks and projects proposed different paradigms for mitigation as it is acknowledged that future disasters cannot be exactly predicted. For instance, [15] provided to the general public a consistent methodology and software (HAZUS-MH) containing models to estimate loses due to an amount of events (such as flooding, earthquakes, hurricane).

      In summary, mitigation can then be defined as a group of activities engaged in before an extreme event in so as to comprehend the relationships between communities (people and systems) and the surrounding physical environment. Such an approach has already been proven successful for disasters prevention and reduction.

      Preparedness: involves equipping people (the community) who may likely have the effect of a tragedy or disaster and agencies and organizations that would aid or assist those affected with the tools and tactics to improve the opportunities of their survival and to miniize any financial and other losses. This phase involves several stakeholders and thus has some essential elements which are designed to make the preparedness phase more result driven [16]. The preparedness phase is the focus of this research because it is critical for helping the community, emergency agencies and organizations to be ready for any emergency [17]. It is also the focus of this research because it determines what is done during the response phase, so if the preparedness phase is inadequate, response to the emergency will also be inadequate or ineffective [18].

      Response: involves undertaking action to decrease or eliminate the results of disasters which have occurred or are occurring to prevent further suffering, financial loss, or both combined. The term relief, commonly used in international emergency management, is amongst the components of response. The organisation of this phase requires certain level of skills and expertise because of the level of risk and danger that might be involved [19][20].

      1. Roles of Emergency Response Personnel

         The phases or stages of EM require that individuals or groups should directly facilitate actions[18]. [17] emphasised that the role of emergency response personnel is to commence emergency response actions which are based on laid down emergency procedures. However, [21] argued that for this to take place, emergency response personnel have a responsibility to assess risks, to develop and maintain plans, to communicate with the public, promote business and crisis continuity plans, share information, and collaborate with other responding agencies who can provide support during response to emergencies.

         Recovery: involves returning the lives of those affected to a standard state after the impact and consequences of the disaster. This phase usually starts after the response activities have come to an end, and can take months or years to complete [12].

   4. Related Work

   The application of Agent-Based simulation (ABS) to emergency response started towards the end of 1990s. Specifically, the yearly RoboCup Rescue simulation contest was initiated in 1999, which was inspired by the Kobe Earthquake in 1996[22]. Contestants are asked to design behaviors for ambulance, fire and police service agents for the objective of exploiting an amalgamated score which reflects the health of casualties and destruction to properties in a city [23][24][25][26]. RoboCup Rescue has in literature been depicted as being concerned with designing smart and fast algorithms, without examining a present human social system as it happens and designs a public policy to be used for it. [27]. With its intention on normative behavior, RoboCup Rescue and even other ABSs of like nature are of limited importance to our work. Thus, the brief summary to follow of ABS for emergency response focuses on work most closely related to that that will be developed in this research, specifically involving agents exhibiting descriptive behavior. For a more wide-ranging review of the applications and implementations of ABS in emergency management, the readers may refer [28][29].

   SimGenis supports the assessment of French emergency saving plans in broad large-scale disaster circumstances[30]. Here, autonomous agents are defined as rescuers or victims(doctors, firemen, nurses, and managers) are symbolized in a virtual incident location comprising of a grid of cells, considered as normal, obstacle or danger. Victim autonomous agents are inanimate and reactive in the sense that they are characterized by a continuously evolving amount of health according to five(5) heuristic rules based on their location, and the rescuers mediation and treatment. Rescuer agents behavior is modelled according to fourteen

   (14) heuristic rules connected to disaster site exploration for victims, on site treatment, victim relocation to advanced medical points and evacuation to hospital, ambulance routings, and the management of unified but distributed rescue. Simulation experiments included either a unified decision making rescue policy with the incident site considered as a zone or a distributed decision making rescue policy with the incident site considered as four zones, in addition with messaging through paper forms or electronic means. For each simulation example, seven configurations were used with between 73200 victims in various status of health and 35150 rescuers. In all simulations, the valuation measures used were minimize global victim evacuation time and make the most of rescue rate. A finding of this work is reported as there being no best rescue plan since this relies on the disaster configuration.

   Planning with Large Agent Networks against Catastrophes (PLAN-C) is a stochastic agent inspired by model for urban catastrophe simulation and emergency planning [31] and has been used to simulate and assess deviations of a hypothetical

   Sarin attack on Manhattan island, New York City [32] and a food poisoning eruption in Minas Gerais, Brazil [33]. PLAN- C's GIS-based environment is denoted as a graph with vertices suggesting particular points including hospitals. Within the environment, an agent can denote a person, an onsite treatment unit, a hospital, an ambulance and the catastrophe or disaster itself. Based on a Sarin gas attack simulation involving 1000 people, 22 hospitals and 5 onsite responder units, a number of connections involving mortality rate have been established [32]. They include connections between the number of fatalities and (i) person behavior with health status at which a person goes to hospital, and extent of worry and level of obedience, (ii) hospital behavior such as resource status, and criteria at which health level to discharge a patient, and (iii) the rate which people are updated with hospital information.

   The Autonomous Robots for Observation of Urban Networks after Disasters (AROUND) project entailed the development of an Agent-based Simulation (ABS) which mimics the ambulance response during post earthquake circumstances in Vietnam [34], and has been recommended to aid decision makers in search and rescue in developing countries[35]. A rescue model, based on the GAMA (GIS and Agent based Modelling Architecture) platform[36], has been developed to offer an environment for simulations. In this model, buildings, hospitals and ambulances are represented as agents, in addition to fire fighters, police officers and victims. As an example, ambulance agents show certain behaviors and follow decision strategies to minimize loss of life including determining choices such as which casualty an ambulance will collect and to which hospital they should be taken. These strategies are based on the agent's local view of the situation and, thus, can be sub-optimal. However, an expert can intervene, via an interactive interface, if he/she identifies a better course of action for an ambulance agent. Based on such interventions, the agents can acquire expert knowledge using adapted machine learning algorithms leading to new decision strategies, which can be used in similar future situations.

   CrisisCoordSim is an ABS for investigating different crisis response coordination mechanisms in the Netherlands, specifically hierarchically mediated coordination and autonomous mutual adjustment [37][38]. The ABS couples a discrete event simulation environment with an agent-based model of the response organization, which includes agents representing firemen and medics along with their respective commanders. Thirty-two scenarios were defined by combinations of number of civilians, firemen and medics, allied with mechanisms for rescue coordination (mediation and mutual adjustment) and assignment coordination (mediated or autonomous assignment of firemen)[39]. Each scenario response was measured in terms of effectiveness and coordination cost with the former consisting of response time, number of civilians affected and number of fatalities, and the latter being the volume of messages exchanged among agents within and btween the fire and medical services. Based on an analysis of the experimental results, a series of insights were offered in relation to the impact of the configuration of coordination mechanisms on the response metrics being assessed.

   Simulation of the Tactical and Operational Response to Major Incidents (STORMI) is an Agent-Based Simulation(ABS) based on official United Kingdom emergency response literature. This ABS provides a contribution in the form of the level of detail of the natures of response modelled combined with the behaviors of agents for Seventeen(17) different emergency first responders. More also, with respect to implementation, the ABS system uses Ordnance Survey MasterMap Geographic Information System (GIS) files [40] in a way that a virtual geographical setting of any region of the UK can be constructed hence offering the flexibility to model major incidents in any location[41]. It includes three(3) major component viz (1) the Scenario Designer which permits users to set up a imaginary single or multi-location incident wherever in the United Kingdom using Ordnance Survey MasterMap's Topography Layer and Integrated Transport Network Layer; (2) the Simulator which allows the response to the incident to be simulated; (3) the Response Designer enables the user to design the prearranged attendances describing which resources go to each incident location during the simulation[42].

   From the forgoing, it can be observed that all the systems are either specific to a country or/and generic. It can also be observed that the systems do not necessarily follow the Agent-based Software Engineering (ABSE) paradigm though they are ABS. Our work will take into cognizant the peculiarity of the Nigerian Emergency situation. The proposed system will also follow ABSE principle for analysis, design and implementation. Via real-time location status regular updates using integrated sensors, this system can meaningfully reduce emergency response times and thereby increasing the overall performance of emergency responses and emergency management in general.

3. GAIA AND JADE

   The Initial proposed GAIA methodology comprises of two main iterative phases namely analysis and design. Gaia methodology does not explicitly handle requirement elicitation and does not necessarily disregard it. GAIA is typically open to any platform chosen for implementation[43]. Empirically, it has been shown that it is better implemented with a platform that is FIPA complaint like JADE. The various phases, relationships and artefacts are as shown in the figure numbered 1.

   Figure 1. Gaia Phases and relationships

   1. The Analysis Phase of Gaia

      The analysis phase entails building conceptual and abstract models that may necessarily not have direct impacts on the system. It presumes that the system analyst has conceptualised the problem and is unambiguous of what the system is expected to do and not do. Here, roles are identified, and their communications or interactions are modelled. The two artefacts produced(output) at the close of the GAIA analysis phase are 1. role models and 2. interaction models. The descriptions of the role may not be comprehensive at this point (analysis stage).

      1. Role Model

         Roles comprise of four attributes-responsibilities, protocols, activities and permissions.

         Responsibilities are a vital attribute of a given role because they define the functionality. Meanwhile responsibilities are in two kinds; the liveness properties and the safety properties. Liveness properties means that the role should add (improvement) something benefiting to the system whereas safety properties means that the role should prevent and disallow that nothing bad happens to or affects the system.

         Permissions are the necessary rights linked with or connected to a role. They recognize the resources accessible by that role to achieve its responsibilities.

         Activities are computations associated or connected with a role that might be implemented or undertaken by the agent void of interactions with another agent(s). Activities are therefore reserved actions. Meaning they are actions that start and end within the initiating agent.

         Protocols are generally computations that necessitate interaction with another agent.

         Figure 2 shows the various attributes of a role. Every role is documented. Table 2 shows the role schema which documents all the attributes of the role. Documentation of the various interactions in the system is represented in the protocol model. Figure 3 is a typical schema of an interaction model.

      2. Interaction Model

         The model consists of definitions for the various set of protocols; there is a one-to-one mapping of the protocols to each form of inter-role interaction. Here, a protocol is regarded as an institutionalised form of interaction.

         The definition of a protocol consists of the following;

         Purpose: a Short textual narrative of the sort of the interaction (e.g., AllocateCourses [44]);

         Initiator: the role (s) responsible for starting the interaction (e.g. admin [44]);

         Responder: the role (s) with which the initiator interacts (e.g., allocator role [44]);

         Inputs: Information used by the role initiator while enacting the protocol (list of courses to be allocated [44]);

         Output: Information delivered by/to the responder of the protocol during the interaction (e.g., allocation chart [44]); Processing: a short textual narrative of any processing that the protocol initiator executes in the course of the computation.

   2. Gaia Design Phase

      The analysis stage or phase is the conceptualisation of the system. It produces the input for the design phase. The activities of design phase involve the transformation of the abstract entities (represented in role and interaction models) of the analysis stage or phase to concrete entities that may have a direct bearing on the realisation of the system. In this phase the three major artefacts are identified; agent type model, service model, and the acquaintance model.

      1. Agent Type

         Agent types are the equivalents of objects in the object- oriented paradigm. They are elementary design components of a typical ABS-agent-based system including their realisation at runtime in agent instances. Agent types in the system are well-defined by the roles that they play.

         In most cases, there is a one-to-one mapping between from role to agent types. Gaia represents Agent Type with a rectangle, and a role with an oval see figure 4.

         GAIA uses annotations to represent the number of instances of such agent mapped and a directed edge from role to the agent as in table 3.

         Protocol name		Inputs
         Initiator	Responder
         Processing		Outputs

         Figure 3. Protocol Schema

         Agent Type N ,m..n, *, +

         Role Schema: RoleName
         Description	Short textual description of the role
         Protocols and Activities	Protocols and activities in that the role plays a part.
         Permissions	Rights associated with the role.
         Responsibilities	Liveness: liveness properties
         	Safety: safety properties

         Role Schema: RoleName
         Description	Short textual description of the role
         Protocols and Activities	Protocols and activities in that the role plays a part.
         Permissions	Rights associated with the role.
         Responsibilities	Liveness: liveness properties
         	Safety: safety properties

         Figure 2 Role with its attributes Table 2. Role Schema for documentation

         Role

         Figure 4. Agent model

         Table 4. Instance Annotations

         Qualifier	Description
         N	There will be precisely n instances of such agent in the entire system
         m..n	This means that there will be between m agent instances and n instances of the agent
         *	The system will have either no agent instance or greater than zero instances of the agent
         +	There will be either 1 instance or more than 1 instances of the agent

      2. Service Model

         Another artefact developed in GAIA methodology design stage is a service model. The service model describes the services provided by roles. A service is seen as a coherent but single chunk of activity that agents will participate in. Each service would be characterised by its properties namely pre- conditions, post-conditions, inputs and outputs. Inputs and outputs are derivative of the protocol model.

      3. Acquaintances Model

   The acquaintance model is the last model which the engineer need to complete. It shows the interaction links that exist between agent types. It is, in fact, a directed graph whose nodes denote agent types and edges indicate communication pathways.

4. JADE

   JADE is an agent software development framework completely implemented using the Java language and it is meant for the engineering of multi-agent systems as well as applications that conform to the standards of FIPA for intelligent agents[45]. JADE offers standard and extensive agent technologies and provides developer some features to streamline the engineering process:

   • Distributed agent platform: The agent platform will be capable of been distributed on numerous hosts. Each of the host houses a Java virtual machine(JVM).

   • FIPA-compliant agent platform: This consist of the agent management system(AMS), a yellow page server- directory facilitator, and agent communication channel(ACC) [46].

   • Effective agent communication language messages transport between agents [46].

   All inter-agent interactions are accomplished via messages passing. FIPA ACL is used to embody the messages. Agents are furnished with an inbox (i.e. incoming message box). Message polling is either by blocking or non-blocking with option for timeout.

   Besides, JADE offers methods (functions) for filtering messages. The programmer can apply more filters on the fields of incoming messages which may include sender, ontology or performative.

   1. Jade Architecture

      Jade, being a FIPA complaint framework hides some core tasks that a programmer would have found repetitive and difficult. Jade consists of agents that can be scattered in different agent container or/and platforms. Each platform may house one or more containers. However, platform must have the Main container which serves as the bootstrap point of a platform: it is the foremost container to be launched and

      all others must join to a main container by a means of registration with it.

      Among many, the main container does the following:

      • manages a table called container table (CT)

      • Manages the global agent descriptor table (GADT)

      • Hosts the two special agents-AMS as well as the DF that offer the agent management as well as white page service, and the yellow page service (default) of the platform, respectively.

        Figure 5 shows the constituents components of the architecture of JADE. Jade also contains tools to support debugging: dummy agent, remote monitoring agent, sniffer agent etc.

        Other features of JADE include:

      • A model for asynchronous programming in agents.

      • Seamless interaction among agents on the same and also on another platforms.

      • Security, Mobility, and other utilities

      • Features that enhances the development of customized applications while exploiting Agent metaphor

      • Has interface between the agent framework and JAVA GUI applications

      • The key advantages of JADE over other frameworks are:

      • It provides supports for mobile platforms

      • Strong development and support team

      • Open source

      • It implements a graphical runtime backend

      • FIPA-compliant

      • Ontologies

      • Interaction protocols as indicated by FIPA

      • custom interaction protocols can effortlessly be introduced

      • Unnecessary to implement a fresh Agent Platform as well as Agent Services

      • The framework handles agent-management ontology as well as functionalities

        • An agent registers with a particular Agent Platform

        • It is given a name and a unique address

        • The Agent class gives a simplified interface to access the services of the Directory Facilitator (searching, registration)

      • Message Transport as well as Parsing

        • Spontaneously (and possibly proficiently) handled by the framework while sending/receiving messages

      • Interaction Protocols should only be inherited via handle methods

      • JADE shades FIPA standards from the Programmer.

   Figure 5 Jade architecture [45]

   1. Agent Naming in JADE

      An agent in JADE is recognized through an extensible set of parameter-value tuple, known as Agent Identifier (AID) that is meant to the container. The AID consists of:

      • Its name.

      • Additional parameters, like identifier resolution service addresses, transport addresses, and so on.

      An agents name is immutable but other parameters in agents AID are mutable. A particular agent might support some methods of communication as well as adding multiple transport values in the :addresses parameter of the AID.

      Agents are also globally identified with a unique name. JADE composes the name by default as a combination of the local name with the '@' symbol, and the owner agent platform identifier i.e. <hostname> ':' <port number of the JADE RMI registry> '/' 'JADE') i.e. Igulu@Igulu-PC:1099/JADE.

   2. JADE Agent Lifecycle

      An agent in JADE framework can assume one of the states in figure 6 in accordance to FIPA specification of Agent Platform Life Cycle.

      INITIATED : Here the agent instance is built but it has not been registered to the Agent Management Service (AMS). In this state, the agent has no name and no address and therefore cannot talk with other agents.

      ACTIVE : Here an agent instance has been registered with AMS. The agent has a common name and corresponding address. Therefore can have access to all JADE features.

      SUSPENDED :Here, the Agent instance is presently stopped. The internal thread is suspended. Again none of the agent behavior can be executed as long the agent instance remains suspended.

      WAITING : Here, the agent instance is blocked and waits for something. The agents internal threads are sleeping and will wake-up when and if certain condition is fulfilled (mostly message arrives).

      DELETED : In this state, an Agent is certainly dead. The agent internal thread has terminated execution. Here the Agent has been deregistered with AMS.

      TRANSIT: An agent assumes this state when it migrates to the new environment(platform or container). The MAS continues message buffering which will be later sent to its new environment.

      Figure 6. Jade Agent LifeCycle

   3. FIPA and JADE

   In the roadmap to standardization, Foundation for Intelligent Physical Agent (FIPA) was established in 1996 by Computer Society arm of IEEE. FIPA is purely a non-profit international organizatio to provide standards for software agent technology.

   FIPA is a conglomeration of academia and industry to provide guiding principles that will be the bedrock for engineering software agent technologies.

   At the central of FIPA is the following set of principles:

   1. Agent technologies provide a new paradigm to solve extent and future problems;

   2. To make agent technologies get considerable degree of maturity;

   3. To be of use some agent technologies require standardization;

   4. Regularization of all-purpose technologies indicates a high level of possibility and provide operative results in other standardization fora;

   5. The standardization of the core mechanisms of agents is not the principal concern, but somewhat the infrastructure as well as the language needed for open effective interoperation.

   FIPA standards are now been followed by the agent community. Jade is one of the popular tools to developing intelligent entities. It is a FIPA compliant framework that is built on Java programming language. The Jade has got a large community because of its FIPA compliance. The popularity is also achieved because JADE is an open source project.

5. INTELLIGENT ROAD EMERGENCY RESPONSE SYSTEM

   1. Existing System

      Current or existing system for solving the emergency problem involves person-to-person communication through the medium of mobile phone calls or mere text messages on

      sight from bystanders. This solution constituted the risk of victim getting on critical or even losing the paramedic or first responders may not get there in time.

      There is also the factor or risk of victims being alone in the incident with no one to call the paramedics. However, software solutions has been built over time to handle this problem and mitigate the risks by introducing automatic alert to family, loved ones and paramedics alike, although proven successful to a certain degree, still there has been the limitation of communication because the existing systems sends little information for in-depth analysis and victim health records to help the paramedics come prepared in special cases as well as making sure the messages arrive on time. We improve on the work of[47]. Notable shortcomings of the current or existing system is the strict reliance on internet and mobile network services. The Nigerian case of internet and telecommunication mobile services is epileptic. There are so many locations that do not have network services.

   2. Proposed System

      The proposed system tackles the problems of the current or existing system by using state of the art cloud networking infrastructure to handle, and process accidents response requests and making sure the paramedics are notified and also responses are attended promptly.

      As in [47], the system uses the smartphone accelerator to extract the Geographical Positioning System (GPS) of the location of an incident and prepares a payload and sends to the Internet of Things(IoT) server for processing. In absence of internet connection, the the proposed system sends an sms as a fallback when no internet connection to the server and the server handles this information signaling and alert all paramedics to the rescue.

      While existing system sends this information to family and friends of the victim as a fallback. The impact of this procedure has been proven to be ineffective over time as there is issue of unavailability of the loved on where cell phones are switched off or no network coverage or simply not near the cell phone. A special case could be case of late message delivery and also no unit on the senders cell phone to send the message. Figures 7 and 8 show the architecture of the system from agent and non-agent perspectives respectively.

      Figure 7. Architecture of the proposed system from agent perspective

      Figure 7. Architecture of the system from non-agent perspective

      Accident Detection

      The detection phase depends on the data extracted from the accelerometer sensor of the smartphone and its GPS receiver are used to determine car accident occurrence.

      Smartphone Accelerometer sensor: The detection phase constantly retrieves information from the accelerometer sensor to track the G-force (i.e. force due to acceleration) experienced by the cars occupants.

      Smartphone GPS receiver: The detection phase also constantly extracts GPS information to determine the speed of the vehicle.

      The speed of the vehicle is used to enhance the probability of accurately identifying an accident using the accelerometer sensor data or information.

      The most important criterion that is used by car accident detectors or detecting systems to detecting car accidents is the G-Force value above 4G [48], experienced by accelerometer sensor of smartphone. Furthermore, (Krafft et al., 2005) emphasized that from series of studies have been performed rear-ended impacts with volunteers; the data used in these studies indicate a exclusive opportunity to ascertain how acceleration impacts the risk of harm in accidents. The outcomes are shown that most car occupants suffer from neurological complications, had a average acceleration above 4G. Truly G-Force value is not sufficient evidence to ascertain car accident, which would lead to false positive sign. The proposed detection phase running inside the smartphone however constantly samples and reads the smartphone accelerometer sensor to detect collision. For accident cases, the smartphone will definitely experience equal acceleration force that the occupants of the car experienced. This is because mobile phones are regularly carried in a pockets attached to vehicle occupants[48]. In reality, there are so many issues that have to be considered during the accident detection phase. These issues are listed and analyzed as follows:

      1. To filter out acceleration values caused by dropping the phone inside the vehicle or sudden stop, whose acceleration values could be interpreted as car accident, the empirical results mentioned in[48] showed when the smartphone is dropped inside the vehicle, it experiences approximately 2Gs on the y-

         axis and z-axis with nearly 3Gs on the x-axis before it is reset. Also in case of sudden stop (braking due to emergency) that does not eventuate into a crash or accident, the acceleration force experienced by the mobile phone is of less magnitude compared to the one experienced during the drop, it experiences approximately less than 1G's in each dimension. Consequently, 4G is chosen as acceleration force threshold value to overpower any false positives that may occur inside the vehicle.

      2. The most referenced system done in this field is triggered when the vehicle is at high speed of above

         24 km/h[48] and the smartphone acceleration experiences greater than 4G. This system did not take into consideration accident detection when the vehicle is moving at a comparatively low speed, below 24 km/h, which is not immune to accident. Consequently, another focus is the detection of vehicle accident at a low speed especially speed below 24 km/h, and the mobile phone experiences acceleration force greater than 4G.

      3. Also it is worthwhile to take into account some cases that cause false positives like accidental dropping the mobile phone whereas the user is outside the car and other false positives whose acceleration force values may be unknown. Thus to fix these issues and to also minimally reduce the false positives presented from these cases, other parameters are investigated and adopted to determine whether the phone is inside the vehicle or outside the vehicle.

   3. Parameters used in Detection

      Here the parameters used in detection of positive true accidents are discussed.

      High Speed Accident: The first parameter used in ascertaining that the user is inside the car is the high speed of the car (and also that of the smartphone). For instance if the speed of the car (as well as the mobile phone) s higher than the speed threshold value (24 km/h) it would signal that the user (as well as the mobile phone) is within the car. At the same time, any acceleration occurrence experienced by the mobile phone is larger than the acceleration threshold value (4G) and thus interpreted as indication of an accident.

      Low Speed Accident: Meanwhile, among all road-traffic accidents, about 90% happen at speed smaller than 14mph (22.53km/h), that cause severe injuries to the occupant[48]. Hence, the following two states illustrate the use of the proposed low speed parameters:

      1. The second parameter used to make sure that the user is inside the car is when the car is continuously travelling at a low speed, less than the speed threshold 24km/h, which is also subject to an accident. This parameter is called speed variation period which is used to measure the speed variation values in certain period of time while the whole speed is below the speed threshold (24 km/h). The idea behind that is when the traffic is oscillating, while it is below 24 km/h, the car wont last for such a long time at steady speed. Actually from practical

         tests, the speed variation period is chosen to be 30 seconds to indicate the user is still inside the car. In other hand, if the user is walking or slowly running while carrying a smartphone, then its speed variation is mostly different than when he is inside the car which is moving at a variation of a low speed mentioned above. To differentiate between the two states, the standard deviation is calculated of different speed values measured for each period of 30 seconds interleaved of 15 seconds from previous and successive speed variation period. From the practical experiments it is found that the standard deviation of different speed values, for the person who is walking, for the speed variation period, is ranging between 1.056 and 1.88, and the standard deviation, for the person who is slowly running is 2.06[47]. In [47], other experiments are conducted for the car travelling at various speeds under the threshold 24 km/h; it is found that the standard deviation for these experiments is ranging between

         2.9 and 7.7. Hence, if acceleration event experienced by the smartphone is greater than 4G and the standard deviation of the speed variation period parameter is greater than the threshold (2.06), then it indicates a sign of accident.

      2. More frequently occurs that the vehicle is traveling at a high speed and suddenly or gradually reduced its speed below speed threshold 24 km/h. Hence, in this case, the second parameter mentioned in step (a) above is used to handle this phenomenon. Actually the second parameter cannot be activated unless a certain period of time has been passing to allow for the standard deviation to be calculated. Therefore, the third parameter used to make sure that the user is inside the car (while the car is at a high speed and reduced to low speed) is the maximum period of time that the vehicle is travelling from the last location where the speed was reduced below the speed threshold 24 km/h. From the practical result, it is found that a maximum period of elapsed 30 seconds is quite sufficient to make sure that the user is unable to exit the car during the maximum period. This parameter, in particular, is used in case the speed of the car was exceeding the threshold and then was reduced to stop at intersections, traffic lights or due other unexpected events. Hence, if acceleration event experienced by the smartphone while the car speed reduced below 24 km/h is greater than 4G and the elapsed time is less than the above mentioned maximum period is occurred, then it is interpreted as a sign of an accident. Clearly, if the above mentioned maximum period is passed with no sign of accident, then this situation is handled by the second parameter explained in the step (a) above. Also the elapsed maximum period is taken into account in calculating the standard deviation of the interleaved speed variation period parameter mentioned in step (a) above.

   4. Analysis Using GAIA

      The analysis phase of Gaia consist of the role model and interaction model. The requirement statement is not regarded as part of the analysis phase as mentioned earlier but it is used as input to the analysis to easily identify the different roles required by the system.

      Five roles are noticeable for the analysis phase of our system namely; SMSManager(SM), InternetManager(IM), MobileDetector (MD), WearableDectector(WD) and Paramedic (P).

      SMSManager (SM) SM is invoked when there is no internet connections. It manages how to bundle the payload that will be sent to the server using local hardware gps.

      InterntManager (IM) Responsible for sending the incident location to IoT server.

      MobileDetector (MD) Using phone accelerometer, detects accident.

      WearableDetector(WD) Our system proposes a wearable device that will be used for the detection of health anomalies. Paramedic (P)- paramedic role is the respondent role. The IoT server processes the payload and broadcast to paramedic which in turn based on proximity responds to the emergency.

      1. Role Model

         After the identification of the roles comes the role model. A Role is made up of four attributes namely; responsibility, permission, activities and protocols. Because of space, we do not include all the roles models of the system.

         Figure 9 defines the role of Detector agent. This role is responsible to detect accident by determining the flip rate and speed of the phone via its accelerometer. Detail explanations are;

         1. Protocols and Activities for this role are; CheckSpeed- This protocol continuously checks the accelerometer and keeps sampling the speed and its variation. Accident is detected when the threshold is exceeded. CheckNetworkConnection This protocol checks connection as soon as the threshold is exceeded.

            ReadLocation This protocol extracts the location of the accident using the location services of the phone. This protocol depends on the CheckNetworkConnection protocol. Alert- This protocol is responsible for updating the Boolean accident signal.

            ExtractWeatherInfo-This protocol is responsible of extracting weather information of the location of the incident. The weather information include wind, humidity, temperature and visibility.

            Role Schema: MobileDetector (MD)

            Description: This role is responsible to detect accident by determining the flip rate and speed of the phone via its accelerometer.

            Protocols and Activities: CheckNetworkConnection, ReadLocation, CheckSpeed, CheckAccelerometer, ExtractWeatherInfo, PreparePayload, Alert, SendPayload

            Permissions: reads accelerometerValue, connection, location update weatherInfo, accidentStatus

            Responsibilities:

            Role Schema: MobileDetector (MD)

            Description: This role is responsible to detect accident by determining the flip rate and speed of the phone via its accelerometer.

            Protocols and Activities: CheckNetworkConnection, ReadLocation, CheckSpeed, CheckAccelerometer, ExtractWeatherInfo, PreparePayload, Alert, SendPayload

            Permissions: reads accelerometerValue, connection, location update weatherInfo, accidentStatus

            Responsibilities:

            PreparePayload- This is initial payload preparation with bare signal for emergency and the location values.

            Liveness: MOBILEDETECTOR = (Speed)

            SPEED=CheckSpeed.CheckAccelerometer.Alert CheckNetworkConnection.ReadLocation.ExtractWeatherInfo.Comp

            osePayload.SendPayload

            Safety:

            • Sensor/Accelerometer must be active Figure 9. MobileDetector Role

         2. Permissions for this role;

            reads accelerometerValue This is read and sved in a temporary structure and used to determine the threshold as described earlier.

            reads connection This is a Boolean variable that holds 1 when there is internet connection and zero when there is not. Reads location- This structure holds the location(latitude and longitude) values including other current weather values of the location.

         3. Responsibilities of the role are functions or actions to be taken in the correct order of execution. They are;

         1. Liveness CheckSpeed is assigned (Speed) which occurs most often endlessly as indicated by . The Speed consist of CheckSpeed.CheckAccelerometer.Alert.CheckNetworkCo nnection.ReadLocation.ExtractWeatherInfo.ComposePaylo ad.SendPayload which execute in this order because of the period (.). The period (.) indicates that the first executes before the second and second before the third and so forth.

         2. Safety this has to do with the precaution taken to ensure accurate result. In this case, the sensor and accelerometer must be active.

      2. Interaction Model

      The reliance and interaction between the different roles are presented in the analysis phase using the interaction model. This model shows the communication or links among the different roles. The protocol definitions are used to model the interaction between roles.

      Here we present just one of the protocols of the proposed system in figure 10.

      The explanations of protocol definition as presented in figure 10 are

      1. Purpose: Inquire(CheckAccelerometerRate)

      2. Initiator: Mobile Detector (MD)

      3. Responder: Internet Manager and SMS Manager(IM & SM)

      4. Input: Accelerometer sensor values

      5. Output: Emergency Status

      6. Processing: Continuously checks to confirm if threshold is exceeded.

      CheckAccelerometerRate		AccelerometerReading
      MD	IM, SM
      Checks the accelerometer value and sends same to IM and SM		readAccelerometerValue
      CheckConnectionStatus		Networkreading
      MD	IM, SM
      Checks the connection status to determine the particular role to communicate with		connectionStatus

      CheckAccelerometerRate		AccelerometerReading
      MD	IM, SM
      Checks the accelerometer value and sends same to IM and SM		readAccelerometerValue
      CheckConnectionStatus		Networkreading
      MD	IM, SM
      Checks the connection status to determine the particular role to communicate with		connectionStatus

      Figure 10. MobileDetector related Protocols

   5. IRERS Design Using Gaia

   The system design of Gaia receives its input from the analysis phase which is basically the conceptualization of the system. In the design phase, the abstract entities presented in the role and interaction models of the analysis phase are changed into concrete entities which impact directly on the actualization of the system. The design phase of Gaia methodology consists of three models namely; Agent Type, Service and Acquaintances models as stated earlier.

   1. Agent Model

      In Agent model, agent types are formed from the collection of roles. The agent type formed can be realized at runtime using agent instances which are all documented in the Agent model.

      In the system, we identified three agent types from the agent roles presented above. They are Detector, PayloadMgr and Paramedic agent types. Figure 11 shows the Agent Types, their roles mapping and instances. Paramedic Agent takes on the role Paramedic (P) and there can be one or more instances of it. Traffic Payload Agent takes on the roles SmsManager (SM) and Internet Manager (IM) and there can be only one instance. The Detector Agent takes on the roles-Wearable Detector and Mobile Detector and there can be exactly 1 instance.

      Figure 11. Agent Type Model

   2. Service Model

      The services related to each agent role, and the indication of the core services properties are recognized in the Gaia services model. A function can be considered as a service. Service is basically a particular, logical block of activity which is engaged by an agent.

   3. Acquaintances Model

   The definition of interaction links that is present among agent types are modelled in the acquaintance model of the Gaia design phase. The model is viewed as a directed graph wherein nodes correspond to agent types and arcs represent interaction pathways. It does not define what and when messages are sent but just indicate existence of pathways. One way interactions exist between Detector Agent and Payload manager Agent, and also between Payload Agent and Paramedic Agent. Also, there exist one way interaction

   between Detector Agent and Paramedic Agent. There are no potential communication bottlenecks.

6. IMPLEMENTATION, RESULTS AND DISCUSSIONS

As at the time of this research there is no standard programming language for ABSE yet ordinary OOP language like Java has framework which bolster the execution of Agent registering easily. Java programming language is utilized to execute the IRERS in this study. Java accompanies a MAS development framework called JADE (Java Agent DEvelopment Framework) which can be utilized to effortlessly interpret the GAIA configuration models into a MAS-dependent on ABSE approach. JADE accompanies ability to make android application which resembles a sub- system in JADE called JADE-ANDROID. We also utilized the capability of some application stack.

The IRERS is an Android application thus must be installed on phones or gadgets that use android OS before usage. Hence, it is essential to indicate the system requirements for effective functioning. It requires the following for maximum performance:

• Android 4.4 and above

• Mobile data

• GPS connection

• Geo-location

• Inbuilt phone accelerometer

No external hardware is required apart from the mobile phone.

1. Discussion

   IRERS being an android application, provides interfaces for the efficient use of the application. Except during registration, user does not necessarily need to open the app. The app runs as a background service until it detects accident. Nevertheless the Paramedics use the map for direction.

   The Intelligent Road Emergency Response System (IRERS) is software designed for users, particularly those in moving vehicles. It is designed to automatically detect road accidents after it occurs and request for help from emergency contacts of the user. The software runs on mobile phones since users are likely to move with their mobile phones most of the times.

   The main functions include, accessing users current location, speed of the vehicle, weather conditions of the current location, the G force and the longitude and latitude of the device for precise location in case of emergency.

   Although the software is designed to automatically detect accidents, it also has an emergency alert button which the user can manually trigger if need arises.

   The system was experimented by installing the app in some friends phones at different locations with different distances. For experimenter purposes, we reduced the flip rate threshold for accident detection. We observed that for within Port Harcourt metropolis and Bori main town where there is full network coverage and internet connection is on, the time of esponse for IRERS and the system of (Ali and Alwan, 2015) are the same with slight variations which is caused by their system using browser for paramedics. Sometimes one has to

   refresh the browser to get updated information. This can be observed in figure 12. Series2 is the old system whereas series1 is IRERS. There is no obvious variation in time paramedics receive emergency alert. The values are measured in second. Gnereally, the IRERS out performs the system of (Ali and Alwan, 2015).

   In cases where there is no internet connectivity, we observed that our system performed way better than their system. This is because the old system sends message directly to family and close friends numbers. There are many reasons for this:

   1. There may be no unit to send the messages to the family members and friends.

   2. There may be no network coverage in that area of accident.

   3. Late message delivery.

   4. There may be no network coverage at the location of the receipient.

   5. It is also possible that the fellow might not be with his/her phone when the sms is received or the phone could be in silent mode.

   6. Since an ordinary phone user is not an emergency management personnel, the fellow might not be at alert for rapid responses.

   7. Even if a message is received, Necessary information to track the location might not be available.

Generally, their approach requires internet for detecting emergency and sending emergency signals. Our system works very well without internet connection. The system extracts the device(local) gps values and sends to dedicated twilio number which routes it to the server upon receipt. As can be seen from figure 13, there are instances where the (Ali and Alwan, 2015) system can not send alert. Intuitively, this could be because of inactive internet connection which is ameliorated in our system.

Our approach is simple. When a user creates an account, the user buys a Twilio number which can work with minimal network coverage. The app sends the gps information to Twilio server. The server in turns sends to our IoT server which receives the information as though it came from an internet source.

Figure 12. Response time with internet connection

Figure 13. Response time without internet connection

CONCLUSION

The study focused on emergency response of the entire emergency management system. It gave particular attention to road emergencies. The system uses mobile phone accelerometer to sense or detect if the G-force detected exceeds the threshold. If it does the system prepares a payload and sends to an IoT server which in turn decodes and extract relevant values from the location and accident information sent and broadcast to paramedics. System is an improvement from the works of [47]. The results obtained from our experiment revealed that our system has performance advantages over the existing system especially where there is no network coverage.

REFERENCES

1. V. N. Ukoji, Trends And Patterns of Road Accidents in Nigeria: (June 2006- May 2014), IFRA-Nigeria working papers series, LAGOS, 2014.

2. M. Hafsa, Q. Javaid, M. A. Shah and M. Kamran, A Survey on Smartphones Systems for Emergency Management (SPSEM), International Journal of Advanced Computer Science and Applications, vol. 7, no. 6, pp. 301-311, 2016.

3. T. Moore and R. Lakha, Tolley's Handbook of Disaster and Emergency Management: Principles and Practice, Oxford: Elsevier, 2006.

4. C. Uhr, Behind the Charts Exploring Conditions for High Level Emergency Response Management, 2007.

5. P. Scaruffi, The Worst Natural Disasters Ever, 2008.

6. R. W. Perry and E. L. Quarantelli, What is Disaster? New Answers to Old Questions, Xlibris, 2005.

7. CCA, CCA (2004) Emergency preparedness: guidance on Part 1 of the Civil Contingencies Act 2004, its associated regulations and non- statutory arrangements. Easingwold: Emergency Planning College, 2004.

8. EMA-Emergency Management Australia , Multi-Agency Incident Management, Australian Emergency, 1998.

9. K. Nimpuno, Disaster management Glossary or disaster and emergency reference, United Nation centre, 1998.

10. Michigan Department of State Police (DOP), Emergency Management Division, Michigan, 1998.

11. D. McEntire, Disaster Response and Recovery,, Chicago: Wiley, 2007.

12. D. Coppola, Introduction to International Disaster Management, 2nd ed., Massachusetts: Elsevier, 2011.

13. W. Waugh and K. Tierney, Emergency Management: Principles and Practice for Local Government, 2nd ed., Washington, D.C: ICMA Press- International City Management Association, 2007, p. 366

14. PSC – Public Safety Canada, An Emergency Management Framework for Canada, 2009.

15. FEMA – Federal Emergency Management Agency , Prevent Disaster Looses, 2009.

16. D. Alexander, Towards the Development of a Standard in Emergency Planning., Disaster Prevention and Management, vol. 14, no. 2, pp. 158-175, 2005.

17. B. Dillon, I. Dickinson, F. Whiteford and J. Williamson, Emergency planning officers' handbook, Oxford: Oxford University Press, 2009.

18. F. Edwards and D. Goodrich, Organizing for Emergency Management in Emergency Management Principles and Practice for Local Government, 2nd ed., L. William, L. Waugh and T. Kathleen , Eds., Washington, DC: ICMA Press, 2007.

19. C. Uhr, Multi-organizational Emergency Response Management – A Framework for Further Development, LU, Lund, 2009.

20. J. Brito, Sending out an S.O.S.: public safety communications interoperability as a collective action problem, Mercatus Publications, 2012.

21. Cabinet Office , Expectations and Indicators of Good Practice Set for Category 1 and 2 Responders, Emergency Planning College., Easingwold, 2009.

22. H. Kitano, S. Tadokoro, I. Noda, H. Matsubara, T. Takahashi, A. Shinjou and S. Shimada, RoboCup Rescue: Search and rescue in large-scale disasters as a domain for autonomous agents research, in IEEE International Conference on SySystems, Man, and Cybernetics, Tokyo, Japan, 1999.

23. S. Marsella, M. Tambe, J. Adibi, Y. Al-Onaizan, G. Kaminka and I. Musela, Experiences acquired in the design of robocup teams: a comparison of two fielded teams, in Autonomous Agents and Multi- Agent Systems, 2001.

24. C. Skinner and M. Barley, Robocup rescue simulation competition: status report. In: Lecture Notes in Computer Science. The Emergency Simulation Program (ESP). http://www.straylightmm.com/, Straylight, 2006.

25. K. Iwata, N. Ito, K. Toda and N. Ishii, Analysis of agents cooperation in robocuprescue simulation, Stud. Comput. Intell., vol. 149, no. 3, p. 227236, 2008.

26. W. Chou, L. Marsh and D. Gossink, Multi-agent coordination and optimisation in the RoboCup Rescue project, in World IMACS/MODSIM Congress, 2009.

27. K. Carley, D. Fridsma, E. Casman, A. Yahja, N. Altman, L. Chen, B. Kaminsky and D. Nave, BioWar: scalable agent-based model of bioattacks, IEEETrans. Syst. Man Cybern. Part A: Syst. Humans, vol. 36, p. 252265, 2006.

28. G. Hawe, D. Wilson, G. Coates and R. Crouch, STORMI: an agentbased simulation environment for evaluating responses to major incidents in the UK, in Ninth International Information Systems for Crisis Response and Management (ISCRAM) Conference, Vancouver, Canada, 2012b.

29. G. Hawe, G. Coates, D. Wilson and R. Crouch, Agent-based simulation for large-scale emergency response: a survey of usage and implementation. 45, 1, Article 8, ACM Comput. Surv., vol. 45, no. 1, 2012a.

30. N. Saoud, J. Dugdale, B. Pavard, M. Ahmed, T. B. Mena and N. Touai, Towards planning for emergency activities in large-scale accidents, in ISCRAM, Brussels , 2004.

31. G. Narzisi, J. Mincer, S. Smith and B. Mishra, Resilienc in the face of disaster: accounting for varying disaster magnitudes, resource topologies, and (sub) population distributions in the PLAN-C

    emergency planning tool, Lecture Notes in Computer Science, vol. 4659, p. 433, 2007.

32. V. Mysore, G. Narzisi and B. Mishra, Agent modeling of a sarin attack in Manhattan, in First International Workshop on Agent Technology for Disaster Management, Hokkaido, Japan, 2006.

33. V. Mysore, O. Gill, R. Daruwala, M. Antoniotti, B. Mishra and V. Saraswat, Multi-agent modeling and analysis of the brazilian food poisoning scenario, in Agent 2005 Conference on Generrative Social Processes, Models, and Mechanisms, 2005.

34. T. Chu, A. Drogoul, A. Boucher and J. Zucker, Interactive learning of independent experts cariteria for rescue simulations, Journal of Universal Computer Science, vol. 15, no. 13, p. 27012725, 2009.

35. A. Boucher, R. Canal, Q. C. Thanh, A. Drogoul, B. Gaudou, L. V. Tuan, M. Victor, N. V. Nguyen, Q. A. N. Vu, P. Taillandier, S. François and S. Stinckwich, The AROUND project: adapting robotic disaster response to developing countries Safety., in IEEE International Workshop on IEEE Security and Rescue Robotics (SSRR), Colorado, United States, 2009.

36. E. Amouroux, T. Chu, A. Boucher and A. Drogoul, GAMA: an environment for implementing and running spatially explicit multi- agent simulations, Lecture Notes in Artificial Intelligence, vol. 5044, no. 4, p. 359371, 2009.

37. R. Gonzalez, Analysis and design of a multi-agent system for simulating a crisis response organization. with C, in the EOMAS Workshop Held in Conjunction, Amsterdam, The Netherlands, 2009a.

38. R. Gonzalez, Crisis response simulation combining discrete-event and agent-based modeling, in Sixth International ISCRAM Conference, Gothenburg, Sweden, 2009b.

39. R. Gonzalez, A Framework for ICT-Supported Coordination in Crisis Response, 2010.

40. Ordnance Survey, Ordnance Survey MasterMap, London, 2015.

41. G. Hawe, D. Wilson, G. Coates and R. Crouch, The STORMI Scenario Designer: a program to facilitate setting up agent-based simulations of major incident emergency response, in Third IEEE International Conference on Emergency Management and Management Sciences (ICEMMS 2012), Beijing, China, 2012.

42. G. I. Hawe, G. Coates, D. T. Wilson and R. S. Crouch, Agent-based simulation of emergency response to plan the allocation of resources for a hypothetical two-site major incident, Engineering Applications of Artificial Intelligence, vol. 46, no. 2015, pp. 336-345, 2015.

43. M. Wooldridge, N. R. Jennings and D. Kinny, The Gaia methodology for agent-oriented analysis and design, J. Autonom. Agents Multi- Agent Syst., p. 285312, 2000.

44. K. Igulu, Z. Piah and P. Asagba, Multi-agent Based Course Allocator Using GAIA Methodology and JADE Framework, African Journal of Computing & ICTs., vol. 8, no. 2, pp. 41-52, 2015.

45. F. Bellifemine, G. Caire and D. Greenwood, Developing multi-agent systems with JADE, Wiley Series in Agent Technology, 2007.

46. FIPA Group, 25 April 2005. [Online]. Available: http://www.fipa.org/.

47. H. M. Ali and Z. S. Alwan, Car Accident Detection and Notification System Using Smartphone, International Journal of Computer Science and Mobile Computing, vol. 4, no. 4, pp. 620-635, 2015.

48. T. Chris, J. White, B. Dougherty, A. Albright and D. Schmidt, WreckWatch: Automatic Traffic Accident Detection and Notification with Smartphones, nternational Journal of mobile network and application, vol. 16, no. 3, pp. 285-303, March 2011.