M&S Driven Experimentation for Concept Development on Combined Manned and Unmanned Vehicles in Urban Environment: Simulation Design

Abstract

In the paper we demonstrate the role of modelling and simulation in NATO Concept development and experimentation process both from individual training and analysis perspective. In the use case a simulation prototype is designed to support a proposed concept validation through experimentation. The stochastic simulation prototype design and development followed modified Distributed Simulation Engineering and Execution Process (DSEEP). The use case concept is framed around future operation of combined manned and unmanned vehicles in urban environment. There are two objectives in the use case. The first one is to design and develop a simulation environment replicating experimental trials like the experiment is happening in the field. The role of M&S is here limited to the generation of data based on the user design of the field experiment. The second objective is to support the experiment by M&S in its full potential employing different experimental designs, like parameters variation, optimization, compare runs, Monte Carlo and sensitivity analysis. The paper demonstrates the importance of a design phase of a simulation that can be used to support logistic experimentation in the urbanized environment and serves to the other researches as a basic building block for their own specific experiment being supported by simulation.

1 Introduction

Concept Development and Experimentation (CD&E) is one the principle of trans-formation within NATO and National environment. CD&E provides a basis for developing credible solutions to identified capability shortfalls by capturing the best ideas and enabling potential solutions to be explored via experimentation and validated [1]. Moreover, CD&E is an integral part of the development of required capabilities and it provides valuable input to the NATO Capability Development Process (CDP). The concept the concept is simply a proposed solution that, even after approval, could be subject to testing and evaluation. However, every concept is different, varying in complexity, timescales and resources and consequently each one may require a unique application of the CD&E approach. Therefore a generic guidance and methodology is needed that must be tailored to a concept’s specific needs and an organization’s processes. Figure 1 describes the overall CD&E methodology. CD&E is applied in three main spheres:

• Transformation oriented. It supports the identification of required capabilities and needs. Transformation-orientated CD&E is likely to generate insights in the problem domain.

• Solution oriented. It finds and develops solutions to specific capability shortfalls/gaps or the exploitation of new opportunities to address capability requirements not yet identified.

• Test and Validation oriented. It focuses on specific solutions and works to confirm its suitability and completeness.

Modeling and Simulation (M&S) is well established in NATO, through the policy level document, NATO M&S Master Plan version 2 [2]. The second part of the document identifies application areas where M&S can be applied. Basically, it can be divided into two main categories. The first one, Training and Education is the most widespread M&S application area, almost all NATO nations have their own Training and Simulation Centre. However, the second category, the M&S to support analysis, is somehow cornered and needs to prove its value in NATO. Support the operations, capability development, mission rehearsal and procurement are the examples of the second category.

In the context of CD&E, M&S can play the most important role in the experimentation. Experimentation is a tool to get insight, to test specific hypothesis or validate the solution [3]. It is perfectly coherent with the previously identified spheres of CD&E applicability. Military experimentation being supported by simulation has been applied at different level of command and in different application areas. Examples of very tactical experiments in command and control domain [4, 5] and in the medical treatment domain [6] and strategic level experiments in defense planning [7] can be taken.

Figure 1 shows a proposed way to use modelling and simulation to support phases of the CD&E methodology. In the Pre-initiation phase there is no specific role of M&S. It uses mainly tools like NATO Defense Planning Process and Strategic Foresight Analysis to identify gaps in current NATO capabilities needed to be addressed.

In the Initiation phase the main product is the Concept Proposal. Because it contains a statement of the challenge the concept is to address, a clear outline of the problem and the scope of the concept, there is a role of M&S mainly in the form of informal and formal modeling of a problem domain. It helps to articulate the problem within the stakeholders.

In the Research phase, the initial concept is developed containing the refined problem statement and the identified compared solutions even with Measures of Performances (MoPs) that serves for the future experimentation as a part of the exercises. In this phase the modeling is still playing the most important role in the problem domain refinement, however in the context of MoPs development, a simulation can be consider to engineer the most relevant ones to the problem domain.

