Business & GA, Commercial

Virtual Data Acquisition

By Charlotte Adams | January 1, 2004
Send Feedback

Flight data acquisition units (FDAUs) in today’s federated air transport avionics architectures are standalone entities. Located in the electronics bay, the FDAU is considered part of the data recording function–a central data collection and distribution point that receives outputs from line replaceable units (LRUs) and feeds the data to the flight data recorder. But the FDAU function is likely to evolve, as architectures become more integrated, more data is collected, and avionics systems are connected over high-speed networks.

Today’s data acquisition unit receives inputs via a multitude of wires, including point-to-point ARINC 429 links, analog lines and discretes. In the evolving network environment, however, the standalone FDAU may transition, in some cases, to a distributed software or hardware/software function. This evolution–as with integration generally–will reduce the weight and volume of cabling required to implement data acquisition but will also increase the function’s complexity.

Anticipating the transition, the Airlines Electronic Engineering Committee (AEEC), in its Digital Flight Data Recorder (DFDR) Subcommittee, has broached the concept of a "virtual" FDAU. A recent AEEC report states that in future aircraft the acquisition of information for the flight recorder "could be accomplished using a distributed technique, whereby the function may be performed by software residing in generic hardware." The report adds: "the acquisition function could be distributed across a number of hardware/software platforms. Therefore, an acquisition function specification will be prepared in lieu of a form, fit and function definition for an acquisition unit."

Project Paper 767

The "virtualizion" of the data acquisition function may be a long time coming. The virtual FDAU (VFDAU) concept is closely associated with work on defining a new, high-bandwidth flight data recorder, known as ARINC project paper 767. This prospective standard will define a recorder with a high-speed interface that can accommodate data, voice, data link and imagery. Although there is no requirement yet for recording cockpit imagery, some airlines believe that the installation of two multifunction 767 recorders will provide some minimum equipment list (MEL) relief, i.e. will allow carriers to fly with one recorder removed. The ARINC 767 project paper is expected to be finished in the fall of 2004, says Dan Martinec, secretary of the AEEC DFDR Subcommittee. (Once a project paper is adopted, it becomes an ARINC standard.) The virtual data acquisition concept may be fleshed out as an attachment or attachments to the ARINC 767 project paper. Or, if the VFDAU proves to be sufficiently complex, it may require a dedicated specification.

"I don’t think the [evolution] is desirable or undesirable," says Robert Swanson, a project engineer with FedEx Express. It’s a result of the way avionics systems in general are going–away from ARINC 429 and towards Ethernet and fiber optics. "There’s not necessarily going to be one point of data acquisition out there any more."

The enhanced ARINC 767 recorder probably will have Ethernet interfaces to support high-bandwidth data transfers, which means mapping data acquisition functions into a networked environment. The speed of 1 gigabit/sec appears to be most appropriate for the recorder interface. It will also resolve many of the latency and timing problems that have been experienced when information from aircraft systems is recorded using much slower data buses, according to Martinec.

Integrated architectures will be implemented differently in different airplanes. The standard dealing with flight data collection in a networked environment probably will document the outputs to be provided to the recorder, based on the network technology–for example, the Avionics Full Duplex Switched Ethernet (AFDX) or fiber optic links, Swanson says. Current data acquisition standards are very specific, calling for a 6-MCU box with an ARINC 600 connector and a certain number of 429 ports. "We can’t define it that way anymore," says Swanson.

The Airbus 380–the first networked air transport aircraft avionics architecture–won’t be introduced with a 767 recorder, however. Airbus plans a standalone enclosure, the common data acquisition module (CDAM), which contains separate data acquisition and aircraft condition monitoring system (ACMS) units. The data acquisition unit will share some functions with the ACMS unit–power supplies, built-in test and external signaling to the flight warning computer–but it still will be somewhat autonomous.

The A380’s data acquisition function is transitional, acquiring avionics information from the Ethernet-based AFDX network rather than through point-to-point links with the avionics systems. It forwards flight data to a traditional ARINC 747 recorder, formatted according to ARINC 717.

Pros and Cons

The applicability and feasibility of a virtual data acquisition function are being debated, however. Engineers want to make sure that the acquisition function’s integrity is protected under any aircraft conditions and that the data is delivered to the flight data recorder according to strict time schedules. If the acquisition function is distributed, they say, the task becomes more complex and certification, more difficult to achieve. Every part of a distributed data acquisition process will have to be guaranteed the same level of integrity (DO-178B, Level D) that it currently has.

