## 4 The Concept Alignment Example Setup and Modeling
### Experimental Setup  
Figure 3 represents an overview of the test generation activities flow, which can be summarized as follows:  
1. The SoS was captured as a UPDM model including the description of the CSs, their interfaces, and the connections between them. For each interface/connection the relevant events exchanged were identified. 2. For each system, the model was detailed with the possible faults that could occur, and how the occurrence of a fault affected its functionality was also formalized. 3. A set of SoS hazard conditions was then identified and modeled. The hazard conditions represented unsafe behaviors that the SoS should not expose and were used by the ATG tool to identify interesting test cases. 4. The enhanced UPDM model was then processed by the ATG tool and a set of test suites was produced. Figure 3: Fault injection-based ATG abstraction level workflow for model-based SoS engineering. The CAE was an emergency response (ER) SoS and the CAE model allowed the exploration of different approaches to the modeling of the different aspects of an ER SoS. In this section, we outline a simplified CAE model to show the limitations and concrete applicability of the ATG process, which we use as a running example in the next section. The CAE model for ATG (CAE-ATG) was developed as a UPDM model in IBM Rational Rhapsody, and Figure 4 provides a top-level view of the system, representing the system's interface description (SV-1) view. The CAE-ATG was composed of three CSs, namely the district, the fire station, and the firefighting machine. Each CS was modeled as a _SystemNode_ that communicated with the others using _Services_ that exchanged events. Each event may represent:  
* An accidental hazardous condition that the SoS should control to avoid losses such as the occurrence of a fire in the district (event _heOnFire_ of the district block);
* A communication/action between blocks in order to safely control the hazardous event (events _evOnFire_ of fire station or _evEst_ of district);
* The occurrence of a fault that degrades the capability of a CS to properly handle or control hazardous events such as _evCarFailure_ of the firefighting machine block. For each block, the set of ports and the events exchanged by each port were defined as well as the connection to other blocks. The objective of the SoS control was to avoid the occurrence of hazardous conditions as a consequence of CS misbehavior or unexpected interactions. For the CAE-ATG, it was possible to define several hazards, and for the simplified case in the analysis used for this experiment, we focused only on one specific hazard, which was expressed as \"every time the district is on fire, the fire is not extinguished in a finite amount of time\". This condition identified a set of undesirable SoS behaviors for which the safety control loop could not react to the detection of a district fire. The following  
Figure 4: CAE-ATG top-level SV-1 system interface description diagram. is a brief description of each CS, focusing on the system requirements for controlling fire events. District: It represents an urban area under the control of a fire station and subject to the occurrence of a fire accident. In case of fire, it is expected that the fire is signaled from the district to the corresponding fire station, and it is considered extinguished if at least one firefighting machine is dispatched to the district and successfully executes its task. Fire station: it has the responsibility of collecting the alarm signals from the district and dispatching as soon as possible a firefighting machine to extinguish the fire. It is the responsibility of the district to keep track of the dispatched machines. Firefighting machine: it has the responsibility of receiving a command from the fire station, to move to the district, and to extinguish the fire. Once the fire has been extinguished, the machine returns to the fire station and can receive another command.