Data Link Available

Ken Simmons, Ed Porisch, Peter Lemme,
Mary Nakasone (Sato), Dave Allen
QANTAS 747-400 FANS Certification Flight Test
June 19, 1995

(Captain took this inflight, from his seat looking back)

Personal Reflections of Data Link Developments 

• ARINC 724B ACARS
• Dawn of satellite data link 
• FANS data link
• ACARS-VHF Interface Unit
• User Modifiable Software
• ACARS Qualification Test
• Satellite Category B
• Required Communications Performance (RCP)

I am celebrating 25 years working on data link.

A book is in the works, this is a part of it.

Please send me your stories.

I am always looking for interviews, too.


ARINC 724B ACARS
In 1989, after eight years working on Boeing Automatic Flight Controls, I switched from Thrust Management Systems to work specifically on Boeing 747-400 and 767 ACARS projects.

After a flight test on a 767, in about 1983, I asked my fellow avionics engineers what was ACARS.

No google search back then.

After a couple of days, someone found a reference, at least we knew what it stood for.

Aircraft Communications, Addressing, and Reporting System (ACARS)

The first application was OOOI, or Out-Off-On-In.

Out-to-In is Block Time (doors closed and parking brake released was common logic)

Off-to-On is Flight Time (weight-on-wheels)

Piedmont famously calculated the benefits of accurate reporting, especially for pilots monthly flight limits (whereby, they found out exactly how many segments were acceptable).

Check it out --> The Piedmont Connection

Therin Dastrup writes:

"I wrote the world's very first ACARS program in 1976 on a "state of the art" processor card with a TMS9900 microprocessor, 12KB EPROM, and 6KB RAM."

At that time, the 747-400 was under pressure from flight crews upset over the loss of the flight engineer crew member and demanded that ACARS provide an offset using automation.

ACARS was buyer furnished equipment (BFE), in this case built against ARINC 724B provisions.

BFE meant the customer would select the part from an "approved" supplier and then Boeing would stand ready to receive the part and "plug it in".

BFE really meant that the supplier sold the airline a vision of what ACARS could do, and then proceeded to patch together the requirements and the software as the details firmed up.

Sadly, details rarely firmed up on schedule, and usually the copy and paste left a few surprises.

Boeing had the integration bench, and whose sole wish for BFE was for the system to work per the specification so we could pass functional test and certification demonstration.

The supplier documents (hardware and software) were processed without much grief.

The issues were typically about unexpected software features.

I learned that the specification was the oracle from which the function was defined.

In a few cases, I could accommodate minor issues by marking up the spec making the issue a "feature" (as a last ditch effort on the eave of delivery).

Of course, safety was a paramount consideration.

The approving flight crew (FAA and Boeing pilots) along with FAA engineering watched ACARS very closely and demanded an explanation whenever something went wrong.

Wireless communication is frustrating, in that "shit happens".

Retries, logoffs, dropped messages for whatever reason.

We had to piece together every thread, manually, to prove that it all worked out in the end; whatever issue was overcome.

One airline in particular was insistent that they would only accept their airplane if ACARS was working.

The airline flight crews literally insisted they would not fly the airplane without it.

ACARS is entirely non-essential to the airplane.

It's funny to have a customer threaten to not take your product, because the part the customer was supposed to provide doesn't work.

The prevailing attitude at Boeing was (and I think still is), do whatever it takes to build a safe product, and by that I mean by helping wherever possible.

In this case, it meant we became pro-active in working with each supplier so they understood our process of acceptance and particularly the expectation that what is being submitted actually works.

It also meant we became very active in industry meetings to socialize and resolve issues and features; a path I still am actively pursuing to this day.

Frankly, we became a bit discouraged with ACARS, as every new part number seemed to take on a life of its own.

We learned you have to push every button, even if not labeled, and in odd sequences.

While the 747-400 had already been delivered some months earlier (part of the reason for my move), ACARS was behind schedule.

The use of an ARINC 739 MCDU permitted ACARS access to the same device used for flight management.

There were interfaces to

• ARINC 740/744 printer (BFE)
• Central Maintenance Computer 
• Crew-Alerting display 
• Flight Management System 
• Aircraft Condition and Monitoring System (BFE)
• Cabin Terminal (BFE)
• Aircraft program pin 
• 7 character registration number
• Analog door and gear proximity sensors 
• open-ground
• VHF radio - Center
• shared voice/data mode

We had four BFE suppliers along with my memory of who we dealt with most...

