Abstract:
The Radio Frequency Health Node (RFHN) provides a method for remotely configuring wireless/wired sensors and accessing the sensor data during flight or other remote activity. The RFHN may integrate the sensors into a higher-level data stream by sending the data to a management facility. Access to the sensors can be made available remotely through the management facility allowing operators to send commands to and receive data from the RFHN and the array of wireless/wired sensors.

Description:
ORIGIN OF THE INVENTION 
       [0001]    The invention described herein was made by employees of the United States Government and may be manufactured and used by or for the Government of the United States of America for governmental purposes without the payment of any royalties thereon or therefor. 
       TECHNICAL FIELD OF THE INVENTION 
       [0002]    The present invention relates generally to data acquisition systems and, in particular, to a radio frequency health node wireless sensor data acquisition system. 
       BACKGROUND OF THE INVENTION 
       [0003]    Electrical systems are critical to the safe operation of aircraft and spacecraft, and wiring is typically used to distribute power and communication signals throughout these systems. NASA&#39;s Space Shuttles each currently contain approximately 230 miles of wiring while commercial aircraft, such as the McDonnell Douglas DC-9, may contain approximately 300 miles of wiring. 
         [0004]    Electrical wire consists of a conductor that is encased in a protective layer of insulation. Wire is typically routed throughout a craft in a series of bundles with clamps and connectors. Safe routing practices include measures to prevent wires from wear, abrasion, contamination, and contact with other components; to gently bend and turn wires during installation to prevent cracking of the insulation; and to physically separate wires from systems whose signals may interfere with one another. 
         [0005]    When the protective layer of insulation on a wire is compromised and the conductor is exposed, the potential exists for a hazardous electrical system malfunction caused by a short circuit or an arc. A short circuit occurs when electricity takes an unintended path. For example, condensation and other conductive materials that are sometimes found on wire bundles can bridge the gap between a wire conductor and adjacent metallic structure. When electrical current follows the unintended path to the metallic structure, a short circuit that could interrupt the function of an electrical system occurs. Short circuits can transfer power to adjacent wires or draw an excessive current from the power source, overheating wires and creating fire hazards. Electrical arcing is a type of short circuit in which high voltage occurs and current crosses a gap, emitting sparks. The sparks include molten material from the wire conductor as it is vaporized by the high energy discharge, producing extremely localized heat. The arcing could ignite flammable products in the area and could potentially initiate an explosion. 
         [0006]    Electrical hazards can become even more critical in extreme environments, such as experienced by space vehicles, such as the NASA Orbiter and commercial expendable launch vehicles. Prototype wireless instrumentation systems have been installed in Orbiters as a result to test the feasibility of the systems. The wireless instrumentation system data is made available in two ways: (1) The data can be dumped from the wireless sensors to a laptop computer during post-landing operations, or (2) The data can be accessed by an onboard Payload General Support Computer (PGSC) if the wireless transmitters (i.e. sensors) are in the line of sight of the crew module windows during the mission. Neither of these methods is sufficient to insure that wireless sensor information from all Orbiter locations (crew module, aft, payload bay, wings) can be viewed by the crew or Orbiter systems in real time. 
         [0007]    Setting up the pre-launch configuration of the current suite of wireless sensors requires physical access to the Orbiter&#39;s aft compartment. For example, an operations engineer carries a laptop computer, with an appropriate wireless receiver attached, into the Orbiter&#39;s aft compartment. The operations engineer then uses the laptop software to set up the wireless sensors for flight. This presents several problems. If the Orbiter&#39;s aft compartment is closed out for flight the operations engineer must command the wireless sensors by opening the aft vent doors and sliding the wireless antenna into the aft compartment. If the launch is scrubbed the wireless sensors require reprogramming, e.g., with a new data acquisition start times. For typical launch scrub scenarios, the launch pad service platforms are not reinstalled. These service platforms are structures put in place close to the Orbiter that allow operations personnel physical access to different areas of the Orbiter. This means there is no access to the aft vent doors and the sensors cannot be reprogrammed, resulting in the loss of wireless data for that mission. 
         [0008]    For the reasons stated above, and for other reasons stated below which will become apparent to those skilled in the art upon reading and understanding the present specification, there is a need in the art for alternative approaches for data acquisition in avionic systems. 
       SUMMARY OF THE INVENTION 
       [0009]    The various embodiments provide wireless/wired data acquisition systems for the gathering and processing of data from wireless/wired sensors. The various embodiments will be described in relation to use in a NASA Orbiter, but it will be apparent that the systems are useable in a variety of avionic as well as stationary environments. The data acquisition systems center around a radio frequency health node or RFHN. The RFHN provides an RF interface between a set of wireless sensors and a higher-level system, such as the Orbiter Vehicle Health Management System (VHMS). The RFHN also provides the capability to add new sensor types as the need arises. Data that are received from sensors are time stamped by utilizing a timing signal received from VHMS. The time correlated data is sent to VHMS which then integrates it into the vehicle data stream. VHMS will make this data available during flight through the VHMS downlink. The RFHN can be commanded to perform predefined data analysis and provide concise data reporting or to download data up to the RF bandwidth limits. The RFHN provides the capability to reconfigure sensors as required for mission changes (launch scrub, extended mission, or additional data requests), provide simple, remote (firing room) interface for non-intrusive configuration of sensors, and access to sensor data. 
         [0010]    For one embodiment, the invention provides a data acquisition system. The data acquisition system includes one or more wireless sensors and a control unit for managing the one or more wireless sensors. The control unit includes at least one transceiver for configuring and receiving data from the one or more wireless sensors, a sequencer to provide autonomous collection of data from the one or more wireless sensors in response to one or more predetermined trigger events, and a sensor data distributor to control a destination of the collected data. 
         [0011]    For another embodiment, the invention provides a method of collecting data. The method includes collecting first data from one or more wireless/wired sensors in response to one or more trigger events, converting the first data in response to a configuration file to generate second data, storing the second data, selecting a first format for output data, and encoding the second data for output in response to the selected first format. 
         [0012]    The invention further includes methods and apparatus of varying scope. 
     
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0013]      FIG. 1  is a functional block diagram of a data acquisition system of the prior art. 
           [0014]      FIG. 2  is a functional block diagram of a data acquisition system in accordance with an embodiment of the invention. 
           [0015]      FIG. 3  is a block diagram of the logical interfaces to an RFHN in accordance with an embodiment of the invention. 
           [0016]      FIG. 4A  is a functional block diagram of the software architecture for an RFHN in accordance with an embodiment of the invention. 
           [0017]      FIG. 4B  is a functional block diagram of the software architecture for a sequencer in accordance with an embodiment of the invention. 
           [0018]      FIG. 5  is a depiction of an example placement of multiple RFHNs within a typical installation in accordance with an embodiment of the invention. 
           [0019]      FIG. 6  is a diagram of an RFHN functional architecture in accordance with an embodiment of the invention. 
           [0020]      FIG. 7  is the data processing flow diagram of RFHN software in accordance with an embodiment of the invention. 
       
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
       [0021]    In the following detailed description of the present embodiments, reference is made to the accompanying drawings that form a part hereof, and in which are shown by way of illustration specific embodiments that may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice disclosed subject matter, and it is to be understood that other embodiments may be utilized and that process, electrical, or mechanical changes may be made without departing from the scope of the claimed subject matter. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope of the claimed subject matter is defined only by the appended claims and equivalents thereof. 
         [0022]      FIG. 1  is a functional block diagram of a data acquisition system  100  of the prior art. Data acquisition system  100  is exemplary of systems as used in NASA Orbiters. The system  100  includes a laptop or other portable programming interface  101  and one or more transceivers  105  for communication with a variety of sensing units  108 . Example sensing units  108  include one or more Micro-Wireless Instrumentation System (Micro-WIS) units  108   a . Micro-WIS units  108   a  refer to the suite of wireless resistive sensors, such as strain gauges, resistive thermal devices (RTDs), pressure sensors, humidity sensors, accelerometers, etc., that are battery operated and communicate via RF. Example sensing units  108  may further include one or more Micro-Strain Gage Units (Micro-SGU)  108   b . A Micro-SGU  108   b  measures strain gage measurements from two external sensors. Example sensing units  108  may further include one or more Micro-Tri Axial Units (Micro-TAU)  108   c . A Micro-TAU  108   c  measures data from three external accelerometers. Example sensing units  108  may further include one or more Wideband Micro-Tri Axial Units (Wideband Micro-TAU)  108   d . A Wideband Micro-TAU  108   d  is a high data rate version of the accelerometer sensing unit  108   c . It measures data from three external accelerometers up to 10,000 samples/sec and stores it internally. Due to the large amount of data stored internally, the Wideband Micro-TAU may be provided with a USB connection to reduce the download time. Such sensors  108  are commercially available, such as the micro-wireless sensors designed and developed by Invocon, Inc., Conroe, Tex., USA. 
         [0023]    Such prior art data acquisition systems for NASA Orbiter operations are configured via RF shortly before a launch. If a launch is delayed or scrubbed, re-programming of the sensors  108  requires line-of-sight access to the units from the laptop  101 . Using the laptop  101  to re-program the sensors  108  is a time-consuming manual task that competes with other Orbiter turnaround operations. Additionally, the different sensor types often require different transceivers  105  to communicate with the laptop  101  for configuration and data download. 
         [0024]    A wireless instrumentation system in accordance with an embodiment of the invention provides a method to mitigate safety concerns due to aging of wires, provide rapid response to vehicle instrumentation needs, provide a low cost solution for after market instrumentation, reduce the amount of vehicle wiring, and provide building blocks for use in Integrated Systems Health Management (ISHM) technologies. 
         [0025]    Data acquisition systems in accordance with embodiments of the invention are used to acquire instrumentation data and include two primary types of components. The first component is the receiving unit called the RFHN (Radio Frequency Health Node) used to manage the sensors and to receive data via a wireless communication link, store, process (if applicable), and forward the sensor data. The second component is the transmitter or wireless sensor used to acquire, process (if applicable), store, and wirelessly transmit the sensor data. The system has the flexibility to be configured as required for each application with different numbers and types of sensors. 
         [0026]    The RFHN facilitates a real-time wireless command and data interface to the commercially available wireless sensors and serves as the single point to interface with multiple sensors of multiple types. The RFHN sends commands to the wireless sensors and receives the instrumentation data from the sensors using the wireless link. With an on-board processor, the RFHN has the capability to perform data preprocessing, data fusion, trending, etc. 
         [0027]      FIG. 2  is a functional block diagram of a data acquisition system  200  in accordance with an embodiment of the invention. For one embodiment, the RFHN hardware is based on the PC  104 + specifications and uses the VxWorks Real-time Operating System (ROS). The RFHN  202  includes a core module  204  and a transceiver module  206  as shown in  FIG. 2 . The core module  204  provides the generic functions and the transceiver module  206  provides the interface to one or more wireless sensing units  208  while the wired interface  211  provides the interface to one or more wired sensing units  209 . The core module  204  can provide such functionality as CPU processing, data storage, power, data output, etc. The core module  204  may include flash or other non-volatile memory for storage of data files. 
         [0028]    The transceiver module  206  provides the wireless link and protocol required to communicate with the wireless sensing units  208 . The wired interface  211  provides the protocol required to communicate with the wired sensing units  209 . For the embodiment shown in  FIG. 2 , the wireless sensing units  208  can provide sensing of a variety of physical phenomena as described generally with reference to the sensors  108  of  FIG. 1 . Example sensing units  208  include one or more wireless temperature sensor units  208   a , one or more wireless strain sensors  208   b , one or more wireless accelerometers  208   c , and/or one or more other sensing units  208   d  for sensing other physical phenomena of interest. Wired sensing units  209  may also be used to sense a variety of physical phenomena discussed with reference to the wireless sensing units  208 . The modular design approach of the RFHN allows other transceiver modules to be integrated into the RFHN with minimal impact to accommodate future wireless sensing units. 
         [0029]    The RFHN  202  may be controlled and configured prior to launch via the T-0 umbilical  214 , e.g., using a serial or Ethernet interface. For one embodiment, the RFHN  202  is adapted to provide autonomous collection of data from the wireless sensing units  208  and wired sensing units  209  in response to one or more predetermined trigger events, e.g., a designated time interval, launch, reentry, landing, alarm indication, etc. 
         [0030]    Commercially available wireless sensors units are currently installed in NASA Orbiters and have flown on many flights since 1998. However, the sensor units have predominately been used in a stand-alone configuration and have not wirelessly communicated with other systems during a mission. 
         [0031]    The wireless communication within the RFHN  202  and the wireless sensing units  208  is, for one embodiment, based on the 916.5 MHz transceiver chip built by RF Monolithics, Inc. This frequency is located within the ISM frequency allocation of the UHF spectrum. The bandwidth is 50 KHz and the output power is set to one milliwatt. The modulation is set to Amplitude Shift Keying (ASK). 
         [0032]    The RFHN  202  as shown in  FIG. 2  includes, for one embodiment, on-board flight hardware that communicates with all the installed wireless sensors  208  and wired sensors  209  for configuration and data download. Data gathered during flight is formatted into a PCM stream and may be sent via a data interface  210  to a higher-level system, such as a Vehicle Health Management System (VHMS) or general purpose computer, where it may be recorded and potentially downlinked to an external system. Configuration information and other commands may be passed from the management facility to the RFHN  202  using a command interface  212 . The RFHN  202  may further include a T-0 umbilical or other secondary interface  214  to configure the sensors, for example, during pre-launch and launch-scrub activities, to download data during post-landing operations, and to aid in Orbiter processing and testing activities on the ground. The command interface  212  includes a serial command path for control, configuration, and time code. The data interface  210  includes a PCM data path for sensor data that is to be stored on the VHMS or other higher-level system. The secondary interface  214  provides the functionality of the data interface  210  and the command interface  212  while providing the ability to bypass the higher-level system, such as the VHMS. The RFHN  202  does not need to be co-located with the wireless sensors  208  for RF communication since the sensors have a relay function that is used to pass data from one sensor to another. 
         [0033]    The following provides an overview of the concept of operations for an exemplary RFHN  202  in a typical installation within a NASA Orbiter, both during flight operations and ground processing. It will be understood that data acquisition systems in accordance with embodiments of the invention are suited for applications and environments other than NASA Orbiters. For example, such data acquisition systems could be utilized in a variety of vehicles for air, sea or land as well as in stationary environments such as within factories. 
         [0034]    The RFHN  202  is powered on during the pre-launch countdown. Data is routed to the Launch Control Center (LCC) via the T-0 umbilical  214  as required. Commands may be issued to the RFHN through VHMS using the command interface  212  or the T-0 umbilical  214  for the purpose of configuring the wireless sensors  208  or wired sensors  209 . 
         [0035]    The RFHN  202  is capable of operating during ascent and may pass data to VHMS for recording. For certain embodiments, only a subset of the wireless sensors  208  and/or wired sensors  209  may transmit data to the RFHN  202  during ascent, such as a temperature sensor  208   a . The other sensors  208 / 209  may store ascent data internally and may pass that data to the RFHN  202  while in-orbit or during post-landing operations. 
         [0036]    In-orbit data dumps of wireless sensor  208  and wired sensor  209  data may be scheduled and controlled by ground personnel. The RFHN  202  may be commanded to retrieve data from the wireless sensors  208  and wired sensors  209 , and transmit the data to the VHMS through the data interface  210 . 
         [0037]    The RFHN  202  can be operated in-orbit to configure and collect data from wireless sensors  208  and wired sensors  209 . Some sensors  208 / 209 , such as a wireless accelerometer  208   c  may not be able to download its raw data within a reasonable time frame due to the large quantities of data and limited sensor RF bandwidth. However, the wireless sensor  208   c  may be programmed to pre-process the raw data and download the processed set of data to the RFHN  202 . 
         [0038]    The RFHN  202  can further be used to configure the wireless sensors  208  or wired sensors  209  for data collection during reentry and landing. Real-time sensor data is sent to the VHMS for recording via the data interface  210 . 
         [0039]    If there is an abort, the RFHN  202  may record data (as needed) in a nominal ascent and entry. Commands to modify data collection can be issued through the VHMS using command interface  212  to compensate for the changes in mission time-line. 
         [0040]    For one embodiment, the RFHN  202  provides a correlation between an input time source and wireless sensor data. A system time may be provided to the RFHN  202  through the command interface  212 , allowing the RFHN  202  to be able to time tag real-time data and pass time on to wireless sensors. This results in wireless sensor data having a time correlation to other Orbiter instrumentation data. 
         [0041]      FIG. 3  is a block diagram of the logical interfaces between the RFHN  202 , wireless sensors  208 , wired sensors  209 , a higher-level system  320  and Ground Support Equipment (GSE)  322 . The higher-level system  320  provides for configuration and control of the RFHN  202 , such as through the wired command interface  330  and may provide time to the RFHN  202 , such as through the wired timing interface  328 , and may receive data from the RFHN  202  through a wired data interface  326 . The RFHN  202  may receive control information from the GSE  322  through Ethernet interface  214  and exchange data via interface  324 . 
         [0042]      FIG. 4A  is a functional block diagram of the software architecture between the RFHN  202  and the GSE  322  in accordance with an embodiment of the invention. The GSE  322  includes a Telnet service and FTP server  431 . This provides the capability to telnet to the RFHN  202  and gain access to the console port over one or more command interfaces, and to transfer files from the RFHN  202  for storage in archive files  435 . 
         [0043]    The GSE  322  further includes a Data Decoder  432  and RFHN Telemetry Processing  433  to handle the de-commutation of the data stream. This data may be used for displays  434  and recorded in archive files  435 . 
         [0044]    A Task Health service  436  may provide the capability to verify that all required tasks are running. If the Task Health service  436  determines that any required task is not running, it attempts to re-spawn the task. The Task Health service  436  records system error messages and significant system status changes on data storage device  437 . This health information may be used to determine the cause of a failure if an error in the data or loss of data occurs during operation. 
         [0045]    A Sequencer service  438  may be provided to facilitate notifying tasks when pre-determined mission events occur. The Sequencer service  438  may be provided with a system time  439  for handling time-based events. 
         [0046]    The Sensor Interface service  440  provides the capability to transmit commands to the RF Transceiver interface  441  and receive sensor status and data in response. The Sensor Interface service  440  monitors the operation of the transceiver and sensors. The Sensor Interface service  440  defines sensor data blocks  449 . The interface requirements will be determined by the sensors chosen for the data acquisition system. 
         [0047]    The Sensor Data Distributor service  442  provides the capability to control the destination of the sensor data. The destination may be determined from a routing table indexed by mission phase. The data may be routed to the Sensor Data Monitor  443 , the Sensor Data Recorder  444  or the Data Formatter  445 . 
         [0048]    The Sensor Data Monitor service  443  provides the capability to display sensor data as received to the console port  446 . The Sensor Data Recorder  444  provides the capability to record the sensor data on the Data Storage Device  447 . 
         [0049]    The Data Formatter  445  provides the capability to assemble data frames and transmit them via the Data Encoder  448 . The Data Formatter  445  retrieves sensor data from Sensor Data Blocks  449  and assembles the data into frames. The data frames are then transmitted via the Data Encoder  448  to the GSE  322 . The data acquisition system may include one or more data queues  450  for management of efficient data flow between the various services. 
         [0050]      FIG. 4B  is a functional block diagram of the software architecture for a sequencer in accordance with an embodiment of the invention. The Sequencer  438  determines current Mission Phase based on System Time  462  and a Mission Phase Table  464 . Mission Phase identifies a particular timeframe during the mission and may be used to change the behavior of other tasks. Some examples of Mission Phases are T−3 minutes to T0 and T0 to T+5 minutes. The Mission Phase Table  464  is built pre-launch and uploaded to the RFHN. The Sequencer  438  monitors System Time  462  and immediately notifies interested tasks, as identified in the Task Notification Table  468 , of the mission phase change. Each task is responsible for determining how the behavior should be modified based on this information. For example, a task collecting sensor data may change a sensor&#39;s configuration or which sensor&#39;s data is being collected and reported. The Current Mission Phase  466  is also stored in a global variable that is available to all tasks and required in case of system restart. In addition, the Sequencer  438  allows the user to override automatic phase detection and force the system to a particular mission phase. This can be used during ground test operations to force the system to operate in a particular mode while test data is collected. 
         [0051]      FIG. 5  is a depiction of an example placement of multiple RFHNs within a typical installation, e.g., within a NASA Orbiter, in accordance with an embodiment of the invention. Because the wireless sensors generally need line of sight access to communicate effectively with the RFHN, multiple placements may be required. Note that line of sight need not be a direct visual path between the component, but merely sufficiently free of obstructions or shielding that might interfere with low-power RF communications. Furthermore, wireless sensors can provide a relay function to pass data from one sensor to another such that an individual sensor need not have direct communication with the RFHN. The RFHN may physically mount to locations in the Orbiter where access to wireless sensors is required. Initially, this is expected to include the aft compartment, but could expand to include the right and left wing, payload bay, and Forward Reaction Control System (FRCS) cavity. 
         [0052]    The RFHN includes an integral power supply converter that obtains power from an external host device, e.g., the Orbiter power bus and converts the power to the voltages that the RFHN needs. The powered state of the RFHN (active/standby) can be controlled by commands from VHMS or other higher-level system. This power interface would be routed to any of the proposed physical locations of the RFHN as depicted, as one example, in  FIG. 5 . 
         [0053]    The RFHN may interface to VHMS or other higher-level system for command, data, timing, and data downlink and storage. The control and data interface would be routed to any of the proposed physical locations of the RFHN as depicted, as one example, in  FIG. 5 . 
         [0054]    In an Automatic Data Collection state, the RFHN may perform data collection based on predetermined events, such as mission time and mission profile. This data collection information may include data collection start/stop times, data collection rates, and configuration parameters for each sensor. 
         [0055]    In a Manual Data Collection state, the RFHN performs data collection based on user commands. The user must supply data collection start/stop and configuration parameters for each sensor by issuing commands in local control state. The data collection operation specified is performed. Once completed, no data collection or recording takes place until another command is issued. 
         [0056]    For both Auto and Manual Data Collection states, the user may enable or disable data recording. Enabling data recording causes all data collected to be recorded to non-volatile storage on the RFHN. While data may be sent to a higher-level system, a diagnostic port may additionally or alternatively be used to retrieve the recorded data from the RFHN. 
         [0057]    The RFHN is proposed as a modular, processor based design that is both physically and electrically expandable. The standard board interface and stacking frame of the PC/104+ standard allow the module to expand as necessary. This provides for individually removable modules such as the power supply, processor, memory, command interface, data interface, and wireless transceiver interface. The software is also modular in design and based on a real-time operating system which provides a stable, deterministic response. 
         [0058]      FIG. 6  is a diagram of the RFHN functional architecture in accordance with an embodiment of the invention. The RFHN  200  includes a high speed serial interface  661 , a data interface  662 , a Mil-Std 1553A or other bus interface  663 , a mass memory  664  for non-volatile data storage, a processor  665  and a power supply  666 . The processor  665  may be coupled to a wireless transceiver  667  for communication with the wireless sensors of the type described herein or may be coupled with a wired interface  669  for communication with wired sensors. The processor  665  may also be coupled to a diagnostic port  668 , such as a T-0 interface, for loading software or commands for testing. One or more additional transceivers may be coupled to the high speed serial interface  661  to allow the RFHN to interface to future wireless sensors without physically modifying the core module. The data interface  662  provides the encoded data stream  670 . Timing synchronization and commands  671  are provided through the bus interface  663 . As noted previously, the power supply  666  may optionally be coupled to a power interface  672  to receive power from an external host. 
         [0059]      FIG. 7  is the data processing flow of the RFHN software architecture in accordance with an embodiment of the invention. The modular design allows sensors to be configured by downloading a file during mission configuration and does not require a new software load. Similarly, predefined computations on collected data, known as “data fusion,” can also be controlled by file downloads. 
         [0060]    In  FIG. 7 , raw sensor data is received at sensor interface card  782 . The input process module  781  receives sensor configuration information from sensor configuration file  780  to convert raw sensor data into a representation of a physical phenomena. For example, where a sensor is a thermal resistive sensor, raw information may be a value in ohms, and the sensor configuration file  780  provides information for the input process module  781  to convert that to a temperature reading. The processed data from input process module  781  is then stored in a data buffer  783  in individual master data files associated with each sensor ID, e.g., ID-1, ID-2, ID-3, etc. 
         [0061]    The data in data buffer  783  may further be processed to increase the information value of the output data by converting the collected data to higher-level information. For example, a master data file may contain pressure readings of a helium tank. This data may be converted into a leakage rate on the tank through a data fusion process module  787 . The data fusion file  786  is a configuration file that would provide the necessary calculations or other manipulations of data contained in the data buffer  783  to generate this fused data. The fused data would then be stored in a fused data buffer  789  as fused files associated with a sensor ID or other identifier. Note that fused data may involve calculations based on more than one sensor. To take the example of a helium tank leakage rate one step further, a temperature sensor may measure a temperature of the helium tank. It would thus be prudent to account for changes in both pressure and temperature of the tank in order to accurately determine a leakage rate. 
         [0062]    Data may be output from either the data buffer  783  or the fused data buffer  789  using the data formatter output process module  784  through the data formatter output card  785 . The data formatter output process module  784  encodes the data string according to one or more format files  788 . The format files  788  define one or more of a size, data rate, Major Frame, and Minor Frame data for particular data output formats. A variety of data formats may be utilized, e.g., standardized data formats such as PCM (Pulse Code Modulation) or IRIG (Inter-Range Instrumentation Group) formats, or non-standard or user customized formats. Commands received at the MIL-STD-1553 or other command interface card  792  are processed by command process module  790  to select a format from the format files  788 . 
       CONCLUSION 
       [0063]    Although specific embodiments have been illustrated and described herein, it will be appreciated by those of ordinary skill in the art that any arrangement that is calculated to achieve the same purpose may be substituted for the specific embodiments shown. Many adaptations of the invention will be apparent to those of ordinary skill in the art. Accordingly, this application is intended to cover any adaptations or variations of the invention. It is manifestly intended that this invention be limited only by the following claims and equivalents thereof.