In the Development phase, the concept become mature with the number of limited experimentation that depends heavily on a simulation whether in the form of a wargame or human in the loop constructive simulation. Due the experimentation supported by simulation bringing the qualitative and quantitative dada, the individual solutions can be compared and if deemed disregard from the concept.

In the Refinement and Validation phase, the concept is being tested and validated in the operational environment. It can happen in NATO exercises where a simulation is already used or in the synthetic environment is created on demand composed of a federation of simulations and functional services. This phase should generate more quantitative then qualitative data available for the analysis. The Approval phase is mainly about staffing the concept by the stakeholders with final approval of the concept by NATO Military Committee. There is no role of M&S in this phase.

All in all, M&S can be used to support CD&E phases to reach the required common understanding and credibility of a proposed concept.

Fig. 1.

CD&E methodology and role of M&S.

In NATO nations, there is a permanent effort to make the autonomous system fully operational, not only including the technological observation [8, 9], but the legal aspects as well [10,11,12]. In NATO Allied Command for Transformation (ACT), there has been an idea of creating a concept proposal of manned and unmanned vehicles deployed to sustain the mission form the logistic point of view in the urbanized area when applying the CD&E methodology. In [13, 14], the authors reviewed processes and techniques from industry, academia and NATO Nations which use M&S methods to enhance the NATO CD&E process when developing concepts involving autonomous systems.

Case Study: Resupply in the “Last Mile” in Hostile Urban Environments

This paper shows the use of M&S methodologies and techniques in support of the CD&E NATO. The case study chosen by the authors is described in the following.

The operation relevant to the developing concept is the last part of a logistic support operation described in [15], also known as “last mile resupply” involving the delivery of combat supplies (mainly ammunition, fuel and lubricant, rations, water, medical supplies and spare parts) from the forward-most logistic base to personnel engaged in combat operations [16].

As depicted in Fig. 2, the logistic operation considers four echelons or levels. The concept of operation to be developed during the CD&E course supports the 2^nd and 1^st echelon, where trucks and logistic units experience the majority of the problems due to the characteristics of the urban environment and the opposition of local bandits groups.

The main problem is that manned trucks with trailer get stuck when fighting in cities. There turning around time take too long and it endangered the expected mission objective. Their mobility and speed in small streets are very limited. Therefore there is a proposal to find a new concept of operations when employing Unmanned Ground Vehicles (UGVs) that could mitigate this risk and there is a proposal to implement a simulation that can help getting insight in this problem domain.

There has been done a few simulation studies dealing within logistic and autonomous system [17, 18], however no engineering aspect of a simulation design phase had been articulated in details.

Fig. 2.

Logistics Approach to be modelled in the simulation tool.

2 Problem Formulation–Study Objectives

The development of a new operation concept of UGVs in the urbanized environment comes from the need of the students of the NATO CD&E Course to learn how to design and conduct experiments in the context of the NATO CD&E process. In the current situation, the students do not have means to test the concept under development and to generate quantitative data for its validations, so they discuss about possible outcomes based on made up results.

For these students, the Operation Concrete Forest (OCF) simulation is an education tool allowing them to investigate the potential of experimentation and the use of simulation-based experiments to collect and analyze quantitative data.

To fulfil the identified user’s need, the following list of objectives for the simulation tool has been identified.

• The OCF simulation tool should allow students to replicate experimental trials like the ones carried out in the field. That is, the simulation tool will provide the students the capability of simulating field experiments.

• The OCF simulation tool should support students to run experimentation by M&S in its full potential, employing different experimental designs, like Parameter Variation, Optimization, Monte Carlo Simulation, Sensitivity Analysis and Calibration.

The following list includes a minimum and initial set of functionalities that the project team currently envisioned as required for fulfilling the objectives.

