US20040186690A1 - System and method for tracking engineering changes relating to a circuit card - Google Patents

Abstract

The invention provides a system and a method of electronically tracking a history of engineering change orders (ECOs) associated with a manufactured device. The device has at least one electronic component thereon. The method comprises, generally, storing in an electronic storage device associated with the device, the history of ECOs and updating the history of ECOs when a new ECO is associated with the device to indicate whether the new ECO was implemented on the device. The system utilizes the method and has an electronic storage device associated with the device and a data element stored therein. The contents thereof indicate the history of ECOs for the device and allow modification thereto to indicate whether a new ECO was implemented thereon. An ECO history enables a determination to be made of compatibilities between hardware and software elements and between hardware and firmware elements.

Description

FIELD OF THE INVENTION
• The invention relates to a system and method for tracking of engineering change orders (ECOs) relating to repairable elements of an electronic device, in particular a system and method for tracking ECOs of field replaceable units (FRUs), such as circuit cards, of a communication device connected to a communication network.[0001]
BACKGROUND OF INVENTION
• It is common for an electronic device (which includes most types of communication devices) to utilize a series of circuit cards to provide aspects of the functionality of the device. Generally, a feature of a circuit card is that it can be removed and replaced from the electronic device when the circuit card fails or needs to be upgraded. In many devices, the circuit card may be replaced in the field, in situ. Accordingly, the circuit card is often referred to as a field replaceable unit (FRU).[0002]
• Circuit cards typically have hardware, software and firmware elements used in hardware circuits to provide their functionality. The hardware elements may comprise upgradeable components such as CPUs, memory modules and other upgradeable and replaceable devices. Firmware is typically stored in non-volatile electronic devices, such as EEPROMs, EPROMs, PLDs and PGAs, and volatile devices such as FPGAs and RAM, provide low level, executable code performing various calculations and operations on input and output signals depending on the program embodied in the firmware. Software, which is frequently stored non-volatile memory, but executes from volatile memory such as RAM, provides an operating code for a program which is executed on a CPU. Upgrades may be implemented to an element to correct existing operational errors or to improve its performance. For example, in hardware a “cut and strap” may be added to change an electrical connection on one of its circuits. In software, a new routine may be added providing a new feature for the program.[0003]
• During the life of an electronic device, engineering change orders (ECOs) may be implemented in a circuit card to correct operational defects or implement manufacturing cost reductions. An operational defect may be a design defect in hardware circuit or software element implemented on the circuit board. A manufacturing cost reduction may be utilizing a different set of (less expensive) components to perform the identical functionality of an earlier design of a hardware circuit for the circuit card.[0004]
• For repair purposes, it is useful to track the progression of ECOs during the life of a circuit card. This is frequently done by associating an ECO with each circuit card of the electronic device. Typically, each circuit card has a unique ECO number relating to the ECO. A component of each ECO number, such as a version number, is incremented as each engineering change is made to the circuit board. Typically, this may be done by keeping a hardcopy or a softcopy register of all implemented ECOs for a card at a repair station. Accordingly, when a circuit board is being repaired, the repair personnel may examine the log, get the ECO information and determine what repairs have been implemented on the card. Appropriate updates may be made to the circuit card, depending on the number of the ECO version of the card and the current number of the ECO version for cards being built. As the register is often associated with the station in a database maintained on a server or a computer, the tracking information associated with the card remains with the station, which causes potential loss of information if the register at the station is lost. However, when a circuit board is repaired, it will be appreciated that an ECO which was implemented to effect a manufacturing cost reduction does not necessarily have to be implemented on the circuit board. There is typically little cost benefit in retrofitting a board with a manufacturing cost reduction design.[0005]
• It will be appreciated that the use of a simple ECO number with a version component to track both operational defects and manufacturing cost reduction implementations does not provide full information to the repair personnel. Further, with the known methods of tracking ECOs, it is difficult to determine whether an upgrade intended for a software/firmware/hardware element on the circuit card is compatible with the ECOs that have been implemented on the card. Accordingly, there is a need for an improved system and method for tracking types of ECOs related to a circuit board to provide improved tracking of compatibilities amongst the circuit boards.[0006]
SUMMARY OF INVENTION
• In a first aspect, a method of electronically tracking a history of engineering change orders (ECOs) associated with a manufactured device is provided. The manufactured device has at least one electronic component installed thereon. The method comprises storing in an electronic storage device associated with the manufactured device the history of ECOs and updating the history of ECOs when a new ECO is implemented on the manufactured device to indicate that the new ECO was implemented thereon.[0007]
• The method may have the history of ECOs indicating, for a given ECO whose history is contained therein, whether that given ECO is a mandatory change or an optional change.[0008]
• The method may have the history of ECOs stored as a series of bits in the electronic storage device.[0009]
• The method may have the electronic storage device mounted on the manufactured device.[0010]
• The method may have the history of ECOs accessible by an analysis device connectable to the manufactured device when the manufactured device is being examined.[0011]
• The method may have the manufacturing device utilizing a programmable element which is installed on the manufactured device. Further, the method may compare the history of ECOs of the manufactured device against a version of the programmable element to determine a compatibility level between the version of the programmable element and the manufactured device. Further still, the history of ECOs of the manufactured device may be used to identify compatible versions of the programmable element which may be installed on the manufactured device.[0012]
• The method may access an ECO mask for the version of the programmable element. Therein, the ECO mask identifies only the ECOs in the ECO history which affect the compatibility level of the version of the programmable element.[0013]
• The method may have the compatibility level indicating at least one of the following conditions: (i) whether the version of the manufactured device is compatible with the programmable element; (ii) whether the version of the manufactured device is backwards compatible with the programmable element; and (iii) whether the version of the manufactured device is not compatible with the programmable element.[0014]
• The method may have the programmable element being a software element. Further, the manufacturing device may utilizes a firmware element which is installed on the manufactured device. Also, the history of ECOs of the manufactured device is further compared against a version of the firmware element to determine whether the version of the firmware element is compatible with the manufactured device.[0015]
• The method may have versions of the software element and versions of the firmware element provided in a bundle of installable elements, which is accessible by the manufactured device.[0016]
• In a second aspect, a system for electronically tracking a history of engineering change orders (ECOs) associated with a manufactured device is provided. The manufactured device has at least one electronic component. The system comprises an electronic storage device associated with the manufactured device and ECO information. The ECO information indicates the history of ECOs associated with the manufactured device. The ECO information can be modified and expanded to indicate the addition of a new ECO and whether the new ECO was implemented on the manufactured device.[0017]
• The system may have comparison information relating ECOs to versions of a programmable element which are installable on the manufactured device, indicating the compatibility of the versions with the ECOs and the manufactured device and ECO mask information to identify the ECOs which affect the operation of the versions of the programmable element for the manufactured device. Further, the system may have an analysis device connectable to the electronic storage device. The analysis device utilizes the ECO information with the comparison information and the ECO mask information to determine whether a version of the programmable element may operate on the manufactured device.[0018]
• The system may have second comparison information relating ECOs to versions of a firmware element which are installable on the manufactured device, indicating the compatibility of the versions of the firmware element with the ECOs and the manufactured device and second ECO mask information to identify the ECOs which affect the operation of the versions of the firmware element for the manufactured device. Further, the analysis device utilizes ECO information, the second comparison information and the second ECO mask information to determine whether a version of the firmware element may operate on the manufactured device.[0019]
• The system may further have a bundle of versions of the programmable element and versions of the firmware element, the bundle being accessible by the manufactured device. Also, the programmable element may be a software element; the analysis device may utilize the ECO information, the comparison information, the second comparison information, the ECO mask information and the second ECO mask information to select a compatible version of the software element and the firmware element from the bundle to be installed into the manufacturing device.[0020]
• In other aspects of the invention, various combinations and subset of the above aspects are provided.[0021]
BRIEF DESCRIPTION OF THE DRAWINGS
• The foregoing and other aspects of the invention will become more apparent from the following description of specific embodiments thereof and the accompanying drawings which illustrate, by way of example only, the principles of the invention. In the drawings, where like elements feature like reference numerals (and wherein individual elements bear unique alphabetical suffixes):[0022]
• FIG. 1 is a block diagram of hardware elements of a circuit card used in association an embodiment of the invention;[0023]
• FIG. 2 is a table providing two versions of engineering change order (ECO) information associated with the circuit card used by the embodiment of FIG. 1;[0024]
• FIG. 3 is a block diagram of a matrix correlating ECOs against versions of hardware, software and firmware elements for the card of FIG. 1, according to an embodiment; and[0025]
• FIG. 4 is a block diagram of a resource module associated with the main controller card used with the embodiment shown in FIG. 1.[0026]
DETAILED DESCRIPTION OF THE EMBODIMENTS
• The description which follows, and the embodiments described therein, are provided by way of illustration of an example, or examples, of particular embodiments of the principles of the present invention. These examples are provided for the purposes of explanation, and not limitation, of those principles and of the invention. In the description which follows, like parts are marked throughout the specification and the drawings with the same respective reference numerals.[0027]
• Basic Features of Electronic System Associated with an Embodiment[0028]
• The following is a description of an electronic system associated with an embodiment.[0029]
• Referring to FIG. 1,[0030]electronic circuit card100 is shown, which is a generic manufactured device.Circuit card100 is a component of an electronic device. Physically,circuit card100 may be an FR-4 board with various electronic modules mounted thereon and electrically connected via circuit tracks to provide manipulation and production of various electronic signals. Exemplary modules oncircuit card100 includemain controller102 and modules104a,104band104c.Controller102 communicates withmodules104 throughcircuit tracks106 incard100. The interface point betweencontroller102 and tracks106 is shown asnode108. Similarly, the interface betweenconnections106 and each ofmodules104 is shown asnodes110.Other devices112 may also be connected either directly or indirectly totracks106 thereby allowing them to communicate with eithercontroller102 ormodules104. As shown, an additional set of circuit tracks114 is provided frommain controller102 to anexternal connector116, thereby allowingcircuit card100 to be associated with other external devices (not shown), which may form part of the electronic device. Each oftracks106 and114 may comprise n separate electrical tracks for carrying signals betweencontroller102 andmodules104.
• [0031]Controller102 provides the main controlling system formodules104. Oncontroller card102 there isCPU118,RAM120,firmware devices122 andnon-volatile memory124. It will be appreciated that there may be several of any of the elements onmain controller102. For the shown implementation,RAM120 stores an operating program which is executed onCPU118.Firmware devices122 are programmable, each having separate program codes.Non-volatile memory124 stores the compressed operating program forcontroller102 and stores configuration information aboutcontroller card102.Non-volatile memory device124 can be implemented as a Serial Electrically Erasable PROM (SEEP) and is used to store local engineering change order (ECO) information, per an embodiment, relating tocircuit card100. In the embodiment,SEEP124 is used to store data which acts as a historical label for the ECOs ofcircuit card100. Further detail on the contents ofSEEP124 is provided below.Internal connections126 provide an electrical connection between the elements ofcontroller102 andinterface node108.
• Generally, each of[0032]modules104 comprises the following hardware, software and firmware elements.Hardware element128, abstractly, is an upgradeable component, and is shown aslocal CPU130. In an embodiment,CPU130 is mounted directly tomodule104 in order to dissuade switch operators from making their own modifications tomodule104. However in another embodiment,CPU130 is mounted in asocket132 which provides a releasable interface for the electrical contact points ofCPU130 to other components inmodules104.Socket132 may comprise a zero-insertion force (“ZIF”) socket, known in the art. Accordingly, withsocket132,CPU130 may be removed and replaced with an upgraded component. Also, an upgrade onhardware element128 may be a physical modification, such as a “cut and strap” made to electronic tracks on the module, shown asmodification140, which breakstrack106A, indicated by the “x” therethrough, and addstrack106B to components in module A. Thesoftware element134 is an executable program code stored in a non-volatile program storage element, such as flash memory, and is decompressed and run from a volatile memory device, such as RAM, and is controlled by an aspect of thehardware element128. For the example, the software element is stored in local RAM136 and operates onCPU130. Software, as is known, frequently undergoes revisions and has to be installed into a releasedcircuit card100. Thefirmware elements138 are executable program codes and are provided in a number of program storage elements, including programmable volatile and non-volatile devices such as PLDs, FPGAs andother devices142. Each of thefirmware elements138 may utilize different program codes. As with software elements,firmware elements138 often are upgraded, which occasionally have to be installed into an existingcircuit card100. An electronic signature containing information on thehardware elements128 onmodule104 may also be stored inSEEP144. It will be appreciated thatother modules104 may not have all of the hardware, software and firmware elements. Generically, the software and firmware elements may be referred to as programmable elements.
• As noted earlier, during the life of[0033]card100, numerous engineering change orders (ECOs) may be implemented to correct and/or update hardware, software and firmware elements oncard100. An ECO may be made tocards100 as they are manufactured, tocards100 already manufactured and installed or, possibly, tocards100 which are being repaired. There are several types of ECOs. For example, forcards100 which have not yet been shipped (includingcards100 being manufactured andcards100 manufactured and about to be shipped), there may be the following types of ECOs, per Table A:

  TABLE A
  ECOs for Manufactured Cards

  ECO Manufacturing
  Category	Implementation Action
  Phase-In	ECO is implemented on a going-
  	forward basis for new cards.
  WIP (Work in Progress)	ECO is implemented for all cards
  	which are currently being built.
  WIP/Fin	“Fin” represents “finished” goods,
  	including cards built and in the field.
  	ECO is implemented for all cards
  	which are being built, cards which have
  	been built and are finalized but not
  	stored for shipping and cards which are
  	finalized which are stored for shipping.
  Recall	ECO must be implemented on all cards
  	being manufactured and cards which
  	have been manufactured.

