# A Methodology for the Design of Application-Specific Cyber-Physical Social Sensing Co-Simulators
## 4 Experimental Validation: Co-Simulator Development and Experiment Description
### Co-Simulator Implementation  
For this first practical use case of the proposed methodology, we decided to design a CPSS co-simulator focused on validating crowd management systems for emergencies (panic control, enhancing attention, etc.) in large facilities. These systems include the three main subsystems of CPSS: the physical world (buildings, stairs, exits, etc. ), the cyber world (sensors, displays or speakers) and the social world (people, social behavior and other similar elements). General elements (see Section 3.3.1), such as time constraints, are present in all subsystems. These elements are transversal entities which condition the entire system's operations and, then, they should be considered in all subsystems and domain specific simulations. First, we perform the requirements and characteristics capture phase. In particular, requirements about the four properties described in Section 3.1 were stablished:  
* REQ#1. Flexibility: The proposed simulation tool is focused in one particular application (crowd management), so requirements about flexibility are not imposed. * REQ#2. Modularity: The proposed co-simulator should allow incorporating new types of devices in the cyber world as new technologies are proposed or investigated. * REQ#3. Scalability: Simulations scenarios are limited to large-facilities so the maximum number of agents in a certain simulation is of various tens of thousands. As maximum, then, the co-simulator must be able to consider fifty thousands of agents. However, as we are saying later, that is not the most common case. * REQ#4. Accuracy: As social models present a limited accuracy (human behavior is very difficult to predict), it is not required a high level of precision in the designed tool (a medium value would be acceptable). Moreover, simulation tools for crowd management present some specific characteristics. Namely:
* CHAR#1. Simulations are performed by social experts, who are not programmers or technological professional. Thus, simulators cannot require technological knowledge. \begin{table}
\begin{tabular}{c c} \hline \hline
**Co-Simulation Paradigm** & **Key Elements** \\ \hline Independent & Individual controls \\ \hline Choreographed & Global scenario definition \\ \hline Orchestrated by a third-party engine & Third party engine connection status \\ \hline Orchestrated by one of the simulators & Main simulator selector \\ \hline \hline \end{tabular}
\end{table} 
Table 10: User interface key elements. * CHAR#2. In general, particular values or states at a certain time step are not interesting. In crowd management global tendencies (e.g., is the panic growing?) are more important than particular values. * CHAR#3. The most important subsystem in crowd management systems is the social world. Simulations must provide precise social information, in order to evaluate the crowd behavior. Physical and cyber worlds are secondary. * CHAR#4. As buildings may be complex structures, designing the models to include correctly the scenario in the simulator can be difficult in some occasions. However, although many agents might be included in one simulation, all of them present the same behavior, so the required processing capabilities to execute the simulations are limited. * CHAR#5. The number of agents in a certain scenario is limited. Buildings are regulated and a maximum capacity is always defined. Even when over-capacity is considered, the number of agents in a certain scenario cannot increase indefinitely. * CHAR#6. Results must be represented using both techniques: temporal and statistical graphics, and animations about the scenario's evolution in time. Apart from the previously presented characteristics, other circumstances must be also considered before implementing the co-simulator (final users and development team characteristics):  
* CHAR#7. The group of future developers does not include any expert on simulators programming. Then, complicated and specific implementation cannot be addressed. * CHAR#8.