Abstract:
The invention generally relates to a telemetry system and method for parsing a set of archived telemetry streams for the purpose of reconstructing the data contained within the set of archived telemetry streams into a newly constructed set of telemetry streams. The newly constructed set of telemetry streams are used as a set of test driver data to evaluate performance in variety of ground based systems. The availability of test drivers produced by the preferred embodiment of the invention shortens the system development time line by allowing an evaluation of hardware and software changes ahead of the actual delivery of vehicle telemetry components, resulting in a reduction of overall program costs.

Description:
STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT 
       [0001]    The invention described herein 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 therefore. 
       BACKGROUND OF THE INVENTION 
       [0002]    1. Field of the Invention 
         [0003]    The invention generally relates to a telemetry system and method for parsing a set of archived telemetry streams and reconstructing the data contained within the set of archived telemetry streams into a newly constructed set of telemetry streams. The newly constructed set of telemetry streams are used to evaluate the performance of a wide variety of ground based systems when used as test driver data. The availability of test driver data produced by the preferred embodiment of the invention shortens ground system development time lines resulting in a reduction in overall program costs. 
         [0004]    2. Description of Related Art 
         [0005]    Historically, developers of complex systems require an environment to conduct testing to ascertain performance and specification compliance during different stages of development. The military fields complex systems such as air-to-air missiles, surface-to-air missiles, ballistic missiles, and all types of manned and unmanned aircraft. Commercial entities field all types of manned and unmanned aircraft. Each of these complex systems requires a supportive test environment during the development stages. 
         [0006]    Military and commercial test ranges rely heavily on the ability to collect data, collect information, and to retransmit the collected data and information in the form of telemetry streams. Software programs onboard the vehicle under test format selected flight parameters and event data into defined telemetry streams that may be transmitted from the vehicle under test and received by a ground station. The telemetry streams are then processed at the receiving ground station and are transformed into analog and digital data suitable for analysis and performance assessment. The accuracy of the data collection and transformation are evaluated at various development stages of the vehicle&#39;s operational flight program and the vehicle&#39;s telemetry system development. 
         [0007]    Generally, the development of a complex system matures during the course of a development time line and then continues to mature over the life span of the vehicle. Vehicles with long life spans are susceptible to component obsolescence, subsequent modernization, and the ever present upgrading of software. It is the subsequent modernization of hardware and upgrading of software that drive many mature and complex systems back into a test phase. 
         [0008]    It is known to automatically generate software code and data files along with a number of auxiliary data files for use with telemetry software. The ability to automatically generate software code and data files is dependent upon a working operational flight program, a telemetry file definition and test input data. One such system is described in a Patent Application Publication No. 2007/0032922, titled as AUTOMATIC GENERATION OF TELEMETRY FLIGHT SOFTWARE ACCOMPANYING SPECIFICATIONS, AND DECODE FILES and is also described in a U.S. Pat. No. 7,099,753, having the same title. What is unknown in the art is the ability to generate a reconstructed set of telemetry data streams from archived sets of telemetry data streams collected during a previously conducted live test, independent of an operational flight program or working telemetry hardware. 
         [0009]    One use of the Multiple Telemetry Stream Parsing and Reconstruction System (MTSP) is to provide test data within a telemetry stream to fill a gap in test data that occurs when a vehicle is simultaneously undergoing a telemetry hardware upgrade, a telemetry parameter definition upgrade, and the ground receiving station&#39;s software and hardware are adapting to these vehicle changes. When all of these modifications and upgrades are addressed serially in time the vehicle program&#39;s schedule is drawn out, overall program risk is shifted to the last testing stage, and any attendant increased program costs are incurred when milestones are missed. 
         [0010]    The advantage of the preferred embodiment is that a reconstructed set of telemetry streams containing what appears to the user to be live data conforming to the requirements of the new telemetry system are available to drive ground station systems. The reconstructed live data streams are generated and used to conduct tests independent of the vehicle&#39;s operational flight program, independent of the vehicle&#39;s telemetry system, and are also used to independently test the changes made at the ground receiving station. In addition to the MTSP, all that is necessary is a set of previously recorded telemetry test data and the new telemetry definition formats. The reconstruction process that generates the reconstructed telemetry streams is accomplished by the MTSP resulting in a shortened development timeline, a shift of risk to an earlier stage of the program, and reducing program costs by allowing development of the vehicle&#39;s telemetry hardware and software changes to be performed in parallel with those changes occurring at the ground station. Running live data having known expected parameters through a ground station&#39;s software and display suite will uncover any errors induced while upgrading the vehicle telemetry system or changing the ground station software and hardware. The described apparatus and method circumvents the need for actual updated telemetry recordings and allows a recertification of the range safety and range users displays to be performed in parallel. 
       SUMMARY OF THE INVENTION 
       [0011]    Complex military and commercial systems are developed according to a time line that consists of a system definition phase, a system requirements phase, a subsystem development stage, a subsystem test phase, a system development stage and a system test phase. Historically, errors found at the system test phase are the costliest and riskiest to correct. Errors found and corrected at the subsystem test phase save program cost, reduce program risk resulting in a product that matures quickly and is available sooner at a lower cost. The development time line concept is applicable to both new and upgraded commercial systems and to new and upgraded military systems. Generally, upgraded military and commercial systems have telemetry (TM) data from previously conducted tests stored in archives. 
         [0012]    The present invention is directed to an apparatus and method that satisfies the need for implementing a comprehensive scheme to playback archived TM data, parse and reconstruct the archived sets of TM streams into entirely new sets of TM streams. The entirely new set of TM streams produced by the present invention will allow a user to reap the benefits of performing system level testing at the subsystem test phase. 
         [0013]    Generally, the apparatus is comprised of a TM playback unit that is compatible with the archived TM data tapes and is used to generate a plurality of input TM streams. A hardware patch panel receives the input TM streams and routes the multiple input TM streams to any number of TM data processors. The TM data processor decommutates the input TM streams into frames and subframes of data. Included within the TM processor is a compiled set of software programming instructions that implement a parsing and reconstruction algorithm that parses the decommutated data and then reconstructs the data producing a set of output TM streams. The reconstructed data within the set of output TM streams includes modifications to the scaling value of the data, changes in the rate at which the data appears, changes in location of the data within the stream, and further includes entirely new data. 
         [0014]    Generally, the method comprises playing back a prerecorded set of TM streams, routing the prerecorded TM streams to a TM data processor, decommutating the prerecorded TM streams, parsing the data produced in the decommutation step, modifying the parsed data parameters, and then inserting any new data parameters. The final step in the method is to merge the modified parsed data, the new data, any original data parameters into a newly constructed set of TM streams for output and recording. 
         [0015]    A recording of the constructed set of TM streams produced as a result of the apparatus and method is available for use as a test driver to perform an evaluation of software and hardware changes made to a ground processing station. When the constructed set of TM streams are used as a test driver an improvement in the development time line for a system is realized by identifying performance issues with the ground station or other equipment at an earlier stage of development. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0016]    The features described above, other features, aspects, and advantages of the present invention will become better understood with regard to the following description, appended claims, and accompanying drawings where: 
           [0017]      FIG. 1  is a high level functional block diagram of the preferred embodiment showing the major functions of the Multiple Telemetry Stream Parsing and Reconstruction System (MTSP). 
           [0018]      FIG. 2  is a depiction of the data format for the input telemetry (TM) streams, the defined parsing and reconstruction process, and an example of the newly constructed output data format for the output TM streams. Producing the output data format is the objective of the preferred embodiment. 
           [0019]      FIG. 3  is a functional block diagram depicting the interfaces and functions internal to the TM data processor for the preferred embodiment. 
           [0020]      FIG. 4  is a flowchart depicting the processing steps performed prior to executing the parsing and reconstruction algorithm. 
           [0021]      FIG. 4   a  is a continuation of the flowchart of  FIG. 4  and further depicts the steps of the parsing and reconstruction algorithm as well as applying the output TM streams as test drivers to evaluate the operation of a ground station. 
       
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 
       [0022]    Referring to  FIG. 1 , shown is a high level functional block diagram  100  generally describing the major functions of the Multiple Telemetry Stream Parsing and Reconstruction System (MTSP). One or more playback units ( 110 ,  115 , and  120 ) are used to play back the archived telemetry (TM) streams. Each of the playback units ( 110 ,  115 , and  120 ) are connected to a hardware patch panel  125  using a barrel nut connector (BNC) patch cable. The hardware patch panel  125  is used to route the playback TM streams ( 111 ,  116  and  121 ) to any one of a number of TM data processors ( 130  and  145 ). The hardware patch panel  125  is used to also used to route a playback TM stream  123  directly to a recorder  170 . 
         [0023]    In the preferred embodiment the TM data processor ( 130  and  145 ) is manufactured by the Acroamatics Telemetry Systems Corporation. Each TM data processor ( 130  and  145 ) is comprised of a specialized front end ( 135  and  150 ) for processing multiple types of TM data formats and a computer processor ( 140  and  155 ) in communication with the specialized front end through a computer memory. 
         [0024]    In the preferred embodiment the playback TM streams ( 111 ,  116 , and  123 ) are in a Pulse Code Modulation (PCM) format having major frames and subcommutated minor frames. The preferred TM data processor ( 130  and  145 ) is manufactured by the Acroamatics Telemetry Systems Corporation. The Acroamatics TM data processor ( 130  and  145 ) is a standard VME chassis with slots for accepting a number of VME compatible input cards and assorted dedicated TM processing cards. Specifically, the Acroamatics TM data processor (Model 2222V) is configured with an input card to perform PCM bit synchronization (Model 501 VA) for up to eight TM streams  309 , a PCM frame synchronizer and decommutation card (Model 502V)  310 , a time code generator translator card (Model 503V)  321 , a data distribution interface card (Model 504VA)  325 , a digital to analog conversion card (Model 506V)  345 , and most importantly a simulator reconstruction card (Model 512V)  322 . The processed telemetry output ( 157  and  160 ) of the Acroamatics TM data processors ( 130  and  145 ) and any unprocessed telemetry stream  123  are routed to recording units ( 165  and  170 ) for recording and data playback ( 175  and  180 ) to a ground receiving station ( 185  and  190 ). The storage media employed by the recording units ( 165  and  170 ) is either magnetic tape, computer memory, or other mass media storage formats. The data playback ( 175  and  180 ) to the ground receiving station ( 185  and  190 ) allows a user to ascertain the proper operation of hardware and software changes made to the ground receiving station ( 185  and  190 ), which in turn shortens the development timeline resulting in saving program funding. 
         [0025]      FIG. 2  is a representation  200  of the decommutated and buffered input data for stream( 1 ) ( 210 - 212 ) and stream( 2 ) ( 220 - 222 ), the parsing and reconstruction processing step  230 , and the generalized output data format for reconstructed stream( 1 ′) ( 240 - 242 ) or a reconstructed stream( 2 ′) ( 250 - 252 ) for the preferred embodiment. Only one processed digital output stream is available from each TM data processor ( 130  and  145 ).  FIG. 2  depicts what appears to be a parallel set of output data streams ( 240 - 242  and  250 - 252 ) but in reality is a depiction of the possible data element changes in any single reconstructed telemetry stream.  FIG. 3  is a functional block diagram describing the interfaces and functions internal to the Acroamatics TM data processor ( 130  and  145 ). One skilled in the arts may reference both  FIGS. 2 and 3  as the basis for understanding the following discussion detailing the critical aspects of the preferred embodiment. 
         [0026]    Specifically, playback TM streams ( 111  and  116 ) are synchronized and decommutated  310  producing TM frame data  315  consisting of TM frames sequenced in time and numbered sequentially ( 210 - 212  and  220 - 222 ). A frame  210  is populated with a plurality of data words where each data word is associated with a unique location within the frame, a value, a defined data rate, and a defined word length that is related to a scaling factor. Other pieces of information are capable of representation within the frame  210  such as frame identification counters, frame header information, subframe identifiers, and timing information. Writing the synchronized and decommutated TM frame data  315  to computer memory  320  is performed under the control of the interface control and timing function  325  using control and timing signals  330 . 
         [0027]    Once the TM frame data  315  is resident in computer memory  320  it is accessible by the data parsing and reconstruction function  335  for subsequent processing by the Parsing and Reconstruction Algorithm  230 . The output of the Parsing and Reconstruction Algorithm  230  is a reconstructed output TM stream having a plurality of TM frames sequenced in time and numbered sequentially ( 240 - 242  or  250 - 252 ). A frame  240  is populated with a plurality of data words that may or may not match the original data contained in the input TM frame data  315 . The Parsing and Reconstruction Algorithm  230  performs the critical feature of the preferred embodiment that manipulates data word locations within the frame or from frame to frame, modifies the data value, redefines the data rate, and redefines the word length that determines the scaling factor. Other pieces of information susceptible to manipulation are frame identification counters, frame header information, subframe identifiers, and timing information. The output of the parsing and reconstruction function  335  is an output digital TM stream  340 . Writing the output digital TM stream  340  of the Parsing and Reconstruction Algorithm  230  to computer memory  320  is performed under the control of the interface control and timing function  325  using control and timing signals  330 . The output digital TM stream  340  is stored in computer memory  320  and made accessible to a digital to analog conversion function  345 . The digital to analog conversion function  345  converts the output digital TM stream  340  retrieved from computer memory  320  to an analog signal  157  suitable for recording on an analog recorder. In another embodiment, the output digital TM stream  340  is stored in computer memory  320  then output directly to a digital recorder ( FIG. 1 , items  165  and  170 ). 
         [0028]    The above discussion for  FIGS. 2 and 3  is applicable to any number of Acroamatics TM Data Processors. Any number of input TM data streams may be coupled to any number of Acroamatics TM Data Processors that manipulate, reconstruct, and produce a new TM output stream that is capable of routing to any designated recorder. 
         [0029]      FIGS. 4 and 4   a , describe of the preferred steps  400  for producing the new TM output streams and applying the new TM output streams as test drivers to assess performance of a ground station that has undergone changes to hardware or to software. 
         [0030]    Referring to  FIG. 4 , the input TM Set Up files are loaded from computer memory ( FIG. 3 , item  320 ) into the PCM processor ( FIG. 1 , item  135 ) in step  410 . The TM Set Up files describe the format of the data relative to the number of TM frames, subframes, word location and word content ( FIG. 2 ,  210 ) and serve as the key to making the otherwise unintelligible stream of buffered digital data intelligible. The decommutated data produced in step  415  is then unpacked (step  420 ) according to the input TM Set Up files and the unpacked data is buffered in computer memory at step  425 . 
         [0031]    The output TM Set Up files are loaded into computer memory in step  430 . The output TM Set Up files serve the same purpose as the input TM Set Up files. Here, the output TM Set Up files provide the template for constructing the new major and minor subframes (step  435 ). The initial data content of the new major and minor subframes (step  435 ) consists of zeros written to all bit locations. The output TM Set Up files also define the modifications for scaling a data word, changing the rate of a data word, defining the changed location of a data word, and providing the content of any data that is to be inserted into the new output TM stream ( FIG. 3 , item  340 ). 
         [0032]    Just as every unique input TM stream requires an input TM Set Up file, every unique output TM stream requires an output TM Set Up file. Accurately preparing all of the TM Set up files is critical in building a useful output TM stream. The information to build an accurate TM Set Up file is specific to the telemetry specification document that defines the content of each telemetry stream and is system dependent. The telemetry specification documents for the input and output telemetry streams must be strictly adhered to when building the Set Up files. 
         [0033]    At step  440  the Parsing and Reconstruction Algorithm is passed the structure for the frames and subframes produced in step  435  with algorithm execution turning to populating the data fields. Referring to  FIG. 4   a , the process of populating the data fields begins by first parsing (step  445 ) the unpacked data that is buffered in computer memory at step  425 . Parsing (step  445 ) is the act of systematically extracting data from the unpacked data residing in buffered computer memory (step  425 ). 
         [0034]    Generally, the parsed data is then subjected to a number of checks (steps  450 ,  460 ,  470 , and  480 ) that determine how the parsed data is to be handled (steps  455 ,  465 ,  475 , and  485 ). At the conclusion of the checks (steps  450 ,  460 ,  470 , and  480 ) and modification steps (steps  455 ,  465 ,  475 , and  485 ) the parsed data is then written into the frame and subframe structure produced in step  435  according to the output TM Set Up file. The populated frames and subframes (step  495 ) now contain the reconstructed digital TM stream ready for output (step  495 ) and recording (step  505 ). The product of the recording (step  505 ) is then ready for use as a test driver data set to assess ground system performance (step  510 ). 
         [0035]    Specifically, the parsed data (step  445 ) is a single data word, or a section of a single data word or multiple data words. The parsed data (step  445 ) is subjected to the first check (step  450 ) to determine whether a scaling operation is required. A scaling operation is defined as reformatting the parsed data to fit into a different number of bits or to fit into a different number of words. The first check (step  450 ) is performed by comparing the definition of the parsed data bit field as defined in the input TM Set Up file to the definition of a corresponding bit field in the output TM Set Up file. When the comparison results in a determination that the length of the bit field is unchanged no scaling modification (step  455 ) is made and the algorithm execution proceeds to the next check (step  460 ). When the comparison determines that a change in the total number of bits (a change in the bit field) is necessary the parsed data is modified (step  455 ). The parsed data modification (step  455 ) is performed by dividing the value of the parsed data by the number of bits in the new bit field resulting in a new scaling factor. 
         [0036]    The next check performed is a data rate check (step  460 ). The data rate check (step  460 ) is performed by comparing the definition of the data rate for the parsed data as defined in the input TM Set Up file to the definition of the corresponding data rate in the output TM Set Up file. When the comparison results in a determination that the data rate is unchanged no data rate modification (step  465 ) is made and the algorithm execution proceeds to the next check (step  470 ). When the comparison determines that a change in the data rate is necessary the data rate of the parsed data is modified (step  465 ). The data rate for the parsed data is modified (step  455 ) by determining the number of occurrences of the parsed data in the newly constructed frames or subframes,  FIG. 2 ,  240 . The number of occurrences may either increase or decrease. With the number of occurrences determined the data rate may be defined (step  465 ) and modified accordingly. At this point in the algorithm, both a scaling operation (step  455 ) and a data rate change (step  465 ) may be applicable. 
         [0037]    The next check performed is a new data check (step  470 ). The new data check (step  470 ) is performed by comparing the definition of the parsed data as defined in the input TM Set Up file to the definition of the data in the corresponding position in the output TM Set Up file. When the comparison (step  470 ) results in a determination that the word definition defines new data the value, data rate, and scaling factor of the new data are stored in memory (step  475 ). 
         [0038]    At this point in the algorithm the parsed data may be scaled (step  455 ), be subjected to a data rate change (step  465 ), or may be identified as new data (step  475 ) or may fail all of the checks (steps  450 ,  460 , and  470 ). In the event that all of the checks fail then the original parsed data is to retain all of its properties including its location within the frame and subframe. When the comparison (step  470 ) determines that no new data is present the algorithm execution performs a location check (step  480 ). 
         [0039]    To avoid overwriting already allocated data fields it is necessary for the algorithm to maintain a location record for all the modified and original data. The location check (step  480 ) is performed to ensure that only one piece of data is written to every bit location in the frame and subframe and that the correct data is written to every location. If the location check passes then the parsed data in its modified or original state is stored (step  487 ) in the constructed frames and subframes resident in computer memory ( FIG. 3 ,  320 ). If the location check fails then an error recovery scheme (step  485 ) is performed. 
         [0040]    In the preferred embodiment the error recovery algorithm (step  485 ) results in another attempt to build the major and minor frame by repeating the algorithm beginning at step  445 . If repeating the algorithm results in the same error the operator is notified that there is a conflict in the TM Set Up files and should verify the implementation of the TM Set Up files. In the event that a different error occurs then a synchronization problem may be present and is addressed accordingly. 
         [0041]    A check (step  490 ) is then made to determine if all of the parsed data has been evaluated. If data remains for parsing then the algorithm is directed to step  454  and more data is processed. Once all of the data has been parsed then the reconstructed frames and subframes are output (step  495 ) for recording (step  505 ). The recorded data is then played back to the appropriate ground system components and ground system performance is evaluated. 
         [0042]    The algorithms described herein may be programmed in any suitable programming language for operation on compatible TM data processing computers and other computer processing hardware. The algorithm for the preferred embodiment is loaded onto a computer readable medium which may include, but are not limited to, memory disks, flash memory devices, optically read media, and mass storage devices. 
         [0043]    One skilled in the art may adapt the applicant&#39;s invention to any TM data processing platform or any compatible playback and recording units. Input signals and output signals used by the MTSP may be analog, digital, PCM or any other TM data format, such as but not limited to, PAM, NRZL, PAL, frequency shift key or video. 
         [0044]    Although the present invention has been described in considerable detail with references to certain preferred versions thereof, other versions are possible. For example, the preferred embodiment refers to a VME based system but is readily adaptable to a Personal Computer Interface (PCI) based system, or the like. Another example of a variation to the preferred embodiment is to convert the internal circuits of the telemetry data processor ( 130  and  145 ) into external devices. One skilled in the art can convert the internal bit synchronizer and decommutation features ( 309  and  310 ) into devices that operate externally to the TM data processor ( 130  and  145 ) to produce the same reconstructed telemetry stream. 
         [0045]    Therefore, the spirit and scope of the appended claims should not be limited to the description of the preferred versions contained herein.