Method and apparatus for verifying a software configuration of a distributed system

[0002] 1. Field of the Invention

[0003] The present invention relates to a method and apparatus for software management in a distributed system. In particular, the invention provides a method and apparatus for verifying the software configuration of a distributed system.

[0004] 2. Background Information

[0005] Distributed computing systems can have a variety of hardware configurations. Each hardware configuration can have a variety of software configurations. Further, each software item in the distributed system can be further comprised of a plurality of software components. Thus, the correct software configuration for the distributed system depends on the hardware that should be present, the software items that should be present for the hardware, and the software components that should be present for the software items.

[0006] Software items may be replaced individually or be corrupted. Some software items may be contained in particular pieces of hardware that may be replaced individually. As a result, the software configuration can be altered by software maintenance, hardware maintenance, or corruption of system storage. What is needed is a method for verifying the software configuration of a distributed system based on data defining the expected hardware configuration and data defining the software items.

[0007] A software record that identifies a software component associated with a processor in a distributed processing system is retrieved from a software configuration database. A check value is calculated for a copy of the software component loaded on the processor. The check value is compared to a second check value retrieved from the software record to verify the software component file.

[0008] FIG. 1, which includes FIG. 1A and FIG. 1B, illustrates an exemplary in-flight entertainment system (IFES), which is a distributed processor system, for use with the present invention.

[0009] FIG. 2 is an example of a hardware configuration data base for use with the present invention.

[0010] FIG. 3 is an example of a software configuration data base for use with the present invention.

[0011] FIG. 4ais a flowchart of one portion of a program that embodies the present invention.

[0012] FIG. 4bis a flowchart of a second portion of a program that embodies the present invention.

[0013] FIG. 4cis a flow chart that shows details of the “calculate first check value” process block 228 of FIG. 4b.

[0014] FIG. 5 is an example of a first report produced by an embodiment of the present invention.

[0015] FIG. 6 is an example of a second report produced by an embodiment of the present invention.

[0016] FIG. 7 is an example of a third report produced by an embodiment of the present invention.

[0017] FIG. 8 is an example of a fourth report produced by an embodiment of the present invention.

[0018] FIG. 1, which includes FIG. 1A and FIG. 1B, illustrates an exemplary in-flight entertainment system (IFES) 100 that typifies a distributed computing system. The IFES 100 is comprised of a plurality of hardware items termed line replaceable units (LRUs) that are controlled by software. LRUs in an IFES 100 include a system manager unit (SMU) 152 that controls devices including a removable storage medium 160 and an attendant control panel (ACP) 156. The IFES 100 further includes LRUs that supply, control, and distribute multi-media data including a system interface unit (SIU) 150, a data server unit (DSU) 164, a media control unit (MCU) 168, and a media server unit (MSU) 170. The foregoing LRUs are connected by a server network hub 128 to create a multi-server network. The IFES 100 further includes seat electronics units (SEUs) 108, 112, 120, that provide in-flight entertainment services to individual seats in an aircraft, and zone bridge units (ZBUs) 124, 130 that connect the SEUs in a hierarchical seat network and connect the seat network to the server network. An IFES 100 may comprise additional LRUs (not shown) connected to the server network or connected to the seat network.

[0019] Some LRUs, termed server LRUs, are general purpose computers that store software in a file system and load the software from the file system as required for execution. Other LRUs, termed embedded LRUs, are specialized micro-controllers that store software in field programmable, non-volatile memory devices, such as flash memory or EEPROM. Still other LRUs, termed non-loadable LRUs, are specialized micro-controllers that store software in memory devices, such as ROM, that do not allow software to be loaded after the LRU has been assembled.

[0020] In order to certify an aircraft, it must be shown to be in conformity with its configuration specification. That is, each subsystem must be determined to be configured according to the specification stored in the system configuration database. The present invention provides a means of demonstrating the conformity of the software portion of the IFES 100 with its configuration specification.