• However, for cards which are already in the field, there may be a different implementation action for an ECO, including, for example, exemplary ECOs per Table B:[0034]

  TABLE B
  ECOs for Cards in the Field

  ECO Field/Repair Category	Field Action
  No Action	None
  Optional	Optional (only if requested)
  Mandatory	Mandatory, but only for cards provided
  	to the repair station.

• It will be appreciated that WIP or WIP/Fin ECOs may or may not require that the affected cards be recalled for repairs, depending on the field action. Further, actions for cards in Table A may be completely independent from actions for cards in Table B. Further actions in either Table A or Table B may include additional actions, depending on manufacturing and repair requirements for production/repair of a card.[0035]
• Current practices preferably implement all ECO actions for a card when the card is manufactured, but cards which are already in the field may not necessarily be recalled to have a new ECO implemented thereon. For example, a phase-in ECO change is not needed to be performed on a repaired circuit card, per Table B, but would be performed on a newly manufactured card which was manufactured after the phase-in date.[0036]
• As such, during the production and implementation lifespan of a family of[0037]cards100,different cards100 within the family which are manufactured at different times will likely have a different set of ECOs implemented thereon, compared withother cards100 in the family. The embodiment provides ECO information which may be used to track the ECOs which have been implemented in a givencard100, which is lacking in the prior art.
• Further Detail of an Embodiment[0038]
• Referring to FIG. 2, an embodiment provides a system and method for tracking ECO information on[0039]card100, thereby providing improved tracking of ECOs. Therein,data structure200 contains ECO information associated with a family ofcards100 and ECO implementation information for a givencard100 belonging to the family. The ECO information represents a history of ECOs associated with a givencard100. The contents of eachdata structure200 is populated with relevant ECO information and is stored locally on a givencard100.
• [0040]Data structure200 comprises aheader field202 and adata field204. Thedata field204 comprises an expanding sequential string of data cells206 used to track ECO information. In this ECO string, each cell206 represents a particular ECO and the value of the cell represents indicates whether the ECO was implemented or not for that givencard100. For each new ECO, the ECO string is lengthened by one cell at the end and that last cell is populated with a value representing the implementation status of that ECO for that givencard100. The length of the number of data cells206 contained within the ECO string is tracked inheader field202. In the embodiment, the data cells206 are each preferably one bit in length and theheader field202 preferably contains a size value indicating a number of byte segments which are currently occupied by thedata field204. Accordingly, the ECO string grows in length by byte length segments. As each additional byte length segment is added, there will be a number ofpad bits208 which follow the last tracked ECO to fill the remainder of the last byte of the ECO string. Initially, each data cell206 in the ECO string is preferably set to be a pad bit.
• In the embodiment, the marking convention for data cells[0041]206 utilizes a “1” to indicate that the ECO associated with that data cell206 has been implemented for that card; and a “0” to indicate either (i) that the ECO has not been implemented; or (ii) that it is a pad bit at the end of the ECO string. In other embodiments, other markings may be used to identify that the ECO was implemented and to identify pad bits. For example, in other embodiments, the last data cell206 in ECO string may be indicated by having a detectable “end of string” value stored in the next data cell206.
• An exemplary progression of an ECO string, embodied in[0042]data field204, is provided. Initially, it is presumed that the length ofdata field204 is one byte. Accordingly,data field204 is padded with eight bits of “0”. Next, during the manufacturing ofcards100, it is presumed that three ECO are sequentially implemented. The first ECO is “WIP/Fin”. For allcards100 built immediately after the first ECO, in theirdata field204,data cell206A is present and is marked with a “1”, indicating that the first ECO was a WIP/Fin. For the remaining spaces indata field204, there are seven pad bits. Second, a “phase-in” ECO is implemented. Accordingly, for allcards100 built at immediately after the second ECO, a second, in addition to the prior information,sequential data cell206B is used indata field204 and its value is marked with a “1”, to indicate that it was implemented. For the remaining spaces indata field204, there are now six pad bits. Finally, a third ECO is implemented, which is a “Phase-in/No Action”. For cards built after the third ECO, it is presumed that the phase-in no action is implemented. However, any cards that were built prior to the phase-in date will not have this ECO applied. Since the field action is “no action”, all cards returning through the repair and upgrade process will not have this ECO applied. Accordingly, for cards built earlier than the phase-in date and repaired after the third ECO, in addition to the prior information, athird data cell206C is provided indata field204 and its value unchanged from the original pad bit. However, when comparing the value of thethird data cell206C against a list of ECOs implemented for the family ofcards100, the presence of the “0” inthird data cell206C indicates that the third ECO was not implemented. For the remaining spaces indata field204, there are five pad bits.
• By examining the data fields[0043]204 ofdifferent cards100, it can be determined which ECOs were specifically implemented thereon.Cards100 built between the first and second ECOs will have adata field204 of “10000000”;cards100 built between the second ECO and the third ECO will have adata field204 of “11000000”;cards100 built after the third ECO will have adata field204 of “11100000”. Finally, cards built between the second and the third ECO, and which are repaired after the third ECO will have adata field204 of “11000000”. Note that such repaired cards have anidentical data field204 to unrepaired cards built between the second and the third ECO, even though cards repaired after the third ECO have a third ECO associated with them (although not implemented). For the embodiment, this situation is acceptable because the more critical information for the embodiment is to track which ECOs have been implemented on a givencard100. In other embodiments, there may be a need to distinguishcards100 having an ECO which is associated with a given card100 (but has not been implemented) fromcards100 which were built before that ECO associated with cards. This may be done by changing the value of the pad bit or by defining a “not implemented” value for an ECO which would be used, when appropriate, indata field204.
• For the embodiment, ECO information, embodied in[0044]exemplary data structure200 is preferably stored at a centrally accessible location, such as inSEEP124 onmain controller102. The data format of the ECO information may comprise any computer readable format, including an ASCII file, a spreadsheet file, bit-wise data or a coded binary file.
• It will be appreciated that in order to track ECO information for any[0045]card100, separate global ECO information, representing all ECOs for the family ofcards100 must be maintained and trackable against the ECO information in a givencard100 of that family. This global ECO information may be stored electronically and compared electronically against the ECO information extracted from a givencard100.
• It will be appreciated that for a[0046]card100 which is being repaired, the ECO information stored thereon is preferably extractable by a repair station having an interface to thecard100. Such an interface may connect to connector116 (FIG. 1). The repair station has operative hardware and software to extract the ECO information from its stored location (here SEEP124) and analyze its contents against the global ECO information. Further, after any ECO is implemented on thecard100 being repaired, the repair station can produce an updated ECO string which incorporates the status of the implemented ECO and then can update the stored ECO information on the card being repaired. The repair station may read and update the values of the ECO information for thecard100 being repaired using techniques known in the art.
• In another embodiment, ECO information may be stored as a series of expanding[0047]rows208 of information. For a given row, each column entry210 therein represents a particular ECO. The value of the entry in a column210 represents whether that ECO was implemented. When a new ECO is added, anew row208 is added. In the new row, a new column210 at the end of the row is also added to track the status of the new ECO. For example, in acard100 which has had no ECOs,rows208 are fully empty. On the implementation of a first ECO,ECO row208A is added torows208. If the first ECO was implemented on acard100, cell210A is marked with a ‘1’. Accordingly, upon readingrows208, it can be determined that thecard100 was built when only the first ECO was implemented, by examining that there isonly row208A inrows208. After a second ECO is implemented, forcards100 built thereafter,rows208 hasrow208B added. If the second ECO was implemented, entry210A is marked as being implemented, to track the first ECO, and210B is marked as being implemented, to track the second ECO. Whencard100 is repaired, itsrows208 can be extracted and analyzed. Later, after third and fourth ECOs are implemented,rows208 may be updated forcards100 built at that time by addingthird row208C andfourth row208D to the ECO history in a similar manner to the addition of the second row. An end ofrow mark208E may be added to indicate the end of the ECO information.
• In yet another embodiment, ECO information may be encoded as part of a serial number associated with[0048]card100. For example, if serial number “1234” is associated withcard100 as a base serial number, then additional codes in a code regime may be appended to the base serial number to indicate detail of ECOs which are associated with thatcard100. For example, one code regime may use two additional ECO indicators which are attached to the end of the serial number. The first ECO indicator would signify the last guaranteed ECO which was implemented on thatcard100. The second ECO indicator would signify the most recent ECO implemented associated with that series of cards. Using this regime, if ECO “A” was the last guaranteed ECO implemented on thatcard100 and ECO “D” was the most recent ECO which could have been implemented on thatcard100, then the serial number would be encoded as “1234AD”. By examining the ECO indicators, an operator may determine what ECO was implemented on the card100 (here, ECO “A”) and approximately when was the card built (here, sometime after ECO “D” was introduced). It will be appreciated that this information may be translated into some appropriate digital format and stored in some non-volatile memory device associated withcard100, such asflash memory124. For example, this information may be encoded, stored and analyzed in a hexadecimal format. For example a bit-string “11010110” would relate to ECOs being implemented in positions, “1”, “2”, “4”, “6” and “7” in the ECO string, which would be encoded and stored as hexadecimal D6.
• Use of ECO Information[0049]
• Referring to FIG. 1, using ECO information stored in[0050]SEEP124, an embodiment provides tracking of ECOs againstcompatible software elements134 andfirmware elements138. In view of ongoing ECOs related tocard100, after an ECO is implemented oncard100, changes incorporated may affect the compatibility of thecard100 with various versions ofsoftware elements134 andfirmware elements138 available to thecard100. For example, if an ECO deletes astorage element142 into which aparticular firmware element138 is programmed, then, thatfirmware element138, in any version, cannot be associated withcard100 having that ECO implemented thereon. Alternatively, when upgrades are made tosoftware elements134 andfirmware elements138, the upgrades may necessarily require that a certain ECO be implemented on a givencard100. For example, incard100,software elements134 andfirmware elements138 may be continually individually upgraded during the operational life ofcard100. As such, if a software upgrade increases the program size of the software to be larger than the original storage device ofcard100 and an ECO implements a sufficiently large storage device for the software upgrade, then thatcard100 must have that ECO implemented thereon if thelarger software element134 is to be installed oncard100.
• As such, ECO information string in[0051]SEEP124 may be extracted and analyzed against requirements for versions ofsoftware elements134 andfirmware elements138 for aparticular hardware element128 oncard100 by an appropriate analysis device which can read the ECO information through a communication interface and conduct an analysis of the ECO information against available versions of the software and firmware elements.
• Referring to FIG. 2, using the format of the above-described ECO information for[0052]data field204, the following example illustrates use of ECO information in an ECO string against operational requirements of versions ofsoftware element134. It will be appreciated that a similar comparison may be made for versions of afirmware element138. For the example, it will be presumed that fordata field204, the ECO string is represented by the bit string “10110” (pad bits are ignored), stored indata structure200 for a givencard100. The contents of ECO string indicates that five ECOs have been associated with thecard100 and that, from left to right, the first, third and fourth ECOs (the first being the oldest ECO), have been implemented in that givencard100. In other embodiments, the order may progress from right to left. Further, for a givensoftware element134, it is presumed that there are four versions thereof, “A” through “D”, and that each version needs to have certain ECOs implemented to operate.
• In order to facilitate a comparison of the ECO string with the proposed[0053]software element134 version, for each software version, the embodiment utilizes an ECO mask to mask out all non-essential ECO elements (for that version) in the ECO string, thereby identifying only the ECOs which affect the ability of the software version to be used on that givencard100. The ECO mask may be implemented as a mask bitstring. As such, when the ECO mask is applied against the ECO string, the unmasked bits are readily identified and evaluated against the requirements of the given software version. This information may be conveniently stored in a table. Table C provides exemplary comparison information listing each software version against its ECO requirements and its related ECO mask bitstring.

  TABLEC
  Software element
  134 Version	Required ECOs	Mask String
  A	First	“_XXXX”
  B	Second	“X_XXX”
  C	Fourth	“XXX_X”
  D	Fourth and Fifth	“XXX—_”

