Field replaceable unit (FRU) identification system tool

A method includes interfacing with a field replaceable unit (FRU) having a memory device configured to store a FRUID image including at least status data. The status data is extracted from the memory device. Repair information associated with a repair of the field replaceable unit is received. The repair information is stored in the memory device. A system includes a field replaceable unit (FRU) and a FRU tool. The FRU includes a memory device configured to store a FRUID image including at least status data. The FRU tool is configured to interface with the FRU, extract the status data from the memory device, receive repair information associated with a repair of the field replaceable unit, and store the repair information in the memory device.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates generally to a processor-based computer system and, more particularly, to a field replaceable unit (FRU) identification system tool.

2. Description of the Related Art

The last several years have witnessed an increased demand for network computing, partly due to the emergence of the Internet. Some of the notable trends in the industry include a boom in the growth of Applications Service Providers (ASPs) that provide applications to businesses over networks and enterprises that use the Internet to distribute product data to customers, take orders, and enhance communications with employees.

Businesses typically rely on network computing to maintain a competitive advantage over other businesses. As such, developers, when designing processor-based systems for use in network-centric environments, may take several factors into consideration to meet the expectation of the customers, factors such as the functionality, reliability, scalability, and performance of such systems.

One example of a processor-based system used in a network-centric environment is a mid-frame server system. Typically, mid-frame servers are employed in high bandwidth systems requiring high availability factors. Minimizing system downtime is an important system management goal, as downtime generally equates to significant lost revenue. Typically, such computer systems are provided with replaceable components or modules that may be removed and/or installed without shutting down the system. This on-line replacement capability is commonly referred to as a hot-pluggable or hot-swappable environment.

Unlike current desktop computer systems, in which the internal cards and devices are essentially disposable (i.e., they are replaced if they fail, and the defective part is discarded without repair), the individual components used to construct higher end systems, such as the mid-frame server described above, are typically returned to the manufacturer or a third-party vendor associated with the manufacturer for repair. Repaired units are then reinstalled in the same or in a different mid-frame server. Such repairable components are commonly referred to as field replaceable units (FRUs). In the service life of a particular FRU, it may be installed in multiple servers owned by different customers. Exemplary units that may be field replaceable are system control boards, processing boards, memory modules installed on one of the processing boards, input/output (I/O) boards, power supplies, cooling fans, and the like.

Throughout the service life of a particular FRU, it may be serviced by different repair entities and installed in different customer facilities. Because of the different entities involved during the service life of the FRU, it is difficult to maintain accurate and retrievable records for the individual FRUs. Different databases including information about the FRU may not be centralized or even available.

SUMMARY OF THE INVENTION

One aspect of the present invention is seen in a method including interfacing with a field replaceable unit (FRU) having a memory device configured to store a FRUID image including at least status data. The status data is extracted from the memory device. Repair information associated with a repair of the field replaceable unit is received. The repair information is stored in the memory device.

Another aspect of the present invention is seen in a system including a field replaceable unit (FRU) and a FRU tool. The FRU includes a memory device configured to store a FRUID image including at least status data. The FRU tool is configured to interface with the FRU, extract the status data from the memory device, receive repair information associated with a repair of the field replaceable unit, and store the repair information in the memory device.

DETAILED DESCRIPTION OF SPECIFIC EMBODIMENTS

It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise, or as is apparent from the discussion, terms such as “processing” or “computing” or “calculating” or “determining” or “displaying” and the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical, electronic quantities within the computer system's registers and/or memories into other data similarly represented as physical quantities within the computer system memories and/or registers and/or other such information storage, transmission and/or display devices.

The programming instructions necessary to implement these software functions may be resident on various storage devices. Such storage devices referred to in this discussion may include one or more machine-readable storage media for storing data and/or instructions. The storage media may include different forms of memory including semiconductor memory devices such as dynamic or static random access memories (DRAMs or SRAMs), erasable and programmable read-only memories (EPROMs), electrically erasable and programmable read-only memories (EEPROMs) and flash memories; magnetic disks such as fixed, floppy, removable disks; other magnetic media including tape; and optical media such as compact disks (CDs) or digital video disks (DVDs). Instructions that make up the various software layers, routines, and/or modules in the various systems may be stored in respective storage devices. The instructions, when executed by a respective control unit, cause the corresponding system to perform programmed acts as described.

