Software rehosting system and method

Details Software rehosting system and method Software rehosting system and method

1999-08-24

2003-11-25

Chaki, Kakali (Department: 2124)

Data processing: software development, installation, and managem

Software program development tool

Translation of code

Reexamination Certificate

active

06654950

ABSTRACT:

FIELD OF THE INVENTION
In one aspect, this invention relates to a software analysis and rehosting system and method that automatically converts a computer program in a particular computer program dialect to another computer program dialect that can be a different version of the same dialect, or an entirely different dialect, or the same dialect, but for use on a different hardware platform. In another aspect, the invention relates to a software system and method that can be used to generate a translation model that would be used to convert a computer program in a particular dialect to another computer program in the same, related or different dialect. In still a further aspect, the invention relates to a software analysis system and method that analyzes an input computer program and generates a report. Thus, In general, the present invention relates to a computer software system, equipment, method and computer program which can be used by, among others, those in the automated test and measurement industry for rehosting, for analyzing and generating reports, and for creating a translation model.
BACKGROUND OF THE INVENTION
With the world approaching the millennium, very valuable computer software written decades ago has become antiquated as new hardware has been developed and as software theories and management theories have changed. One area of software that has been greatly affected by these changes is the area of test programs (TP's). These are a class of extremely valuable software programs grouped with interfacing hardware and associated documentation to form a Test Program Set (TPS). TPS's are used with very expensive Automatic Test Equipment (ATE) hardware and software systems that have been built to test electronic components. A TPS is used to operate and control testing and monitoring equipment for the electronics test industry in support of the aerospace, defense, automotive, and telecommunications industries. These programs often contain tens of thousands of lines of code and have been written in computer languages which have been in existence for almost half a century. This class of so-called legacy program code is written in such languages as ATLAS, BASIC, JOVIAL, FORTRAN, etc.
In the field of aviation electronic test systems, there is a maintenance hierarchy which supports avionics testing. The first level of test is incorporated into the electronic module or Line Replaceable Unit (LRU) and is called a Built In Test (BIT). If an electronic module's BIT detects an error, the module is checked at a flight line with organizational-level test equipment to check out the problem, and then removed and replaced from the aircraft if confirmed to be faulty. The defective module is then taken to an intermediate-level ATE station for testing by a test station. The intermediate-level test system performs extensive testing to identify and isolate any failed circuit cards in the module. Faulty circuit cards are removed and replaced and the module is returned to operational condition for use in the aircraft. Faulty circuit cards, which were identified and removed as part of module testing are shipped to a regional repair center which has depot-level test equipment. The repair center tests the failed circuit card to identify and isolate any failed components. Faulty components are then removed and replaced, and the circuit card is repaired to an operational condition and returned for use again. A typical, conventional test station, depicted in
FIG. 1
at
130
, is shown in a schematic block diagram. A Unit Under Test (UUT)
132
is connected to test station
130
by a connector
134
. Unit Under Test
132
can be, for example, electronic equipment from an aircraft or missile. Test station
130
runs an appropriate TPS, which is depicted at block
136
.
Connector
134
is schematically shown in
FIG. 1
as a cable, but more likely it would simply be a hardware connector unit having a highly configured arrangement. One of the problems with older systems is that the standardized hardware connector has changed. In an overly simplistic example, it would be similar to trying to plug a newer three-pin electric wire connector having a grounded pin into an older electric wall socket only having two pins. In the hardware connectors, there is also the problem that the newer connectors use different “pin outs,” or arrangement of connector pins. Testing of the equipment involves among other thing the application of test current and voltage signals. If the pin arrangement is not properly considered when these signals are being applied, it could be fatal to the equipment. TP's control among other things the application of these test signals and thus a legacy TP can be pin specific.
Test station
130
is typically comprised of conventional, but usually specialized, computer hardware, depicted as block
140
and run by conventional system software shown as block
142
. In a conventional test station, computer hardware could be a Pentium based computer running a modern Commercial Off The Shelf or COTS system software (e.g. Microsoft Windows NT operating system). A software interface
144
is connected to computer hardware
140
, and can be as simplistic as specific drivers for other hardware equipment, such as drafting equipment or printers. Test station
130
also includes a hardware specific interface
146
that must correspond to connector
134
so that they can be plug and pin compatible. Finally, test station
130
includes a plurality of instruments
148
, such as a Volt-Ohm Meter (VOM), that can be controlled by software and can be selectively connected to the UUT and selectively read and used by the TPS.
A TPS typically includes very expensive software. For example, in the military aircraft industry, where these systems must emulate an entire aircraft in order to test the electronic units, often the cost to develop a single test program may be several hundred thousand dollars.
Now with a dwindling defense budget and an increased availability of lower cost commercially based test instruments utilizing components based on VXI/PXI technology, re-hosting of legacy Test Programs (TPs) onto new test platforms is an attractive alternative to writing new software. An example of a management theory that has changed is the desire to switch from specially created software languages to COTS software environments. These changes have created an overwhelming task of migrating existing software written in one language or dialect to new test platforms which support different languages and dialects. As used herein, in order to avoid the difficult task of deciding whether two computer programs are of different versions of the same language or are of two different languages, the term “dialect” means a computer language or a version of a computer language.
Current practice is to migrate legacy test programs to modern industry leading commercially available programming environments. In this way major industries such as the military and avionics industries can take advantage of COTS tools for building their new test systems. These tools include PC plug-in boards, VXI/IVI plug-play instrument drivers, and LabVIEW and LabWindows/CVI test software tools, etc. This migration affords the industries the benefits from the high volumes, lower prices and better worldwide compatibility and support that are common with COTS tools. Unfortunately, any migration to modern programming environments has to consider either rewriting very valuable legacy computer software or manually converting it, both prospects being extremely time consuming and expensive because of the magnitude of the task. Thus, there is a need for a conversion tool that can accept legacy software (e.g., ATLAS, BASIC, JOVIAL, and FORTRAN), and produce software in a language or dialect that is compatible with the modern software environments (e.g., LabWindows/CVI, LabVIEW,Visual Basic, Visual C++, and new version of ATLAS).
Another current need is the ability to substitute or swap out one test instrument for either a similar one

Affiliated with

Also associated with

Rating

Software rehosting system and method does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Software rehosting system and method, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Software rehosting system and method will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3142709