• In the mask bitstring, an “X” indicates a “don't care” value for that particular ECO for that version of the software element and a “_” indicates that the value of that ECO needs to be evaluated. The value would be either “1” or “0” to signify whether or not the ECO must or must not be applied. For the embodiment, it is preferable that the evaluated ECO must be implemented, necessitating that the field be a “1”. (In other embodiments, it may be that the evaluated ECO must not be implemented, necessitating that the field be a “0”. Known bitstring manipulation and comparison techniques may be used to address either situation.) Accordingly, for the given[0054]card100, comparing each version ofsoftware element134 against its ECO string “10110” indicates that Versions “A” and “C” may operate thereon, while Versions “B” and “D” will not operate thereon. In an embodiment, comparison information contained in Table C may be stored in an accessible location incard100, such asflash memory148. Further, the mask string for versions ofsoftware elements134 may be stored in a different section offlash memory148. Alternatively, mask bitstrings may be stored remotely to card100 and accessed when a givencard100 is being analyzed for its software and firmware compatibilities.
• Also, data extracted from comparison information (such as that provided in Table C) and the ECO information provides present and backward compatibility information of any version of a[0055]software element134 with each of the ECOs for a givencard100. This data may be processed by a procedure operating with that givencard100. In particular, the mask bitstring may be used to evaluate these compatibilities. As a particular example, for version “A” ofsoftware element134, as long as acard100 has at least the first ECO implemented thereon, then version “A” may operate on that card. Version “A” will still operate on that card whether or not any other ECOs have been implemented, as their values are “don't cares”.
• For a given[0056]card100, when a new ECO is implemented, that card may be evaluated against each existing version of thesoftware element134 to assess its compatibility therewith. Then, the information in Table C may be updated, including the mask bitstring. Similarly, when a new version ofsoftware element134 is developed, it may be assessed against the existing ECOs and then the information in Table C may be updated.
• The embodiment also enables use of the ECO information for a given[0057]card100 to compare the ECO information for that card against ECO requirements of different versions ofsoftware elements134,firmware elements138 andhardware elements128.
• The embodiment also enables the ECO information for a given[0058]card100 to be correlated against software/firmware download bundles available to that card. In particular, the ECO information for that card may be used to identify particular sets of compatible software and firmware elements for it stored in the bundles.
• Referring to FIG. 1, to illustrate the correlation, a description is provided of a bundling system related to a[0059]card100 for trackingsoftware elements134 withcompatible firmware elements138 for that card. Therein, the bundling system bundles a particular version of asoftware element134 with its compatible versions offirmware elements138. The bundling system is referred to herein as anapplication bundle146. Inapplication bundle146, for each version of asoftware element134, there is a firmware loader, which provides an interface between theapplication bundle146 and thehardware element128. The firmware loader is a software program which loads the selectedfirmware elements138 into theirrespective memory devices142. Accordingly, when theparticular software element134 is provided tomain module104, the embodiment may select the most appropriate set offirmware elements138 for thatparticular software element134. In the embodiment, eachsoftware element134 has a record, which is accessible by other elements (such as a firmware loader, described later) offirmware elements138 andhardware elements128 which will operate with it. Using bundles of versions ofsoftware elements134 with bundles of versions offirmware elements138, it is possible to separately update one version of asoftware element134 and one version of afirmware element138 for a givencard100. It will be appreciated that as a bundle, thefirmware elements138 andsoftware elements134 may be upgraded independently of each other.
• For a given[0060]card100, using the ECO string, the application bundles146 and data extracted from comparison information (such as information found in Table C), the embodiment can determine whichsoftware element134 is compatible with that card, using a similar process described above.
• Further, for any particular version of a[0061]software element134, the ECO string can be used to determine which versions of firmware elements138 (normally associated with a version of a software element) are compatible with a givencard100. In order to track compatibilities of thevarious firmware elements138, comparison table includes comparison information relating to thevarious firmware elements138 associated with a particular version of asoftware element134. Table C.1 is an exemplary representation of the comparison information which is associated with Version “A” of a particular software element134 (as described above).

  TABLE C.1
  Version of
  Firmware Element 138	Required ECOs	Mask String
  M	First only	“_XXXX”
  N	First and Third	“_X_XX”
  O	First and Fourth	“_XX_X”
  P	First, Fourth and Fifth	“_XX—_”