• Rockwell Collins
• Neal Spear
• Teledyne Controls
• Therin Dastrup, Dave Pook, George Simmons
• Allied Signal
• Jorge Rivero
• Sundstrand
• Tom McGuffin, Ed Anderson

Allied Signal later bought Sundstrand, and then much later bought Honeywell, which is known as Honeywell.  Others have entered the marketplace.

The first great panic I faced had nothing to do with the avionics.

The ACARS ground station terminal, the terminal from which messages were sent from and were received, was running out of paper.

The sad story is, the terminal was so archaic, we could not locate a supplier for paper.

Without the paper, the terminal was useless.

<another time - sending an engineer around the world to change a roll of paper>

The happy outcome, we were able to cobble together another computer terminal and swap out the old terminal.

The funny part, the terminal was installed a long, long ways away from the avionics lab.

We were able to get everything to work well enough that all four suppliers received type certification by Feb 1990.

I won an award for the accomplishment.

It was the first type certification of ARINC 724B four times over.

Data Communications was a great group to work with.  Gary Patton was my supervisor: supportive, funny, energetic and quite generous.  Jack Hayes left the group when I arrived, but Howard Kenoyer, Glenn Torgerson, John Sheehan and Ron Lundquist stayed on, with Kevin Dihle and Chuck Sheldon supporting.  Ana Lazo-Perez (Christofferson) provided software support for DO-178 approval (spec, configuration index, accomplishment summary) with Max Hayashi as Systems DER (John Sheehan was a DER candidate then, and I followed in 1991).

My group at Boeing was focused on 747/767, while there was another avionics engineering group responsible for 737/757 ACARS, notably Nigel Lee and Dave Lyndon.   By 1993 we combined under one group that I supervised.

ACARS embedded applications were developed uniquely by each supplier, making each test filled with discovery and experimentation.

Many messages, uplink and downlink, were specifically composed for an airline.

While ARINC 597 and ARINC 724 ACARS had been in existence from 1977-1978, the Boeing 747-400 was the first airplane to embrace ACARS as an essential element in system design, and this would lead to breakthroughs in satcom and FANS as well.

The MCDU and printer interface offered the flight crew extensive access to custom reports and messaging.

The central maintenance computer could be programmed to send messages based on flight phase with fault summaries.

The central maintenance computer could be interrogated from the ground in real-time, with requested reporting.

The ACMS could be programmed similarly for airline-selected telemetry.

The free text messaging available to both cabin terminals and to the flight crew, with functional addressing, offered a flexible tool for unforeseen circumstance or event.

Every customer had a unique configuration of BFE (supplier, part number, features) that required a new development, integration, and certification.  

It took at least 18 months to build the airplane, assuming releases are completed by nine months from delivery.  

Part numbers, wiring diagrams, outline and connectors, power, cooling had to be accounted for by all disciplines.

My job, which involved a group of people for just ACARS interfacing with many other groups, was two-fold:

1. Build the airplane - the "Releases" (the project)
2. Deliver a working system - "Certification" (the staff)

In the earliest days, Boeing avionics was divided project and staff (I was staff), but now we were one group.

It was my experience that some people are naturally better at releases, and others better at testing and coordination. 

It is never a good idea to force someone to do releases or to put someone in the lab that doesn't want to be there.

Two years or more ahead of delivery, customer engineers would deliver documents detailing the customer requested configuration, including part numbers, suppliers, and interface features.  

Data link was new and quite complex, yet every customer wanted ACARS.

My group spent a lot of time meeting with each airline and their suppliers to arrive at a committed configuration.

Building the airplane, the releases, was simplified because of ARINC 724B standardization.  

The different mix of equipment would change the wiring diagrams.  

The registration number was surprisingly difficult to nail down, changing at delivery sometimes.

One airline bought an ACARS and said they wanted it to be just like another.  We tested the ACARS and the messages were encoded to be sent to the other airline!

The suppliers had some challenges meeting schedules, mandating weekly telecons with supplier management, long lists of action items and schedules to review.

My first data link subcommittee meeting was in Feb of 1990, and literally the first thing I heard was a problem when a message originates from the air and the ground at the same time. 

Messages passing in the mail has been an issue forever!

Dave Knerr writes

"I got started in ACARS back in the early 90's when I took over for Bob Roeder at UAL. Built a lot of AOC apps integrating ACARS with UAL's ground system to support Dispatch, Crew Scheduling and Maintenance.  

I worked with Capt. Wayne Alshire to get the UAL FANS program going.  

Amazing with all the Internet, Broadband and WiFi out there that ACARS is still in wide use by airlines, military and corporate aviation.  

