# A Method for Modeling and Testing Near-Real-Time System Scenarios
## 3 Certification of UAV Operational Scenarios
### 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 [PERSON] and [PERSON] [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 ([PERSON] and [PERSON] [27]) depend on the class and purpose of its platforms.