# Sensors and Communication Simulation for Unmanned Traffic Management
## 4 Agent-Based Simulation in a Distributed Architecture
### Pre-Simulation Workflow: Models and Scenario Definition  
Next, the functionality of those services in charge of defining the different simulation scenarios is presented. First, the model definition service, together with its associated database, allows defining and storing different simulation models for each simulation element: pilot behavior, drone types, sensor types, communication nodes, sensors, airspace structures, and weather. These reusable models are composed of two elements:  
* A set of statistical properties and parameters that determine an agent behavior, which is persisted in the aforementioned database (named \"model\").
* An associated programming class (named \"behaviour_class\") in the corresponding simulation service that implements the modeled behavior and uses the previously mentioned parameters to reproduce agent behavior at simulation time.  
This way, for a given type of agent, different behaviors can be defined as different behaviour_class implementations. Moreover, different sets of parameters (different models) can also be defined to alter the same behavior by linking them to the same behavior class. Models can be retrieved by other services to define the scenarios in generation time and to generate the appropriate instances of each agent.  
Model information is used within pre-simulation services to allow the definition of a simulation scenario that is orchestrated by the scenario definition service, that also maintains a database to persist all scenarios. A scenario can be manually defined by the user or generated randomly by the platform using some user-provided information (simulation area and duration, number of flights, sensors and communications nodes density) and statistical models included in each of the services. Each scenario is composed of:  
* A simulation environment which encompasses the definition of a mobile communications network as a series of geopositioned nodes, a surveillance network as a series of geopositioned sensors, an airspace definition as a set of no-flight zones or geofences, a model for a backbone fixed communications network, and a weather model. All these elements are defined using the environment definition service.  
Figure 2: Proposed simulation architecture.  
* A set of flights to be simulated. Each of them is specified through an expected flight plan, a drone, a GCS and pilot model. These flights are defined using the traffic generation service. As it is also necessary to predict drone trajectories from flight plans, this will be done by the trajectory prediction service.  
Both elements include a list of actions (action class) that allows scheduling relevant user-defined events that are independent from the autonomous behavior of the actors, and that must occur during the simulation: flights start, flights end, and forced contingencies. By \"forced\" contingencies, we mean those that do not arise naturally from the interaction of the different actors in simulation time, but that are defined and programmed by the user in the scenario to guarantee their occurrence in order to be able to evaluate the UTM system reaction in their presence. The occurrence of these type of contingencies is modeled within the contingency generation service that allows their creation as actions that are appended to the action list. A detailed description of a scenario data model and its relationship with models defined in the model definition service is depicted in Figure 3. There, it can be seen that all agents are geopositioned and have an associated model, from those defined in the model definition service, which defines their respective behavior.  
Figure 3: Proposed data model for simulation scenario definition (in orange), models definition (in gray), and associated behaviour_class files in each simulation service. For clarity purposes, the majority of classes’ parameters have been omitted.