# A Method for Modeling and Testing Near-Real-Time System Scenarios
## 5 Sample Scenario
### Handover Scenario Description  
Control being taken over by another GCS requires appropriate system configuration, which is set by the platform pilot, who releases the control. The platform computers communicate automatically with the GCS which is to take over. After confirming communication, the pilots agree on the moment to return control. During the handover procedure,  
Figure 6: Transformation of the sequence diagram from Figure 5 to EFSM. communication may be lost, for which the platform's computers must be prepared, i.e., appropriate modules must be implemented to handle dangerous situations. The process involves four orthogonal states describing processes supervised by two pilots and processes implemented on the platform. The platform processes are divided into two logical parts: flight control processes (UAV mission group) and hazardous situations control processes (UAV EX group). The model uses simplifications of the pilot operation scheme, which do not affect the described method of checking the correctness of the algorithms. The states \(s_{0}\) are the states \(FL\) from the UAV EX machine, \(ST\) from the UAV mission machine, \(CO\) from the Pilot1 machine, and \(ID\) from the Pilot2 machine. The _Mode_ parameter is an element of the \(P_{I}\) and \(P_{O}\) sets. The value of the minimum flight altitude (\(H_{min}\)) belongs to the set of variables \(V\). The control transition describing the handover process leaves the \(CO\) state of the Pilot1 machine to the \(HA\) state of the same machine. For Pilot2, control transitions begin at the \(ID\) state and end at \(HR\) state. Figure 7 shows the state machine model describing handover. Figure 8 shows the model shown in Figure 7 after transformation and elimination of orthogonal states (see [PERSON] et al. (2015)). Figure 7: State machine for an unmanned system with support for dangerous situations in flight and support for UAV handover by another GCS. Four orthogonal states within a complex state machine are presented. The system status, which describes the moment of establishing communication, is marked in green. The diagram shows selected transitions for states marked in green. The model is the basis on which the algorithm's test paths are determined. In a graph showing state connections, one can determine the transition paths between any states, if the paths exist. The first basic method of generating test coverage for a machine without orthogonal states is to check according to the paths generated, using a depth-first graph search (DFS) algorithm (see [PERSON] [34], [PERSON] [35]). It is easy to see that the structure of valid code in any language does not allow control to be passed inside the loop section. The code will, therefore, contain loops or loops nested in other loops, which can be easily detected by the DFS algorithm. The transformation to a model without orthogonal states requires great care because most states that can be generated automatically as a Cartesian product of states for each machine are not allowed. The apparent convenience of writing in the form of a machine without orthogonal states, however, causes a great deal of difficulty in system modeling. For example, the state (P1(HA), U(HA), E(FLY), P2(HR)) is valid, but the state (P1(HA), U(HA), E(RTB), P2(HR)) is not allowed because the pilot cannot transfer control to the UAV when the platform detects a fault that forces a _ReturnToBase_ command generation. Figure 9 presents the sequence diagram for the state (P1(HA), U(HA), E(FL), P2(HR)). The algorithm checks the readiness of the pilot software to take over the UAV from another GCS. A simplified version of the algorithm is shown, which contains one conditional statement (_alt_ segment). Modeling message flow based on a state machine with orthogonal states requires precisely designing the sequence of state transitions so that the programmer is able to determine the moment of state change in various orthogonal blocks of the state machine model.