A Method for Modeling and Testing Near-Real-Time System Scenarios

Abstract

Unmanned platforms are becoming more and more widely used in both civilian and military applications. The flight safety of such aircraft is crucial. Therefore, it becomes necessary to formally model and rigorously test their software. Commencement of an unmanned air vehicle’s (UAV) operation requires it undergoing a certification process, which further heightens the quality requirements. The validation process of the designed system is presented on the example of verifying the correctness of the operational scenario involving the transfer of control over a UAV between two ground control stations (GCSs). The paper introduces the method of designing unmanned aerial vehicles and testing their functionality based on finite-state machines. The architecture description of the system encompasses the use cases view and logical view of the 1+5 architectural views model. The paper concentrates on system requirements and their transformation into unified modeling language (UML) state machine diagrams. The authors present a method of mapping requirements to functions related to flight safety and system dynamics models expressed as communicating extended finite-state machines (CEFSMs). Moreover, the paper shows the rules for testing the correctness of state machine models using methods based on determining flows in directed graphs. It should be emphasized that the paper considers the certification of UAV software components from the system safety viewpoint, which directly affects the airworthiness of the air platform.

1. Introduction

This article presents the concept of modeling the architecture and operating scenarios of a near-real-time system, which implements system operating scenarios subject to the certification process. To describe the issue and related problems for this purpose, the case of designing the construction of an unmanned aerial vehicle (UAV) managed from a ground control station (GCS) is used. The UAV mission management system is a near-real-time system due to delays in the radio link between the UAV and the GCS.

Conducting a certification process that ends with issuing a decision regarding system safety requires an evidentiary process in which detailed system scenarios are presented, along with their mapping to the architectural elements on which they were implemented. For the purposes of certification, a methodology for describing scenarios must be developed, allowing them to be tested and providing evidence that all code affecting the system’s safety has been covered with tests. Issues related to capacity planning must be described, i.e., ensuring the throughput of individual architectural elements from the point of view of processing requirements (capacity planning).

This type of activity requires methodical system design, starting from collecting a coherent and complete set of requirements for the system (high-level requirements) and decomposing the requirements into detailed requirements (low-level requirements). The final stage of requirements modeling is the presentation of all system functionalities in the form of decomposed system use cases on use case diagrams. At this point, for each use case of the system (function or group of interrelated functions, depending on the level of decomposition), the place in the system architecture where the given functionality will be implemented is determined.

In the next steps of system design, operating scenarios are designed in the form of finite-state machine (FSM) models known from the SysML language (an engineering extension of UML). Each machine is decomposed into different diagrams describing the processing in the system. Typically, sequence diagrams are used. For each state machine, a description of test case coverage should be prepared, usually the so-called path coverage, transition coverage, or state coverage. This involves describing a coherent and complete set of possible paths (transitions) in state machines that directly correspond to the processing scenarios in the system. The prepared sets of system scenario coverage translate directly into test sets and system test plans.

Because unmanned systems controlled by ground control stations (GCSs) can be considered distributed systems connected via wireless networks with a high degree of unreliability, they are usually modeled using state machines containing parallel states, interconnected only by sequences of controls sent between states. This type of system modeling requires determining test coverage of all scenarios on a modified state machine description, which is an additional complication when modeling the system. Due to the dispersion of the elements of the system under consideration, we use the 1+5 architectural views model, adapted to describe the cooperating independent components (Górski [1]). In this article, the logical view of the model is used to present the allowed states of the unmanned aircraft system.

This paper presents an example of modeling unmanned system scenarios using UML state machines containing parallel states and methods of transforming the UML model to ECFSM models (an extension of the classic FSM machine), and then, to a state machine model without parallel states (FSM). Based on such a model, a method and examples of generating coverage of processing paths are presented. Then, for the abstract system model designed in this way and the selected operating scenario, an unmanned system architecture model is presented, on which the software implementing the previously described scenarios is embedded.

The system architecture was prepared for an unmanned aircraft system for which it is possible to implement the functionality of transferring control between GCSs. Generally, the system functions were modeled in the use cases view of the 1+5 model using UML use case diagrams. UAV takeover involves giving control of the UAV to a second control station (GCS). In such a scenario, the distributed system consists of five components: a UAV, two GCS control stations, and two ground data terminals (GDTs). The separation of GDT components is not accidental and occurs in every case when the system has to isolate the place of working of operators from the place of data transmission using a radio station to the UAV. In this case, there are two typical connections between system elements. The first is the GCS landline connection to the GDT. These are usually connections made using optical fibers. The GDT connection to the UAV is a radio connection. The described architecture is very popular and is practically used in most air systems used by the military. An example of such an architecture is the Turkish Bayraktar TB2, which uses handover procedures when patrolling borders. Systems of this type are used by border protection services, including the European Frontex. They perform search and rescue missions and border protection missions against smugglers.

The novelties presented in this work concern the description of the method of modeling near-real-time system operation scenarios and the location of these scenarios in the system’s hardware architecture. For this purpose, the UML modeling language and the model-based system design methodology were used in such a way as to minimize the scope of work in the description of system scenarios, model transformation, and methods of generating tests based on the prepared models. For this purpose, CEFSM machines commonly known from the literature, and their simplified versions of EFSMs, were used. In the article, it is shown how to generate EFSMs from sequence diagram models and how to build test scenarios. The method of integrating scenarios with flight safety functions described in the Functional Hazard Analysis formal document is also presented. The work aims to show how to model the system architecture ensuring the required level of safety and reliability. Reference is made to the NATO 4586 standard [2], which indicates the preferred method of building solutions for military unmanned software.