[0021] The configuration specification of the IFES 100 for a particular aircraft is stored in an aircraft configuration database. An exemplary aircraft configuration database is shown in FIG. 2. The aircraft configuration database comprises data that defines the hardware that should be present on the aircraft, the interconnections of the hardware, the physical locations of the hardware, and the logical addresses of the hardware. Shown in FIG. 2 are fields for LRU, the alphanumeric descriptor of the processor described by the record, ID, an identifying field which is combined with the LRU field to provide a unique identifier for every processor in the system, H/W Part No., a hardware part number, Log Adr, the logical address that provides access to the processor over the system network, Location, a description of the physical location of the processor, IsSvr, a flag that indicates that software for the processor is stored on a file system, IsEmb, a flag that indicates that software for the processor is stored in a loadable memory, and IsNld, a flag that indicates that software for the processor is stored in a non-loadable memory. The aircraft configuration database may contain additional fields not shown in FIG. 2.

[0022] The software configuration for the IFES 100 is stored in a software configuration database. An exemplary software configuration database is shown in FIG. 3. Shown in FIG. 3 are fields for LRU, the alphanumeric descriptor of the processor on which the software item described in the record should be loaded, S/W Name, a descriptive name of the software item, S/W Part No., a part number of the software item, File Name, the file name of the file that contains the software item on the master disk and on server processor file systems, and Check Value, a computed value based on the contents of the file for the software item that can be used to verify a copy of the software item. The software configuration database may contain additional fields not shown in FIG. 3.

[0023] The software configuration database is generated when the software is built. It is not specific to any particular aircraft. It may contain information about hardware and software items that are not used in a particular aircraft. A record for an LRU that is not present in a hardware configuration is ignored.

[0024] The aircraft configuration database and the software configuration database are loaded and stored in the IFES 100 as part of the installation process. A configuration check program that embodies the present invention is also loaded and stored in the IFES 100 as part of the installation process. The configuration check program uses information from the aircraft configuration database and the software configuration database to verify the software configuration of the IFES 100. The configuration check program is used only in a maintenance mode of the IFES 100.

[0025] Installation of the aircraft configuration database includes making a copy of the database in a file system that is part of the IFES 100 and placing a copy of the aircraft configuration database part number in a registry maintained by a processor in the IFES 100. Installation of the software configuration database includes making a copy of the database in the file system that is part of the IFES 100 and placing a copy of the software configuration database part number in the registry maintained by the processor in the IFES 100. In another embodiment, one or both databases are copied into the file systems of additional processors that will run the configuration check program for software that is loaded on the file system of that processor and/or hardware that is connected to that processor.

[0026] The database part numbers are retrieved from the aircraft configuration database and the software configuration database to confirm that the correct databases were installed. FIG. 4ais a flowchart for the method of confirming the database installation.

[0027] A first software build part number is retrieved from the software configuration database 200. A second software build part number is retrieved from the registry 202. The first and second part numbers are compared to confirm that the software configuration database present on the file system matches the one installed 204. If there is a mismatch between a part number retrieved from the database and the registry, a warning message is issued 206. In another embodiment, a software configuration database version number is also retrieved and displayed.

[0028] A first hardware database part number is retrieved from the hardware configuration database 208. A second hardware database part number is retrieved from the registry 210. The first and second part numbers are compared to confirm that the hardware configuration database present on the file system matches the one installed 212. If there is a mismatch between a part number retrieved from the database and the registry, a warning message is issued 214. In another embodiment, a hardware configuration database version number is also retrieved and displayed. FIG. 5 is an example of a report produced by an embodiment of the present invention that shows a mismatch for both the hardware configuration database and the software configuration database.

[0029] After the part numbers of the loaded databases are confirmed, the software loaded on the individual processors in the system is verified as shown in FIG. 4b. The aircraft configuration database is read to determine what hardware should be present 220. A record from the aircraft configuration database, as illustrated by FIG. 2, includes information about one hardware item, also termed a line replaceable unit (LRU), in the IFES 100. The information in the record includes the LRU name, system identifying number, hardware part number, logical address, location description, and flags that describe how software is stored by the hardware (file system, loadable non-volatile memory, or non-loadable memory). The record may contain additional items not described. There is one record in the hardware configuration database for every processor present in the distributed processor system. Each hardware record is read 220 and processed 222-252 until an end of file is detected for the hardware configuration database 254 indicating that all records in the hardware configuration database have been processed.