Referring now toFIG. 1, a simplified block diagram of a repair system2is provided. The repair system2may be implemented in a repair facility for servicing and/or upgrading field replaceable units (FRUs). The repair system2includes a FRU tool3interfacing with a FRU4. The FRU4may be installed in the FRU tool3or coupled to the FRU tool3through an external interface5. The FRU4is equipped with a FRU identification (FRUID) memory6for storing data regarding the associated FRU4, such as identification data and data regarding its service and operating history. Components received for repair or upgrade may be installed in the FRU tool3and data stored on their respective FRUIDs6may be extracted and/or modified. The FRU tool3may or may not be the same type of system in which the FRU4had been previously installed. The FRU tool3may have various implementations and capabilities. The FRU tool3may be configured to interface with a FRUID Image Repository (FIR)7for storage of images from the FRU4and other FRUs maintained under the control of the provider of the systems in which the FRUS are installed. The FIR7may be located at a site remote from the repair facility including the FRU tool3, and a communication link8may be provided for transferring the FRUID images between the FRU tool3and the FIR7. For example, the FRUID images may be transferred using a modem connection, a network connection, or an internet connection. An exemplary technique for implementing the FIR7is described in greater detail in U.S. Provisional Patent Application Ser. No. 60/381,399, incorporated above.

Turning now toFIG. 2, a simplified block diagram of the FRU tool3in accordance with one embodiment of the present invention is illustrated. In the illustrated embodiment, the FRU tool3is a computer system adapted to run under an operating system12, such as the Solaris™ operating system offered by Sun Microsystems, Inc. of Palo Alto, Calif. As described above, FRUs4received at a repair facility may be installed in the FRU tool3as internal components or connected through external interfaces. The repaired or modified FRU4may be then returned to its previous installation or placed into stock for future installations. The FRU tool3executes a FRUTool software application13for accessing the data stored on the FRUID6.

The FRU tool3, in one embodiment, includes a plurality of system control boards15(1-2), each including a system controller20, coupled to a console bus interconnect25. The system controller20may include its own microprocessor and memory resources. The FRU tool3also includes a plurality of processing boards30(1-6) and input/output (I/O) boards35(1-4). The processing boards30(1-6) and I/O boards35(1-4) are coupled to a data interconnect40and a shared address bus42. The processing boards30(1-6) and I/O boards35(1-4) also interface with the console bus interconnect25to allow the system controller20access to the processing boards30(1-6) and I/O boards35(1-4) without having to rely on the integrity of the primary data interconnect40and the shared address bus42. This alternative connection allows the system controller20to operate even when there is a fault preventing main operations from continuing.

In the illustrated embodiment, the FRU tool3is capable of supporting6processing boards30(1-6) and4I/O boards35(1-4). However, the invention is not limited to such an exemplary implementation, as any number of such resources may be provided. Also, the invention is not limited to the particular architecture of the FRU tool3.

For illustrative purposes, lines are utilized to show various system interconnections, although it should be appreciated that, in other embodiments, the boards15(1-2),30(1-6),35(1-4) may be coupled in any of a variety of ways, including by edge connectors, cables, and/or other available interfaces.

In the illustrated embodiment, the FRU tool3includes two control boards15(1-2), one for managing the overall operation of the FRU tool3and the other for providing redundancy and automatic failover in the event that the other board15(1-2) fails. Although not so limited, in the illustrated embodiment, the first system control board15(1) serves as a “main” system control board, while the second system control board15(2) serves as an alternate hot-swap replaceable system control board.

The main system control board15(1) is generally responsible for providing system controller resources for the FRU tool3. If failures of the hardware and/or software occur on the main system control board15(1) or failures on any hardware control path from the main system control board15(1) to other system devices occur, system controller failover software automatically triggers a failover to the alternative control board15(2). The alternative system control board15(2) assumes the role of the main system control board15(1) and takes over the main system controller responsibilities. To accomplish the transition from the main system control board15(1) to the alternative system control board15(2), it may be desirable to replicate the system controller data, configuration, and/or log files on both of the system control boards15(1-2). During any given moment, generally one of the two system control boards15(1-2) actively controls the overall operations of the FRU tool3. Accordingly, the term “active system control board,” as utilized hereinafter, may refer to either one of the system control boards15(1-2), depending on the board that is managing the operations of the FRU tool3at that moment.

