[Scenario 1] Incident Response SoS Scenario

1. Summary of Scenario

(1) SoS Definition

• Mass Casualty Incident (MCI): NHS England defines a Mass Casualty incident for the health services as an incident (or series of incidents) causing casualties on a scale that is beyond the normal resources of the emergency and healthcare services’ ability to manage. A Mass Casualty incident may involve hundreds or thousands of casualties with a range of injuries, the response to which will be beyond the capacity of normal major incident procedures to cope and require further measures to appropriately deal with the casualty numbers. Casualties are likely to be a mixture of categories with 25% requiring immediate lifesaving intervention, 25% requiring intervention that can be delayed and 50% being walking wounded or minor injuries.
  • <Mass Casualty Incident – Wikipedia>
  • <What is a mass casualty incident?>

 

(2) Real-world Example: SoS for Grenfell Tower Fire Incident

• A fire incident that covers large area, and cause an overwhelming number and severity of casualties is considered as mass casualty incident (MCI). London Grenfell tower fire incident, can be a good illustrative example. The following are basic facts reported after the fire incident occurred.
  

  image from socialworkhelper (https://www.socialworkhelper.com/2017/09/12/grenfell-tower-three-months/)

  • Entity 1: Grenfell tower
    • It is a 24-storey Brutalist concrete tower block, designed in 1967 and completed in 1974
    • It measures 67.3 m (220 ft) high and contained 120 flats
    • A block of social housing flats in North Kensington, London occupied by between 400 and 600 people
  • Entity 2: Fire incident
    • Occurred on 14 June 2017
    • (It is believed that) fire started accidentally in a fridge-freezer on the fourth floor
    • Caused an estimated 80 deaths and over 70 injuries
    • A total of 151 homes were destroyed in the tower and surrounding area
  • Entity 3: Emergency services
    • Received the first report of the fire at 00:54 local time (just midnight)
    • First crews arrived six time units after the alarm
    • In less than 25 time units, almost all floors were caught by fire
    • It burned for about 60 hours until finally extinguished (two and a half day)
    • More than 250 firefighters and 70 fire engines from stations all over London were involved in efforts to control the fire
    • Over 100 London Ambulance Service crew on at least 20 ambulances attended
    • Seventy-four people were confirmed by the NHS to be in six hospitals across London

(3) Why is Grenfell Tower Incident Response System an SoS?

Dimension	Observations in the scenario
Autonomy of Constituents	Constituent systems in SIMVA-SoS can have range of actions. These actions need not be known at the SoS level, except the actions that are used to perform a role in SIMVA-SoS. For example, a FF could have range of actions including promoting fire safety via talks, advice and training sessions, using firefighting and rescue equipment, inspecting and enforcing safety standards, demonstrating the use of firefighting equipment, performing practice drills, working with police and ambulance service personnel, undertaking physical and academic training, and checking and maintaining vehicles, equipment, hydrants and water supplies. SIMVA-SoS considers only those actions which are used to fulfill the common goal, i.e. the SoS level goal, and only those the constituent systems publically use to perform their role.
Independence	Constituent systems in SIMVA-SoS perform their action to fulfill specific role identified/decomposed from the SoS level goal. In doing so, regardless of how they do it, the only requirement is communicating state of their action to related constituent systems. For example, how a FF perform the search or rescuing operation is encapsulated in its action. Independently they perform their action, and only communicate action status to the respective constituent systems.
Distribution	Constituent systems in SIMVA-SoS exchange only information using the infrastructure provided by SIMVA-SoS. For example, in the MCI scenario under consideration, a FF communicate the status of its action to other constituent systems simply putting the information on the shared communication infrastructure. Thus, SIMVA-SoS provide distribution by enabling constituent systems communicate concurrently on logical time. Each constituent systems have a shared logical time tick to perform their atomic action at once.
Evolution	The SIMVA-SoS simulation engine always keep track of constituent systems activity logs at each tick, and this enables to create consistent evolution steps and preservation of specified properties. In the MCI scenario under consideration, at each tick SoS state update, for example map update, is communicated to all constituent systems. The logs and update information helps to maintain and monitor evolution steps preserved.
Dynamic Behavior	SoS structure and composition changes dynamically as constituent systems make autonomous decisions. SIMVA-SoS provide a mechanism to manage the changes and direct them to the intended SoS level goal. In the MCI scenario under consideration, if a FF quiets its participation, the simulation engine can easily recognize it by counting missed self-status notification. The simulation engine, thus, free SoS level resources which were assigned to that specific constituent system (this can include restructuring and rescheduling the remaining constituent systems, or admitting if there are constituent systems that can play the role).
Emergence of Behavior	SIMVA-SoS identifies emergent behavior based on SoS level goal progresses. In the MCI scenario under consideration, certain FF performing search actions, and some Ambulance performing transferring action contribute to the progress of SoS level goal only when the actions are synergized.  The simulation engine compute and determines the cumulative contribution of each constituent systems actions to the progress of SoS level goal by analyzing log data.
Interdependence	By analyzing log data, SIMVA-SoS provide explicit identification of interdependence, the tracing of mutual dependencies, and the ability to use these links to assess the impact of constituent system changes. When a FFs moves patients to safe zone, activity details are added to the log database. Similarly, when Ambulances transfer patients to Hospitals from the safe zone, activity details are added to the log database. Since these two activities are related and contribute to the SoS level goal progress, SIMVA-SoS can determine interdependences, and can assess the impact of either of the constituent system performance in fulfilling their role.
Interoperability	SIMVA-SoS assumes heterogeneous constituent systems in terms of capability and role, but having identical model and semantics.

 

2. Goals & Requirements

(1) Goal Priorities

• Priority 1:  To Save and Preserve Life
• Priority 2: Mitigate/minimise the impact of the incident
• Priority 3: Support a return to a new normality
• In order to deliver these, a further common objective is: To support the work of emergency service partners

(2) Roles and Responsibilities of Organizations

• 1) Policy Service
  • Protect life and property
  • Co-ordinate the multi-agency response
  • Protect and preserve the scene and investigate the incident
  • Prevent crime and disorder
  • Collate and disseminate casualty information