• The OCF simulation tool should allow students to run stochastic experiments varying a set of factors to assess the impact of these factors on the experiment results. An initial set of factors include:

  • The level of complexity of the environment in terms of density and size of obstacles, or width of streets and roads. These parameters will affect to the mobility of the vehicles in the urban environment in terms of, for instance, speed or turning time. More characteristics could be added as the project evolve.

  • Number, type, size and capacities of the vehicles. The simulation tool is meant to allow students to compare the performance of Unmanned Ground Vehicles (UGVs) and Manned Trucks of different sizes and with different mobility, sensing, communication and transportation capacities.

• The OCF simulation tool should allow to run stochastic simulation and to collect metrics to compute Key Performance Indicators (KPIs) to assess the performance of the simulated system providing graphical representations of these KPIs and allowing the comparison of the KPIs of the simulated system for different experimental configurations.

This list of functionalities created the foundations for the design of the Simulation Environment Requirements (DSEEP Activity 2.3) further described in the methodology section.

3 Methodology

For the development of the simulation tool, the project team will apply the IEEE 1730 Std. – Distributed Simulation Engineering and Execution Process (DSEEP) [19] and IEEE 1516.4 Std. - Recommended Practices for Verification, Validation and Accreditation (VV&A) of a Federation [20]. To help on the communication between the stakeholders involved in the projects (i.e., Sponsor, Customer and Technical Team), the products developed at each DSEEP stages, see Fig. 3, are linked with the NATO Architecture Framework [21] views. SCRUM is used as an agile framework for the development and delivering of the Simulation SW products [22].

Fig. 3.

Top-level view of the VV&A overlay for the DSEEP process

The work here presented covers the second phase of DSEEP shown at Fig. 4, i.e., Perform Conceptual Analysis. The purpose of the following sections is to provide a conceptual representation of the intended problem space and the real world domain based on the needs statement and objectives already identified. The conceptual model provides an implementation-independent representation that serves as a vehicle for transforming objectives into functional and behavioural descriptions. It covers the second step of DSEEP and describes activities taken by the team to design OCF simulation, as shown at the Fig. 4.

Fig. 4.

Main activities carried out at DSEEP Stage 2 – Perform Conceptual Analysis

Therefore, methodologically the very first activity is to develop a scenario or set of scenarios that will create the boundaries of the problem domain and creates the full picture of operational environment allowing the specification of the KPIs for future experimentation and all the operational environment entities and their attributes. The second activity is to develop the conceptual model describing in the formal way the model of urbanized environment where manned and unmanned vehicles are operating in the logistic domain. The very last activity brings engineered detailed requirements that simulation must reflected.

As stated before, the whole conceptual model has been developed using NATO Architectural Framework (NAF) views. NAF is an enterprise architecture framework [20] that provides guidelines on how to describe and document an architecture or a system. It consists of rules, guidance, and products for developing and presenting architecture or systems descriptions that ensure a common denominator for their understanding, comparison, and integration.

4 Results

The following section describes activities under the second step of DSEEP, the conceptual model design.

4.1 Development of Scenario

From [14] we can describe general scenario for the use case:

“The approaches to the city of Lyonesse, where the 2^nd and 1^st echelon operations take place, are limited to a few narrows. Groups of bandits have infiltrated the city attacking the front and rear of convoys, slowing down and even stopping the supply to the 2^nd echelon. The trucks with trailers have a hard time to turn and pass the stricken trucks. Even if this situation itself does not cause much damage, it creates shortages up the chain and it hampers the supply operations and draws some manpower away to serve as organic force protection. They also have problems to find their way in the city. They need the bigger streets to move around, but sometimes these streets are blocked. Therefore, the transfer times are longer. Problems in the 1^st echelon gets even worse, crews sometimes got disoriented and, in some cases, isolated and surrounded. In some other cases, miscommunications lead to deliver the wrong cargo to the wrong unit.”

Figure 5 provides a simplified description and representation of the scenario to be simulated.

Fig. 5.

Assets are used to shuttle between to fixed points through a complex hostile urban environment. A manned truck with trailer gets stuck when fighting in cities. Truck turning around time is too long since the mobility and speed in small streets are limited. There is a suggestion that using UGVs could solve this problem.

