Skyroute – technical details – Hugo Flora Velhinho

The technical details

How Skyroute works: dividing the concept into tasks

Reading the navigation procedures file and establishing links between objects

Flight simulations often use data files with the procedures encoded according to the ARINC424 standard. The files are normally simple text files with a well-defined format. The content of these files is usually filtered and compiled for target devices, but computer software and IOS interfaces usually use the simple text format. Because the ARINC records are optimized and do not duplicate information, the procedures must be reconstructed from different records to be used. The encoded procedures rely on other records describing the airport, the runways, the waypoints and the navigation radios. Using the procedures in this file allows a consistent and realistic path to be chosen for the CGE. Find out more about ARINC424 on Wikipedia.

Making the information available – NavDB

The quantity of information in an ARINC 424 file can be overwhelming. Getting only the required information is important. Only the procedures applicable in the direct vicinity of the training area should be presented to the program where the choice of the procedure is made. This can be an automated process where CGE are assigned a departure or landing procedure based on the area where they manoeuver, or a short list could be presented in the IOS for the instructor to choose manually.

NavDB is a .NET C# program that reads an ARINC-424 database in PC file format. It establishes relationships between the records and constructs objects. For example, it links an airport with its runways, and the runways with its landing aids and procedures. More examples: A terminal area and its waypoints, a named route with its waypoints.

This program is a cross-platform .NET library that can be used on Windows and Linux. This means it can be used directly by any local .NET application but it can also be used locally or remotely with a network interface by any other application.

To make NavDB accessible to any other application on the same machine or remotely, written in C, C# or C++, I decided to use a RPC server. This Remote Procedure Call server listens on a TCP port and allows any other application using gRPC to access the ARINC-424 information as objects. It is very easy to extend the available services as the requirements of the client applications grow. gRPC is also available for Java and Python.

The requests and responses are in easy-to-use C-like structures with named strings and numbers and other basic structures.

This message request from the server a list of airports meeting some criteria:

message AirportRequest {
Coordinates areaCenter = 1;
uint32 minRunwayLengthFt = 2;
uint32 maxResults = 3;
}

The server would then return a stream of responses with this format:

message ResponseAirport {
string Identifier = 1;
string Region = 2;
string Subregion =3;
string Lat=4;
string Lon=5;
string Alt=6;
string MagVar=7;
}

Assigning a procedure to a CGE

Some airports have multiple runways; having CGE using the same runway or a runway parallel to the one used for training is usually sufficient. CGE can be created and assigned the appropriate SID or approach at regular intervals to simulate a busy airport. Assuming a dedicated subprogram is responsible for the generation of CGE. This program monitors the trainee’s position and queries NavDB for the local airport. It receives a sorted list of airports. It selects an airport and queries NavDB for the runways at that airport. It receives a sorted list of runways. It selects a runway and gets the list of procedures. It chooses a procedure and gets the different legs defining the trajectory. It is now ready to send the information to the subprogram animating the CGE and/or to the IOS to display the path the CGE will follow. This process is repeated at different steps, depending on the scenario and the airport traffic density desired. It is not necessary to repeat some queries to the server as the ARINC424 information does not change during the simulation.

The following pictures show a selection of SIDs from runway 08L from EDDM. The waypoints in blue were obtained from NavDB. The background is a VFR chart from open flightmaps Germany. Some waypoints have a mandatory below, at or above altitude and this information is used in the preparation of the path. For the common case where the altitude information for a waypoint does not figure in the database, it is interpolated based on the runway altitude and the desired altitude at the end of the SID or route begin, or the next fully described waypoint. The interpolation takes the distance into account to maintain a constant climb profile when permitted.

Some airports have multiple runways; having CGE using the same runway or a runway parallel to the one used for training is usually sufficient. CGE can be created and assigned the appropriate SID or approach at regular intervals to simulate a busy airport. Assuming a dedicated subprogram is responsible for the generation of CGE, this program monitors the trainee’s position and queries NavDB for the local airport. It receives a sorted list of airports. It selects an airport and queries NavDB for the runways at that airport. It receives a sorted list of runways. It selects a runway and gets the list of procedures. It chooses a procedure and gets the different legs defining the trajectory. It is now ready to send the information to the subprogram animating the CGE and/or to the IOS to display the path the CGE will follow. This process is repeated at different steps, depending on the scenario and the airport traffic density desired. It is not necessary to repeat some queries to the server as the ARINC424 information does not change during the simulation.