Today’s FDAU performs two main functions as part of the flight recording system, explains Armen Nahapetian, vice president of engineering for Teledyne Controls. The equipment acquires parameters–usually with various electrical characteristics–and multiplexes the parameters into a single stream. The FDAU also performs auxiliary functions, such as checking the validity of parameters, performing some conversions and switching between buses. In an Ethernet/integrated environment, he says, some of the responsibility for acquisition will be addressed by an "integrated parameter acquisition function," and some of the multiplexing function will move to the Ethernet switches and routers. "The auxiliary functions, however, along with the interface to the flight recorder, as well as some of the regulatory requirements, will have to be addressed by a physical FDAU or by one or more virtual FDAU functions distributed in the integrated system."

A virtual data acquisition function also could be implemented as a software task residing in avionics systems. Or the acquisition function could be split into several hardware/software components that collect data from the aft, center fuselage and electronics bay, respectively, involving multiple data sources and collection points. The complexities of validating and qualifying a distributed acquisition function, however, may prove to be too difficult, according to one industry observer.

Even in an environment where most aircraft have integrated avionics systems, there still will be a role for standalone acquisition units. Retrofit applications to non-integrated avionics architectures are obvious cases, says Nahapetian. "But even in newer aircraft with integrated avionics, there might be cases where the introduction of a new technology or even a new regulation will force one of the integrated functions to be moved back to a standalone unit."

An operator, for example, may want to replace an integrated maintenance recording function with a wireless link that is outside of the integrated architecture. Or the introduction of a new parameter recording regulation, which can’t be met with the existing system, might force the installation of an auxiliary FDAU, Nahapetian observes. If image recording is required some day, this capability may be added through standalone data acquisition hardware. Such a requirement also could necessitate a specialized image processing unit to compress the images before recording them.

Beyond Black Boxes

"Virtualization" of data collection functions also is occurring outside of the "black box" world that flies the aircraft and runs critical systems. Flight data has many other potential applications besides feeding the flight data recorder, and carriers are designing their own data gathering functions that tap into flight data for ACMS, electronic flight bags and flight operational quality assurance (FOQA), for example.

Quick access recorders (QARs), which are used to support FOQA, as well as maintenance applications, are on the front line of this trend, says Raul Segredo, president of Avionica, a QAR manufacturer. QARs are typically fed by the same FDAU that forwards data to the flight recorder. As network-based avionics become more prevalent, the QAR will bridge flight data to the aircraft network, he says.

Avionica’s QARs can collect flight data from an FDAU and output the data through an Ethernet port directly to an EFB, airborne server or other aircraft networked device. This capability, to be available by the second quarter of next year, is the "first step that bridges the world of black boxes to Ethernet aircraft networks," Segredo claims. "Aircraft will incorporate onboard networks alongside existing avionics, in cases where networked equipment primarily will be certified to lesser standards and interconnected to existing avionics through interface units such as a QAR, he says.

Software on an airline-controlled EFB, running on Windows, is less expensive to write and easier to update than software running on a black box. Turning condition monitoring into a software application also can make that process more efficient, robust and reliable, Segredo says.

FedEx Path to Future

Cargo carrier FedEx Express is "virtualizing" flight and aircraft condition monitoring system (ACMS) data collection in the form of an independent, airline-controlled flight data collection path in its Airbus 380s, which it will begin to receive from Airbus in 2008. Airbus will install two onboard servers running the Linux operating system. The servers will store flight data, flight operational quality assurance (FOQA) data, onboard information system (electronic flight bag, or EFB) documents and other software in Oracle databases. The two Airbus servers will receive data through a "secure communications interface" from the A380’s Avionics Full Duplex Switched Ethernet (AFDX) avionics network.

FedEx, however, will add its own, third server, running on Windows, which will attach to the dual-server network through a secure router. This additional path will allow FedEx, or any other airline, to host its own applications, which can be modified and upgraded at will, as long as configuration control is maintained. Company-written applications, such as weight and balance calculations, troubleshooting guides and wiring diagrams, will be hosted on the third server, which FedEx will certify to DO-178B, Level D, says Bob Bouchard, aircraft development advisor with the cargo carrier.

With an additional server, FedEx, for example, can run its own customized software for the A380 EFB and control the EFB’s monitor, keyboard and mouse, even though the EFB hardware is being provided by a third company, reportedly Sagem. "You can use Jepp charts if you wanted to," Bouchard adds. Other airlines are interested in the third server concept, as well, he says, and some even want a fourth server to host in-flight entertainment (IFE) applications.

Another advantage of this approach is that "we can run some of these programs while the airplane is flying in," says Bouchard. Triggers built into the third server’s database set thresholds for downloading fault messages to maintenance technicians prior to the aircraft’s arrival. FedEx plans to install the server on its A380s and get a supplemental type certificate on the first airplane before it goes into revenue service.

Receive the latest avionics news right to your inbox