[0030] For each hardware record, the software configuration database is searched to locate records with LRU fields that match the LRU field for the current hardware record 222. The search is continued until an end of file is detected for the software configuration database 252 indicating that all records in the software configuration database have been processed in the search for software records that match the hardware record being processed. This is necessary because more than one software item may be loaded on a single LRU.

[0031] A record from the software configuration database provides information about one software component that should be loaded on one hardware component if present in the system. The information in the record, as shown in FIG. 3, includes the software name, the software part number, the LRU identification for hardware items on which the software should be loaded, the software file name, and a check value for the file computed at the time the software configuration data base was created. The check value is computed by performing an exclusive OR checksum for the file containing the software item. Other types of check values used to assure the integrity of a stream of data, as are known in the art, may be used as the check value. The record may contain additional items not described.

[0032] In one embodiment of the invention, the software configuration database is searched for all instances of software records that indicate that a software item described by the record should be present on the identified LRU. In another embodiment of the invention, the aircraft configuration database and the software configuration database form a relational database that allows the software records associated with a hardware record to be retrieved based on the relating field of the LRU identity.

[0033] In another embodiment of the invention, the software configuration database includes information about software items that are comprised of one or more software components. If a software item should be present for the LRU identified by the record from the aircraft configuration database, then the software configuration database is further consulted to determine the software components that should be present for the software item. In one version of this embodiment, the software configuration database is searched for all instances of software records that indicate that a software item described by the record should be present for the identified software item. In another version, the software configuration database has a relational structure that allows the software component records associated with a software item record to be retrieved based on the relating field of the software item identity.

[0034] The software loading for each software record located is verified for the processor identified by the current hardware record. The method of verifying the loading of the software item is determined by the manner is which software is loaded on the hardware item. Some LRUs, termed server LRUs, are general purpose computers with disk based file systems. Software for server LRUs is stored in the file system. Other LRUs, termed embedded LRUs, are specialized processors that store their programs in field loadable, non-volatile storage such as EEPROM or flash memory. Still other LRUs, termed non-loadable LRUs, are specialized processors that have programs in non-loadable memory such as ROM or PROM. The software for non-loadable LRUs is loaded as part of the manufacturing process for the LRU and it is not possible to alter the software configuration of an installed non-loadable LRU. The type of software storage on an LRU is indicated in the record for the LRU in the aircraft configuration database. In the exemplary database shown in FIG. 3, the flags shown as IsSvr, IsEmb, and IsNld are tested to determine what type of verification to use 224.

[0035] If the LRU is identified by the hardware record as a server LRU, the one or more files containing the software components identified by the software configuration database are checked to verify that they are consistent with a check value stored in the record for that software component in the software configuration database. The software configuration database contains information, such as the filename, that permits the configuration check process to locate the software component on the server processor's file system. This file locator is retrieved from the software configuration database 226.

[0036] A check value is a value computed based on all the data stored in the file for a software component 228. FIG. 4cis a flowchart that illustrates one method for computing a check value. In this embodiment, the check value is computed by initializing the check value with the value of a first data unit retrieved from the software file as loaded on the processor 258. A next data unit is retrieved from the software file 262. If the end of the software file has not been reached 264, the retrieved data unit is combined with the current value of the check value by an exclusive OR operation 266. This is repeated, beginning with the retrieving of the next value 262, until the end of the software file is reached 264. Processing then continues with retrieval of a second check value as stored in the software record in the software configuration database 230. The second check value is computed at the time the software is built and stored in the record for the software component in the software configuration database. In other embodiments, other forms of check values that give unique values for a file that change if any single bit in the file is changed, are used as the check value. It is important to note that the check value is not stored in the file being checked, or, if it is, that it is not used for computing the check value for the purposes of the present invention.