For ease of illustration, the data interconnect40is illustrated as a simple bus-like interconnect. However, in an actual implementation the data interconnect40is a point-to-point switched interconnect with two levels of repeaters or switches. The first level of repeaters is on the various boards30(1-6) and35(1-4), and the second level of repeaters is resident on a centerplane (not shown). The data interconnect40is capable of such complex functions as dividing the system into completely isolated partitions and dividing the system into logically isolated domains, allowing hot-plug and unplug of individual boards.

In the illustrated embodiment, each processing board30(1-6) may include up to four processors45. Each processor45has an associated e-cache50, memory controller55and up to eight dual in-line memory modules (DIMMs)60. Dual CPU data switches (DCDS)65are provided for interfacing the processors45with the data interconnect40. Each pair of processors45(i.e., two pairs on each processing board30(1-6)) share a DCDS65. Also, in the illustrated embodiment, each I/O board35(1-4) has two I/O controllers70, each with one associated 66-MHz peripheral component interface (PCI) bus75and one 33-MHz PCI bus80. The I/O boards35(1-4) may manage I/O cards, such as peripheral component interface cards and optical cards, that are installed in the FRU tool3.

In the illustrated embodiment, the processors45may be UltraSPARCIII™ processors also offered by Sun Microsystems, Inc. The processors are symmetric shared-memory multiprocessors implementing the UltraSPARC III protocol. Of course, other processor brands and operating systems12may be employed.

Selected modules in the FRU tool3are designated as FRUs4and are equipped with FRUID memories6. Exemplary FRUs so equipped may include the system controller boards15(1-2), the processing boards30(1-6), and the I/O boards35(1-4). The FRU tool3may also include other units, such as a power supply85(interconnections with other devices not shown), a cooling fan90, and the like, equipped with FRUIDs6, depending on the particular embodiment. The FRU tool3may be configured to allow hot or cold swapping of the field replaceable units.

Turning now toFIG. 3, a simplified diagram of the FRUID6is provided. In the illustrated embodiment, the FRUID6is a serial electrically erasable programmable read-only memory (SEEPROM) and has an 8 Kbyte space to store information about the associated FRU. Of course, other memory types and storage sizes may be used depending on the particular implementation. The FRUID6includes a 2 Kbyte static partition200dedicated to store “static” information and a 6 Kbyte dynamic partition205to store “dynamic” information. Certain data is intended to remain in the FRUID6throughout its service life (i.e., lifetime duration), while other data is only intended to remain during a single installation of the FRU4(i.e., field duration). Data with a field duration may be erased or set to a default value prior to shipping the FRU4to a different installation. Certain data with a field duration, as will be described in greater detail below) may also be accumulated with field data from previous installations using cumulative records. The storage life of the various data is described in greater detail below.

The particular format for storing data in the FRUID6is described in greater detail in U.S. Provisional Patent Application Ser. No. 60/381,400, incorporated above.

Some of the benefits derived from the information stored in the FRUID6are:Fatal Error Identification—a fatal error bit may be set on FRU failure and will remain set until after the FRU has been repaired and reset by the repair depot to prevent “accidental” reuse of the failed FRU;Ease of Tracking Errors—in the event the FRU has been “repaired” and returned to the field, and failed again subsequently with the same or similar failure, the failure log is tagged to insure special attention will be given to the failed FRU;Trend Analysis—quick identification of certain batch of FRUs with known defects can be done by a serial number embedded into the SEEPROM;Trend Analysis—quick analysis can be performed by collecting information of specific FRUs, including power-on hours, temperature logs, and the like;Trend Analysis—quick identification of components from specific vendors on premature failures of certain FRUs; andField Change Orders can be applied easily with patches after identifying the range of affected FRU by serial numbers.

