Paul’s blog originally appeared in the October/November 2014 issue of the AircraftIT Operations eJournal.
One item of news that may have passed you by over the summer was the much-anticipated publication of ATA Spec2300. When I say, “much anticipated”, I do of course mean, “much anticipated amongst the circle of data standards nerds, in which I frequent”. As for everybody else, you’re probably thinking “[sigh] not another data exchange standard”.
I used to be the type of person who would scoff at data standards. The XKCD standards comic pretty much summed up my thoughts on the subject.
Having previously worked with a number of, mainly consumer, application-programming interfaces (APIs), in order to connect software applications and internet services, I never understood the fuss about aerospace data standards. If I wanted to represent the location of an aircraft onto a map, all I would have to do as a programmer would be to send the latitude and longitude of the current location via a well defined web service call and Google Maps would do the rest. Not to make light of the technical challenges involved in working APIs, but this kind of integration between apps and services like Twitter and YouTube are being taught in my son’s school… and he’s ten years old.
So why all the fuss when it comes to getting content from an aircraft OEM, to the operator and ultimately in the hands of the flight crew? For one thing, OEM data is way more complicated than some of the data my boy and his pre-teen pals are working with. A Flight Crew Operating Manual is a bit more sophisticated than the 140 characters in a tweet. Secondly, the route an FCOM takes from the OEM before it finds it’s way onto an EFB is somewhat meandering to say the least. A typical flight ops manual, depending on the amount of modification and knife & forking that it undergoes, will find itself being passed between multiple content management, reconciliation, and workflow systems before ultimate approval, publication, and distribution. The exchange of data between these systems requires integration points that can be costly to develop and maintain. Add into the mix that an airline requires data for multiple manual types for different aircraft types, often from different OEMs, and you start to see the scale of the problem. If each OEM had its own proprietary format for their content, then the cost and complexity of this flow of data would soon spiral out of control.
This is why Boeing, Airbus, Bombardier, and Embraer (along with a number of airlines, software vendors, and content experts) have devoted their time over the past couple of years to developing the next generation of flight operations data standards to meet some of the challenges of next-generation aircraft and the content needed to put knowledge in the hands of those who will be flying them. June 2014 saw the publication of the first version of ATA Spec2300 thanks to the efforts of A4A’s Flight Ops Interest Group (of which yours truly is a member). However, at the time of writing there’s no OEM that seems to be ready to embrace the standard and publish its flight ops content in this format. I personally had assumed that Airbus would have adopted Spec2300 for the launch of the A350, but I understand from good authority that this isn’t the case. Boeing, too, is not ready to adopt the standard until there is a run on demand from their airline customers. United and Air Canada have shown signs of interest in adopting the standard for their flight ops manuals, but this doesn’t represent a tipping point.
Standards are great, but unfortunately unless they are adopted then they are not much use to anyone. Spec2300 may be at risk of withering on the vine unless the case is made for the benefits it will bring, then hopefully demand will ultimately follow. Whose job is this I wonder? The OEMs? The airlines? Or the likes of me? Time will tell I suppose….Or at least that’s how I see it.