The rest of the work is as follows. Section 2 presents the most important literature items related to the issues described in the article. Section 3 shows how to model requirements and transform the requirements description into a formal UML use case model. Issues related to modeling functions related to the safety of UAVs in flight, described in the formal document Functional Hazard Analysis (a document required in the certification process of air platforms), were also discussed. Section 4 presents the principles of transformation from formal state machine models containing parallel states in UML to EFSM machines using an intermediate step, i.e., model transformation based on sequence diagrams. A method of practical system modeling is shown, which allows the use of basic UML models (state machines and sequence diagrams) for planning a set of system tests. The relationship between sequence models and EFSMs is discussed, for which there is extensive literature related to planning the testing of model paths. Section 5 shows an example of modeling system functions based on the task of transferring control of a UAV between two GCS stations. An example of generating test coverage of the model based on the transformation model to EFSM and generating test path coverage is discussed. Section 6 encompasses a discussion on the pros and cons of the method. Section 7 summarizes the method described in the work and indicates further possible directions of its development.

2. Related Work

In the course of their work, system designers develop the system architecture in terms of performing tasks for the final user. Most of these tasks do not affect the safety and security of the platform and do not have to be subject to a certification process, which is aimed at checking whether the system as a whole is safe to use. Therefore, there are no imposed requirements for the methodologies that should be used in the system design process. There are also no applicable management methodologies indicated. In the process of building the system, one can use the NAF (NATO Architecture Framework [3]) methodology or a preferred methodology DO-178. DO-178C [4] is a standard that covers the software life cycle to ensure correctness and robustness in software systems for airborne systems. The process includes software testing, quality assurance, and configuration management. DO-178C is a formal methodology widely used in both the civilian and defense sectors.

UML [5] (or its SysML extension when there is a need to model hardware architecture) can be used to design software. The process of building and testing the system does not differ significantly from the processes used in the industry. Differences appear when testing the reliability of the solution. System designers must demonstrate the robustness of the system’s designed mechanisms to prevent or mitigate the effects of an unsafe situation such as loss of communication with a UAV, GPS jamming, and engine failure. Increasing the formal control during the design process with the use of UML is possible through the use of formal methods of building software models based on the indications of DO-331 [6] as well as guidelines for object modeling of systems based on the DO-332 document [7]. When using mathematical models, system designers can rely on the guidelines described in the DO-333 methodology [8]. A detailed description of issues related to system design principles is beyond the scope of this article. The interested reader will find detailed information in the book by Hilderman [9].

As technology advances rapidly, safety-critical software is becoming more complex. In a system containing safety-critical modules, many factors influence software reliability. These include, among others, the hardware and software configuration of the system and the architecture of the communication link. In such systems, the risk of failure is greater because the failure of a single component can result in a major failure of the entire system. The reader can find many approaches to building models and preparing model-based tests that have been presented in the literature for at least the last 20 years. In this article, we deal with the design of a system called model-based testing (MBT), the aim of which is to design it in such a way that test scenarios can be generated based on formal models. Automatic generation of test data is usually difficult, but is possible with proper design principles. In this paper, we transform the system model represented by the UML state machine into an extended EFSM state machine model using sequence diagrams. Test paths can be generated for such a transformation. An example of a path generation method is the work of Lu and Miao [10].

MBT is a natural complement to the model-driven engineering (MDE) approach, which assumes designing the system in such a way that some of the codes can be generated from the model. Both complementary concepts are part of a broader methodology called model-based system engineering (MBSE).

In order to ensure the safety of the developed system, systematic, efficient, and effective software testing is necessary. The testing process must be supported by safety analysis to ensure the reliable operation of embedded software in a safety-critical system. Safety analysis techniques such as Functional Hazard Analysis (FHA) and Preliminary Hazard List Analysis (PHLA) (Huang [11]) are used to identify possible threats to ensure system safety.

In model-based testing, the operations in an algorithm can be represented by models built from a description of functional requirements. There are both formal and informal methods for modeling the algorithms used. Informal modeling methods include, for example, UML state machines. Formal modeling tools such as Petri nets (PNs), finite-state machines (FSMs), extended finite-state machines (EFSMs), and communicating extended finite-state machines (CEFSMs) are common modeling tools used to formally model the behavior of a software system. In practical applications, informal UML models are used to describe the algorithm. The informal model is then transformed into a formal EFSM model for which a testing method can be determined, as shown in the article.

In safety-critical systems, safety should be analyzed independently using one of the safety analysis techniques. Safety analysis artifacts can then be integrated to test safety and appropriately mitigate undesirable behavior. For this purpose, system dynamics modeling can be used in both UML and FSMs. Dwinandana et al. [12] presented an example of MBT (model-based testing) with the extended finite-state machine (EFSM) approach for mobile applications. Kalaji et al. [13] used EFSMs for functional verification and proposed an automatic test pattern generation approach.

The MBT process using finite-state machines (CEFSMs) in testing allows for modeling complex systems in which many operations are performed in parallel. Communicating extended finite-state machines (CEFSMs) are multiple EFSM machines with communication channels between them. Machines exchange messages with each other, which allows for synchronization of tasks. This framework allows for the ability to model safety-critical systems that consist of multiple components modeled as EFSMs.

Some authors have proposed a safe testing technique. They build a behavioral model using communicating EFSMs (CEFSMs) and a failure model for each possible failure using fault trees. The fault trees are transformed into a CEFSM representation in the compliance process and then integrated into the behavioral model. They apply various graph coverage criteria to generate test paths to check for errors. This approach meets many of the requirements of standards such as DO-178C. This approach allows for the integration of the description of software operation and the statistical model of device failure in one model, as presented by Gannous [14].

Rocha et al. [15] introduce a procedure for generating tests from UML models that uses MDE concepts to formalize UML sequence diagrams and convert them to EFSM machines. The basic principles of converting UML models to EFSM models were also discussed, in particular the rules for dealing with elements such as loops and optional conditions.

Cartaxo et al. [16] use a model-based testing (MBT) approach to generate test cases from labeled transition system (LTS) models translated from sequence diagrams. This approach uses a formal model extracted from the sequence diagram to generate test cases.