The scenario depicted in Fig. 5 will be used to compare the performance of systems with different characteristics. The users should be able to run this scenario using Unmanned Ground Vehicles (UGVs) or Manned Trucks, and within these macro categories of vehicles the users will be able to choose from a list of configurations.

To assess the performance of the system, in the described scenario, data will be collected during the simulation runs to compute the KPIs. The following KPIs have been identified:

• Supplies delivered per hour. Weight of goods that successfully reached the destination point per hour.

• Operational Cost per Ton. Estimated operational cost of the assets required in current operations per ton of material deployed.

Urban Environment Model Description and Environmental Conditions

The urban environment to be represented in the simulation tool covers an area of 6.4 km by 4.6 km, i.e., a total area of approximately 30 km². Streets in this urban environment range from streets seven meters wide and relatively easy to transit, streets five meters wide imposing more difficulties to large vehicles, to narrow streets of three meters wide passable only with small vehicles. The urban environment will be populated with obstacles which can hamper and limit the mobility capacity of the vehicles. Obstacles will be characterized by size, depending on the characteristics of the vehicles and size of the obstacles, these can be overcome or not. Environmental conditions such as type of terrain, day/night operations, or climate are not considered in this version of the simulation environment.

The following list provides a description of the elements to be considered in the modelling and implementation of the urban environment:

• Street -Walkable path. The simulation environment should allow representing paths that can be transit by vehicles representing streets in the urban environment. Obstacles can also appear in the streets.

• Building. Non-walkable area. There are areas in the urban environment that cannot be transit by vehicles because they are occupied by buildings.

• Forward-most logistic base. Entry point. One or more entry points to the urban environment representing the forward-most logistic base where the “last mile resupply” operation starts.

• Delivery point. One or more locations in the urban environment where the supplies have to be delivered.

• Obstacles. Elements in the urban environment that can limit or hamper the mobility of the logistics units.

Vehicles

Vehicles, the only entities being modeled, represent delivery assets or platforms which have to complete the mission of delivering a certain amount of goods to the delivery points in the urban environment. Vehicles can be unmanned ground vehicles (UGVs) or manned trucks. Figure 6 shows two pictures of a UGV developed by QinetiQ and Milrem Robotics to support operations.

Fig. 6.

TITAN is a QinetiQ and Milrem Robotics system developed to modeled in the simulation.

Both types of vehicles have sensing capabilities to collect imagery information from the environment and to process it to take decision on how to proceed in the mission. In order to exploit this information, the vehicles, both UGVs and Manned Trucks, keep an internal representation of the environment in the form of map.

The delivery mission is executed by two or more vehicles of the same type which have the capacity to communicate to other members of the team the position of obstacles so the assets can reconsider the paths followed to optimize their performance.

The goal of the vehicles is to deliver an assigned amount of cargo from an entry point to a delivery point as quickly as possible. The performance of the single vehicles and the aggregated performance of the whole system are going to be evaluated in terms of operating cost and cargo delivered by hour.

Vehicles are characterized by the parameters summarized in the following list. The difference between the two types of vehicles are given for different capabilities in terms of mobility, sensing and communication capabilities, and processing and quality of information stored in the internal map.

• Type of vehicle, i.e., Unmanned Ground Vehicle (UGV) or Manned Truck. In a simulation run all the vehicles are of the same type.

• Speed [km/h]. Average speed of a vehicle.

• Turning Time [s]. Average time to turn or modify the direction of the path followed.

• Payload capacity [Ton]. Capacity of cargo of the vehicle.

• Load/Unload time [min]. Average time required for loading and unloading operations.

• Mean time between failure [h]. Mean time between two failures of the vehicle.

• Detection distance [m]. Maximum distance at which a vehicle can detect an obstacle placed in the urban environment.

• Communication range [km]. Average distance the vehicle can shared information about obstacles found in the environment.

• Off-road capacity level. Capacity of the vehicle to overcome obstacles of a given size.

Interaction Among Vehicles

