How I learned to stop worrying and love ARINC 424

In my previous post I mentioned somewhat off-hand that I was working on a reader lib for a navigation standard known as ARINC 424. The project has come a long way, and is at the point I felt comfortable about publishing it https://crates.io and hopefully start getting some eyes on this.

However, in the open source world very few things are unique, and surely there must be some good ARINC 424 readers out there already right? Well, I'll get into that in this post as well as some challenges that I have been having while implementing this. I think then the post has a natural breakdown like:

What is ARINC 424?

Project Motivation

Language Choice (🦀 rusters rejoice)

Status (so far)

Challenges (so far)

What is ARINC 424?

So, aside from the linked Wiki article, I can give a little more context here. ARINC 424 is just a numbered standard that used to be owned by an OLD company called Aeronautical Radio, Incorporated (hence, ARINC). They created a lot of standards over the years since their inception in 1929. Mostly this related to radio use, but as computers came into use in aviation, they started looking at data standards there too.

1980 is when ARINC 424 was first published and detailed a record format that could sequentially be loaded with high reliability. The standard details a fixed-width format that compresses navigation information into 132-character ascii lines that can be read into a database onboard a flight computer. This was huge back in the day, and detailed all of the data validation needs of those days which mostly relied on some older ground-station-based methods of navigation.

Data formats from the 80s are extremely fun to encounter

Here is what one of the navigation aid (navaid) lines could look like in today's version of the standard:

# record for a ground-station navigation aid called a localizer<br>SUSAD KFATK2 IRPW K2011130 ITWN IRPWN36471081W119435663E0130003470 NARFRESNO YOSEMITE INTL 261851713

When you break some of it down, you can see how this could encode a lot of useful information:

[S] - standard record<br>[USA] - area<br>[D] - section of the database; navaids<br>[KFAT] - airport<br>[K2] - ICAO region code<br>[IRPW] - navaid identifier<br>...<br>[N36471081] - location latitude (N 36°47'10.81")<br>[W119435663] - location longitude (W 119°43'56.63")<br>...

This is a simplified example of course, and there are many different types of records to handle and not all of them have the same formats. To make this manageable, however, ARINC standards are documented quite well and there is a PDF that can be obtained for each revision, historic or current, in order to learn more about how to create either the data as a data provider, or how to read the data as a data user.

You know you're dealing with that old school goodness when data samples are scanned printouts

Now, ARINC as a company is no longer with us. But the standard is so pervasive that even recently at AERO 26' - the largest general aviation conference in Europe - I asked the folks at both Garmin and Boeing-Jeppesen how things are and they both mentioned current need for supporting ARINC 424 in their products. So how does the standard get updated if the company that owned it no longer exists? Well, it got transferred to a subdivision in SAE International (another large standards org) and several organizations in aviation work together. The primary needs nowadays are kept light:

address new developments in navigation systems/tech and incorporate the necessary data

fix format issues or issues in incorrect documentation that can lead to implementation problems

That's pretty much the only time a new revision will be needed. But it is still updated and the latest revision is revision 23, from around 2022. A new revision is in the works now, but not much has changed in aviation so 23 is currently the only thing needed in the world atm.

There are also other formats for navigation data, like AIXM, which is out of scope for this post, but is an XML-based data format that is way more expressive for the data, and this is generally where the industry is going, but because most equipment is built with ARINC 424 as the first-class data format to load in, so must ARINC 424 stay for now.

This is a lot of info, so I hope it was presented in a good way, but if not, shout and I can update this section to improve the narrative and make it clearer.

Project motivation

The primary motivation for me as with any project is that I had a problem and went into the rabbit hole and realized there was an opportunity to offer something better. I really wanted to be able to use the FAA CIFP exports for a separate project relating to airspace management data. Now, as alluded to before, I could use AIXM for this, but I needed something that could potentially work with COTS data loaders for flight management systems. Many flight management systems unfortunately ONLY work with ARINC 424 databases. Most providers create the...