Brosch et al. [17] proposed using overlapping information inherent to some views of UML models used for automatic testing. Their proposal takes into account a subset of the state machine diagrams and sequence diagrams that model only forbidden scenarios using only neg fragments in the sequence diagram. The SPIN3 model checker is proposed to check whether a set of state machines fulfills a safety property described as a neg fragment of a sequence diagram.

Tripathy and Mitra [18] presented a method based on generating test cases using activity diagrams and UML sequences. The method involves transforming the sequence diagram into a graph called a sequence graph and transforming the activity diagram into an activity graph. Both models are then integrated to generate a test suite. The proposal uses UML models to generate tests but does not use the concept of MDE or formal test generation models.

Muthusamy and Badurudeen [19] developed an approach to generating test cases based on designed UML sequence diagrams. The sequence diagram is transformed into a sequence diagram graph (SDG), based on which test cases are generated. The sequence diagram is based on the Object Constraint Language (OCL). The SDG describes actions as nodes and interactions as paths. Test cases are generated by visiting nodes and edges of the SDG graph. This concept uses UML models to generate tests but does not use formal models.

Determining functional testing paths (testing scenarios) is usually based on transforming the formal UML model into a graph model on which such test scenarios are defined. The algorithms used to determine software testing paths are the so-called path coverage algorithms. The algorithms generally use directed acyclic graphs (DAGs), because for other graphs the coverage problem becomes NP-hard. Below are some more interesting items from the literature on the subject. Due to the complexity of the problem of testing algorithms described with cyclic graphs, the designer is forced to simplify the models, which is shown in the article.

One of the most important works in the field of path coverage in acyclic graphs is the work by Ntafos and Hakimi [20], which presents several methods for determining path coverage in DAGs. The article presents, among others, the minimum path coverage algorithm and the required path problem.

Caceres et al. [21] presented a method of computing the minimum path coverage (MPC) of a directed acyclic graph (DAG). Although it is known to solve the problem by simply reducing the flow to the minimum, recent solutions use modifications of this idea to obtain algorithms parameterized by the number of MPC paths.

Advanced theoretical analyses in the field of determining coverage in directed graphs and applications to program testing are described in the work by Foucaud and Kovse [22]. They estimated lower and upper bounds on the minimum size of identification path coverage for general graphs.

3. Certification of UAV Operational Scenarios

3.1. System Requirements

When designing systems to be certified, several sources of requirements can usually be identified: market requirements (requirements of the potential user) and airworthiness requirements (imposed by national regulations or the system-certifying authority).

In the process of certification of the flight management system of unmanned aerial platforms and the platforms themselves, applicable regulations require the designer to consult with the end user and the certifying institution throughout the system design process. This is an often overlooked aspect of work that results in design errors.

The description of requirements based on the UML modeling language takes the form of high-level requirements that are refined into low-level requirements. Low-level requirements constitute the starting base for modeling the so-called system use cases (one of the UML formal models). The process of specifying requirements is often described in the literature. The interested reader should examine the paper by Delligatti [23]. Zoughbi et al. [24] propose an approach to improve communication and collaboration between system designers in the context of RTCA DO-178, by using a UML profile that allows for modeling security-related concepts and properties in UML.

3.2. System Use Cases

From the point of view of the system designer, the designed product can perform missions (scenarios) that have a direct impact on the way the tasks are carried out:

• UAV flight performing object reconnaissance with the use of sensors available on the platform at an altitude that allows maintaining communication with the GCS;
• UAV flight without contact with a GCS (autonomous flight), using sensors available on the platform.

The scheme of the system’s operation in the implementation of various types of scenario is similar. The pilot can perform missions by controlling the platform in the following flight modes: takeoff, flight according to a predefined route, flight to the indicated points by the pilot, loiter, return to base, landing, flight according to the parameters set by the pilot in manual control mode (not possible in autonomous mode), and emergency parachute ejection.

During the implementation of the system operation scenarios related to the platform’s flight, scenarios regarding the recognition of objects using on-board sensors, EOW (electro-optical), IR (infrared), and SAR (synthetic-aperture radar), are implemented. The differences in the implementation of scenarios lie in the scope of information collected and the method of transmitting data to the user.

The system designer must indicate the scenarios to be certified. For example, a general scenario (see Figure 1) may be indicated regarding the implementation of the mission in contact with the GCS, which must include:

• changing flight modes;
• Air traffic control (ATC) support;
• using the available payload for recognition;
• handling of dangerous situations in flight, in particular, uncontrolled leaving of the mission area, collision with a terrain obstacle or other aircraft, loss of radio link, and loss of GPS signal.

In the event of dangerous situations for the UAV, when there is no contact with the GCS, the algorithms of the platform are developed in such a way that the platform is able to safely return to the landing site (see, for example, the paper by Stecz and Gromada [25]). When this is not possible, the platform lands in emergency mode by ejecting the parachute at the minimum allowable altitude. Detailed algorithms for UAV behavior in the event of several dangerous situations occurring at the same time depend on the implemented algorithms. Example solutions are presented in [25]. However, it should be borne in mind that the handling of dangerous situations is closely related to the size of the platform and its architecture [26].

In each case, the system designer must define a list of scenarios that are not subject to certification and indicate the reasons for not subjecting them to the certification process. These can be, for example, scenarios implemented in typical military applications during combat operations. Such scenarios are usually not certified.

The system operation scenarios consist of the developed flight modes of the platform and the functions analyzed by the certifying authority regarding the platform’s flight safety. The functions listed in FHA are simultaneously associated with sets of potential emergency states, as a result of which the mission may fail or end in a plane crash. The emergencies listed by the certifying authority have been referred to the categories of emergencies in flight indicated by the system designer, which describe possible dangerous events and indicate ways of resolving the resulting situations. It can be assumed that the list of emergency states will be provided by the system designer, but in this case, the list must be approved by specialists conducting the certification process.

The process of defining dangerous situations that may occur during the UAV flight also requires determining the priority of handling the situation by the pilot or the UAV (in case of data link loss).