• As Version “A” of[0062]software element134 required the first ECO to be implemented, then versions “0” and “P” firmware element138 (which is compatible with Version “A” of software element134), must also have the first ECO implemented. This relationship is noted by having the first ECO noted as being required for each version of the firmware element136. Other specific required ECOs for a particular version of a firmware element are identified in Table C.1. All of these requirements are reflected in the mask bitstrings. It will be appreciated that the data in Tables C and C.1 may be combined in other arrangements, including having a single mask bitstring for a particular version of asoftware element134 and a particular version of afirmware element138. Further, other linking and compatibility information between various versions ofsoftware elements134 andfirmware elements138 may be provided in another section of Table C.1 (not shown).
• Referring to FIG. 3, another embodiment collects and stores information similar to information provided in Tables C and C.1 in a central location, to provide a system and method for tracking[0063]compatible software elements134 andfirmware elements138 with members of the family ofcards100. Therein,matrix300 is used to track compatibilities of ECOs of the family ofcards100 against existingfirmware elements138 andsoftware elements134.Field300A provides a marker for the version of the matrix stored for a given set ofhardware elements128. For the example, the version ofmatrix300 is “Card100Rel 1”.Matrix300 is preferably stored at a centrally accessible location, such as inflash memory148 onmain controller102. The data format ofmatrix300 may comprise any machine readable format, including an ASCII file, a spreadsheet file or a coded binary file. Accordingly,main controller102 has access to data indicating the hardware/firmware/software element compatibilities for itself and its associatedmodules104.
• In[0064]matrix300, a row entry is provided for aparticular hardware element128 incard100. Fields in the row provide information about its current set ofcompatible firmware elements138 andsoftware elements134. In describing the rows and columns ofmatrix300, first a description is provided of the relationship between ahardware element128 and itsaffected firmware elements138. Next, a description is provided of the relationship between ahardware element128 and itsaffected software elements134.
• In[0065]matrix300, for ahardware element128 listed in a row, entries in rows302identify hardware elements128 for themodule104 which affectfirmware elements138 andsoftware elements134. As an example,entries302A,302B and302C relate to a first CPU, such asCPU130A, oncard100 “CPU A”, versions “Rel 1” and “Rel 2”;entry302D related to a second CPU, such asCPU130B, “CPU B”, having “Rel 1”;entry302E relates to thecard100 itself, as “cut and strap” revisions may be made to the card itself such asmodification140.
• For the hardware/firmware element relationships, for each[0066]hardware element128 identified in row302, a list offirmware elements138 whose ability to function are affected by the upgrade to thathardware element128 is provided in entries in the corresponding set ofcolumns304. Each entry in set ofcolumns304 is a reference number and version number for a particular firmware download for the affectedfirmware element138 identifying a compatible version of that firmware element which will operate with the particular version of the hardware element in that row. Accordingly for the example in set ofcolumns304, three firmware downloads are identified relating to the first CPU. They are identified as “FirmElem1 Rel1” in column304A(1), “FirmElem2 Rel1” in column304A(2) and “FirmElem3 Rel1” in column304A(3); each firmware download is the latest version of each firmware element which is compatible with that upgraded version of thathardware element128 inentry302A.
• Entries in[0067]matrix300 indicate the compatibility levels for the ECOs with ahardware element128 and its associatedfirmware elements138, using the mask string data described earlier. Amask string306 is provided for each upgradedhardware element128 inmatrix300, in a similar fashion to the mask bitstring information provided in Tables C and C.1.
• When an ECO is made, its effect(s) on the listed[0068]software elements134 andfirmware elements138 inmatrix300 must be recognized by some manner and thenmatrix300 must be updated accordingly. For the present embodiment, newly implemented ECOs and their effect(s) onsoftware elements134 andfirmware elements138 are tracked by design personnel responsible for designing and maintaining the family ofcards100. The personnel would also be responsible for making the appropriate updates tomatrix300 and Tables C and C.1. However, once updates are made, the embodiment provides an automated system to identifyappropriate software elements134 andfirmware elements138 for a givencard100 having a given ECO history stored in itsSEEP124.
• It will be appreciated that other information relating versions of[0069]software elements134,firmware elements138 andhardware elements128 against the ECO history may be stored in other matrices in similar or other formats.
• For tracking compatibilities between ECOs and hardware/software element relationships, for each[0070]hardware element128 identified in row302, a list ofsoftware elements134 whose ability to function are affected by the upgrade to thathardware element128 is provided in entries in the corresponding set ofcolumns308. The software elements may be large sections of code, e.g. entire software elements which operate on a microprocessor, or small sections of code, e.g. software elements embodying device drivers. The number and size of software elements tracked against a hardware element may be set to the particular requirements of a trackingsystem utilizing matrix300. Each entry in set ofcolumns308 is a reference number and version number for a particular software download for the affectedsoftware element134. Accordingly for the example in set ofcolumns308, three software downloads are identified relating to the first CPU. They are identified as “SoftElem1 Rel1” in column308A(1), “SoftElem2 Rel2” in column308A(2) and “SoftElem3 Rel1” in column308A(3); each software download is the latest version of eachsoftware element134 which is compatible with that upgrade version of thathardware element128 inentry302A. For example, ifhardware element128 is a new CPU requiring anew software element134 for “SoftElem1”,new row302C is added. Entry300C provides the details of thenew hardware element128, namely “CPU130A Rel3”.HSCL field310C contains an ECO mask indicating any ECOs which must be present or not present in thecard100 in order to enable thathardware element128 with that associated set ofsoftware elements134 to operate, having similar properties as ECO strings described earlier for Tables C and C.1. Formatrix300 as an example, ECO mask forCPU130A,Rel 1 and its associated software elements is set to “1X0X”.
• It will be appreciated that the compatibility of[0071]software elements134 to a version of ahardware element128 is generally independent of the compatibility of that version of thehardware element128 to itsaffected firmware elements138. Accordingly, the values inHFCL field306 andHSCL field310 do not necessarily correlate to each other for a given version of ahardware element128.
• In addition to mapping current compatibilities with a[0072]hardware element128 and a software element, a Backward Hardware/Software Compatibility Level (BHSCL) entry infield312 provides compatibility information of ECOs between versions of hardware elements and their associated sets of software elements. For example, if a hardware element is a microprocessor and the microprocessor is upgraded to provide new functionality, a new set of software elements may be associated with the upgraded microprocessor to support the new functionality. The upgraded microprocessor and the new set of software elements would appear inmatrix300 as a new row entry. However, older software elements associated with older microprocessors may still be able to operate on the upgraded microprocessor, as long as the new functionality is not required in the system. In such a case, the BHSCL provides an indication of which ECOs are needed to operate an older set of software elements for that version of the hardware element.
• To set the BHSCL ECO string, as with the ECO strings in Tables C and C.1, design personnel must determine which versions of software can operate with the version of the hardware element identified in a particular row[0073]302. Generally, design personnel may generate a BHSCL ECO string by taking the related HSCL ECO string incolumn310 and then determine which particular ECOs in that string may be masked such that the resulting ECO string allows an older version of a software element to operate on that version of the hardware element.
• In a similar manner to the BHSCL ECO string, in another[0074]embodiment matrix300 may include backwards compatibility information of a firmware element to a version of a hardware element (not shown), i.e. a backward hardware firmware compatibility level (BHFCL) ECO string. It will be readily seen that a similar analysis of compatibilities between versions of software elements to a given hardware element would be performed for versions of firmware elements to a given hardware element to generate BHFCL ECO strings.
• The embodiment also tracks changes made to[0075]firmware elements138 andsoftware elements134 which do not affect the functionality of the existing levels ofhardware elements128. For example, a change may be made to asoftware element134 to correct an internal error which affects nothing else. To track these changes, a new version of thesoftware element134 is used. In the new matrix version, a new version value infield300A is entered and each entry for amended software element134 (or firmware element138) is updated to its new version. For example, if asoftware element138 “SoftElem3” in column308(3) is upgraded to “SoftElem3 Rev2” and the upgrade did not affect any other elements, then new software element SoftElem3 Rev2 would now appear in column308(3) of the new matrix. Also,new matrix300′ is created with identical entries tomatrix300, except that each entry for “SoftElem3” in column308(3) is changed toSoftElem3 Rev2. A similar revision tomatrix300 and its elements would be made for internal revisions made tofirmware elements138. It will be appreciated that historical data inolder matrices300 may be stored in archives.
• As an additional feature, once a compatible version of a[0076]software element134 and a compatible list of versions offirmware elements138 is determined for a card100 (using, for example, ECO information and Tables C and C.1 or matrix300) theproper software element134 andfirmware elements138 may be identified inapplication bundle148 and downloaded to the correct storage devices in thatcard100 using the firmware loader and additional interface software. If theproper software elements134 andfirmware elements138 are not available, an error message is preferably generated.
• Expanding on the present and backward compatibility evaluation of the embodiment described above, data extracted from sources such as[0077]matrix300, Tables C and C.1 and the ECO information, may also be used to identify compatible versions offirmware elements138 for acard100. In certain circumstances, it may be preferable to upgrade afirmware element138, independent of its associatedsoftware element134, or vice versa. This may occur ifcard100 has a standardized set ofsoftware elements134 installed thereon, which is not meant to be updated for the time being. Again, this data may be processed by a programmed procedure operating with thatcard100 to identify specific isolated versions of afirmware element138 or versions of asoftware element134 for thatcard100.
• An application bundle may be stored in a flash bank of[0078]memory148. In the embodiment, there is anactive flash bank148 and aninactive flash bank148. The operating firmware and software elements are stored in theactive flash bank148 and new downloads are stored in theinactive flash bank148. Once the new download is verified, the embodiment can switch between the active andinactive flash banks148.
• Referring to FIGS. 1 and 4, following is an example of an[0079]illustrative download system400 for an embodiment, which may be used in conjunction with the ECO information to determine whichapplication bundle146 should be provided tocard100.
• Therein,[0080]resource module402 is connected via acommunication link404 tomain controller104.Resource module402 comprises anapplication bundle library406, which contain a series ofapplication bundles146A . . .146N formany hardware elements128, as described earlier. Eachapplication bundle146 has onesoftware element134 associated with a set offirmware elements138. Thesame software element134 may be associated with several different sets offirmware elements138 in different bundles. The operator ofmain controller104 selects the resource module302 from which thefirmware elements138 and/orsoftware elements134 are to be downloaded. However, using embodiments described above, aparticular bundle146 may be selected from the series of bundles after appropriate comparisons are made against the ECO information for thetarget card100.Resource module402 may be a CD-ROM, and FTP site, a web server or other known data sources. Next, after a comparison is made with the ECO information and thebundles146, the operator can select theappropriate application bundle146 from theresource module402. The selected application bundle may be selected because either: (i) it has software elements134 (and/or firmware elements138) which are presently compatible with thetarget card100; or (ii) it has software elements134 (and/or firmware elements138) which are backward compatible with thetarget card100. Next, one of theflash banks148 inmodule104 which is to receive theapplication bundle146 is selected. Generally, theflash bank148 which is selected is the non-operational flash bank, i.e. the current firmware and software elements are provided from thecurrent flash bank148. The new application bundle is downloaded to the inactive flash bank.
• From the above description, it will be appreciated that the embodiment provides a centralized system for tracking ECOs for a card and for tracking compatibilities for firmware and software elements for that card.[0081]
• Other embodiments may have network repair stations which can access all of the ECO information of multiple installed cards remotely through an appropriate communication network and compare the compatibilities of several cards against compatibility information to determine which software and firmware elements can be used with each installed card. In such a system a repair station and its associated analysis device can access ECOs of installed cards in electronic devices through a communication network. For a given software upgrade, the repair station can determine whether or not the software upgrade can be applied to all or any of the installed cards. Using the accessed ECO information, the operator at the repair station can be informed of any target cards which require ECOs to be applied before the software upgrade can be applied to those cards.[0082]
• It is noted that those skilled in the art will appreciate that various modifications of detail may be made to the present embodiment, all of which would come within the scope of the invention.[0083]