Left UAL in 2004 to start my own company. We have been running our own ground servers supporting ACARS applications for our customers and just added ATC data link (FANS) functionality for customers to test, train and get approved for FANS operations.  

The specs haven't changed a lot since I was involved in the various sub-committees back then. Some of them are dated 1999."

User Modifiable Software
Every ACARS certification flight test was a rapid-fire sequence of conditions, each requiring careful audit to be sure every message was accounted for and any loss explained.

The flight crew were the user interface.

The flight crew enters in all the information, is alerted, and reads and comprehends any messages or displays.

The ACARS interface was through MCDU display or through the printer; but the MCDU was the control unit.

Occasionally the MCDU menu (display) would have a mistake in it.

In some cases, we could volunteer a change to the specification and accept the misspelling, as long as it was not misleading.

On one flight, we discovered the ACARS MCDU display had a fuel quantity readout in pounds, and the airplane was programmed for kilograms.

The airplane had a dedicated fuel quantity display in kilograms.

The FAA would not accept the ACARS display for fear the number could be construed to be kilograms.

We argued that the flight crew would defer to the aircraft fuel quantity indication.

There was an unfortunate incident on a 767 in 1983, regarding confusion over fuel quantity lead to a dead-stick, successful emergency landing.

Check it out --> Gimli Glider

Not long after the FAA would not accept the ACARS with the wrong fuel quantity units, Sundstrand and Lufthansa began promoting the concept of user-modifiable software.

User-modifiable software was a special partition that had no executable features, rather static settings and content.

A good example, which we were also promoting on the same basis, was satellite voice, where we needed a way to load the telephone numbers (the directory), which was unique to each airline and would change occasionally.

