Control systems for a variety of applications can be composed of many electronic components, including numerous computational and control devices that include non-volatile software programs. All of these electronic components must interface and interact with each other for the system to function correctly. In some cases, a verification process is implemented to ensure that each item of software has been tested to verify that the components work properly with each other. Once a system is verified through testing, a document is produced listing the valid software version numbers for a specific system configuration. This document must be manually checked against each of the components installed in the system from time-to-time. If the components of the control systems do not satisfy the verified restraints of the system configuration numerous problems may be created. This problem is particularly acute in complex software systems having components that are continually being upgraded or replaced, such as aircraft avionics, manufacturing control systems, business financial systems, and the like.
According to one embodiment of the invention, a system configuration process is implemented to verify that each component implemented in the system is compatible and includes the appropriate software version. The verification is completed by comparing the components installed in the system to a system configuration definition that is permanently stored or “imprinted” within a memory.
In another embodiment of the invention, a system configuration definition is integrated with software in a system, as well as on one or more external computers. This allows the actual component software version numbers to be queried by a user as part of a pre-operation check. Additionally, a user can query the component software revision numbers as components are added or removed from the system, thereby verifying that the system's configuration is correct and operable.
In another embodiment of the invention, a system configuration process that includes a system configuration definition is integrated with avionics control software on an aircraft. The system configuration definition can also be stored in a maintainer's computer. This allows the actual set component software version numbers to be queried by a pilot as part of a pre-flight check, so that any incompatibilities are discovered before the flight. Additionally, the maintainer can query the component software revision numbers as components are added or removed from the aircraft avionics, thereby verifying that the aircraft's system configuration is correct and flyable.
In yet another embodiment, after software version numbers are queried, the results of the query are returned to a user (e.g., a pilot, maintainer, or system administrator). If the system configuration is incorrect, the querying software reports the incompatible components so that they can be corrected. After the correction, the system configuration can be queried again to verify that a proper system configuration has been achieved.
Other aspects of the invention will become apparent by consideration of the detailed description and accompanying drawings.
Before any embodiments of the invention are explained in detail, it is to be understood that the invention is not limited in its application to the details of construction and the arrangement of components set forth in the following description or illustrated in the following drawings. The invention is capable of other embodiments and of being practiced or of being carried out in various ways. Also, it is to be understood that the phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting. The use of “including,” “comprising,” or “having” and variations thereof herein is meant to encompass the items listed thereafter and equivalents thereof as well as additional items. Unless specified or limited otherwise, the terms “mounted,” “connected,” “upported,” and “coupled” and variations thereof are used broadly and encompass both direct and indirect mountings, connections, supports, and couplings. Further, “connected” and “coupled” are not restricted to physical or mechanical connections or couplings.
Electronic components are increasingly being used to control functions in a variety of settings. For example, many air, land, and sea vehicles employ a multitude of electronic components to control a plurality of functions (e.g., navigation, maneuvering, power, weapons, etc.). Additionally, other arenas, such as manufacturing, heavy equipment, chemical processing, business management systems, etc., may utilize a variety of electronic components to control functions. These and other complex systems often have separate software modules supplied by different manufacturers that are regularly modified, upgraded and replaced.
The electronic components (and the software implemented by these electronic components) are often tested individually and as sub-assemblies to ensure proper operation, as well as compatibility with each other. For example, a certain application that requires the use of several different types of components (each of which may include several versions of software) are tested as an assembly to ensure that each of the components operate properly, and that the software being implemented by the components are compatible with each other. In some embodiments, as described in greater detail below, this testing process is referred to as a product test verification (“PTV”).
The illustrative embodiments of the invention described below generally relate to an aircraft. More specifically, the embodiments described herein relate to an aircraft having one or more removable, replaceable, and/or interchangeable electronic components (referred to generally as line replaceable units (“LRU”) or weapon replaceable assemblies (“WRA”)). These components commonly contain non-volatile memory that can be supplied or “loaded” with software which is used to control a variety of functions of the aircraft (e.g., a radar system, a guidance system, a weapons system, a targeting system, a pilot interface system, etc.). However, as should be apparent to one of ordinary skill in the art, embodiments of the invention may also be adapted to a variety of other vehicles and/or systems, such as factory manufacturing systems, business management, financial and accounting systems, chemical, pharmaceutical and biopharmaceutical processing systems, equipment or patient monitoring systems, complex security systems, trucks and other large vehicles, mining and mineral exploration equipment, power plants, food processing plants, spacecraft, sorting systems, and any other systems having software components whose compatibility is desirable.
For example, some modern aircraft are multi-purpose with removable and replaceable components (e.g., WRAs) to serve different missions. A basic mission might be search and rescue, while a more advanced mission might be armed search and rescue. Another mission may include armed interdiction. Aircraft mechanics and technicians (“maintainers”) can remove components or add components to customize the configuration of the aircraft to the mission that is being carried out. This customization is done as needed, perhaps during military actions. All of the components assembled on the aircraft for a particular mission need to operate correctly with a certain system configuration. Additionally, over the lifetime of an aircraft, components may become obsolete and be replaced by components with additional functionality. Many components' software may also be upgraded. Components may also be removed and shared between different aircraft of a fleet. Thus, prior to releasing the aircraft for use, a PTV is completed to ensure that all of the components and associated software revisions and/or versions operate properly with one another. The result of a PTV is a document (or electronic file) that provides a listing of all of the components and associated software that is authorized to be used in the aircraft. For example, a PTV can include data related to the type of component that is authorized to be installed, as well as the software revision(s) that are authorized to be used. If a certain component has multiple different valid software revisions (e.g., revision 3.1, 3.12, 3.2, etc.), each of those revisions is listed in the PTV.
As components are replaced, revised, and/or upgraded, the system configuration can be maintained using the system configuration management process 100. The first step in the process 100 is to implement a PTV process that includes testing software version numbers (step 105). For example, in addition to testing each of the components (e.g., WRAs) that may be installed in the aircraft, each software (the software corresponding to the components) revision is tested. This is done to ensure that a particular set of components includes software versions that has been tested to operate properly with software of other components, and has been certified for flight. As described above, aircraft may change from one configuration to another, and include one or more components that are replaceable with other components having different versions of software and/or hardware. Additionally, software upgrades may occur over the life of the aircraft. There are also a variety of different vendors that may provide components and subsystems, which results in the components having multiple software version numbers. Different vendors may also be supplying the same components. Additionally, several versions of software may be valid or allowed for a single component. Such circumstances leads to an extensive PTV process that includes the testing of valid software versions for each of the components that may be installed in the aircraft.
The PTV process can be used while creating system configuration definitions (“SCD”). For example, SCDs, which can be identified by a name and/or number (e.g., system configuration 54.2), can be created to carry out certain tasks, and include certain sets of components to perform those tasks. For example, an SCD that is created for a search and rescue mission may include a specific set of WRAs that are installed in the aircraft. Accordingly, the SCDs can include a listing of each component that is allowed to be installed on the aircraft and the corresponding valid software revision number(s) that are implemented by that component. For a particular aircraft, there may be multiple valid SCD, for example, to accommodate system configurations that include different combinations of WRAs.
Referring again to
Each of the components of the SCDF is tested prior to being included in the SCDF to ensure that they operate properly with one another (e.g., tested during the PTV process). As described in greater detail below, the SCDF can be uploaded to a portion of a main or “mission” computer of the aircraft, and may be stored permanently within the aircraft.
After the software load component has been created (step 110), a user, such as a system administrator, can select a system configuration for the aircraft (step 115). For example, a system administrator can determine the proper system configuration for the aircraft (e.g., a system configuration that is appropriate for a certain mission), and transfer the associated software from the software load component to a portable electronic device (e.g., a portable computer). The SCDF is also transferred to the portable electronic device. This device can then be used by a maintainer to transfer the software to the WRAs in the aircraft, as described in greater detail below. In some embodiments, the system administrator may issue a maintenance work order and only include a single updated software version for one of the WRAs in the aircraft (e.g., the software for each WRA may be installed and/or updated independently of the other WRAs).
After the desired system configuration has been selected by the system administrator, the portable electronic device is ready to load a system configuration into the aircraft (step 120). In some embodiments, a portable electronic device is equipped with an automated software loading program. For example, a maintainer can connect the portable electronic device to the main computer (illustrated as AOP/ASP in the embodiment shown in
In some embodiments, the system configuration must be loaded each time the aircraft is readied for flight. For example, after a military aircraft lands and is shut down, the memory of the main computer, as well as the memories of the WRAs, are cleared for security reasons. Accordingly, prior to flying the aircraft again, the main computer software and the software for the WRAs must be restored (e.g., loaded into the main computer and WRA memories). Prior to loading the software, a maintainer may verify that the memories of the main computer and WRAs are ready to be configured (step 125). The maintainer or pilot can then load the software corresponding to the selected system configuration into the main computer and WRAs (step 125).
The SCDF is preferably permanently stored in an aircraft personality module (“ACPM”) (which may be a portion of the main computer) until the SCDF is updated by a subsequent change to the PTV. The ACPM is generally a permanent component of the aircraft (i.e., it cannot be removed like the WRAs) that can store the SCDF in a non-volatile memory (e.g., read-only memory, flash memory, and the like). Thus, the SCDF can be permanently stored within the ACPM or other memory device. In some embodiments, as described above, the SCDF is a “truth table” (see, for example,
After the SCDF has been stored in the ACPM, the maintainer executes a verification process using, for example, a system configuration utility (e.g., as shown and described with respect to
In some cases, one or more WRAs or other electronic models may not automatically report their part numbers or installed software version. In these cases, the maintainer will manually read a label affixed to the outside of the WRA or other module that contains the module's part number and software version data. The maintainer or operator then presses a key or otherwise manually marks a check box in the PTV system that indicates he has visually confirmed the software version data for the non-operating modules. The PTV algorithm verifies that the check boxes for the non-reporting modules have been marked before outputting a clear to launch indicator. The list of installed components with respective software version data is a subset of the total list of components actually installed in the system. If one or more modules does not automatically report its part number or software version data, the subset list has fewer entries than the complete list of components actually installed with their actual software version data, and the modules not listed in the automatically-generated list will need to be manually verified. If the automatically-generated list of components includes data for all modules, then the subset list and the complete list of components are the same.
In some embodiments, the system configuration utility 200 is installed in memory of a portable electronic device, such as the portable computer shown in step 120 of
As described above, one of the functions of the system configuration utility 200 is to determine if the components installed in the aircraft are allowed according to an SCDF that is stored in an ACPM 220. This can be accomplished by invoking an algorithm 230 to cross reference the SCDF with the WRA software revision numbers (as well as other data) that are requested and received by a WRA request module 225.
A user (e.g., a pilot) of the system configuration utility 200 may implement the system configuration utility 200 by initializing or launching the utility (e.g., using a pilot interface, as shown, for example, by
After the user makes a functional selection, the system configuration utility 200 opens the SCDF from a storage device within the ACPM 220. The system configuration utility 200 then queries the aircraft's WRAs (e.g., using the request module 225, as described above) to obtain their individual software version numbers. Next, the system configuration utility 200 invokes an algorithm 230 to compare the contents of the SCDF with the WRAs' software version numbers. In some embodiments, other data, such as the make and model number, the device number, and/or the manufacturer part numbers of the WRAs are also compared to the contents of the SCDF. The system configuration utility 200 then reports the results of the algorithm 230 to the user. For example, the system configuration utility 200 may indicate that all WRAs meet the SCDF (e.g., it is OK to fly), that some of the WRAs do not meet the SCDF (e.g., it is not OK to fly), or that there is a problem with one or more of the software programs (e.g., it is not OK to fly). These results can be reported via the HMI 205.
In some embodiments, similar to the system configuration utility 200 shown in
In some embodiments, in addition to loading software into the WRAs, the software loader application 300 can be used to transmit and store a SCDF in the ACPM 310 of the aircraft. As described above, the SCDF can be used to verify that the components installed in the aircraft and their software versions are compliant with the SCDF. Accordingly, the system configuration utility 300 can then be initialized to verify that the aircraft's system configuration is correct.
The WRA column 505 provides the name and/or type of WRA included in the system configuration. For example, in the embodiment shown in
The software version number column 510 provides a listing of supported software version or revision numbers. As shown in
The device number column 515 provides data related to device numbers of the WRAs. Each of the WRAs is assigned a device number, which can be used to locate the device in the aircraft. The AOP Enumeration column 520 provides the number assigned to the specific software program in a single WRA or LRU. For example, if a WRA has eight programs, they would be assigned numbers from 0 through 7. Each program in each LRU/WRA must have its compatibility checked separately.
The manufacturer part number column 525 provides data related to the part numbers of the WRAs. The manufacturer part numbers are generally assigned to the WRAs during manufacture, and are not changed.
In other embodiments, the truth table 500 may include more or fewer columns (and corresponding data) than those shown in
As discussed above in connection with
The embodiments described with respect to
In other embodiments, the system configuration process can be used in non-vehicle related applications. For example, the system configuration process may be used to verify the electronic components implemented in an air traffic control station (e.g., a variety of radios and other communication devices, radar systems, and other computing systems). These electronic components may be upgraded, removed, and/or replaced by other components, and thus, can benefit from a system configuration process that verifies that the electronic components (and their software) are compatible. The system configuration process can also be implemented in a manufacturing setting that implements motor drives, programmable logic controllers (“PLCs”), vibration sensing systems, and the like, which interact with each other. Accordingly, the system configuration process can be used to verify that the software implemented by each of the devices are compatible. Other applications will also be apparent to administrators of complex software systems having many software modules.
This application claims priority to U.S. Provisional Patent Application Ser. No. 60/931,690 filed on May 24, 2007, the entire content of which is incorporated herein by reference.
Number | Date | Country | |
---|---|---|---|
60931690 | May 2007 | US |