[0037] The first check value is compared to the second check value 232. If the two values are equal, there is a very high confidence that the loaded software component is the same as the software component identified by the software configuration database because the computation of the check value is chosen such that any single bit change in the file produces a different value and all possible check values are produced with a substantially equal probability. The likelihood of two different files having the same check value is approximately one divided by the number of possible check values. If the first check value is the same as the second check value, the configuration is reported as “OK” 234. If the values are not equal, then “FAIL” is reported 236.

[0038] If the LRU is identified by the hardware record as an embedded LRU, a first software part number of the software contained in the LRU is retrieved from the LRU 238. A second software part number is retrieved from the record in the software configuration database 240. The first part number is compared to the second part number 242. If the two values are equal, there is confidence that the loaded software component is the same as the software component identified by the software configuration database. If the first part number is the same as the second part number, the configuration is reported as “OK” 244. If the part numbers are not equal, then “FAIL” is reported 246.

[0039] In another configuration, a check value is computed by the embedded LRU for the software loaded on the LRU. The check value reported by the LRU is compared to the stored check value in the software configuration database. If the two values are equal, there is a very high confidence that the loaded software component is the same as the software component identified by the software configuration database as discussed above.

[0040] If the LRU is identified by the hardware record as a non-loadable LRU, the part number of the software contained in the LRU is retrieved from the LRU 248 and reported with an “INFO” status 250 indicating that the part number is for information only and has not been confirmed. Neither a check value nor a software part number are verified because the software content of non-loadable LRUs is not controlled as part of the software configuration of the IFES 100. In another embodiment, non-loadable LRUs are verified by a part number or check value reported by the LRU as described above for embedded LRUs.

[0041] The above described process continues for each matching software record 252 of every hardware record 254. In this way, all software components that should be loaded on every hardware component that should be present are verified. The process halts when the end of the hardware configuration file is reached 256.

[0042] In another embodiment, the above process is distributed. A master processor requests slave processors to perform the configuration verification for a subset of the processors in the system and report the results to the master processor. The master processor then prepare a report for the entire system based on the received reports. This embodiment is particularly useful in distributed systems with a hierarchical architecture in which the master processor cannot communicate directly with every processor in the system. Slave processors are chosen so that the software on all processors is checked and the results gathered and forwarded to the master processor for reporting.

[0043] FIG. 6 shows an exemplary report produced by an embodiment of the present invention. The part number of the loaded software configuration database 200 is reported on the first line. The part number of the loaded hardware configuration database 208 is reported on the fourth line as “Database P/N.” In the lower, tabular section, one line is reported for every software component on every hardware component of the system. The items reported include Cfg, the result of the configuration check 234, 236, 244, 246, 250, LRU, the processor descriptor from the hardware configuration database, ID, the processor identifier from the hardware configuration database, S/W Name, the name of the software component from the software configuration database, S/W Part No., the software part number from the software configuration database, D/B Part No., the part number of the hardware database that was used to generate the report for this hardware component, H/W Part No., the processor part number from the hardware configuration database, and S/N, the processor serial number as reported by the processor.

[0044] FIG. 7 shows an exemplary summary report produced by an embodiment of the present invention. This report is identical to the standard report shown in FIG. 6 except that all report lines for identical software components loaded on the same type of processor are reported on a single line with the number of units being reported listed as Qty, which replaces S/N. Note that “OK” components and “FAIL” components that are otherwise identical are reported separately; e.g. the ZIM Op Code on the ZBU.

[0045] FIG. 8 shows an exemplary extended report produced by an embodiment of the present invention. This report is identical to the standard report shown in FIG. 6 except that the report for each hardware component is expanded to include multiple lines. Additional information is reported including the actual check value computed for the software component; e.g. Actual XCRC. The extended report may show software items and the software components that make up the software items. Additional information obtained from the hardware configuration database, the software configuration database, or as reported by the processors in the system, may also be reported.

[0046] While certain exemplary embodiments have been described and shown in the accompanying drawings, it is to be understood that such embodiments are merely illustrative of and not restrictive on the broad invention, and that this invention not be limited to the specific constructions and arrangements shown and described, since various other modifications may occur to those ordinarily skilled in the art.