Detailed operational scenarios in the form of system use cases (see standard OMG [5]) or practical examples (Stecz and Kowaleczko [27]) depend on the class and purpose of its platforms. To simplify the description of the scenarios implemented by the unmanned aerial vehicle system, the functions performed by the system were grouped into sets, hereinafter referred to as decomposed system use cases, which include elements related to UAV flight management in various flight modes of the platform (including activities related to preparation for the start of the mission), payload management, and handling emergencies that may occur at a specific stage of the mission (see Figure 1).

The following decomposed system use cases (basic groups of system functionalities) were distinguished:

• Mission planning;
• Pre-flight procedure;
• Automatic start;
• Automatic landing;
• Automatic flight through predefined waypoints;
• Flight with manual control (with stabilization);
• Flight in other modes (to the point and circling);
• Parachute ejection;
• Return to base.

The article describes the scenario of another GCS taking control of the UAV, as shown in Figure 1.

3.3. Linking Scenarios with Functions Affecting Flight Safety

By combining the general use cases presented in Section 3.2, the system designers are able to design any mission that can be performed by a system using unmanned platforms (see Figure 2). The proposed approach significantly simplifies the description of scenarios for certification purposes.

Since each system use case describes the behavior of the system regarding UAV control, sensor management, and handling of dangerous situations in flight, the system use cases decomposed in this way should be assigned to the corresponding requirements in the STANAG 4730, EMACC, or STANAG 4671 (depending on system class) and functions affecting flight safety listed in the FHA. Each of the FHA functions has been assigned corresponding identified emergency states. Each of the states can be uniquely assigned to one or more use cases of the system. The safety of the system and the correctness of the prepared solution will be checked by verifying the assignment of each of the emergency states to the appropriate special situation that may occur in a given case of system use, which is presented in Figure 2. This way of combining scenarios with system security requirements is a very important element that is described in the article. The presented approach allows for an efficient method of conducting airworthiness testing of an air platform with minimal effort on the part of external auditors.

Table 1. An example of the description of an emergency state. Each state is assigned to a function belonging to the group described in the FHA. The emergency state has its priority, indicating how quickly the system should handle the problem that has been identified.

ID	Function	Emergency State	Flight Phase	Expected Effect on UAVs, Humans, Missions, Other Systems	Emergency Classification	Verification Method	Comments
100.1	Ensuring stability and control
100.1.1	Determination of spatial orientation and speed of UAV	Inability to determine spatial orientation in the range, roll, pitch, and yaw of the air platform	All phases except PARACHUTE	UAV loss: a threat to humans	II	Tests in hardware in the loop simulator	Method of responding to the occurrence of an emergency broken down into the operation of the pilot, when communication between the GCS and UAV is active, and autonomous operation of the UAV in the event of data link loss

shows the functions related to safety in the flight of the platform and dangerous situations concerning the indicated flight modes. The impact of emergencies on the environment is also described. The method of verifying the occurrence of emergencies is indicated.

The role of the system designer is to indicate each of the identified hazardous situations. In addition, the system designer is also responsible for the following actions:

• naming the hazardous situation;
• assigning the hazardous situation to one of the predefined groups;
• describing the hazardous situation unambiguously, not allowing for different interpretations;
• defining the expected effects on UAVs, humans, missions, and other systems;
• assigning a priority to the hazardous situation;
• presenting the methods of preventing the occurrence of hazardous situations;
• presenting the method of detecting the occurrence of a given situation;
• describing how the system reacts to the operation of the pilot or the operation of UAV systems (when there is no communication with the GCS).

When describing risky situations that may be caused by various conditions (including, for example, weather conditions or UAV propulsion system failures), it is extremely important to describe how to react after such a situation occurs during the flight. A correct description of the reaction to a problem occurring during a UAV flight must contain an indication of how to remove or bypass the problem with reference to places in the system where appropriate automatic procedures will be implemented. For example, one can imagine a failure of the propulsion system or avionics components, which will cause such instability in the UAV flight that it will be impossible to maintain communication with the GCS. In this case, pilot procedures do not apply. The unmanned platform must react in autonomous mode (without contact with the GCS). Therefore, it requires the design and implementation of appropriate procedures during the system design phase. Failure to define the main use cases of the system will result in unreliable tests of system functionality.

In practice, the designer of the unmanned system can implement the automatic procedure of returning to the landing zone in each case of loss of communication between the UAV and the GCS. Moreover, in the event that there is an avionics problem during return, the UAV can deploy its parachute immediately in fail-safe mode. This approach is theoretically very safe but carries the risk of the uncontrolled landing of the platform in built-up areas. An even more serious problem will be when the UAV lands on a road where vehicles are moving. Therefore, larger and better-designed unmanned platforms analyze the possibility of returning to base after a failure in the event of loss of communication with the pilot.

It is also worth discussing the types of algorithms that are used to implement the handling of special situations in flight. Currently, many problems are proposed to be solved based on artificial intelligence algorithms. In this group, there are mainly heuristic algorithms and convolutional neural networks for the classification of input data. Formally, it could be considered that the algorithms of this class are sufficient to design safe systems. Our experience shows, however, that deterministic algorithms should be used, the correctness of which is easy to prove formally. Of course, this is not possible in every case. However, it is worth giving two examples of the approaches used. First, Kalman filters are often used to identify failures on an air platform (Kim et al. [28]), which is now standard. For this purpose, algorithms from groups of expert systems based, for example, on techniques implemented in Prolog or CLP languages, are not widely used. The same applies to the algorithms for determining the UAV flight trajectory in the event of a potential collision with another air platform. The most common approach is the geometric approach (Park and Tahk [29]), which can be easily tested on a simulator.

4. Modeling the System Scenarios with Finite-State Machines

4.1. Validation and Verification of Requirements

Quality control in requirements engineering consists of two basic activities: requirements validation and requirements verification. Validation is usually understood as the activity of checking that requirements are correct, acceptable, and prioritized. The purpose of requirements verification is to familiarize the user with the requirements and to confirm their completeness, consistency, and unambiguity. Quality control of requirements is difficult when end users lack technical knowledge or expertise in a particular field. Moreover, requirements are documented in natural language, which may lead to their ambiguous interpretation.