Vehicles can sense obstacles and share position and characteristics of the obstacles with other vehicles in the operation. This will provide information to those vehicles to generate more efficient routes.

Obstacles are placed in the urban environment to hamper or impede the movement of vehicles. However, in some situations, depending on the characteristics of both vehicles and obstacles, the later can be overcome and the vehicles can continue its pre-defined path. For instance, if a big vehicle with a high off-road capacity finds a small obstacle in a wide street, the vehicle can overcome it. When the situation is such that the obstacle cannot be overcome, the vehicle will have to turn and modify the path is following to reach the destination.

Initial and Termination Conditions of Simulation

The following list contains all possible initial conditions:

• A complexity level for the environment is selected, and

• At least one obstacle is placed, and

• Vehicle type and number is selected, and

• All vehicles has an entry point (A) assigned, and

• At least one delivery point (B) is set up, and

• A defined amount of goods have to be delivered, and

• All vehicles receive a mission.

The following list contains all possible termination conditions:

• All the goods have been delivered, or

• All the vehicles are stuck, or

• 24 h has passed.

4.2 Development of the Conceptual Model

The conceptual model is a conceptual representation of the intended problem space based on the user needs, sponsor objective and the description of the scenario provided in the previous sections. The conceptual model provides an implementation-independent representation that serves as a vehicle for transforming objectives into functional and behavioural descriptions for system and software engineers.

The goal of the conceptual model is to identify relevant entities within the domain of interest, to identify static and dynamic relationships between entities, and to identify the behavioural ad transformational (algorithmic) aspects of each entity [18].

Static Relationship

Figure 7 depicts the NAF L7 View – Logical Data Model of the simulation tool to be implemented. This Logical Data Model has been developed after the analysis done in the previous section on the scenario to be simulated. The Logical Data Model is concerned with identifying information elements, and describing their relationships. The Logical Data Model identifies information elements relevant for the architecture, relationships between information elements, attributes of information elements and associate attributes with data entities.

Fig. 7.

NAF v4.0 L7 View – Operation Concrete Forest Simulation Tool - Logical Data Model.

Dynamic Relationships – Vehicle Behavior

Figure 8 shows the NAF v4.0 L5 – Logical States view for the entity Vehicle when executing a delivery mission, i.e. delivery an amount of goods from an entry point to ad delivery point. Logical States viewpoint is concerned with the identification and definition of the possible states a node (entity in our case) may have, and the possible transitions between those states.

At the beginning of the operation vehicles are assigned with a logistic base (entry point) in which the vehicles are going to be load with the cargo assigned to them.

If the loading operation does not fail, the vehicle is assigned with a delivery point and starts the execution of its mission, which goal is to reach the assigned delivery point and deliver the goods assigned. During the delivery mission, the vehicles loop through four states:

• Collect Information: in this state, the vehicles using their available sensors collect information of the surrounding environment.

• Process Information: in this state, the vehicles compile the information collected in the previous state and process it with information collected in previous steps or received from other vehicles that are also in operation. Their internal map of the environment is updated with the processed information and this information is shared with the rest of the team using a broadcast (not direct message) strategy.

• Make Decision: with the information compiled in the internal map, the vehicles evaluate the alternative movements available and based on the strategy implemented for path planning (i.e., shortest path, avoid obstacles, etc.) the alternatives will be weighted and one will be chosen to be executed.

• Execute action: vehicles’ actions are mainly turn around, if needed, and move in the chosen direction. The kinematic model of the vehicle which governs the turning and moving actions depends on the average turning time and average speed of the vehicle, and on the characteristics of the transiting street. It will be further described later in this document.

Once the vehicle arrives to the destination assigned, it will enter in a new state in which the vehicle will be unloaded and the mission is completed.

In any of these states failures of operation can arise due to reasons such as unavailability of loading and unloading resources or failure in the vehicle operation.

Fig. 8.

NAF v4.0 L5 View - Vehicle Behaviour Logical States.

Dynamic Relationships - Logistic Bases and Delivery Points Processes