Referring now toFIG. 4, a simplified block diagram of an exemplary FRU4having a FRUID6is shown. As described above, the FRU4may represent one of the system control boards15(1-2), one of the processing boards30(1-6), one of the input/output (I/O) boards35(1-4), the power supply85, the cooling fan90, and the like. The FRU4includes a plurality of submodules405. For example, the FRU4may be a processing board30(1-6), and the submodules405may be the processors45, e-caches50, memory controllers55, and DIMMs60. Selected submodules405(e.g., the DIMMS60) may also be themselves field replaceable and have their own FRUIDs6. The submodules405may be organized into groups410. For example, a processor45and its associated e-cache50, memory controller55, and DIMMS60may be organized into a single group410.

Returning toFIG. 3, the data stored in the static partition200and dynamic partition210is now described in greater detail. The particular types of static and dynamic data stored in the FRUID6that are detailed herein are intended to be exemplary and non-exhaustive. Additional static and dynamic data may be stored in the FRUID6depending on the particular implementation. The information stored in the static partition200is typically information that is not expected to change over the service life of the FRU4, while the dynamic data includes data that is written to the FRUID6during its service life.

The manufacturing data210may include information such as the part number, serial number, date of manufacture, and vendor name. The system ID data215may include information such as an ethernet address and a system serial number (i.e., of the system in which the FRU is installed). The system parameter data220may include information about the system, such as maximum speed, DIMM speed, maximum power, and the like.

The operational test data225provides information about the most recent iteration of tests performed on the FRU4. The operational test data225is typically written during the manufacture of the FRU4or while it is being repaired, not while the FRU4is in the field. When the FRU4is received at a repair depot, the operational test data225may be accessed to determine which tests had been previously run on the FRU4. For each of the possible tests that may be run on the FRU4, a summary record may be provided that indicates when the test was performed and the revision of the testing procedure used. The detailed operational test data225may be captured and cleared prior to shipping the FRU4for installation, but the summary record detailing the last tests performed may be retained.

The installation data230specifies where the FRU4has been used, including the system identity and details of the parent FRU (i.e., the FRU in which the current FRU4is installed). The installation data230may also include geographical data (e.g., latitude, longitude, altitude, country, city or postal address) related to the installation. The installation data230typically has a field duration.

The operational history data235includes data related to selected parameters monitored during the service life of the FRU4. For example, the operational history data235may include power events and/or temperature data.

Power on and off events are useful in reconstructing the usage of the FRU4. The power event data could indicate whether the FRU4was placed in stock or installed in a system and shipped. The idle time would indicate the shelf life at a stocking facility before use. The time interval between a fatal error and a power on at a repair center could be used to track transit time. The total on time could be used to generate a mean time before failure metric or a mean time before fatal error metric. Detailed power event records may have a field duration. A cumulative power history record having an indefinite duration may be used to accumulate the power history across different installations of the FRU4. The power information stored for the current installation may be accumulated with other power history data from previous installations.

Temperature data is useful for analyzing service life and failure rates. Failure rate is often directly dependent on temperature. Various aging mechanisms in the FRU4run at temperature controlled rates. Cooling systems are generally designed based on predicted failure rates to provide sufficient cooling to keep actual failure rates at an acceptable level. The temperature history may be used for failed components to determine whether predicted failure rates are accurate. Temperature history can affect failure rate both by aging and by failure mechanisms unrelated to aging. Minimum and maximum operating temperatures are recorded to establish statistical limits for the operating range of the FRU4. Temperature values are grouped into bins, with each bin having a predetermined range of temperatures. The count of time in each temperature bin defines the temperature history of the operating environment. A last temperature record may be used to approximate the temperature of the FRU4when it failed. Temperature data from one FRU4may be compared to the histories of other like FRUs to establish behavior patterns. Failure histories may be used to proactively replace temperature-sensitive parts. An indefinite cumulative temperature history record may be used to accumulate the temperature history across different installations of the FRU4. The temperature information stored for the current installation may be accumulated with other temperature history data from previous installations, and the temperature records with a field duration may be erased.