Claims (15)

We claim:

1. A method of electronically tracking a history of engineering change orders (ECOs) associated with a manufactured device having at least one electronic component thereon, comprising:

storing in an electronic storage device associated with the manufactured device, the history of ECOs; and

updating the history of ECOs stored in the electronic storage device when a new ECO is implemented on the manufactured device to indicate that the new ECO was implemented on the manufactured device.

2. The method of electronically tracking a history of ECOs associated with a manufactured device, as claimed inclaim 1 wherein:

the history of ECOs is stored as a series of bits in the electronic storage device.

3. The method of electronically tracking a history of ECOs associated with a manufactured device, as claimed inclaim 2 wherein:

the electronic storage device is mounted on the manufactured device.

4. The method of electronically tracking a history of ECOs associated with a manufactured device, as claimed inclaim 3 wherein:

the history of ECOs is accessible by an analysis device connectable to the manufactured device when the manufactured device is being examined.

5. The method of electronically tracking a history of ECOs associated with a manufactured device, as claimed inclaim 4 wherein:

the manufacturing device utilizes a programmable element which is installed on the manufactured device; and

the history of ECOs of the manufactured device is compared against a version of the programmable element to determine a compatibility level between the version of the programmable element and the manufactured device.

6. The method of electronically tracking a history of ECOs associated with a manufactured device, as claimed inclaim 5 wherein

