## 5 Experimental Results  
The ATG execution process is responsible for identifying the hazardous chains of events leading to the verification of an ATG condition that might be the reachability of an unsafe state or the enabling of a fault detection mechanism. Each event chain represents a test case that can be used to reason on the model. The whole process implemented from a technical point of view in the experiment to enable the ATG can be summarized as follows. 1. The designer produces the UPDM model of the SoS following the guidelines in Section 4. 2. The model is checked by a model validation component. Only a subset of the UPDM language is supported by the ATG engine and the main purpose of the validation is to verify the compliance of the input model with the supported features. This is to avoid the execution of time-consuming successive steps by catching unsupported elements as soon as possible. In case the validation fails, an error report is produced, and the translation is aborted. 3. When the model is compliant with the ATG restrictions, the simulation is invoked to generate the test cases. In particular, the following steps are performed: (i) the model is processed using a model-to-model transformation that produces a semantically equivalent model; (ii) the generated model is processed as a formal problem for the verification to enable the ATG execution; and (iii) the ATG execution is effectively performed, and a set of test cases is produced as well as a test generation report. As an example, we simulated the application of the scenario generation analysis to the CAE-ATG model. The ATG process intuitively looked for possible fault events injections that led to the verification of the hazard, which in this case was the absence of the _evEst_ event within five model execution steps after the occurrence of a fire event. For each generation loop in the algorithm, a MCS was produced according to input models as the minimal operations and states for the top-level events. Then, the MSC was used in conjunction with error constraints in the system-level design to inject faults for a test case. In this experiment, multiple scenarios were generated as test cases under different settings of the ATG algorithm parameters. Some generated scenarios are represented in Table 4. For conciseness, only the relevant events are represented in the table and only the change of value is marked after the ATG. The three test cases identified different evolutions of the SoS leading to the hazard condition. The three scenarios were representative of three distinct \"families\" of unsafe behaviors exposed by this simplified CAE SoS. Scenario SC-01 identified the presence of a car failure event _evCarFailure_ as a cause of hazard due to the design of the fire district control mechanism that did not take into account the possibility that a car fails during the dispatching and could send a dispatch event to a car without any check on its availability. The state-machine description of the fire station reacted to the alarm dispatching the car; however, as captured by the test case, if at the same time the car was in a failure state it could not receive the dispatch command; hence, it was not capable of extinguishing the fire. This test case exposed a problem related to the fire district design. This may be due to the simplified abstraction or to a design error. Scenario SC-02 showed how the occurrence of a communication fault event in the fire district led to the verification of the accident. This scenario exposed a possible fault tolerance issue with the SoS, i.e., all the communications were handled by the fire district. In this case, a redundant communication mechanism inside the fire district was neededto handle possible communication errors properly, without affecting the safety of the entire SoS. Scenario SC-03 identified a test case where, due to the limited number of vehicles, the SoS was not capable of successfully tackling a fire event if more than three fire events were previously detected.