• 2) Fire & Rescue Service
  • Save Life
  • Protect Property
  • Protect the Environment
  • Provide assistance in support of local communities
• 3) Ambulance Service
  • Save Life and prevent further suffering
  • Facilitate Patient Triage
  • Provide casualty treatment and transport to the most appropriate facility
  • Co-ordinate all health resources supporting the incident

 

3. System Components Design

See PDF file for components design of SoS.

[wpdm_package id=’562′]

 

[Scenario 2] Smart City Robot Agent SoS Scenario

1. Summary of Scenario

(1) Smart factory and its components

Smart factory (i.e., Industry 4.0) is a revolutionary trend of manufacturing industries, which promises to deliver a more responsive, adaptive, and connected manufacturing line. New market requirements and emerging autonomously technologies such as IoT are shifting the manufacturing companies’ environment toward smart factories. Thanks to IoT physical objects are seamlessly integrated into the information network where they can become active participants in business processes, communicate information about their status, surrounding environment, production processes, maintenance schedule and even more. In addition, rising energy prices, increasing ecological awareness, and changing consumer behaviors toward greener products are driving decision makers to put green manufacturing and energy efficient production processes at the top of their priorities. Furthermore, unlike the way in which existing factories provide products to customers, situations are changing in which factories produce and provide customized products to meet the needs of customers of late years. As a representative example, Jun Ji-hyun’s lipstick, which appeared in the drama “My Love from the Star,” has gained huge popularity in Korea, Japan and China. However, the company has never experienced inventory problems because the company analyzed customers’ needs and increased production in advance by conducting a preliminary survey of SNS such as Instagram and Facebook. As such, Smart Factory should enable efficient production of products according to customer needs.

There are four main components in this smart factory scenario. First is robots which are considered as autonomous constituent systems (CSs) of this scenario. In this scenario, there are two organizations, Manufacturing and Distribution. In manufacturing organization, we assume that there are three constituent systems, component management robots, process robots, packaging robots. In distribution organization, we assume that there are four CSs, stock management robots, cleaning robots, transferring robots (e.g., KIVA system), delivery robots (e.g., Amazon Prime Air). Second one is policies generated by analyzing customer behaviors. In this smart factory scenario, this smart factory can generate its policies by analyzing customers’ behaviors in social networks. The third component is energy suppliers for robots. Each robot automatically charge itself before discharged. The last part is cloud computing platform that enables communication between robots.

 

(2) Real-world Example: SoS for Autonomous Collaborative Robots