The presented certification method consists of mapping requirements in the form of system use cases to certification requirements and system safety functions, which allows protecting designers from preparing a solution for which essential safety requirements have been omitted. Each requirement specification can be checked to be complete, correct, unambiguous, necessary, prioritized, verifiable, and concise.

A requirement is considered complete when it is sufficient to carry out further design work at an appropriate level of detail. The required level of completeness varies depending on the methodology and the stage in the life cycle at which the requirement is studied or represented. Using the DO-178 design methodology when building an unmanned system, the designer can be sure that none of the essential requirements will be omitted. A requirement is considered consistent with the identified stakeholder’s needs when it is not inconsistent with other requirements. This is ensured by the FHA functional decomposition verified by the certifying authority. A requirement is considered to be stated concisely when it does not contain superfluous and redundant content. A requirement is feasible when it is feasible within the agreed risk. Moreover, it should be confirmed by experiments or prototypes. Building unmanned systems based on prototyping models is a commonly used approach. A requirement is considered unambiguous when it is defined in such a way that it can be verified whether the solution meets the user’s needs or not. In the case of a set of requirements mapped to FHA, the designer is able to quickly verify their unambiguity. A requirement is considered testable when the designer can verify, using simulator tests or tests performed during UAV flights, whether the requirements have been met. Acceptable levels of compliance verification depend on the system function to which the requirement applies. Each requirement must be prioritized, which allows requirements to be grouped by severity and value over all other requirements. This provides a demonstrated approach to merging requirements with the FHA.

Before designers of unmanned systems begin testing the system on simulators and then in flight in real weather conditions, the formal system model must be theoretically checked. The method presented in this work is used for this purpose.

4.2. System Dynamics Modeling with Communicating Extended Finite-State Machines

Communicating extended finite-state machines are finite-state machines often used to model a communications protocol because they can detect major protocol design flaws, including constraints and deadlocks.

CEFSMs can be more powerful than finite-state machines in situations where several messages can be transmitted simultaneously. CEFSMs are multiple EFSMs with communication channels between them. This structure gives the capability of modeling safety-critical systems that consist of multiple components modeled as EFSMs. A CEFSM is defined as a tuple $Q=(S,s_0,E,P,T,A,M,V,C)$ (Lee and Yannakakis [30]), where the tuple’s elements are:

• S: a finite set of states;
• $s_0$: an initial state;
• E: a set of events;
• P: a set of predicates;
• $T:SxPxE\to SxAxM$: a set of transition functions;
• A: a set of actions;
• M: a set of communicating messages;
• V: a set of variables;
• C: a set of input/output communication channels.

A predicate is presented as $P=(e,[conditions],a,m)$, where the condition is constructed using variables, where $e\in E,a\in A,m\in M$.

CEFSM communication channels correspond to the orthogonal states of state machines in the UML language, hence the analogy between these models is obvious. When modeling the system using CEFSM machines, a transformation to the EFSM model should be performed for the description of orthogonal states. For the EFSM model, coverage can be easily determined using path-coverage tests. This article presents a method of transforming state machines in the UML format to EFSM machines, using an intermediate stage based on modeling using sequence diagrams.

4.3. System Dynamics Modeling with UML State Machines

The section presents a method of describing system dynamics using UML state machines containing orthogonal states. It is based on a simple example of controlling UAVs.

A key element of the section is the claim that any orthogonal state model can be converted into a state machine without orthogonal states. The test coverage can be determined by the model created in this way. The article describes an example of designing test cases for a flight mode change scenario and a more complicated scenario of transferring the UAV under the control of another pilot working in another GCS.

An example scenario is shown in Figure 3.

This is a simplified version of the scenario that does not include handling dangerous situations that may occur during a UAV flight. The described model makes several assumptions simplifying its form, which increases its readability but does not significantly reduce the practical significance of the model. Infinite paths are not allowed, which in the case of UAVs has its justification: it is impossible to fly without distance limits. The length of a flight is always determined by the parameters that can be measured. The presented model is conservative, i.e., in the event of a communication failure, the mission is assumed to be interrupted. This is not the rule for advanced systems.

The orthogonal states can be transformed into a nonorthogonal state. Suppose the orthogonal state has n regions and the ith region has $m_i$ states. Each new state is a tuple $(s_1,\dots ,s_i,\dots ,s_n)$, where $s_i$ is a state in the $ith$ region. There exists a transition from $(s_1,\dots ,s_{i1},\dots ,s_n)$ to $(s_1,\dots ,s_{i2},\dots ,s_n)$ if there is a transition from $s_{i1}$ to $s_{i2}$ in the ith region.

Figure 4 shows the example of orthogonal to nonorthogonal state transformation.

In the presented model, platform states are described by the states (U(WP), P(CO)) and (U(LO), P(CO)). State (U(LA), P(AL)) indicates the landing mode of the platform that remains under the supervision of the pilot. The (U(PA), P(PA)) state means the emergency parachute landing mode.

Interesting transitions in the model shown in Figure 4 are the transitions to the (U(UR), P(RF)) state, which are generated based on time transitions in the UAV mission block of the orthogonal state shown in Figure 3. In practice, the system designer must guarantee that in the event of loss of communication, the system will go to the state (U(PA), P(RF)), which is only signaled by the pilot as no communication. The description of methods for restoring communication, searching for a lost UAV, and controlling autonomous flight is beyond the scope of the article.

A state machine that does not contain orthogonal states is a model on which one can precisely define test scenarios of the system in the form of the so-called path coverage for the state machine. Given a directed graph $G=(V,E)$, a path coverage is a set of directed paths such that every vertex $v\in V$ belongs to at least one path. Note that a path coverage may include paths of length 0 (a single vertex) (Bang-Jensen and Gutin [31]). A path coverage may also refer to a vertex-disjoint path coverage, i.e., a set of paths such that every vertex $v\in V$ belongs to exactly one path. Vertex-disjoint path coverage is sometimes used in system testing.