Logistic Bases and Delivery points are also represented as entities in the simulation model to be developed. At this location, load and unload processes are executed. Figure 9 and Fig. 10 shows the NAF v4.0 L4 View – Logical Activities for the processes to be implemented at these locations.

At the Logistic Bases, the vehicles are load with the assigned cargo; while at the delivery points the vehicles are unloaded once reached the assigned destination. In both cases, a queue will be used as loading/unloading services (i.e., loading/unloading machinery or soldiers itself) are limited in number and several assets can arrive at the same time not being able to be served in parallel.

Fig. 9.

NAF v4.0 L4 View - Logistic Base Logical Activities.

Fig. 10.

NAF v4.0 L4 View – Delivery Point Logical Activities.

Dynamic Relationship: Entities Interactions and Sequence of Activities in the Scenario

Figure 11 shows the NAF v4.0 L6 View – Logical Sequence of the scenario to be developed in the simulation tool. The sequence of activities and logical flows described in this diagram are those needed for the execution of on delivery mission by one vehicle.

Interactions amongst vehicles through communication channels will be done asynchronously simulating a broadcast channel.

Fig. 11.

NAF v4.0 L6 View – Logical Sequence of the event in the scenario.

4.3 Develop Simulation Environment Requirements

This subsection describes the requirements for the simulation environment that are derived from the objectives and from the scenario and conceptual model developed in previous sections.

OCF Students and Instructors Requirements

The first set of requirements that have been derived from the analysis of the user needs statements and the simulation environment objectives are those related with the functionalities that are going to be provided to the two main users (actors) of the simulation tool: the OCF Student and the OCF Instructor. Figure 12 shows the requirements to meet the needs and fulfil Objective 1, i.e. providing a tool to provide the capability of simulating field experiments.

Fig. 12.

OCF Student Requirements to meet the needs of Objective 1.

Figure 13 shows the requirements to meet the needs and fulfil Objective 2, i.e. to run experimentation by M&S to its full potential using methods such as Parameter Variation, Optimization, Monte Carlo Simulation, Sensitivity Analysis and Calibration.

For a sake simplified visualization, Fig. 13 do not elaborate in detail on the requirements related to inputs variations or outputs visualization. For those requirements concerning variation ranges or distribution of input parameters, the parameters that will be considered are number of vehicles, type of vehicles and level of complexity. For those requirements related to visualization and comparison of results, the outputs to be considered are those related with the identified KPIs: Operational Cost and Supplies delivered per hour.

Fig. 13.

OCF Student Requirements to meet the needs of Objective 2.

From the analysis of needs and objectives, and after conversations with the project customers, it has also arisen the need of providing CD&E Instructors with a module within the OCF Suite of Tools to configure and set-up the exercises that the students are going to simulate. Figure 14 shows the requirements for this module.

Fig. 14.

OCF Instructor Requirements to provide a tool to set up exercises for the CD&E course.

5 Conclusion

The paper discusses the need to have an engineering approach to design and develop a simulation that serves as an education and experimentation tool to support the design of a new concept of operations in the urbanized area.

The authors recommend, following DSEEP steps together with the agile development technique, to deliver a final product as soon as possible to the customer. DSEEP standard needs to be tailored to better fit the unique project requirements and it is strongly recommended to use the NATO Architectural Framework as the formalized way do develop the conceptual model. The conceptual model is the most important tool to achieve a common agreement on the project with the customer.

The main outcome described in this paper is the designed conceptual model, that could serve to other researchers as on a building block for their own simulation development. This would clearly facilitate to focus on the specific research objectives by adopting the described approach and models. In such approach, conceptual model can serve as a template for the future simulation studies in the urbanized environment. Further work will be focused on the implementation of the simulation. At time being Fig. 15 shows the current user interface. A simulation prototype is being developed with AnyLogic SW where entity behavior is modeled by Agent Based Modeling and discrete Event Simulation paradigms.

Fig. 15.

Graphical User Interface for monitoring the execution and evolution of KPIs of Operation Concrete Forest M&S-based field experiments.