We consider a scenario that autonomous robots collect trash with cooperation. This robot scenario simplifies the main features of the smart factory SoS scenario. First, there are robots that collect trash at the sea as autonomous constituent systems (CSs). Each robots communicate to other robots for sharing the existence of trash and its positions. Second, the policies of the SoS affect the cooperative behavior of this robot system. In the smart factory scenario, the policies of SoS are automatically changed by the analysis of customer behaviors in SNS. However, in this robot scenario we assume that SoS managers set the policies of SoS. Third, this robot scenario also considers the energy issue same as smart factory. There are energy supplies that robots should revisit before they are discharged and SoS managers can set a policy of robot behaviors for minimizing the energy consumption. Lastly, we assume that each robot communicate by using internet connection at the cloud computing platform.

 

(3)Why is the autonomous collaborative robot scenario an SoS?

Dimension	Observations in the scenario
Autonomy of constituents	Constituent systems in SIMVA-SoS can have range of actions. These actions need not be known at the SoS level, except the actions that are used to perform a role in SIMVA-SoS. For example, the robots in this scenario could have range of actions including traversing a specific area, collecting garbage, recharging, sending messages to nearby robots, etc. SIMVA-SoS considers only those actions which are used to fulfill the common goal, i.e. the SoS level goal, and only those the constituent systems publically use to perform their role.
Independence	Constituent systems in SIMVA-SoS perform their action to fulfill specific role identified/decomposed from the SoS level goal. In doing so, regardless of how they do it, the only requirement is communicating state of their action to related constituent systems. For example, how a robot perform the searching and collecting operation with or without other robots is encapsulated in its action. Independently they perform their action, and only communicate action status to the respective constituent systems.
Distribution	Constituent systems in SIMVA-SoS exchange only information using the infrastructure provided by SIMVA-SoS. For example, a robot communicate with other robot by using the Cloud infrastructure. Thus, SIMVA-SoS provide distribution by enabling constituent systems communicate concurrently on logical time. Each constituent systems have a shared logical time tick to perform their atomic action at once.
Evolution	The SIMVA-SoS simulation engine always keep track of constituent systems activity logs at each tick, and this enables to create consistent evolution steps and preservation of specified properties. In the collaborative robot scenario, at each tick SoS state update, for example additional trash founded, is communicated to all constituent systems (i.e., robots). The logs and update information helps to maintain and monitor evolution steps preserved.
Dynamic Behavior	SoS structure and composition changes dynamically as constituent systems make autonomous decisions. SIMVA-SoS provide a mechanism to manage the changes and direct them to the intended SoS level goal. In the collaborative robot scenario, if a robot is broken, the simulation engine can easily recognize it by counting the missed self-status notification. The simulation engine, thus, free SoS level resources which were assigned to that specific constituent system (this can include restructuring and rescheduling the remaining constituent systems, or admitting if there are constituent systems that can play the role).
Emergence of Behavior	SIMVA-SoS identifies emergent behavior based on SoS level goal progresses. In the collaborative robot scenario, certain robots performing searching action, and some other robots performing collecting action contribute to the progress of SoS level goal only when the actions are synergized.  The simulation engine compute and determines the cumulative contribution of each constituent systems actions to the progress of SoS level goal by analyzing log data.
Interdependence	By analyzing log data, SIMVA-SoS provide explicit identification of interdependence, the tracing of mutual dependencies, and the ability to use these links to assess the impact of constituent system changes. When some robots search garbage and sends signal to other robots, activity details are added to the log database. Similarly, when robots given messages collect and transfer garbage, activity details are added to the log database. Since these two activities are related and contribute to the SoS level goal progress, SIMVA-SoS can determine interdependences, and can assess the impact of either of the constituent system performance in fulfilling their role.
Interoperability	SIMVA-SoS assumes heterogeneous constituent systems in terms of capability and role, but having identical model and semantics.

 

2. Goals & Requirements

(1) SoS level goal

• To efficiently manage and control the manufacturing and distribution system

(2) Roles and Responsibilities of Organizations

• 1) Manufacturing Organization
  • Manage manufacturing process
  • Control the quality of the products
  • Manage the raw materials
  • Make schedule of production line process
  • Package the products
• 2) Distribution Organization
  • Get order
  • Manage the inventory
  • Manage the warehouse
  • Deliver the products

 

3. System Components Design

See PDF file for components design of SoS.

[wpdm_package id=’562′]