In the end, the FAA agreed that as long as the executable software could limit the user-modifiable software to ensure nothing unsafe would occur, concluded that anything could be displayed as long as it said ACARS on top they would not care (well, that's how I took it, because they confirmed fuel quantity units were not an issue now).

Later on the Airplane Personality Module emerged as one means to collect all the "static" airplane-specific data into a memory device, rather than program pins.  This was especially a benefit for satcom, allowing simpler box-swaps.

The concept of having a uniquely programmed memory device did not seem the best solution, so I was able to promote an alternative, which did not win over the community.  As the years progressed, I do feel my commentary is even more relevant today, and especially along the concepts developed in ARINC 791.

Check it out --> Airplane Personality Module (1996)

ACARS/VHF Interface Unit (AVIU)

A short-coming of the ARINC 724B wiring is that VHF mode control originates in the ACARS.

ACARS is a "level D" system, whereas the VHF is a "level C" system.

ACARS failure was at most a minor event, but failure (loss) of both of two required VHF radios was a major event.

No one cared until one day, on a cert test, a particular ACARS would not give up the VHF radio for voice control.  

The FAA mandated to Boeing that a placard be installed limiting use of the radio connected to ACARS as not one of the two radios necessary for dispatch of the airplane.

It was curious that Long Beach FAA aircraft certification office did not levy the same placard on McDonnell Douglas production airplanes.

Seattle FAA aircraft certification office insisted every service bulletin issued during this period also include the placard.

The FAA mandate meant that if one VHF radio was failed, ACARS would have to be made inoperative in order to take credit for the radio connected for voice application.

I developed a hardware solution that could be applied between the ACARS and the VHF radio control panel that would arbitrate the ACARS commands and the pilot mode commands so that ACARS would not be in control.

Boeing filed for and was issued patents for this, with me as the inventor.

ACARS/VHF transceiver Interface Unit (AVIU)

United States 5,809,402         Issued September 6, 1996 

An Aircraft Communication, Addressing, and Reporting System (ACARS) to VHF transceiver interface unit (AVIU) which allows direct pilot control of the VHF mode (voice or data) and also commands the ACARS into the proper mode.

ACARS/VHF transceiver Interface Unit (AVIU)

United States 5,920,807          Issued June 16, 1998 

An Aircraft Communication, Addressing, and Reporting System (ACARS) to VHF transceiver interface unit (AVIU) which allows direct pilot control of the VHF mode (voice or data) and also commands the ACARS into the proper mode.

Dawn of Satellite Data Communications

Satcom (ARINC 741) was in development at the same time as ACARS. 

Satcom only interfaced with ACARS as an alternate bearer to VHF.

It turned out that most of the challenges were not getting satcom to turn on and connect, it was getting ACARS to recognize satcom (including the data link service provider, ARINC at first) and to keep all the messages flowing.

As a result, I ended up taking responsibility for the satcom and the data link as a "super-lead" (later supervisor), with a dedicated lead for data link and another for satcom to help me.

We were successful in completing the first type certification (data level zero) in August 1990, on a United 747-400 with Rockwell Collins satcom and a Ball low gain antenna.

The Inmarsat ground station provider was behind schedule, so we ended up using a Rockwell Collins (Interim) Ground Station

Rockwell Collins Interim Ground Station (IGS) in Comsat Santa Paula (1991)

Guy White, Vizada (Comsat) Santa Paula,  with the IGS (in storage) at Santa Paula, 2010

We learned that there was some confusion on the coding of the ICAO bit pattern and we had to limit installations to a handful of airplanes (four) until the production ground stations came on line and we could proceed with what is now known as "data level 2".

Check it out --> Inmarsat Satellite Communications (1994)

Future Air Navigation System (FANS)

The next data link step was FANS.

I learned back then, never name the system you are developing "future" (or "Next")!

Both the ACARS and the satcom were effectively ready to go for what we would certificate in June 1995.

It took years of wrestling with ATN community until we finally agreed on a way forward: we could use ARINC 622 ACARS convergence function (four bits equals one hex character) to pass the ATN bit-oriented messages over the ACARS character-oriented network.

Philip Clinch writes:

"At the beginning of 1993 it was realized the ATN version of ADS/CPDLC would never be ready by the 777 launch in 1995. 

The AEEC data link group was given 6 months to define a way to have ADS/CPDLC work over ACARS and we wrote AEEC 622 in record time as a temporary alternative to ATN that was so good is now being used by the FAA NextGen CPDLC"

ARINC 622 also spells out the ATS Facilities Notification as an alternative to "context management" in the ATN.

Check it out --> Comments on use of ARINC 622 (1994)

A breakthrough in the process of accepting ACARS was an agreement of how long it should take to send a message.

In truth, one day Dave Allen asked me in passing, how long should it take to get a message to the ground and get an ACARS acknowledgement back, or the other way around. 

We agreed on 60 seconds, from which the hazard analysis could be completed regarding airspace separation assurance.

It was such a simple assumption, but it become a cornerstone.

Once everyone was onboard with ACARS and using Inmarsat along with VHF, the avionics development was mostly focused on the FMS, on the displays, on the DSPs, and the ANSPs.

Comm messages were a new category of crew alerting. 

Comm message logic turned out to be rather tricky, and starting back with satcom voice in 1993, it took a couple of years to work out.

Check it out --> Crew Alerting Messages for ACARS and Satcom (1995)

The data link function for FANS "just worked".

As I had learned so many times over, a tandem connection from FMS to ACARS to satcom/VHF to DSP to ANSP/Airline has many opportunities for failure. 

We had to watch every message carefully to be ready to point the finger at the circumstance leading to a retry or a timer expiration.

We did have some issues.  Notably, the "NoComm" shadow when leaving VHF coverage still plagues the industry.

A lesson from the school of hard knocks, "The simpler the function, the more perfect it must perform."

It first became clear to me in Thrust Management, where complex control law adjustments were approved without comment, but any change to the easily-understood mode control logic brought comments from everyone.

In FANS, I found that everyone expected the wireless data link system to work perfectly.

Any message retry demanded an explanation and assurance that it was not a problem.

However, other systems, like those starting with "F", seemingly had a few little whoops and gotchas, that by and large were noted but accommodated.

Not suggesting any safety issues here, but just that a defect in a very complex system may be deemed acceptable when the same defect in simple system would probably be deemed unacceptable.

I had chance to fly on a revenue flight where we had authority to test FANS data link.

On the ground at Kai Tak, Hong Kong, after completing FANS flight test

Capt. ?Ray Heiniger?, Second Officer???, Capt. David Massy-Greene
QANTAS engineer ???, Boeing Flight Test Engineer ?John Waters?
Boeing Supervisor David Allen in the foreground

Check it out--> QANTAS crew sets record flying from LHR to SYD nonstop in 747-400

<for another time: movie from flight deck arriving at Kai Tak, my search for a white shirt big enough to fit me so I could pass through immigration, paying for dinner, jump seat observer with QANTAS from SYD to BKK to LHR>

I flew many experimental flights testing FANS data link, including the certification flight test.

I was a Boeing DER for ACARS, satcom, printers, ACMS, DFDAU and DFDR (flight recording).

Post Flight   "FANS is Certificated"   June 19, 1995   Sydney
Boeing Flight Test Engineer ?John Waters?, QANTAS Captain David Massy-Greene, 
FAA Pilot ???, Boeing Experimental Pilot Tom Twiggs, 
FAA Engineer Clyde Halstead

I am also happy to have been aboard the first commercial FANS flight, especially it being on June 22, 1995; or 622.

I was one person among a huge crowd

• The key airlines (United, QANTAS, Air New Zealand, Cathay Pacific) and especially their flight crews and supportive engineers.
• Wayne Aleshire, David Massy-Greene, Ian Varcoe, and ???
• Boeing which had an army of engineers and analysts
• I leaned mostly on Dave Allen and Dwayne Broderson
• Suppliers of FMS, ACARS, display systems, and satcom
   
• Service providers ARINC, SITA, and Inmarsat
• Endless committees and groups (ICAO, RTCA/EUROCAE, RPG, AEEC)
• Regulators/ANSP 
• DGAC, Airways New Zealand, FAA, Australian CASA
• The smaller the country the quicker they can adapt
  <another time, Papua New Guinea and Alaska lead the way>
• Tom Kraft from the FAA has stayed the course!

Tom Kraft and Dave Allen celebrate FANS certification
QANTAS Post Flight
(yes, we had a beer, we were in Australia)

Congratulations to all.

For me, it was like landing on the moon!

Today, we call it FANS-1.

Check it out - FANS ACARS and SATCOM issues (1995)

Check it out --> FANS Status (1996)

ACARS Qualification
My first exposure to ACARS was using ARINC over VHF.

Later we installed SITA VHF stations at a few nearby airports to enable integration testing.

With satcom, we could connect to either ARINC or to SITA.

We conducted development testing over the air, on the live network.

The idea was that we were right there, ready to pull the plug if something went weird.

I can't really recall that we were pulling plugs very often.

However, ARINC started to notice that ACARS in-service were creating some issues, causing congestion.

A good example of a disruptive event is a stuck mic, to which the radio can take action unilaterally.

In any case, ARINC came to realize that the ACARS quality level was not consistent, and that some particular part numbers were causing them difficulty.

The one feature that rung everyone's bell was when there was an outage and all the ACARS went to the primary frequency to recover, at the same time (where normally they are distributed to secondary frequencies), causing it to become so congested that it took at least one overnight cycle to parse everyone into the secondary frequencies.

One day in around 1992, ARINC Steven Leger and John Sullivan visited and let us know we needed to follow a more structured development, in particular

• use of a dedicated (off line) test network
• passing an ARINC qualification test.

My first reactions were frustration at the difficulties, but there were real issue to be solved and I agreed with their mandates.

During FANS, as a part of the certification, we developed a FANS qualification test, which lives on in various forms, such as Aircraft Equipment Interface Test (AEIT), ARINC 618 appendix C, ARINC AQP, SITA VAQ.  Kevin Dihle was diligent inpulling together all the details into a workable model test sequence.

Check it out --> FANS-1 ACARS and Satcom must pass Airplane Equipment Interoperability Test (AEIT) (1995)

Satellite Category B

Having left Boeing to consult to Iridium, in 1999 I crafted what would be called satellite category B (see ARINC 618).

Check it out --> Satellite Category B

Iridium circuit switched data calls would be better served if we could speed up the ACARS store and forward by using what now would be called spoofing, or performance enhancing proxy.

Satellite category B provided a local ack to get the ACARS MU/CMU to cough up all of its traffic, especially multi-block messages. 

Once all the traffic is aggregated, Iridium would put up a circuit switched call and move the collected messages.

Today, Iridium uses Short Burst Data (SBD), a method we did not even know of at that time.

The issue of getting ACARS to cough up larger messages has not died, rather it has taken a new life with ARINC 841,  Media Independent Aircraft Messages (which sadly completely ignored satellite category B)

Required Communications Performance (RCP)

I worked closely with Roy Oishi and Tom Kraft under RTCA SC-189 to develop a concept to follow Required Navigation Performance (RNP) that could be applied to data link or voice.

Here is a paper I contributed to the working group.

Check it out --> Required Communication Performance (RCP) (1998)

Tom Kraft has been an amazing data link proponent, and through the joint leadership with Arnold Oldach, PARC/CWG has produced GOLD, explaining how all the data link bits play together, and especially how to monitor them for compliance and acceptance.

I remain hopeful to show how we can use non-safety radios for safety applications if we can meet the RCP.

Peter Lemme

peter@satcom.guru

Copyright 2015

All rights reserved