the history of ECOs of the manufactured device is used to identify compatible versions of the programmable element which may be installed on the manufactured device.

7. The method of electronically tracking a history of ECOs associated with a manufactured device, as claimed inclaim 6 wherein:

for the version of the programmable element, an ECO mask is accessed to identify only the ECOs in the ECO history which affect the compatibility level of the version of the programmable element.

8. The method of electronically tracking a history of ECOs associated with a manufactured device, as claimed inclaim 7 wherein:

the compatibility level indicates one of at least the following conditions:

(i) whether the version of the programmable element is compatible with the manufactured device;

(ii) whether the version of the programmable element is backwards compatible with the manufactured device; and

(iii) whether the version of the programmable element is not compatible with the manufactured device.

9. The method of electronically tracking a history of ECOs associated with a manufactured device, as claimed inclaim 8 wherein:

the programmable element is a software element;

the manufacturing device further utilizes a firmware element which is installed on the manufactured device; and

the history of ECOs of the manufactured device is further compared against a version of the firmware element to determine whether the version of the firmware element is compatible with the manufactured device.

10. The method of electronically tracking a history of ECOs associated with a manufactured device, as claimed inclaim 9 wherein:

versions of the software element and versions of the firmware element are provided in a bundle of installable elements, the bundle being accessible by the manufactured device.