The status data240records the operational status of the FRU4as a whole, including whether it should be configured as part of the system or whether maintenance is required. If maintenance is required, a visible indication may be provided to a user by the system. Exemplary status indications include out-of-service (OOS), maintenance action required (MAR), OK, disabled, faulty, or retired. A human-supplied status bit may be used to indicate that the most recent status was set by human intervention, as opposed to automatically by the system. A partial bit may also be used to indicate while the entire FRU4is not OOS, some components on the FRU4may be out-of-service or disabled. If the system sees the partial bit checked, it checks individual component status bits to determine which components are OOS or disabled. The status data240may also include a failing or predicted failing bit indicating a need for maintenance. Typically, the status data240related to the current status has an indefinite duration, but status event data that records status changes may have a field duration.

The error data245includes soft errors from which the system was able to recover. These soft errors include error checking and correction (ECC) errors that may or may not be correctable. The type of error (e.g., single bit or multiple bits) may also be recorded. A rate-limit algorithm may be used to change the status of the FRU4to faulty if more than N errors occur within a FRU-specific time interval, T. Typically, the error data245has a field duration.

The upgrade/repair data250includes the upgrade and repair history of the FRU4. The repair records include repair detail records, a repair summary record, and an engineering change order (ECO) record. Typically, the repair records are updated at a repair depot when a repair is completed on the FRU4. The repair information stored on the FRUID6may also include the number of times a returned FRU4is not diagnosed with a problem. During a repair operation, one or more engineering change orders (ECOs) may be performed on the FRU4to upgrade its capability (e.g., upgrade a processor45) or to fix problems or potential problems identified with the particular FRU4model. For example, a firmware change may be implemented or a semiconductor chip (e.g., application specific integrated circuit (ASIC)) may be replaced. Typically, the upgrade/repair data250has an indefinite duration.

The customer data255is generally a free-form field in which the customer may choose to store any type of desired information, such as an asset tag, the customer's name, etc. The customer data255may be updated at the customer's discretion. Typically, the customer data255has a field duration.

Turning now toFIG. 5, a simplified diagram illustrating the interface between the FRU tool3and the FRU4during a repair or upgrade evolution is provided. In block500, the FRU4is received from the field. The FRU4may be received due to a fault condition with the FRU4or a need for an upgrade. In block510, a pre-test may be performed on the FRU4to determine if it is operating properly. If no problems are identified, a no trouble found (NTF) condition may be indicated. At the time of the pretest, the FRU tool3captures the image stored in the FRUID6and queues the pre-test image for transfer to the FIR7(seeFIG. 1) in block520. If the FRUID6is corrupt or failed in block530, the most recent FRUID image archived in the FIR may be requested in block540, and the FRU tool3may update the FRUID6with the archived image in block550.

The upgrade, debug, and repair process occurs in block560. The FRU tool3provides the status data240and error data245extracted from the FRUID image in block570. Such data is useful for determining the nature of the problem associated with the FRU4necessitating its repair. If a problem with the FRU4prevents extraction of the pre-test FRUID image, it may be extracted after a repair has been performed in block560and transferred to the FIR7in block520. The FRU4passes to a final test stage at block590. User input associated with the repair or upgrade activity is provided in block600, and the FRU tool3creates a repair record detailing the repair/upgrade activity and stores the record on the FRUID6in block610and transfers a port-repair FRUID image to the FIR7in block615. For example, a user may select from a plurality of predefined repair or upgrade activities using a drop-down list. Based on the selection, the FRU tool3may generate the repair information and store the repair record in the FRUID6. The particular makeup of the repair/upgrade records is described in greater detail U.S. Provisional Patent Application Ser. No. 60/381,386, incorporated above.

In block620, data in the FRUID image is processed and/or reset to default values. For example, records having a field duration may be erased or set to default values. Temperature and power data may be accumulated in cumulative summary fields, and the status and error data may be cleared. Following the processing in block620, the FRU tool3sends the updated stock FRUID image for archival in the FIR7in block630and updates the image stored in the FRUID6in block640. Subsequently, the FRU4is placed in stock in block650, and the repair upgrade process completes.

Storage of information on the FRUID6and retrieval of that information during repair activities provides advantages related to fault diagnosis and record keeping. Much of the important information associated with the service life of the FRU4is contained within the FRUID6, and is thus always available with the device. Information related to operational history, problems, repairs, upgrades, etc. remains retrievable.