# Designing a Reliable UAV Architecture Operating in a Real Environment
## 3 Modeling of UAV Architecture
### System Architecture with SIL Elements  
This section shows the extensions of the physical architecture that concern the preparation of additional components simulating the operation of those systems that cannot be run during system tests in the laboratory. Due to the scope of the simulation performed and the used UAV physical components (GPS / INS and ADSB), it was decided to use the Software-in-the-Loop (SIL) simulation scheme. Software-in-the-Loop represents the integration of a production code into a mathematical model simulation, providing engineers with a virtual simulation environment for the development and testing of complex systems. SIL makes it possible to test the software before the hardware prototyping phase and accelerates the development cycle. SIL enables the earliest detections of system-level defects or bugs.  
Figure 4: Physical architecture of UAV with logical units depicted (collision avoidance modules). The figure shows GCS components and UAV components with the radio data link marked.  
Testing of complex systems, in particular those that can cause harm to humans, must be performed in conditions similar to reality. In this sense, simulators of real systems are built. If most or part of the critical UAV systems is simulated by software, it is referred to as SIL (Software-in-the-Loop) simulator testing. This approach has many disadvantages, the main of which is the need to prove that the software simulator corresponds precisely to the software embedded on the actual platform. In this respect, the most difficult thing is to simulate the computing power, including the processors' load. In addition, systems often use a different architecture associated with differences in the interpretation of variables and how some operations are performed. However, it is not easy to test a system other than based on SIL in some situations. Examples include simulating collisions of unmanned aerial vehicles, simulating a collision with a terrain obstacle, or simulating GPS/INS signal interference. In the case of GPS/INS systems, modern systems are so intelligent that it is impossible to substitute GPS position data to the device to simulate a flight. Therefore, in most cases, GPS/INS signal interference is tested based on SIL. The presented approach simulates the operation of GPS/INS spatial orientation systems and the ADSB system's operation, which generate information about UAVs whose flight trajectories may cause an air collision with our UAV. The SIL scheme is sufficient in this case to test the correctness of the designed algorithm. The SIL architecture integrated with GCS and UAV elements is shown in Figure 5.  
When testing the collision avoidance procedures, one can use the software embedded on the real Mission Computer (MC). The change in the platform's position is still simulated by software, but algorithms are used to determine new flight courses embedded in the MC. At this point, we can talk about the Hardware-in-the-Loop (HIL) class simulation, in which original elements of the air platform are used. However, in order to consider the simulation environment to meet the requirements of the HIL test environment fully, an FCC would have to be added to this environment, which would be fed with the necessary data about the platform position and the status of onboard equipment. However, it is not necessary to properly test the collision avoidance algorithm.