11. The method of electronically tracking a history of ECOs associated with a manufactured device as claimed inclaim 10 wherein the analysis device is remotely connectable to the manufactured device through a communication network.

12. A system for electronically tracking a history of engineering change orders (ECOs) associated with a manufactured device having at least one electronic component thereon, comprising:

an electronic storage device associated with the manufactured device; and

ECO information associated with the electronic storage device, indicating the history of ECOs associated with the manufactured device and allowing modification thereto to indicate when a new ECO was implemented on the manufactured device.

13. The system for electronically tracking a history of ECOs associated with a manufactured device, as claimed inclaim 12, further comprising:

comparison information relating ECOs to versions of a programmable element installable on the manufactured device, indicating the compatibility of the versions with the ECOs and the manufactured device;

ECO mask information to identify the ECOs which affect the operation of the versions of the programmable element for the manufactured device; and

an analysis device having access to the ECO information, the comparison information and the ECO mask information and adapted to determine whether a version of the programmable element may operate on the manufactured device.

14. The system for electronically tracking a history of ECOs associated with a manufactured device, as claimed inclaim 13, further comprising:

second comparison information relating ECOs to versions of a firmware element which are installable on the manufactured device, indicating the compatibility of the versions of the firmware element with the ECOs and the manufactured device;

second ECO mask information to identify the ECOs which affect the operation of the versions of the firmware element for the manufactured device; and

the analysis device further utilizes the second comparison information and the second ECO mask information to determine whether a version of the firmware element may operate on the manufactured device.

15. The system for electronically tracking a history of ECOs associated with a manufactured device, as claimed inclaim 14, further comprising

a bundle of versions of the programmable element and versions of the firmware element, the bundle being accessible by the manufactured device,

wherein

the programmable element is a software element and the analysis device utilizes the comparison information, the second comparison information, the ECO mask information, the second ECO mask information and the ECO information to select a compatible version of the software element and the firmware element in the bundle to install into the manufacturing device.

Images