In order to determine path coverage based on such a generated graph (the state diagram always has one input and at least one output), the procedure of converting arcs into vertices should be used and the depth-first search algorithm (Cormen et al. [32]) should be performed on such a graph. In this case, we will obtain allowable testing paths for the state machine. Algorithms for determining more sophisticated coverage in directed graphs and applications to program testing are described, for example, in the works by Ntafos and Hakimi [20] and by Foucaud and Kovse [22].

It should be noted that the way the state is modeled in UML state diagrams does not allow for the direct generation of integration tests but is sufficient to show the paths that need to be tested during integration and certification tests, both on the simulator and in the UAV flight.

4.4. Detailing Scenarios with UML Sequence Diagrams

Any scenario written in the form of a sequence of UML state machine states can be detailed as a list of consecutive sequence diagrams, where at least one sequence can be represented for each state. Sequence diagrams model in detail the processing paths of a system implementing a specific scenario.

Figure 5 shows a model in the form of a sequence diagram of one of the system functions described by the state (U(WP), P(CO)).

In each state, the classes responsible for processing in the system have been distinguished. In the case of a ground station in the system, communication with the UAV is carried out by the VSM (vehicle-specific module) and EFIS (electronic flight instrument system) objects. From the platform side, communication is carried out by the flight computer. It is worth noting here that the VSM facility is an element described in the standard for the construction of an unmanned platform management system. Its task is to transform messages described in the standards into control messages understandable for a specific type of UAV. Therefore, the VSM is usually the most thoroughly tested element of the system.

The flight computer verifies the possibility of changing the flight mode (e.g., by determining the position of the UAV in the context of the planned flight route). After checking the feasibility of setting the flight mode, this computer generates a message to the autopilot controllers. After changing the flight mode, the flight computer sends the status to the EFIS. The status is presented to the pilot.

4.5. Transformation Rules of UML State Machines to Extended FSM

After defining a model presenting the system dynamics in the form of sequence diagrams, the next step is to define the rules for transforming the UML model into the EFSM model. The rules will use the sequence diagram model as input and the EFSM model as output.

For a state machine model in UML without orthogonal states, path coverage can be determined, where starting from the initial state, all possible transitions (paths) to the final states will be determined. However, there remains the problem of testing a UML state machine that does not match the FSM state machine.

To check the correctness of path coverage, a sequence diagram should be designed for each state, showing the use of each function present in the UML machine state. Any UML sequence diagram can be converted to an EFSM machine, as shown in this section.

An extended finite-state machine (EFSM) M is a 6-tuple $(S,s_0,P_I,P_O,V,T)$ (see Androutsopoulos et al. [33]):

• S: a finite set of states;
• $s_0\in S$: an initial state;
• $P_I$: a finite set of input parameters;
• $P_O$: is a finite set of output parameters;
• V: a finite set of internal variables;
• T: a finite set of transitions.
• $T:Sx{P}_{I}xG\to SxUx{P}_O$

Each transition $t\in T$ in a 6-tuple, where elements of this tuple are a source state, a destination state, an input event modeling the interaction of the input event with a list of input parameters $P_I$, a logical expression (guard condition G) expressed by variables from $V,P_I$ and comparison operators, a function that updates variables of V and $P_O$, and an output function used to modify values of parameters $P_O$ or variables V.

The most important rules for model transformation are presented below according to Rocha et al. [15]. These rules were used for model transformation in this article.

• Rule 1—Sequence diagram

The sequence diagram instance maps directly to the EFSM instance and is given the same name. Moreover, when the initial lifeline is found, the initial state $s_0$ of the EFSM is created.

• Rule 2—Transition

A new state is created for all occurrences of the message or operation and added to EFSM. A new transition is added that connects the new state to its predecessor within the EFSM model. If an operation returns an output value, an additional state is added for each possible output of that operation.

• Rule 3—Switching elements: $alt$ and $opt$

For all instances with the $alt$ or $opt$ operator in the sequence diagram in the EFSM, a new state and a new transition are created for each operand. New transitions connect the current state to new states.

• Rule 4—$loop$

For all instances of a sequence diagram with a $loop$ interaction operator, the response message must be defined as the last operand message.

An example transformation of a sequence diagram model into an EFSM machine model is shown in Figure 6. Only one loop is visible, which concerns the selection of the next route point. Without this loop, the diagram presents a DAG graph in which minimum flow methods can be used to determine path coverage for algorithm testing purposes.

The figure shows two branches of the tree that correspond to the two alt alternatives shown in Figure 5. In this sequence diagram, there is only one loop, which starts at the last vertex $S7$ and goes to the first vertex $S0$. This model allows skipping this loop because the logic of the algorithm is identical for each subsequent waypoint of the route. In such a case, EFSM can be treated as an acyclic graph, which greatly simplifies the process of proving the correctness of the algorithm. In the case of the presented model, the set of variables V includes the flight mode of the UAV flight computer. The input parameters of $P_I$ are the set of flight parameters for the mode, such as the UAV speed or flight altitude. The output parameters of $P_O$ are the set and possible flight parameters of the UAV flying in a specific flight mode.

5. Sample Scenario

This section will show an example of a complicated and potentially dangerous scenario of UAV handover by another GCS. The designed operating scenario during this operation must be carefully checked for its robustness to potential errors.

5.1. 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, 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 Rocha et al. [15]).

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 Shimon [34], Sedgewick [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. A model that integrates orthogonal states into one machine allows for a significant simplification of the system description. However, the project may lose information regarding message transitions between separate devices that are not elements of one device, but data exchange between them takes place via radio communication in close-to-real time. For this reason, combining orthogonal states in state machines must be performed at the lowest level. At this level, only functions with the $entry$, $do$, and $exit$ stereotypes are operated on. Figure 9 shows the sequence of message exchanges between two GCSs. The sequence corresponds to the status messages (P1(HA),U(HA),E(FLY),P2(HR)) named $entry:setDLConfig$ and $do:connect$, shown in Figure 8. The first group of messages for the $getGCSpos\left(\right)$ message corresponds to the functions implemented within $entry:setDLConfig$. The rest of the messages correspond to the $do:connect$ function.

5.2. Generating Tests for a Handover Scenario

In the case of system modeling, it is difficult to show a consistent and reliable method for determining test cases based on the system design in UML. This is related to the flexibility of modeling and the lack of limitations imposed on IT system designers. In the case of safety-critical system models, certain assumptions can be made that increase software safety while simplifying the models themselves in UML or other formal languages. The basic principles related to the construction of real-time or near-real-time safety-critical systems that facilitate modeling are:

• decomposition of functionalities affecting system safety;
• designing independent modules that communicate with each other synchronously or asynchronously and assigning them to various resources of computers and devices;
• avoiding deep nesting, including complex loops, in algorithm design.

These types of design rules are used in the construction processes of elements of unmanned platforms that are subject to certification, such as flight control elements. In practice, this means that when designing algorithms in the form of UML sequence diagrams, it should not happen that there are multiple conditional branches ($if$ section) or multiple loops ($loop$ section), including nested loops, in the processing path. It can be assumed with a high degree of probability that in a safety-critical system the occurrence of loops in the software supervising the system control in almost every case comes down to the execution of a finite (and usually very small) number of iterations. At this point, most loops can be reduced to a finite sequence of instructions following each other without returns, which allows the processing path to be modeled in the form of a directed graph without cycles (DAG). To determine the path coverage in a graph, one must first convert the sequence diagram model shown in Figure 9 to the EFSM machine shown in Figure 10. After conversion, a DAG is constructed on which path coverage can be determined. The algorithm consists of two steps: determining the allowable flow and determining the minimum flow (Ciurea and Ciupala [36]).

At the same time, it is worth noting that software modules in which sequences of operations are repeated cyclically usually collect specific device states and transmit them to decision-making subsystems. Each of these algorithms can be checked individually, which is usually not a problem because the sequences of operations are not complicated. The presented test generation method allows for covering the scenario paths for a selected part of the system.

Path coverage methods are one of the most popular planning methods for determining system testing paths. It is worth emphasizing again that these methods do not guarantee the determination of full coverage, i.e., coverage of all processing paths, which in the case of a multi-module system is an NP-hard problem and may not be feasible in practice in a finite time. The methods support the determination of the so-called minimum coverage, which guarantees that each program unit is checked at least once.

A draft of the path coverage algorithm is shown in Algorithms 1 and 2.   

Algorithm 1: Path coverages in DAG

Input: G Result: $P=P_1,\dots ,P_k\dots ,P_K$, K number of paths covering G Algorithm: 1. find cycles in G 2. convert G into DAG $G^{\prime }$ by removing back edges leaving only tree, forward, and cross edges (DFS) 3. assign each $v\in G^{\prime }$ vertex without a successor to the set $V^{\prime }$ 4. select source vertex $s\in G^{\prime }$ 5. k = 1 6. for each pair $(s,v):v\in V^{\prime }$   {$P_k$ = pathCoverage($G^{\prime }$,s,v); $k=k+1$} end

Algorithm 2: pathCoverage

Input: G, s—source vertex, t—target vertex Result: P—path coverage Algorithm: Ciurea and Ciupala [36] 1. establish a feasible flow 2. establish the minimum flow from a given feasible flow

For the sequence algorithm shown in Figure 9, the designated path coverage is shown in

Table 2. Details of EFSM transitions.

ID	Transition	Input Samples	Output Time [s]
1	S0 → S1	setDLGConfig
2	S1 → S2	sendDLGConfig(rFreq)
3	S2 → S3	setChannel(rFreq)
4	S3 → S4	setChannel(rFreq,antennaID)
5	S4 → S5	getGCSpos(GCSid)
6	S5 → S6	connect(UAVid)	OK
7	S6 → S7	connectionWithGCASet()
8	S7 → S8	connectionSet(status)
9	S8 → S9	sendMessage(GCS2ready)
10	S9 → S10	message(DLOK)
11	S10 → S11	ack()	connOK
12	S11 → S12	ack()	connOK
13	S12 → S13	ack()	connOK
14	S13 → S14	channelReady()
15	S5 → S15	connectionTimeout()
16	S15 → S16	ack()	connNOK
17	S16 → S17	ack()	connNOK
18	S17 → S18	channelNotReady()

.

The methods are usually based on a graph approach and determining minimum flows based on a modified network, on which the permissible flow (Ciurea and Ciupala [36]) is first determined. These methods have been known since the late 1970s and have been strongly developed since the 1990s (Ahuja et al. [37] and Ahuja et al. [38]). Modifications and extensions of the coverage planning methods are the required pair or required path problem methods (Ntafos and Hakimi [20]).

In order to understand the method of determining the minimum flow in DAG, it is necessary to describe the method of constructing the network on which such flow will be determined. Figure 11 and Figure 12 show the algorithm for building a flow network divided into subsequent stages of network construction and determining the minimum flow. It should be borne in mind that in the first phase of the algorithm, the maximum flow in the network (or feasible flow) is determined. Then, in the second phase, the minimum flow is determined.

When determining maximum flow, it is worth connecting vertices located on one path that has no branches. This action reduces the number of vertices in the network, which simplifies the calculations.

It is also worth noting an important element influencing further calculations. Each vertex of the network is an element of the algorithm (in the presented case, the sequence diagram), and when determining coverage it must be taken into account in one of the tests.

Figure 11 shows the network created after vertex reduction. For each of the vertices of the new network (e.g., S0–S4), two new vertices were generated: ${(S0-S4)}^{\prime }$ and ${(S0-S4)}^{″}$. The minimum flow between these vertices is 1 and the maximum value is C (usually it can be equal to the number of vertices of the network). This move allows the addition of an arc $({(S0-S4)}^{\prime },{(S0-S4)}^{″})$ to be forced when determining the maximum flow. This corresponds to the determination of the flow through the vertex $(S0-S4)$.

Then, the network is expanded according to the algorithm given by Ciurea and Ciupala [36]. The feasible flow problem can be solved by solving the maximum flow problem defined in the transformed network. Two new nodes have been added: source node $S^{*}$ and sink node $T^{*}$. For each node i with $b\left(i\right)>0$ we add a source arc $(S^{*},i)$ with capacity $b\left(i\right)$, and for each node i with $b\left(i\right)<0$ we add a sink arc $(i,T^{*})$ with capacity $-b\left(i\right)$.

Figure 12 shows this; $b\left(i\right)$ is the difference between two sums—the sum of the minimum flows entering the vertex i and the sum of the minimum flows leaving the vertex i.

Then, the problem of maximum flow in this transformed network must be solved. If the maximum flow saturates all source and sink arcs, then the initial problem has a feasible solution. Otherwise, the problem is not feasible.

It is worth paying attention to an important element related to determining the maximum (or allowable) flow in a situation where there are network arcs with minimum flows greater than 0. In such a case, before starting the calculations, the values of the minimum flows of the arcs flowing in and out to each of the vertices should be corrected so that the principle of flow conservation is met. This situation is shown in Figure 12. An arc with a minimum capacity of 1 exits from the $S{5}^{\prime }$ vertex and an arc with a capacity of 0 enters. The modification of the capacity value in this case consists in increasing the value for the entering arc. One of the paths in the flow network from vertex $S^{*}$ to $T^{*}$ is the path ${(S6-S14)}^{″},T,S,(S0-S4)\left(S5\right),{(S6-S14)}^{\prime }$.

After joining the vertices into vertex $(S6-S14)$ and sorting starting from vertex S, one of the two minimum coverage paths in the network from Figure 12 is determined. This path is as follows: $(S,S0,S1,\dots ,S13,S14,T)$.

An alternative method to the method based on flows determined in graphs is a flow method defined based on mixed-integer linear programming (MILP) tasks. In the literature, there are many examples of algorithms for determining network flows based on integer problems (Cruz-Mejia and Letchford [39]). The tasks basically concern determining the maximum flow, but after transforming the network in accordance with the model presented by Ciurea and Ciupala [36], the task of determining the minimum flow can be solved. However, the minimum flow problem is not the same as the minimum cost network flow task, which should be emphasized.

6. Discussion and Limitations

The elements of the architectural description are located in the architectural views of the 1+5 model (see Górski [40]). Two views were used. The first was the use cases view, where the functional requirements are placed. The second one was the logical view, where class design is presented along with UML sequence diagrams and UML state machine diagrams. The method also includes non-functional requirements expressed in the form of procedures, e.g., “REQ 2001: Handover procedure”. However, this has not yet been properly formalized. In the 1+5 model, the contracts view is devoted to storing non-functional requirements. In the course of further work, a way of including this type of requirements in the contracts view and their direct connection with test cases will be modeled. The model also includes an integrated services view. It will be used to model the cooperation of the UAV and the ground control station. The article focuses on the implementation of the mission. Authentication, which is an important aspect of drone swarm security, is not yet considered in the method. In general, distributed identity management and authentication of individual drones is the topic of current research, in particular using blockchain technology (see Pengbin et al. [41]). This seems to be an interesting area for potential extensions of the method.

Proving the correctness of software is not limited only to the methods described in the article. Other popular and frequently encountered methods are formal proofs using linear temporal logic (LTL) and computation tree logic. Computation tree logic (CTL) is branching logic, which means that the algorithm model has a tree structure. It is used to formally verify software components, usually by applications called model checkers. One of them is NuSMV (symbolic model verifier; see Cimatti et al. [42]). Model checkers check whether a given software module has safety properties. CTL can determine that certain initial or final conditions are met (e.g., all paths of the algorithm being checked end in one of the feasible final states). The general application of the CTL technique is to prove that all possible executions of a program avoid certain undesirable conditions. The safety property is verified by the model checker, which examines all possible transitions from program states that satisfy the initial condition and ensures that all such program executions satisfy this property. The interested reader can obtain additional information about this formal technique in the papers by Abuin et al. [43] or Kesten and Pnueli [44]. Computation tree logic belongs to a class of temporal logics that includes linear temporal logic (LTL).

7. Conclusions

The scope of system tests performed as part of the unmanned aerial platform certification process requires adaptation to the platform class. This applies to both military and civilian platforms. However, the general approach to managing system scenario requirements and in-flight safety analysis requirements remains the same for all platform classes. In the case of requirements for the certification process, it is worth remembering that they are an extension of the set of system requirements. These requirements focus on checking the correctness of the platform design process, as well as verifying whether the designed system is safe to use.

This paper briefly discusses the current legal status in the field of testing and certification of unmanned aerial vehicles. The principles of mapping requirements to functions related to flight safety are discussed in detail. This is the first step in the flight system certification process.

A method of formally describing the system’s operation using a UML state machine is also discussed, which was detailed by modeling the system’s operation using UML sequence diagrams. A method of transforming models describing processing sequences into EFSM machine models is presented. The method of generating test cases covering all processing paths for a selected system operation scenario is also shown.

Further research directions will primarily concern increasing the automation of the transformation process of the described models, which will simplify the system testing processes. In particular, methods of transforming models in the form of directed cyclic graphs to directed acyclic graphs will be checked.

Another direction for further work is to verify the possibility of checking models based on techniques based on LTL (linear temporal logic) and CTL (computational tree logic) logic. There are commercially available software tools for formal verification of finite-state systems, such as NuSMV. The tool lets one check finite-state systems for specifications in CTL temporal logic. For example, the NuSMV input language is designed to enable the description of finite-state machines ranging from synchronous to asynchronous. The use of LTL and CTL techniques increases the accuracy of system model verification.