Search Images Maps Play YouTube News Gmail Drive More »
Sign in
Screen reader users: click this link for accessible mode. Accessible mode has the same essential features but works better with your reader.

Patents

  1. Advanced Patent Search
Publication numberUS20050257215 A1
Publication typeApplication
Application numberUS 11/051,118
Publication dateNov 17, 2005
Filing dateFeb 3, 2005
Priority dateSep 22, 1999
Also published asUS6976062
Publication number051118, 11051118, US 2005/0257215 A1, US 2005/257215 A1, US 20050257215 A1, US 20050257215A1, US 2005257215 A1, US 2005257215A1, US-A1-20050257215, US-A1-2005257215, US2005/0257215A1, US2005/257215A1, US20050257215 A1, US20050257215A1, US2005257215 A1, US2005257215A1
InventorsPhilip Denby, Douglas Hughes, Jonathan Fletcher
Original AssigneeIntermec Ip Corp.
Export CitationBiBTeX, EndNote, RefMan
External Links: USPTO, USPTO Assignment, Espacenet
Automated software upgrade utility
US 20050257215 A1
Abstract
The automated software upgrade utility allows a customer, product supplier or software vendor to upgrade the operating system, firmware, applications and data files on any product regardless of the product type and characteristics. This upgrade process can be invoked from a remote location or via interaction directly with the target device.
Images(5)
Previous page
Next page
Claims(22)
1. A system for automatically upgrading executable instructions on client devices over a network that selectively provides data communication between the system and the client devices, the system comprising:
at least one memory storing at least one version of a set of upgraded instructions selectively loadable to the client device and executable thereby; and
a server coupled to the memory and operable to execute a first set of server instructions to push the at least one version of the set of upgraded instructions to at least one of the client devices based on a current configuration of the client device, and operable to execute a second set of instructions to allow at least one of the client devices to pull the at least one version of the set of upgraded instructions to the client device based on a current configuration of the client device.
2. The system of claim 1 wherein the client device is an automatic data collection device selected from the group comprising a radio frequency identification reader, a machine-readable symbol reader; and a magnetic stripe reader.
3. The system of claim 1 wherein the current configuration of the client device is stored at the server.
4. The system of claim 1 wherein the client device periodically contacts the server to determine the availability of a specific version of the set of upgraded instruction stored in the at least one memory.
5. The system of claim 1 wherein from time to time, the server contacts the client device at a scheduled time to determine the current configuration of the client device.
6. The system of claim 1 wherein the at least one version of a set of upgraded instructions stored at the at least memory device comprises at least one of an operating system; an application; and a set of user data.
7. The system of claim 1 wherein the at least one version of a set of upgraded instructions stored at the at least memory device comprises an upgraded operating system.
8. The system of claim 1 wherein the server operable to organize a plurality of client devices into a logical group and allow for a single event to initiate at least one of a push or a pull of the set of upgraded instructions to each of the client devices in the logical group.
9. A method for automatically upgrading executable instructions on client devices, the method comprising:
storing remotely from the client devices at least two versions of client executable upgraded instructions selectively loadable to the client device and executable thereby;
communicatively coupling a server and at least one of the client devices;
operating the server in at least a first instance to push an installation of at least a first version of client executable upgraded instructions to the client device; and
operating the server in at least a second instance to allow at least one of the client devices to pull an installation of the first version of client executable upgraded instructions to the client device.
10. The method of claim 9 wherein the first instance occurs before the second instance.
11. The method of claim 9 wherein the second instance occurs before the first instance.
12. The method of claim 9, further comprising:
determining a configuration of the client device;
selecting between the at least two versions of client executable upgraded instructions based on the determined configuration of the client device.
13. The method of claim 12, further comprising:
storing the configuration of the client device at the server.
14. The method of claim 9, further comprising:
determining an availability of a specific version of client executable upgraded instructions.
15. The method of claim 9 wherein the installation of a new operating system comprises:
determining a configuration of at least one of the client devices;
archiving an application and a set of user data of the client device on the server;
providing a version of installation software of the new operating system to the client device corresponding to the configuration of the client device;
rebooting the client device;
installing a version of the archived application optimized to the new operating system on the client device; and
restoring the archived set of user data to the client device.
16. A method for automatically upgrading instructions on a client device, the client device having memory for storing instructions, the method comprising:
providing data communication between a number of client devices and a server through a network;
storing in a memory accessible by the server, a plurality of versions of client upgrade instructions selectively loadable to the client device and executable thereby;
in at least one instance pushing an installation of at least one of the versions of client upgrade instructions from the server to at least one of the client devices; and
in at least a second instance, pulling an installation of at least one of the versions of client upgrade instructions from the server to at least one of the client devices.
17. The method of claim 16, further comprising:
determining a configuration of at least one of the client devices; and
selecting one of the versions of client upgrade instructions based on the determined configuration of the at least one of the client devices before pushing or pulling an installation of at least one of the versions of client upgrade instructions from the server to at least one of the client devices.
18. The method of claim 17, further comprising:
storing a representation of the configuration of the client device at the server.
19. The method of claim 17, further comprising:
storing a representation of the configuration of the client device at the client device.
20. The method of claim 16, further comprising:
from time-to-time, the client device determining whether a specific version of client upgrade instructions is available on the server.
21. The method of claim 16 wherein storing in a memory accessible by the server, a plurality of versions of client upgrade instructions selectively loadable to the client device and executable thereby comprises storing an upgrade version of an operating system.
22. The method of claim 21, further comprising:
determining a configuration of the client device;
archiving an application and a set of user data of the client device on the server;
providing the upgrade version of the operating system to the client device corresponding to the configuration of the client device;
rebooting the client device;
installing a version of the archived application optimized to the upgraded version of the operating system on the client device; and
restoring the archived set of user data to the client device.
Description
    CROSS-REFERENCE TO RELATED APPLICATIONS
  • [0001]
    This application is a continuation of U.S. patent application Ser. No. 09/664,459, filed Sep. 18, 2000, now pending, which application is incorporated herein by reference in its entirety.
  • [0002]
    Additionally, this application claims the benefit under 35 U.S.C. 119(e) of U.S. Provisional Patent Application No. 60/155,502, filed Sep. 22, 1999, which application is incorporated herein by reference in its entirety.
  • INCORPORATION BY REFERENCE OF COMPUTER PROGRAM LISTING APPENDIX
  • [0003]
    This application herein incorporates by reference the Computer Program Listing Appendix attached hereto as CD-ROMs entitled “Philip M. Denby, Douglas L. Hughes, and Jonathan D. Fletcher, “AUTOMATED SOFTWARE UPGRADE UTILITY,” 480062.665C1, Feb. 3, 2005.” This program listing is included on a total of two (2) compact discs. Compact discs “Copy 1” and “Copy 2” are identical copies. The files located on each compact disc copy include:
      • ngextrn.h, 3/26/04, 20 KB
      • ngpblist.c, 3/25/04, 25 KB
      • upgrade.c, 3/25/04, 270 KB
      • upgrade.h, 3/25/04, 25 KB
      • upgrade.ini, 3/25/04, 2004, 20 KB
  • TECHNICAL FIELD
  • [0009]
    Embodiments of this invention relate to automatically upgrading software.
  • BACKGROUND AND SUMMARY
  • [0010]
    Automatic upgrade utilities are known in the prior art. However, prior art automatic upgrade utilities are not known to have provided firmware upgrades across an entire product line for units comprised of a plethora of different characteristics. In addition, prior art on automatic upgrade utilities are not known to operate across any network transports. Prior art on automatic upgrade utilities have rarely operated in the automatic data collection (“ADC”) device platform environment.
  • [0011]
    Many suppliers customize their products according to customer requirements. This is especially true with regard to products related to automatic data collection (“ADC”). Accordingly, the precise characteristics of the products sold by the supplier, even within a single product line, vary greatly. In the prior art, upgrades required a confusing disk swapping process and/or a direct serial connection to the device that required considerable user attention to ensure the upgrade completed successfully. Upgrades frequently consumed several hours, as each detail of the product being upgraded had to be painstakingly checked and disks constantly swapped. Moreover, an operator needed to be present to swap the diskettes. The presence of the operator often meant that during business hours the ADC device platform was unavailable for data collection while an upgrade was being accomplished. Many users were extremely reluctant to perform the installation procedure themselves because they were afraid of making mistakes and they were also concerned that they did not possess the requisite technical understanding to complete the process successfully.
  • [0012]
    The following summary lists the issues resolved by implementing the automated upgrade process:
      • Reduce the downtime of the device due to an upgrade being performed
      • Reduce inputs required from the user to eliminate operator error
      • Reduce the time required to perform an upgrade, reduce manpower required
      • Increase the odds of having the upgrade process conclude successfully
      • Allow for scheduling of the upgrade during off-hours
      • Initiate simultaneous upgrades to multiple target devices
      • Allow for grouping of devices to reduce redundant operations
      • Perform the upgrade over a network to many devices as well as over a serial connection to a single device
      • Allow for upgrades to occur from remote, centralized locations
      • Support differing scopes of upgrades via the same utility, i.e. install a patch versus install a new version of the operating system
      • Provide a single utility that can perform upgrades of a device's operating system, firmware, application and data files.
  • [0024]
    The automated software upgrade utility allows a customer, product supplier or software vendor to upgrade the operating system, firmware, applications and data files on any product regardless of the product type and characteristics. This upgrade process can be invoked from a remote location or via interaction directly with the target device.
  • [0025]
    The automated upgrade process is independent of the device hardware platform, operating system, the network transport utilized by the device, and the target device itself.
  • [0026]
    The automated software upgrade process also allows for modification of the hardware configuration of the target device, e.g., change and reformat a hard drive partition.
  • [0027]
    The automated upgrade utility may reside at remote sites, such as the user's place of business, and periodically query the product supplier for firmware upgrades. Alternatively, the upgrade utility may reside with the product supplier and periodically locate remote products and perform the upgrade process.
  • [0028]
    In both configurations, the software upgrade utility retains the ability to identify all pertinent product characteristics, freeing the developer of the firmware upgrade from concerns regarding installing the upgrade across a wide range of product characteristics and nearly endless possible configurations.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • [0029]
    FIG. 1 is a block diagram illustrating a suitable environment for aspects of the invention.
  • [0030]
    FIG. 2 is an example screen display of an example System Maintenance Menu.
  • [0031]
    FIG. 3 is an example screen display of a source inquiry dialog box.
  • [0032]
    FIG. 4 is an example screen display of a minor upgrade confirmation dialog box.
  • [0033]
    FIG. 5 is an example screen display of a major D upgrade confirmation dialog box.
  • [0034]
    FIG. 6 is an example screen display of a major C upgrade confirmation dialog box.
  • [0035]
    FIG. 7 is an example screen display of a severe upgrade confirmation dialog box.
  • DETAILED DESCRIPTION
  • [0036]
    The automated software upgrade utility enables a product supplier or software vendor to remotely upgrade the firmware on any of its products, such as automatic data collection (“ADC”) device platforms, regardless of product type or product characteristics. The upgrade utility may reside at remote sites, such as the product owner's place of business, and periodically query the product provider for firmware upgrades. Alternatively, the upgrade utility may reside with the product provider and periodically locate products at a product owner's facility and perform the upgrade process. In both configurations, the software upgrade utility retains the ability to identify all pertinent product characteristics, freeing the developer of the firmware upgrade from concerns regarding installing the upgrade across a wide range of products, each having nearly endless possible configurations. The invention is applicable for both ADC device platforms, ADC servers, and associated devices such as printers and radios.
  • [0037]
    Upgrades may be classified from minor to severe. The minor upgrades are typically small software patches that have been determined not to pose a serious problem to other functionality. In contrast, severe upgrades constitute functionality that must be carefully provided to the product so as not disrupt the product or its functionality.
  • [0038]
    The Product Supplier or Software Vendor publishes a software update, i.e., patch, upgrade or new release. The published releases can either be pushed down to the software upgrade server or they can be pulled from the published location.
  • [0039]
    Once the software upgrade utility has received the published release, it can be distributed in one of four methods. The first being, the software upgrade utility can act as a publishing location for other software upgrade servers, i.e., push the software release to other software upgrade servers or allow them to pull the latest software releases from the master software upgrade server.
  • [0040]
    The second method is to schedule jobs within the software upgrade utility to push the software release to the target device(s), data collection devices registered in IDRS, at the requested time.
  • [0041]
    The third method involves when devices initially register with IDRS for the first time. If IDRS is configured such that a specific configuration must exist on the device, and software is a component of that standard configuration, then the designated files are automatically transmitted to the target device.
  • [0042]
    The fourth method involves a device that has an outdated version of the software resident. Upon startup of the device a check is done to ensure that the correct version(s) of the applicable software is resident, if not the device initiates the request for the upgrade to be initiated.
  • [0043]
    Following are the functional requirements for the automated upgrade utility:
      • Allow upgrades or replacement of a device's operating system, firmware, application and data files from a single utility.
      • Allow for scheduling of upgrades to occur at designated scheduled times or initiated manually at any time.
      • Allow for devices to be organized into logical groups to allow for a single event to initiate upgrades for multiple devices.
      • Allow for the upgrades to be performed via a remote, centralized location as well as from the location where the devices are physically located.
      • The upgrade process must be independent of the transport network that the device is attached to.
      • The upgrade process must support both devices that exist on wired networks as well as wireless networks.
      • The upgrade process itself must not involve any user involvement once it has been initiated.
      • Software to be upgraded can originate from any location, i.e. CD-ROM, telnet to the hard disk of system running the upgrade process, retrieved from a web site or bulletin board, etc.
      • If the nature of the upgrade requires the hardware configuration of the target device to change, then this must not require user intervention. It must be fully automated as well. An example is changing the size of the hard disk partitions or changing the operating system. After the upgrade is completed, the device must be returned back to a fully functional state such that it can be used in a production environment. All configuration parameters and applications must be restored to allow this to happen.
  • [0053]
    FIG. 1 illustrates a server 100 having a firmware upgrade utility 101. The server 100 may be operated by the producer of ADC device platform, for example. The firmware upgrade utility 101 utilizes a transportation network 102 to reach a host 103. The firmware upgrade utility 101 may perform its operations using any transportation network 102. The host 103 may comprise a centralized computing facility for a purchaser of the ADC device platforms products, for example. The host 103 in turn communicates with one or more controllers 104 over a transportation network 107 that in turn communicate with one or more ADC device platforms 105 over a transportation network 108. Each controller 104 typically communicates with one or more ADC device platforms 105. The firmware upgrade utility 101 may also perform its operations using any transportation network 107 and any transportation network 108.
  • [0054]
    The upgrade utility 101 determines whether the upgrade concerns the controllers 104 and/or the ADC device platforms 105. The upgrade utility 101 locates the communications procedure for communicating with the host 103, the controllers 104, and if necessary with the ADC device platforms 105. The upgrade utility 101 then contacts the host 103 and uses resources on the host 103 to communicate with the controllers 104. For example, the host 103 may identify the type of the transportation network 107 to the upgrade utility 101. The upgrade utility 101 examines the controller 104 for its characteristics pertinent to the upgrade. Alternatively, the upgrade utility 101 may consult a database 106 that contains the characteristics of the controllers 104 and the ADC device platforms 105. The upgrade utility 101 then locates the appropriate upgrade, determines how to proceed with the upgrade given the controller's characteristics, and provides the controller 104 with the necessary upgrade. If the upgrade also applies to the ADC device platforms 105, then the upgrade utility 101 examines the ADC device platform 105 for its characteristics pertinent to the upgrade. Alternatively, the upgrade utility 101 may consult the database 106 for pertinent ADC device platform characteristics. The upgrade utility 101 then locates the appropriate upgrade, determines how to proceed with the upgrade given the ADC device platform's characteristics, and provides the ADC device platform 105 with the necessary upgrade. Finally, the upgrade utility 101 ensures that the controllers 104 and the ADC device platforms are returned to the same state they were in prior to the upgrade.
  • [0000]
    1.1. DCS Upgrade Utility
  • [0000]
    1.1.1. Purpose and use of feature
  • [0055]
    The DCS Upgrade Utility is a tool to manage the distribution of upgrade files placed on the Data Collection Server 300 (DCS 300). The DCS upgrade utility will allow the upgrade process to be started from the DCS 300, or from the ESD tool. The ESD tool can be at a remote site (remotely) or on the target DCS 300 (locally). The DCS upgrade utility will eliminate diskette swapping and prompting.
  • [0056]
    BIOS upgrades will continue to be accomplished by diskette.
  • [0057]
    There are four classifications of upgrades: Minor, Reboot, Shutdown, and Severe. A minor upgrade does not require rebooting or shutting processes down. A major C upgrade requires the DCS 300 to reboot. A major D upgrade requires some processes like data collection to shutdown. When the upgrade is finished, the stopped processes will be restarted. A severe upgrade is an upgrade that requires changing partition sizes and/or changing operating systems. This also requires the DCS 300 to reboot. If a severe upgrade is necessary, it will require an upgrade CD-ROM in the CD-ROM drive.
  • [0000]
    1.1.2. Results of Feature Usage
  • [0058]
    Previous upgrades required disk swapping and considerable user input. Sometimes the upgrade took hours. An operator needed to be present to swap diskettes. This usually meant that during business hours the controller was unavailable for data collection while an upgrade was being accomplished.
  • [0059]
    With the DCS Upgrade Utility in conjunction with the ESD tool, a DCS 300 software upgrade can be scheduled for an inactive time and doesn't require that an operator be present when the upgrade is being accomplished. The amount of time an upgrade takes to perform is also reduced. Initiating an upgrade, from the System Maintenance Menu at the DCS 300, by selecting DCS Upgrade Utility, also requires little attention. Just start the upgrade and walk away.
  • [0000]
    1.1.3. Feature Options
  • [0060]
    The upgrade can be started remotely or at a DCS 300 using the ESD tool. A start time can be chosen so the upgrade doesn't interfere with data collection. The upgrade can also be started from the System Maintenance Menu at the DCS 300 by selecting DCS Upgrade Utility.
  • [0000]
    1.1.4. Assumptions
  • [0061]
    To use the DCS Upgrade Utility, the DCS software must be at 300 ver 1.0 or greater. Or, To use the DCS Upgrade Utility, the controller must be at 0200 ver 3.0 and have the DCS Upgrade Utility installed. In this case, if the upgrade is started from the controller, “g:\upgrade\upgrade” must be entered at the command line. The DCS Upgrade Utility can be installed from ESD or from a diskette.
  • [0062]
    The upgrade files can be transferred over to the DCS 300 by ESD, or FTP without the use of a CD-ROM. The upgrade files can be transferred from an Intermec Web page to a DCS 300 with ESD. Or, the upgrade files can be transferred from an Intermec Web page to a PC. Then, ESD or FTP in the binary mode can transfer the files to the DCS 300. If the upgrade files are to reside on the DCS 300, up to 120 MegaBytes must be available on drive d: of the hard drive depending on the size of the upgrade files.
  • [0063]
    An upgrade CD-ROM must be in the CD-ROM drive or these files need to be present in the d:\upgrade directory to start the upgrade:
  • [0064]
    FILE WHEN THE NEW FILE IS COPIED
      • upgrade.exe only when the file changes
      • *.zip every upgrade
  • [0067]
    If a CD-ROM is used in the upgrade of an 0200 controller, the user will need to enable the parallel port in the BIOS at the beginning of the upgrade and disable the parallel port in the BIOS at the end of the upgrade. The DCS 0300 comes with a CD-ROM drive installed and no BIOS changes are necessary.
  • [0000]
    1.1.5. Interfaces to Initiate or Exercise the Feature
  • [0000]
    1.1.5.1. Making Upgrade Files Available to the DCS 0300
  • [0068]
    For each upgrade, new upgrade files will need to be made available to the DCS 300 before the upgrade is initiated. There are several methods to make the files available. The user can place a CD-ROM in the CD-ROM drive, or the user can put the files in the d:\upgrade directory with ESD or FTP. There are different ways to make the files available because some users do not have the capability to utilize TCP\IP and won't be able to use ESD remotely or won't be able to use FTP.
  • [0000]
    1.1.5.1.1.1.1. CD_ROM
  • [0069]
    When using a CD-ROM the user will place an Upgrade CD-ROM in the CD-ROM drive and initiate the upgrade from the System Maintenance Menu or from ESD (remotely of locally).
  • [0000]
    1.1.5.1.2. ESD Tool
  • [0070]
    When using the ESD tool remotely, the user will download a file (e.g. 300V10.zip) from an Intermec Web page to a PC. The ESD tool will unzip the file in a directory. The ESD tool will copy the upgrade files to the d:\upgrade directory on the target DCS 300. The user will then schedule the upgrade using the ESD tool. ESD will initiate the upgrade remotely at the appropriate time. To use this method, the target DCS 300 must have a LAN card installed with IP enabled.
  • [0071]
    Alternately, the user can put an upgrade CD-ROM in the CD-ROM drive at the target DCS 300 and schedule the upgrade from ESD (locally or remotely).
  • [0000]
    1.1.5.1.3. FTP
  • [0072]
    When using FTP, the user will download a file (e.g. 300V10.zip) from an Intermec Web page to a PC. The user will unzip the file in a directory. The user will login into the DCS 300 using FTP and set the binary mode. The user will change directories to d:\upgrade. Then, the user will copy all the files to the DCS 300. To use this method, the target DCS 300 must have a LAN card installed with IP enabled.
  • [0073]
    The upgrade can then be started at the DCS 300, from the System Maintenance Menu, or by ESD (remotely or locally).
  • [0000]
    1.1.5.2. Starting the DCS Upgrade Utility
  • [0074]
    An upgrade can be initiated from ESD remotely or locally or the upgrade can be started from the DCS 300 System maintenance menu.
  • [0075]
    See the ESD section for more information on initiating an upgrade from ESD.
  • [0076]
    Referring to FIG. 2, to initiate an upgrade from the DCS 300, select DCS Upgrade Utility from the System Maintenance Menu.
  • [0077]
    When DCS Upgrade Utility has been selected a box will show that asks the source of the upgrade files. FIG. 3 is an example screen display of a source inquiry dialog box. Referring to FIG. 3, after the source of the upgrade files has been entered a menu will come up and ask if the user wants to start the upgrade or cancel. Pressing start will initiate the upgrade. Pressing cancel with end the upgrade.
  • [0078]
    Different upgrades will cause the DCS Upgrade Utility to present different confirmation dialog boxes to allow the user to have a last chance to cancel the upgrade. FIGS. 4-7 illustrate different dialog boxes that the DCS Upgrade Utility displays dependent upon the severity of the upgrade. Once a Start button has been pressed on any of the dialogs of FIGS. 4-7, the upgrade cannot be stopped.
  • [0000]
    1.1.5.3. Upgrade Behavior
  • [0079]
    When the upgrade is started, a file, upgrade.ini, is extracted from the zipped up files. This file contains the parameters of the upgrade, the software version of the upgrade, and a version controller.
  • [0080]
    The version controller is a list of versions of DCS 300 software that can be upgraded to its upgrade software version. The DCS 300's software version is compared to the version controller. If the DCS 300's software version is in the list, then the upgrade will proceed. A readme.doc can be found in the same directory as the upgrade files (d:\upgrade or CD-ROM). The readme.doc file contains information on what versions of DCS 300 software the upgrade files can upgrade.
  • [0081]
    The parameter list in the upgrade.ini file controls the upgrade behavior. It controls if the DCS 300 needs to reboot, shut down various DCS 300 processes, or proceed as is. The rebooting and process control is done automatically and requires no user input.
  • [0000]
    1.1.5.4. User Interface
  • [0082]
    A user at the DCS 300 during an upgrade will see various messages at a command prompt window on the DCS 300 screen depending on the size of the upgrade.
  • [0083]
    If the upgrade is a severe upgrade, the DCS 300 will reboot to an alternate operating system. These are the messages that can show on the screen based on additional upgrade.ini parameters:
      • Backing up system files
      • Deleting partitions
      • Creating partitions
      • Formatting partitions
      • Restoring system files
      • Checking video drivers
      • Restoring configuration
  • [0091]
    In addition to these messages, the user will see a list of files being copied to the appropriate directories after the partitions are formatted.
  • [0092]
    If the upgrade is a major C upgrade, the DCS 300 will reboot to an alternate operating system. These are the messages that can show on the screen based on additional upgrade.ini parameters:
      • Backing up system files
      • Restoring system files
      • Checking video drivers
      • Restoring configuration
  • [0097]
    In addition to these messages, the user will see a list of files being copied to the appropriate directories after the system files are backed up.
  • [0098]
    If the upgrade is a major D upgrade, these are the messages that can show on command prompt window on the DCS 300 screen:
      • stopping data collection
      • starting data collection
      • shutting down the DCS 300 GUI
      • starting the DCS 300 GUI
  • [0103]
    In addition to these messages, the user will see a list of files being copied to the appropriate directories after the processes have been shut down.
  • [0104]
    If the upgrade is a minor upgrade, then all the user will see is a list of files being copied to the appropriate directories.
  • [0105]
    The ESD tool can also inquire the version of the upgrade software on the DCS 300 and the version of the DCS 300 software to make sure the upgrade will proceed normally.
  • [0106]
    The DCS upgrade Utility will behave the same when the operating system is ported to Windows NT in a future release of the DCS 300.
  • [0000]
    1.2. DCS Upgrade Utility
  • [0107]
    Currently a new upgrade kit is developed for each release. The latest was on CD-ROM. Previous upgrade kits were on diskette and took a long time to install.
  • [0108]
    With the DCS Upgrade Utility, changes to the C: drive will be zipped up into a file called os_drive.zip. Changes to the D: drive drive will be zipped up into a file called nextgen.zip. And, changes to the F: drive will be zipped up into a file called boot.zip. The upgrade files will either be and placed in the D:\upgrade directory with the ESD tool, from CD-ROM, or with FTP if the upgrade is ran from the d:\upgrade drive. If the upgrade is ran from the CD-ROM, the zip files will need to be on the CD-ROM. The upgrade can then be initiated by selecting DCS Upgrade Utility from the System Maintenance Menu, scheduled and initiated by ESD, or from the command line. The DCS Upgrade Utility will allow zipped-up files, on CD-ROM or placed in the d:\upgrade, to be exploded into the appropriate directories.
  • [0000]
    1.2.1. Making the Zip Files
  • [0109]
    One zip file for each drive will be needed. The zip file will be made with the use of a batch file. The batch file will contain all the names and directories of the files that need to be updated. A typical command in the batch file to zip a single file is “zip-a os_drive.zip c:\ibmcom\1e100t.rsp”. This line adds (-a) c:\ibmcom\1e100t.rsp to the zip file os_drive.zip. To zip the entire ibmcom directory, use this command: “zip -a -r -S os_drive.zip c:\ibmcom”. Because the files that need updated are different for each upgrade, new zip files will be needed for each
  • [0110]
    The same upgrade.ini needs to be zipped up in every zip file. For REBOOT and SEVERE upgrades a list of backup files (upgdbkup.lst) will also need to be zipped up in the zip files. This upgrade.ini is used to verify that the zip file is valid. These are the valid zip file names:
      • os_drive.zip—These are changes to the c: drive which contains the main operating system.
      • nextgen.zip—These are changes to the d: drive which contains the DCS software. The changes to the upgrade.exe should not be in here unless the upgrade is SEVERE. This is because the upgrade.exe on the d:\upgrade directory will be running if the upgrade was initiated from the d:\upgrade drive.
      • boot.zip—These are changes to the f: drive which is the alternate operating system used by SEVERE and REBOOT upgrades.
        1.2.2. Upgrade Files
  • [0114]
    This is what the directory structure should look like on the CD-ROM and in the d:\upgrade directory:
    • Volume in drive D is UNOVA
  • [0116]
    Volume Serial Number is D0AD-8D81
    Directory of D:(OR G:)\UPGRADE\
    01/01/01 12:00a  <DIR>   .
    01/01/01 12:00a  <DIR>   ..
    12/08/97 01:17p   83,418,895 OS_DRIVE.ZIP
    12/08/97 01:21p   12,131,654 NEXTGEN.ZIP
    12/08/97 01:21p   12,131,654 BOOT.ZIP
    12/08/97 01:21p   12,131,654 UPGRADE.EXE
    09/04/97 08:31a  <DIR>   SVGA
    09/04/97 08:31a  <DIR>   VGA
    09/04/97 08:31a  <DIR>   TOOLS
       7 File(s) 95,550,549 bytes
    Directory of D:(OR G:)\UPGRADE\SVGA
    09/04/97 08:31a  <DIR>   .
    01/01/01 12:00a  <DIR>   ..
    01/22/94 11:29a    23,840 BVHSVGA.DLL
    04/08/94 11:29a   123,645 IBMDEV32.DLL
    11/30/93 11:29a    38,704 IBMVGA32.DLL
    04/09/94 11:29a    77,436 VSVGA.SYS
       4 File(s)   250,549 bytes
    Directory of D:(OR G:)\UPGRADE\VGA
    09/04/97 08:31a  <DIR>   .
    01/01/01 12:00a  <DIR>   ..
    08/12/96 11:29a    32,750 BVHSVGA.DLL
    08/04/96 11:29a    82,891 IBMDEV32.DLL
    07/16/96 11:29a    34,439 IBMVGA32.DLL
    08/29/96 11:29a   147,965 VSVGA.SYS
       4 File(s)    250,549 bytes
    Directory of D:(OR G:)\UPGRADE\TOOLS
    09/04/97 08:31a  <DIR>   .
    01/01/01 12:00a  <DIR>   ..
    07/10/97 11:29a    2,149 CARD.IRQ
    06/05/97 01:58p    138,291 UNZIP.EXE
    8 File(s)  233,628 bytes
    Directory of D:(OR G:)\UPGRADE\TOOLS\CONFIG
    09/04/97 08:31a  <DIR>   .
    09/04/97 08:31a  <DIR>   ..
    09/04/97 08:31a  <DIR>   1E
    09/04/97 08:31a  <DIR>   1E100
    09/04/97 08:31a  <DIR>   1E100E
    09/04/97 08:31a  <DIR>   1E100ET
    09/04/97 08:31a  <DIR>   1E100T
    09/04/97 08:31a  <DIR>   1E1T
    09/04/97 08:31a  <DIR>   1T
    09/04/97 08:31a  <DIR>   2E
    09/04/97 08:31a  <DIR>   2E100
    09/04/97 08:31a  <DIR>   2E100T
    09/04/97 08:31a  <DIR>   2E1T
    09/04/97 08:31a  <DIR>   LAN_LESS
    09/04/97 08:31a  <DIR>   LIC_STRT
    09/04/97 08:31a  <DIR>   ONE_RF
    07/19/96 03:34p    37 STARTUP.CMD
    09/04/97 08:31a  <DIR>   TWO_RF
    09/04/97 08:31a  <DIR>   T_AX_CM2
       19 File(s)   37 bytes
    Directory of D:(OR G:)\UPGRADE\TOOLS\CONFIG\1E
    09/04/97 08:31a  <DIR>   .
    09/04/97 08:31a  <DIR>   ..
    06/04/97 08:30a    761 PROTOCOL.INI
       3 File(s)   761 bytes
    Directory of D:(OR G:)\UPGRADE\TOOLS\CONFIG\1E100
    09/04/97 08:31a  <DIR>   .
    09/04/97 08:31a  <DIR>   ..
    04/30/97 11:15a    786 PROTOCOL.INI
       3 File(s)   786 bytes
    Directory of D:(OR G:)\UPGRADE\TOOLS\CONFIG\1E100E
    09/04/97 08:31a  <DIR>   .
    09/04/97 08:31a  <DIR>   ..
    06/02/97 02:35p    983 PROTOCOL.INI
       3 File(s)   983 bytes
    Directory of D:(OR G:)\UPGRADE\TOOLS\CONFIG\1E100ET
    09/04/97 08:31a  <DIR>   .
    09/04/97 08:31a  <DIR>   ..
    06/02/97 02:22p    1,367 PROTOCOL.INI
       3 File(s)   1,367 bytes
    Directory of D:(OR G:)\UPGRADE\TOOLS\CONFIG\1E100T
    09/04/97 08:31a  <DIR>   .
    09/04/97 08:31a  <DIR>   ..
    04/30/97 11:17a    1,160 PROTOCOL.INI
       3 File(s)   1,160 bytes
    Directory of D:(OR G:)\UPGRADE\TOOLS\CONFIG\1E1T
    09/04/97 08:31a  <DIR>   .
    09/04/97 08:31a  <DIR>   ..
    06/04/97 08:31a    1,134 PROTOCOL.INI
       3 File(s)   1,134 bytes
    Directory of D:(OR G:)\UPGRADE\TOOLS\CONFIG\1T
    09/04/97 08:31a  <DIR>   .
    09/04/97 08:31a  <DIR>   ..
    05/01/96 02:07p    938 PROTOCOL.INI
       3 File(s)   938 bytes
    Directory of D:(OR G:)\UPGRADE\TOOLS\CONFIG\2E
    09/04/97 08:31a  <DIR>   .
    09/04/97 08:31a  <DIR>   ..
    06/04/97 08:31a    962 PROTOCOL.INI
       3 File(s)   962 bytes
    Directory of D:(OR G:)\UPGRADE\TOOLS\CONFIG\2E100
    09/04/97 08:31a  <DIR>   .
    09/04/97 08:31a  <DIR>   ..
    04/30/97 11:18a    1,013 PROTOCOL.INI
       3 File(s)   1,013 bytes
    Directory of D:(OR G:)\UPGRADE\TOOLS\CONFIG\2E100T
    09/04/97 08:31a  <DIR>   .
    09/04/97 08:31a  <DIR>   ..
    04/30/97 11:19a    1,393 PROTOCOL.INI
       3 File(s)   1,393 bytes
    Directory of D:(OR G:)\UPGRADE\TOOLS\CONFIG\2E1T
    09/04/97 08:31a  <DIR>   .
    09/04/97 08:31a  <DIR>   ..
    06/04/97 08:31a    1,342 PROTOCOL.INI
       3 File(s)   1,342 bytes
    Directory of D:(OR G:)\UPGRADE\TOOLS\CONFIG\LAN_LESS
    09/04/97 08:31a  <DIR>   .
    09/04/97 08:31a  <DIR>   ..
    02/28/96 11:54a    216 NGSETUP.CMD
    10/02/95 10:25a    627 PROTOCOL.INI
    02/28/96 11:54a    1,509 TCPSTART.CMD
       5 File(s)   2,352 bytes
    Directory of D:(OR G:)\UPGRADE\TOOLS\CONFIG\LIC_STRT
    09/04/97 08:31a  <DIR>   .
    09/04/97 08:31a  <DIR>   ..
    04/04/96 07:41a     17 DCMF1.LIC
    02/08/96 03:13p     17 DCMF2.LIC
    02/08/96 03:15p     17 DCMF3.LIC
    06/20/96 12:54p     17 DCML1.LIC
    04/04/96 07:42a     17 DCML2.LIC
    02/08/96 03:14p     17 DGML3.LIC
    03/21/97 07:38a    1,271 NGSYS.BAK
    06/26/97 12:54p    1,256 NGSYS.INI
    02/08/96 03:14p     17 NOLIMIT.LIC
    02/08/96 03:15p     17 NOLIMITF.LIC
       12 File(s)   2,663 bytes
    Directory of D:(OR G:)\UPGRADE\TOOLS\CONFIG\ONE_RF
    09/04/97 08:31a  <DIR>   .
    09/04/97 08:31a  <DIR>   ..
    06/02/97 02:07p    388 NET.CFG
       3 File(s)   388 bytes
    Directory of D:(OR G:)\UPGRADE\TOOLS\CONFIG\TWO_RF
    09/04/97 08:31a  <DIR>   .
    09/04/97 08:31a  <DIR>   ..
    06/02/97 02:08p    217 NET.CFG
       3 File(s)   217 bytes
    Directory of D:(OR G:)\UPGRADE\TOOLS\CONFIG\T_AX_CM2
    09/04/97 08:31a  <DIR>   .
    09/04/97 08:31a  <DIR>   ..
    11/01/95 04:43p    4,841 TWAX_CM2.CF2
    11/01/95 04:43p   28,928 TWAX_CM2.CFG
    11/01/95 04:43p    2,782 TWAX_CM2.NDF
    11/01/95 04:43p    325 TWAX_CM2.SEC
       6 File(s)  36,876 bytes
     Total Files Listed:
       126 File(s)  96,573,903 bytes
  • [0117]
    If an upgrade is to be performed from the d:\upgrade drive, and changes to this directory tree should be copied over before upgrade begins.
  • [0000]
    1.2.3. Starting the DCS Upgrade Utility
  • [0118]
    The DCS upgrade utility can be started from ESD, from the System Maintenance Menu, or from the command line. The Upgrade Utility is a stand alone application with the following command line syntax:
      • upgrade [q or s]
  • [0120]
    The qualifier “q” is optional. It is used to pre-test the upgrade to see if it will proceed normally. The “s” qualifier is used to indicate that a save and activate will be done if it is necessary. Either the “q” or “s” is used, not both at the same time.
  • [0000]
    1.2.3.1. ESD
  • [0121]
    IF ESD is used, ESD will first send a system transaction to the message handler with these one of these sets of parameters:
  • [0122]
    “d:\upgrade\upgrade /q”—The query of the upgrade started from the d: drive.
      • “g:\upgrade\upgrade /q”—The query of the upgrade started from the CD-ROM
  • [0124]
    A query will just run the phase 0 part of the upgrade and place the results in a file (upgrade.log). The results include error messages, parameters of the upgrade, the current phase of the upgrade, and the size of the disk drive. ESD will check upgrade.log for error messages. If error messages are found it will not proceed with the upgrade. If no error messages are found, ESD will send a system transaction to the message handler with these parameters:
  • [0125]
    “\f:\upgrade\upgrade”—The upgrade started from the d: drive
      • “g:\upgrade\upgrade—The upgrade started from the CD-ROM
      • “/f:\upgrade\upgrade /s”—The upgrade started from the d: drive and a save and activate will be done if necessary.
      • “/g:\upgrade\upgrade /s”—The upgrade started from the CD-ROM and a save and activate will be done if necessary
        1.2.3.2. System Maintenance Menu
  • [0129]
    When the upgrade is started from the system maintenance menu, upgrade.exe is started by 300UgradeUtil in ngpblist.c. 300UgradeUtil will prompt the user for the source of the upgrade file, then call upgrade.exe with these parameters:
      • “d:\upgrade\upgrade /q”—The query of the upgrade started from the d: drive.
      • “g:\upgrade\upgrade /q”—The query of the upgrade started from the CD-ROM
  • [0132]
    When the query is done 300UgradeUtil will parse upgrade.log for error messages. If error messages are found, a message will be displayed on a message box on the GUI and the upgrade will end. If there was no errors, upgrade.ini will be parsed again for the parameters of the upgrade, and prompt for a last chance cancel or start based on the parameters. If start is selected, 300UgradeUtil will call upgrade.exe with these parameters:
      • “\f:\upgrade\upgrade”—The upgrade started from the d: drive
      • “g:\upgrade\upgrade—The upgrade started from the CD-ROM
      • “/f:\upgrade\upgrade /s”—The upgrade started from the d: drive and a save and activate will be done if necessary.
      • “/g:\upgrade\upgrade /s”—The upgrade started from the CD-ROM and a save and activate will be done if necessary
        1.2.3.3. Command Line
  • [0137]
    When the upgrade is started from the command line, the user will enter send “f:\upgrade\upgrade” or “g:\upgrade\upgrade”. This should only be used when a 0200 Controller is upgraded to DCS 300, ver 1.0. No save and activate will be done.
  • [0000]
    1.2.4. Upgrade Control
  • [0138]
    In phase 0 of the upgrade, upgrade.ini will be extracted from each zip file. This file will contain the type of the upgrade, the subsections of the type of upgrade, the software version of the upgrade, the version level, and a version controller. The parameters will be used to select the sections of the upgrade that need to be performed. As enhancements are made to the DCS 300, and new sections to the upgrade process are identified, additional parameters can be added to this file and the upgrade executable. The upgrade.ini file is also for security. If the file cannot be extracted from a zip file then the upgrade will not proceed. An upgrade.ini file typically contains the following tags and parameter definitions:
  • [0139]
    [Version Level]
      • Version=300 x.x
  • [0141]
    [Upgrade]
      • Type={SEVERE, MINOR, REBOOT, or SHUTDOWN}
      • Version=DCS 300 x.x
  • [0144]
    [Changed_Software]
      • OS={YES or NO}
      • NEXTGEN={YES or NO}
      • SWAPPER={YES or NO}
      • BOOT={YES or NO}
      • BOOT_MANAGER={YES or NO}
  • [0150]
    [Changed_Partitions]
      • OS={YES or NO}
      • NEXTGEN={YES or NO}
      • SWAPPER={YES or NO}
      • BOOT={YES or NO}
      • BOOT_MANAGER={YES or NO}
  • [0156]
    [OS]
      • START={BOTTOM or TOP}
      • File_System={FAT or HPFS}
      • Vtype={PRIMARY or SECONDARY}
      • 540_NAME={currently 0000003f}
      • 540_SIZE={the size of the new partition}
      • 2200_NAME={e.g. 0000003f}
      • 2200_SIZE={the size of the new partition}
      • 2500_NAME={currently 0000003f}
      • 2500_SIZE={the size of the new partition}
  • [0166]
    [SWAPPER]
      • START={BOTTOM or TOP}
      • File_System={FAT or HPFS}
      • Vtype={PRIMARY or LOGICAL}
      • 540_NAME={e.g. 0000003f}
      • 540_SIZE={the size of the new partition}
      • 2200_NAME={e.g. 0000003f}
      • 2200_SIZE={the size of the new partition}
      • 2500_NAME={e.g. 0000003f}
      • 2500_SIZE={the size of the new partition}
      • Restore_START={BOTTOM or TOP}
      • Restore_File System={FAT or HPFS}
      • Restore_Vtype={PRIMARY or LOGICAL}
      • Restore540_SIZE={the size of the new partition}
      • Restore2200_SIZE={the size of the new partition}
      • Restore2500_SIZE={the size of the new partition}
  • [0182]
    [NEXTGEN]
      • START={BOTTOM or TOP}
      • File_System={FAT or HPFS}
      • Vtype={PRIMARY or SECONDARY}
      • 540_NAME={e.g. 0000003f}
      • 540_SIZE={the size of the new partition}
      • 2200_NAME={e.g. 0000003f}
      • 2200_SIZE={the size of the new partition}
      • 2500_NAME={e.g. 0000003f}
      • 2500_SIZE={the size of the new partition}
      • Restore_START={BOTTOM or TOP}
      • Restore_File_System={FAT or HPFS}
      • Restore_Vtype={PRIMARY or LOGICAL}
      • Restore540_SIZE={the size of the new partition}
      • Restore2200_SIZE={the size of the new partition}
      • Restore2500_SIZE={the size of the new partition}
  • [0198]
    [BOOT]
      • START={BOTTOM or TOP}
      • File_System={FAT or HPFS}
      • Vtype={PRIMARY or LOGICAL}
      • 540_NAME={e.g. 0000003f}
      • 540_SIZE={the size of the new partition}
      • 2200_NAME={e.g. 0000003f}
      • 2200_SIZE={the size of the new partition}
      • 2500_NAME={e.g. 0000003f}
      • 2500_SIZE={the size of the new partition}
  • [0208]
    [BOOT_MANAGER]
      • START={BOTTOM or TOP}
      • Vtype={PRIMARY or LOGICAL}
      • 540_NAME={e.g. 0000003f}
      • 2200_NAME={e.g. 0000003f}
      • 2500_NAME={e.g. 0000003f}
  • [0214]
    [Processes]
      • NextgenGui={YES or NO}
      • DataCollection={YES or NO}
      • FUU={YES or NO}
      • ViDaemon={YES or NO}
  • [0219]
    [Disk_Size]
      • Num_Cylinders540_D_Drive={e.g. 97}
      • Num_Cylinders2200_D_Drive={e.g. 97}
      • Num_Cylinders2500_D_Drive={e.g. 97}
  • [0223]
    [VIDEO_FIX]
      • Flix_Config={YES or NO}
      • Copy_Files={YES or NO}
  • [0226]
    [Version_Controller]
      • Range={0200 Ver 3.0, DCS 300 Ver x.x-y.y, z.z}
        1.2.4.1. Version Level
  • [0228]
    The version level refers to the parameters that can be stored in upgrade.ini. Upgrade.exe (Upgrade.c) contains a version level also. This version level refers to the parameters that upgrade.exe can read. The version numbers must match. When upgrade.exe is ran, it will compare the two version numbers. If the numbers don't match, the upgrade will end.
  • [0000]
    1.2.4.2. Upgrade
  • [0229]
    The Upgrade header contains the type of upgrade and the version of the upgrade. These are the types of the upgrade (upgrade.ini):
      • MINOR /* no process need to be stopped, no rebooting */
      • REBOOT /* a major upgrade of the c drive including operating system or and upgrade of running d: drive processes on a DCS 300 with OS/2*/
      • SHUTDOWN /* a major upgrade of the d drive that needs processes shut down. This will not be used until the DCS 300 is migrated to Windows NT. The DCS 300 processes should be written with PC hooks to shut down the process remotely. */
      • SEVERE /* a severe upgrade of the DCS 300 which includes repartitioning or a new operating system */
  • [0234]
    The SEVERE and SHUTDOWN upgrades will need to specify additional information (subsections) in the upgrade.ini.
  • [0000]
    1.2.4.3. Processes
  • [0235]
    The Processes header contains the processes that need to shut down. SHUTDOWN will need to specify which processes to stop, such as nextgen.exe or data collection. A NO means “don't shutdown processes” and a YES means “shutdown the process”. For all other types of upgrades this subheading is ignored.
  • [0236]
    1.2.4.4. Changed Software Changed software is only used for SEVERE and REBOOT upgrades. Changed software contains a list of the partitions that will have software updates. Changed software is used to indicate that the software in a partition has changed. For a SEVERE upgrade, If the partition size or file system will change, then, the corresponding setting here will also need to be set to YES because the software will have to be put back after the partition has been reformated.
  • [0000]
    1.2.4.5. Changed_Partitions
  • [0237]
    Changed partitions is only used for SEVERE upgrades. All other types will ignore this information. Changed Partitions contains a list of the partitions that will be changed. If the partition is set to NO, it will not be changed. If it is set to YES, it will be changed. Not all partitions will change. It is possible that only one will change (it didn't change size, it could change the file system perhaps). If the BOOT partition changed, the SWAPPER partition should also be changed. This is so the BOOT partition can change sizes. These will be set to one if data on the partition changed (files) or the partition information changed (size, file system, . . . ).
  • [0000]
    1.2.4.6. OS, SWAPPER, NEXTGEN, BOOT, BOOT_MANAGER
  • [0238]
    These headings are used only if they are set to YES in the Changed_Partitions heading. They are only used by SEVERE upgrades. All other upgrades ignore this information. The disk drive information is set here. There needs to be partition information for each partition the was set to YES in Changed_Partitions.
  • [0239]
    The START parameter indicates if the partition is to be created at the bottom or top of the free space on the disk. The current file system is HPFS. This will be changed to FAT for Windows NT. The files system type is used by fdisk when the new partition is created and by format. Vtype indicates if the partition is primary or logical. Usually the operating system is on the primary partition and is on the c: drive. The size information is used to create the partition. These numbers must be correct for the different drive sizes (540M, 2.5 Gig, and 2.2 Gig) or fdisk will return an error. The name of the drive is important to delete the partition using fdisk. The name can be found by doing a fdisk/query. This will need to be done for all three sizes of drives (540M, 2.5 Gig, and 2.2 Gig). If other sizes of disk drives are used, the information will have to be added here too. These parameters are for fdisk.
  • [0240]
    If the name of the partition is not included in the os, swapper, nextgen, or boot sections (used only if the partition was set to YES in Changed_Partitions), then the partition will not be deleted. If the size was no included the partition will not be created. And, if the file system was not specified, the partition will not be formated.
  • [0241]
    For example, for DCS 300 ver 1.0, the swapper partition will need to be deleted, and recreated at a smaller size because there will be two new partitions. For the swapper partition, since it needs to be deleted, the name of the partition will need to be included. Since it also needs to be created at a smaller size the, the size should also be included as well as the file system. The nextgen and the OS partitions will not be deleted or recreated so the size, file system, and name information for the partitions should not be included. The information on the nextgen and the OS partitions will change, so OS and NEXTGEN should be set to YES under the changed software heading in upgrade.ini. Two new partitions will be created—the boot partition and the boot manager. The names for these should not be included because they didn't exist before.
  • [0000]
    1.2.4.7. Disk_Size
  • [0242]
    Disk size is the number of cylinders in the d: partition for each of the disk sizes. If a new hard drive is added, new entries will need to be added here. Currently in the field there are 540 Meg hard drives and 2.5 Gig hard drives. Soon there will be 2.2 Gig hard drives.
  • [0000]
    1.2.4.8. Video Fix
  • [0243]
    There are currently three type of video cards out in the field. For SEVERE upgrades and reboot upgrades, config.sys will be changed when creat_ng is ran. Also, a new config.ngc might be copied over. If the files are changed, they will have to be changed to reference the correct video drivers. Fix_Config will need to be set to YES if the config.ngc or config.sys is changed. If operating system is updated or replaced, then the video driver software for the correct card will have to be copied over to the appropriate directories. Copy_Files will need to be set to YES to cause the files to be copied over.
  • [0000]
    1.2.4.9. Version_Controller
  • [0244]
    The version controller will contain the range of software that can be upgraded.
  • [0245]
    For this release it will be 0200 ver 3.0 that can be upgraded. It can be a list or a range such as 300 ver 3.0-3.3, 3.5.
  • [0000]
    1.2.4.10. Example
  • [0246]
    An example upgrade.ini file that will be used for upgrades from 0200 Ver 3.0 to DCS 300 Ver 1.0 is included in the Computer Program Listing Appendix:
  • [0247]
    The type of upgrade shown in the example upgrade.ini file is SEVERE because the upgrade needs to delete and create partitions. The only partition that will be deleted is the swapper partition. It is being deleted to make room for two more partitions. The two new partitions are the alternate boot partition (BOOT) and boot manager. The swapper partition will be recreated at a smaller size. The OS and nextgen partitions will not be deleted or recreated, but new files will be copied over.
  • [0248]
    Since the swapper, the boot, and the boot manager partitions will change size, the SWAPPER, BOOT, and BOOT_MANAGER settings under changed_partitions are set to YES.
  • [0249]
    Data for all the partitions will change, so all the values in the Changed_Software are set to YES.
  • [0250]
    For the SWAPPER section, all the information for the partition is added except the name and size of the partition for the 2.2 Gig drive because none exist out in the field.
  • [0251]
    For the BOOT section, the boot partition name is not included because no boot partition was there before so no deletion of the partition will be attempted. The delete sections of the upgrade looks for the name of the partition to delete. If the name is NULL the section will be skipped. The new partition will be created at the top (START=TOP) of the free space on the hard drive.
  • [0252]
    For the BOOT_MANAGER section, the new partition will be created at the top (START=TOP) of the free space on the hard drive. The name is not included because boot manager was not installed before.
  • [0253]
    Creat_ng will be ran, so Fix_Config under Video_Fix will be set to YES.
  • [0254]
    For the Version Controller section, controller with 0200 Ver 3.0 software can be upgraded to DCS 300 Ver 1.0.
  • [0000]
    1.2.5. Upgrade.log file
  • [0255]
    Upgrade messages will be sent to the controller screen as well as to a file, upgrade.log. At the beginning of the upgrade, a default upgrade.log will be copied over to d:\upgrade. Phase 0 messages are used by ESD and 300UgradeUtil to determine if the DCS upgrade utility will proceed without errors. This is what the default message file looks like:
    • [PHASE]
      • phase=
    • [DISK_SIZE]
      • disk_size=
    • [VIDEO_CARD]
      • VIDEO_CARD=
    • [ERROR_MESSAGES]
    • [SUCCESS_MESSAGES]
  • [0264]
    If the upgrade is SEVERE and the d: partition is to be deleted and recreated, the upgrade.log will be copied over to the f: drive befor the d: drive is deleted.
  • [0000]
    1.2.5.1. Phase heading
  • [0265]
    At the completion of each phase, the next phase to be ran is set here. There are currently six phases (0, 1, 2, 3, 4, and 5). None of the upgrades use all six phases. The MINOR upgrade only uses phase 0 and phase 5. A REBOOT upgrade uses phase 0, phase 4, and phase 5. A SEVERE upgrade uses phase 0, phase 1, phase 2, phase 3, and phase 5. A SHUTDOWN upgrade only uses phase 0 and phase 5.
  • [0000]
    1.2.5.2. Disk Size Heading
  • [0266]
    The disk size is written to upgrade.log if the upgrade is SEVERE. An IOCTL command is ran that queries the number of cylinders in drive.
  • [0000]
    1.2.5.3. Video Card Heading
  • [0267]
    This is used for SEVERE and REBOOT upgrades.
  • [0000]
    1.2.5.4. Error Messages
  • [0268]
    These are the error messages that can be put in upgrade.log in phase 0:
      • Invalid disk size
      • Invalid zip files(s)
      • The upgrade files are not compatible with the DCS upgrade utility
      • The path for the upgrade files is incorrect.
      • The upgrade.ini is incorrect.
      • Incorrect number of parameters
      • DCS 300 ver x.x can not be upgraded to DCS 300 ver y.y. You must first upgrade to DCS 300 ver z.z the use this upgrade.
  • [0276]
    These are the error messages that can be put in upgrade.log in all other phases:
      • Creat_ng failed. The error messages can be found in TBD.
      • The upgrade completed with errors
      • The upgrade could not complete
      • Error Copying files to C: Drive
      • Error Copying files to D: Drive
      • Error Copying files to F: Drive
      • Backup failure:
      • Restore failure:
      • “Could not open master system file list.
      • Restore is in progress . . .
      • Backup is in progress . . .
      • Target directory creation error.
      • ERROR—Access to drive denied
      • Could not open the migration list file.
        1.2.5.5. Success Messages
  • [0291]
    These are the success messages that can be put in upgrade.log in phase 0:
      • DCS 300 ver x.x will be upgraded to DCS 300 version y.y.
      • 0200 Controller ver 3.0 will be upgraded to DCS 300 version 1.0.
  • [0294]
    These are the success messages that can be put in upgrade.log in all other phases:
      • Successful upgrade
        1.2.6. Save and Activate
  • [0296]
    If the /s parameter was passed in, a SEVERE and REBOOT upgrade will test to see if a save and activate is necessary. If the save and activate is necessary, the new default files will be copied over. Then data collection will be stopped, CM/2 will be ran, and then LAPs will be initiated. Timers will be used to wait to wait for data collection to stop, and for CM/2 setup and LAPs to finish.
  • [0000]
    1.2.7. Assumptions
  • [0000]
    1.2.7.1. Processes that Need to be in Place for the Upgrade Utility
  • [0297]
    It is assumed that there will be a config file that contains information on the software version. This will help control upgrades because the DCS 300's software version can be compared to the version controller in the upgrade files.
  • [0298]
    For ESD to start the DCS Upgrade Utility, a new functionality needs to be added that can spawn a command line utility based on a transaction.
  • [0299]
    The GUI needs to be changed to add the DCS 300 Upgrade Utility to the menu options. If the Upgrade Utility was selected, a new procedure in ngpblist.c will start the upgrade with the query option and examine the results in upgrade.log when the query is done. If there were no error in upgrade.log, the GUI will show a last chance box based on the type of upgrade (the type of upgrade is also in upgrade.log). If START was selected, the upgrade utility will be started without the query option.
  • [0300]
    The GUI needs to be changed to continuously check to see if there is an IPC call for a quiet save and activate. The upgrade utility will need to be able to do a quiet save and avtivate without rebooting or user input. Existing procedures like ActivateCfgOK, DcStopTimer, ActivateAfterStop, CheckCmsetup, ActivateAfterCM2, CheckLapsDone, and ActivateAfterLaps and the procedures they call will need to able to accept two more input parmater (quiet, or not quiet, and no reboot, or reboot possible).
  • [0000]
    1.2.7.2. Limitations
  • [0301]
    When an upgrade to DCS 300 ver 1 from 0200 ver 3.0 is done, no save and activate will occur because the changes to the DCS software are not in place. Also, the upgrade will need to be started from the command line for the same reasons.
  • [0302]
    The SHUTDOWN type of upgrade will not be used until the DCS 300 is migrated to Windows NT. The new DCS 300 processes should be written with IPC hooks to stop them remotely.
      • Much of the previous upgrade kit (upgrade to V3.0 on CD-ROM) can be used. Changes will need to be made to the sections, though. Phases of the upgrade will be used again with the addition of the upgrade parameter list in upgrade.ini.
        1.2.8. Software Structure
        1.2.8.1. ngpblist.c
  • [0304]
    For upgrades started from the GUI, code will need to be added to ngpblist.c to add the DCS 300 Upgrade Utility. A new dialog will be created when this option is selected. Under the create event of this dialog a new function (300UgradeUtil) will be added that will prompt the user for which directory the upgrade files are in. Based upon the choice, 300UgradeUtil will call upgrade.exe with these parameters: “upgrade /d:\upgrade /q”, if “D: Drive” was selected or “upgrade /g:\upgrade /q” if the “CD-ROM” option was selected. Upgrade.exe will perform phase 0 of the upgrade and quit. Phase 0 determines if the upgrade files are valid, extracts upgrade.ini from the upgrade files, determines if the upgrade.exe is compatible with the upgrade.ini, and determines the type of upgrade. The results of phase 0 is output to upgrade.log. Then upgrade.exe ends. The CreateUpgradeUtil function spawns the upgrade.exe. It then starts a xvt_timer and for each timer event generated, calls CkUpgradeLogFile. This function looks for the update.log file and when successfully opened verifies that no errors were generated by the upgrade.exe application. If errors are present, they are presented to the user in a XVT message dialog otherwise the success message that was written to the log file is displayed. If there were no errors, and based on the type of upgrade, a last resort box will show asking if the user wants to start or cancel the upgrade.
  • [0000]
    1.2.8.1.1. Pseudo-Code for ngpblist.c
  • [0305]
    Pseudo-code for example procedures that SideButtonsMenuListOk calls for the upgrade utility are included in the Computer Program Listing Appendix in file “ngpblist.c.” These procedures include:
      • SideButtonsMenuListOK
      • CreateUgradeUtil
        1.2.8.2. UpgradeUtilok (WINDOW xdWindow)
      • This function is called when the user clicks the OK button in the DCS Upgrade Utility dialog.
  • [0309]
    If CD-ROM was selected as the source then verify a CD is in the drive.
  • [0310]
    If not display an error.
  • [0311]
    Spawn the upgrade.exe application using the /q (query) option for a parameter.
  • [0312]
    Start the xvt_timer
  • [0000]
    1.2.8.3. CkUpgradeLogFile(VOID)
  • [0313]
    This function is called when a E_TIMER event is received in the DCS Upgrade Utility dialog. Loop until a successful open is performed on the upgrade.log file or until nn timer events have be generated. If we time out, then inform the user and quit the process. After a successful open is performed, parse the upgrade.log file using the function:
    • LONG FindValue (PSZ pszFilePath, PSZ pszSection, /* “[ERROR_MESSAGES]*/PCHAR szFindString)
      • If no errors are found then parse the file again and display the messages written under the “[SUCCESS_MESSAGES]” section in a xvt_note dialog.
      • When we return from the note dialog, parse the upgrade.log file and find the type, (section=”[UPGRADE_TYPE]”).
      • Based on the type, display the appropriate dialog (see functional spec. for the different levels of upgrades.
      • If the type is MINOR or SHUTDOWN, show the user a Start or Cancel type dialog allowing the user to proceed or abort the process. Upgrade.exe is again called with no paramters.
      • IF the type is REBOOT or SEVERE, show the user a Star or Canel type dialog along with a check box to Save and Activate their current configuration.
  • [0320]
    Upgrade.exe is again called and if the Save and Activate check box is checked, then /s is passed in as a parameter to the call.
  • [0000]
    1.2.8.4. Upgrade.exe
  • [0321]
    There are six phases to the upgrade. Phase 0 tests to see if the upgrade files are valid and examines the parameters of the upgrade. Phases 1, 2, and 3 are for SEVERE upgrades only. Phases 1, 2, and 3 delete, create, and format partitions. Phase 4 reboots the DCS 300 to the f: drive if the type of upgrade is REBOOT. MINOR and SHUTDOWN upgrades will jump from phase 0 to phase 5. Phase 5 extracts the zip files.
  • [0000]
    1.2.8.4.1. Phase 0
  • [0322]
    Phase 0 does these tests for each possible zip file:
      • A check is done to see if the zip file exists (it is not an error if it does not exist)
      • If it exists the upgrade.ini is extracted from it
      • If there wasn't an upgrade.ini and error is logged to upgrade.log and the upgrade ends.
      • If there was an upgrade.inii, its version is compared to the version of upgrade.exe.
      • If the versions don't match, an error message is logged in upgrade.log and the upgrade ends.
  • [0328]
    At this point, if there is no upgrade.ini, an error message is logged to upgrade.log and the upgrade ends. If there is an upgrade.ini the version of the DCS 300 is compared to the version controller in upgrade.ini. If the DCS version doesn't fall in the range in the version controller, an error message is logged to upgrade.log and the upgrade ends. Next the type of upgrade is retrieved and logged to upgrade.log. If it is a SEVERE upgrade, the disk size is also logged to upgrade.log. If no errors have occurred, the success messages is logged to upgrade.log. The message tells the current version of the DCS 300 and the version it is being upgraded to. If the “q” parameter was used to call upgrade.exe, the upgrade will end. If the “q” parameter was not used the phase is set to the proper value and the upgrade continues. The new phase is logged in upgrade.log.
  • [0000]
    1.2.8.4.2. Phase 1 (used by SEVERE only)
  • [0329]
    The DCS 300 will do a save and activate if the /s parameter was passed in.
  • [0330]
    Phase 1 will extract upgdbkup.lst from one of the zip files and back up the users system files to the d:\upgrade directory. In phase 2 these files will be copied to the boot partition (f: drive).
  • [0331]
    If BOOT=YES was set in upgrade.ini, phase I will delete the swapper partition if the name was set in upgrade.ini. This is so the boot partition can change sizes. Next, the boot partition will be deleted if the the name was set in upgrade.ini. If the delete of the boot partition failed an error message recorded to upgrade.log. The old partition settings will be in the upgrade.ini. If the partitions were deleted successfully, the new boot partition will be created if the size is not equal to zero.
  • [0332]
    Phase 2 will be entered in the upgrade.log so that when the DCS reboots, phase two will be started.
  • [0333]
    A new config.sys and startup.cmd will be copied over the old so that when the DCS 300 reboots to the c: drive, the upgrade program will run.
  • [0334]
    Now the DCS 300 will reboot if it hasn't already.
  • [0000]
    1.2.8.4.3. Phase 2 (Used by SEVERE Only)
  • [0335]
    Phase two will format the swapper partition in the specified file system if the file system was set in upgrade.ini. If it fails, an error message will be recorded to upgrade.log and a error message will print to the screen and the upgrade will end. The DCS 300 is not functional but it is bootable to the C: drive.
  • [0336]
    If no error occur, the boot partition will be formatted in the specified file system if the file system was set in upgrade.ini. If an error occurs, an error message will be written to upgrade.log and the DCS 300 will be set up to boot up normally and the DCS will reboot to the C: drive. The DCS 300 is fully functional, but the upgrade failed. If no errors occur, boot_drive.zip will be exploded into the new drive and the backed up system files will be copied over as well as the upgrade.ini and upgrade.log files.
  • [0337]
    If errors occur during the copying, an error message will be written to upgrade.log and the DCS 300 will be set up to boot up normally and the DCS will reboot. The DCS 300 is fully functional, but the upgrade failed. If the e: drive was not deleted before, it can be now if SWAPPER=YES under the changed partitions heading in upgrade.ini. If it fails, an error message will be recorded to upgrade.log and a error message will print to the screen and the upgrade will end. The DCS 300 is fully functional.
  • [0338]
    If there was no errors and If NEXTGEN=YES under the changed partitions heading in upgrade.ini, the d: drive will now be deleted if the name was set in upgrade.ini. If it fails, an error message will be recorded to upgrade.log, the swapper partition will be recreated, an error message will print to the screen, and the upgrade will end. The DCS 300 is not functional but it is bootable to the C: drive.
  • [0339]
    If there was no errors and If OS=YES under the changed partitions heading in upgrade.ini, the c: drive will now be deleted if the was set in upgrade.ini. If it fails, an error message will be recorded to upgrade.log, an error message will print to the screen, and the upgrade will end. The DCS 300 is not functional but it is bootable to the c: drive.
  • [0340]
    If there were no errors, the deleted partitions will now be recreated through fdisk if the sizes were set in upgrade.ini. If a partition creation fails, an error message will be recorded to upgrade.log, an error message will print to the screen, and the upgrade will end. The DCS 300 is not functional and it is not bootable to the c: drive.
  • [0341]
    If no errors occur creating the partitions, the DCS will reboot to the f: drive if OS, NEXTGEN, or SWAPPER is set to YES under the changed partitions heading in upgrade.ini.
  • [0000]
    1.2.8.4.4. Phase 3 (Used by SEVERE Only)
  • [0342]
    Phase three will first format the os partition in the specified file system if the file system was set in upgrade.ini. If the format fails, an error message will be recorded to upgrade.log, an error message will print to the screen, and the upgrade will end. The DCS 300 is not functional and it is not bootable to the c: drive because there is no operating system on the c: drive. The DCS 300 was booted from the f: drive and is at a command prompt.
  • [0343]
    If there are no errors, the nextgen partition will be formatted in the specified file system if the file system was set in upgrade.ini. If the format fails, an error message will be recorded to upgrade.log, an error message will print to the screen, and the upgrade will end. The DCS 300 is not functional and it is not bootable to the c: drive because there is no operating system on the c: drive. The DCS 300 was booted from the f: drive and is at a command prompt.
  • [0344]
    If there are no errors, the swapper partition will be formatted in the specified file system if the file system was set in upgrade.ini. If the format fails, an error message will be recorded to upgrade.log, an error message will print to the screen, and the upgrade will end. The DCS 300 is not functional and it is not bootable to the c: drive because there is no operating system on the c: drive. The DCS 300 was booted from the f: drive and is at a command prompt. If there are no errors, the upgrade zip files are now ready to be exploded—increment the phase to 5 .
  • [0000]
    1.2.8.4.5. Phase 4 (Used by REBOOT Only)
  • [0345]
    The phase is set to 5 in the log file. The DCS 300 will do a save and activate if the /s parameter was passed in and if a save and activate is necessary. Now the DCS 300 will reboot.
  • [0000]
    1.2.8.4.6. Phase 5
  • [0346]
    If REBOOT was set in upgrade.ini, upgdbkup.lst will be extracted from one of the zip files. This is the list of files to be backed up and restored. The system files will be copied to the d:\upgrade\backup directory. If the backup fails, an error message will be recorded to upgrade.log, an error message will print to the screen, and the upgrade will reboot the DCS 300 to the c: drive. The DCS 300 is fully functional and operation will resume as normal except the upgrade did not complete successfully.
  • [0347]
    If the REBOOT parameter is set under the changed partitions heading in upgrade.ini, upgrade.exe will run CreatUpgradeTmpFile. This procedure will read the last successful section from ng_confg.log and copy it to a temp file to be used when creat_ng is ran. If the CreatUpgradeTmpFile fails, an error message will be recorded to upgrade.log, an error message will print to the screen, and the upgrade will reboot the DCS 300 to the c: drive. The DCS 300 is fully functional and operation will resume as normal except the upgrade did not complete successfully.
  • [0348]
    If the SHUTDOWN parameter is set under the changed partitions heading in upgrade.ini, the nextgen processes will now be stopped.
  • [0349]
    For all upgrades, the zip files will now be extracted to the appropriate drive and directories. If OS=YES under the changed_software heading in upgrade.ini, os_drive.zip will be exploded in the c: drive. If the unzip fails, an error message will be recorded to upgrade.log, an error message will print to the screen, and the upgrade will end. The DCS 300 is might or might not be functional and it might or might not be bootable. The status is unknown because the c: drive is corrupted. The DCS 300 was booted from the f: drive and is at a command prompt.
  • [0350]
    If there is no errors and NEXTGEN=YES under the changed_software heading in upgrade.ini, nextgen_drive.zip will be exploded in the d: drive. If the unzip fails, an error message will be recorded to upgrade.log, an error message will print to the screen, and the upgrade will end. The DCS 300 is might or might not be functional but it is bootable to the c: drive. The DCS 300 was booted from the f: drive and is at a command prompt.
  • [0351]
    If there is no errors and the REBOOT or SEVERE parameter is set, creat ng will be ran to restore the user configuration. If the creat_ng fails, an error message will be recorded to upgrade.log, an error message will print to the screen, and the upgrade will reboot to the c: drive and end. The DCS 300 is functional but not configured.
  • [0352]
    If there is no errors and the REBOOT or SEVERE parameter is set, the procedure systemRestore will be ran to restore the backed up system files. If the systemRestore fails, an error message will be recorded to upgrade.log, an error message will print to the screen, and the upgrade will reboot to the c: drive and end. The DCS 300 is functional but not configured fully.
  • [0353]
    If there is no errors and the REBOOT or SEVERE parameter is set, the procedure EnableTcpipInConfigSys will be ran to start TCP/IP in the config.sys if it was set before. If TcpipInConfigSys fails, an error message will be recorded to upgrade.log, an error message will print to the screen, and the upgrade will reboot to the c: drive and end. The DCS 300 is functional but not configured fully.
  • [0354]
    If there is no errors and the REBOOT or SEVERE parameter is set, the procedure HostNAMeRestore will be ran to restore the host name in config.sys. If HostNAMeRestore fails, an error message will be recorded to upgrade.log, an error message will print to the screen, and the upgrade will reboot to the c: drive and end. The DCS 300 is functional but not configured fully.
  • [0355]
    If the REBOOT or SEVERE parameter is set, the DCS 300 will now reboot to the c: drive and be ready for normal operation.
  • [0356]
    If the SHUTDOWN parameter is set, the stopped processes will now be restarted.
  • [0357]
    If there was any errors configuring the controller fully, the user will have to reconfigure the DCS 300.
  • [0000]
    1.2.8.4.7. Pseudo-Code for upgrade.c
  • [0358]
    The main body of upgrade.c calls these functions:
      • main
        • SearchAndAddStringtoFile
        • FormatPartition
        • DiskSize
        • CreatePartitions
        • IncrementPhase
        • HostNameRestore
        • FindValue
        • UpdtConfigLog
        • SystemBackup
        • SystemRestore
        • CreateUpgradeTmpFile
        • DosExecPgmWrapper
        • EnableTcpipInConfigSys
        • SaveAndActivate
        • RestoreVideoType( )
        • SaveVideoType( )
      • A copy of pseudo-code for an example “upgrade.c” file is included in the Computer Program Listing Appendix.
        1.2.8.4.8. Pseudo-Code for Upgrade.h
      • A copy of pseudo-code for an example header definition is included as file “upgrade.h” in the Computer Program Listing Appendix.
        1.2.9. Data Organization
      • Changes will be made to a SysMaintitems structure in a ngextrn.h file. A copy of pseudo-code for an example header definition is included as file “ngextm.h” in the Computer Program Listing Appendix.
Patent Citations
Cited PatentFiling datePublication dateApplicantTitle
US4527237 *Apr 14, 1983Jul 2, 1985Nanodata Computer CorporationData processing system
US4801786 *May 21, 1985Jan 31, 1989Anatoli StobbeChecking system and method for verifying checking stations in a monitoring system
US4825058 *Oct 14, 1986Apr 25, 1989Hewlett-Packard CompanyBar code reader configuration and control using a bar code menu to directly access memory
US5034598 *Dec 29, 1989Jul 23, 1991Hewlett-Packard CompanyKeyboard emulation system providing audible feedback without a built-in transducer
US5036479 *Apr 20, 1989Jul 30, 1991Trw Inc.Modular automated avionics test system
US5052020 *Jan 18, 1990Sep 24, 1991Norand CorporationMethod of and apparatus for controlling modulation of digital signals in frequency-modulated transmissions
US5121342 *Aug 28, 1989Jun 9, 1992Network Communications CorporationApparatus for analyzing communication networks
US5218188 *Oct 24, 1989Jun 8, 1993Norand CorporationCompact hand-held RF data terminal
US5261079 *Dec 18, 1990Nov 9, 1993International Business Machines CorporationInterface for keyboard emulation provided by an operating system
US5295154 *May 3, 1993Mar 15, 1994Norand CorporationRadio frequency local area network
US5309351 *Sep 2, 1992May 3, 1994Texas Instruments IncorporatedCommunications, information, maintenance diagnostic and training system
US5322991 *Feb 23, 1993Jun 21, 1994Norand CorporationCompact hand-held RF data terminal
US5349678 *Aug 21, 1991Sep 20, 1994Norand CorporationVersatile RF data capture system
US5365546 *Jul 22, 1991Nov 15, 1994Norand CorporationMethod of and apparatus for controlling modulation of digital signals in frequency-modulated transmissions
US5404493 *Nov 17, 1992Apr 4, 1995Intermec CorporationMethod and computer system for processing keycode data and symbol code data in a bar code device
US5418684 *Feb 4, 1994May 23, 1995Norand CorporationHand-held data capture system with interchangeable modules
US5425051 *Jun 30, 1994Jun 13, 1995Norand CorporationRadio frequency communication network having adaptive parameters
US5440564 *Feb 9, 1993Aug 8, 1995Motorola, Inc.Data multiplexer with simultaneous multiple channel capability
US5453933 *Sep 8, 1993Sep 26, 1995Hurco Companies, Inc.CNC control system
US5471596 *Nov 10, 1994Nov 28, 1995Digital Equipment CorporationComputer memory device holding a data structure for implementation of function objects
US5490252 *Sep 30, 1992Feb 6, 1996Bay Networks Group, Inc.System having central processor for transmitting generic packets to another processor to be altered and transmitting altered packets back to central processor for routing
US5497450 *Jan 7, 1994Mar 5, 1996Monarch Marking Systems, Inc.Universal controller interface for barcode printers
US5572512 *Jul 5, 1995Nov 5, 1996Motorola, Inc.Data routing method and apparatus for communication systems having multiple nodes
US5577229 *Dec 19, 1994Nov 19, 1996Alantec CorporationComputer system and method for pipelined transfer of data between modules utilizing a shared memory and a pipeline having a plurality of registers
US5579367 *Mar 13, 1995Nov 26, 1996Chaparral Communications, Inc.Multi-medium closed-loop controlled satellite broadcast network for simple end-user operation
US5602742 *Jan 10, 1995Feb 11, 1997Solondz; Leonard I.Postage metering system
US5604516 *Jun 30, 1994Feb 18, 1997Symbol Technologies, Inc.Graphical user interface control for providing both automatic and manual data input
US5613160 *Nov 18, 1992Mar 18, 1997Canon Kabushiki KaishaIn an interactive network board, method and apparatus for placing a network peripheral in a default configuration
US5623603 *Nov 2, 1994Apr 22, 1997Fls Acquistion CorporationMethod of transferring data at adjustable levels of priorities to provide optimum response to user demands
US5623604 *Nov 18, 1992Apr 22, 1997Canon Information Systems, Inc.Method and apparatus for remotely altering programmable firmware stored in an interactive network board coupled to a network peripheral
US5640002 *Aug 15, 1995Jun 17, 1997Ruppert; Jonathan PaulPortable RF ID tag and barcode reader
US5673385 *Jan 16, 1997Sep 30, 1997Hewlett-Packard CompanyMethod for downloading special code from a computer to a hard copy apparatus
US5724510 *Sep 6, 1996Mar 3, 1998Fluke CorporationMethod of configuring a valid IP address and detecting duplicate IP addresses in a local area network
US5742762 *May 19, 1995Apr 21, 1998Telogy Networks, Inc.Network management gateway
US5748884 *Jun 13, 1996May 5, 1998Mci CorporationAutonotification system for notifying recipients of detected events in a network environment
US5761428 *Nov 12, 1997Jun 2, 1998Ncr CorporationMethod and aparatus for providing agent capability independent from a network node
US5799317 *Nov 8, 1995Aug 25, 1998Mci Communications CorporationData management system for a telecommunications signaling system 7(SS#7)
US5857190 *Jun 27, 1996Jan 5, 1999Microsoft CorporationEvent logging system and method for logging events in a network system
US5860068 *Dec 4, 1997Jan 12, 1999Petabyte CorporationMethod and system for custom manufacture and delivery of a data product
US5893083 *Mar 19, 1996Apr 6, 1999Hewlett-Packard CompanyMethods and apparatus for monitoring events and implementing corrective action in a computer system
US5917043 *Dec 20, 1996Jun 29, 1999Smithkline Beecham Corporation4-aryl-5-pyrimidine imiazole substituted compounds
US5919248 *Mar 25, 1997Jul 6, 1999Fluke CorporationMethod and apparatus for determining network health as a function of combined percent utilization and percent collisions
US5943503 *Jan 9, 1997Aug 24, 1999Canon Kabushiki KaishaStatus-controlled interrogation of peripheral device status
US5961594 *Feb 25, 1997Oct 5, 1999International Business Machines CorporationRemote node maintenance and management method and system in communication networks using multiprotocol agents
US5969326 *Jan 14, 1998Oct 19, 1999Intermec Ip Corp.Method and apparatus of autodiscriminating in symbol reader employing prioritized and updated table of symbologies
US5974237 *Dec 18, 1996Oct 26, 1999Northern Telecom LimitedCommunications network monitoring
US5979757 *Dec 20, 1996Nov 9, 1999Symbol Technologies, Inc.Method and system for presenting item information using a portable data terminal
US6027024 *Jul 3, 1997Feb 22, 2000Metrologic Instruments, Inc.Hand-held portable WWW access terminal with visual display panel and GUI-based WWW browser program integrated with bar code symbol reader
US6028605 *Feb 3, 1998Feb 22, 2000Documentum, Inc.Multi-dimensional analysis of objects by manipulating discovered semantic properties
US6041041 *Apr 15, 1997Mar 21, 2000Ramanathan; SrinivasMethod and system for managing data service systems
US6073169 *Apr 8, 1997Jun 6, 2000Abb Power T&D Company Inc.Automatic meter reading system employing common broadcast command channel
US6094679 *Jan 16, 1998Jul 25, 2000Microsoft CorporationDistribution of software in a computer network environment
US6095422 *Aug 26, 1999Aug 1, 2000Intermec Ip Corp.Method and apparatus of autodiscriminating in symbol reader employing prioritized and updated table of symbologies
US6102295 *Jan 14, 1998Aug 15, 2000Intermec Ip Corp.Method and apparatus for decoding symbols by declaring erasures of element characteristics
US6108782 *Jun 24, 1997Aug 22, 20003Com CorporationDistributed remote monitoring (dRMON) for networks
US6119941 *May 4, 1998Sep 19, 2000Intermec Ip Corp.Automated help instructions for automatically or adaptively configuring a hand-held device, such as a bar code reader or hand-held personal computer
US6122664 *Jun 27, 1997Sep 19, 2000Bull S.A.Process for monitoring a plurality of object types of a plurality of nodes from a management node in a data processing system by distributing configured agents
US6170015 *May 15, 1998Jan 2, 2001Nortel Networks LimitedNetwork apparatus with Java co-processor
US6175868 *May 15, 1998Jan 16, 2001Nortel Networks LimitedMethod and apparatus for automatically configuring a network switch
US6178426 *Jan 15, 1998Jan 23, 2001Symbol Technologies, Inc.Apparatus with extended markup language data capture capability
US6195171 *May 10, 1996Feb 27, 2001Canon Kabushiki KaishaPrinter and interface unit, printing system, and method for setting communication parameters in printer
US6199753 *Nov 4, 1999Mar 13, 2001Symbol Technologies, Inc.Method and system for presenting item information using a portable data terminal
US6226675 *Oct 16, 1998May 1, 2001Commerce One, Inc.Participant server which process documents for commerce in trading partner networks
US6229540 *Oct 13, 1998May 8, 2001Visionael CorporationAuditing networks
US6243105 *Nov 19, 1998Jun 5, 2001Ncr CorporationDrill-down method to historical data in a performance monitor using a platform independent program
US6263387 *Oct 1, 1997Jul 17, 2001Micron Electronics, Inc.System for automatically configuring a server after hot add of a device
US6269330 *Oct 1, 1998Jul 31, 2001Attune Networks Ltd.Fault location and performance testing of communication networks
US6272537 *Nov 17, 1997Aug 7, 2001Fujitsu LimitedMethod for building element manager for a computer network element using a visual element manager builder process
US6279153 *Jan 15, 1997Aug 21, 2001Nec CorporationMulti-user flash ROM update
US6285889 *Aug 4, 1997Sep 4, 2001Nokia Mobile Phones LimitedInformation output system, method for outputting information and terminal devices for outputting information via mobile communication network
US6289501 *Mar 31, 1999Sep 11, 2001Unisys Corp.Method for generating simple document type definitions
US6305605 *Aug 9, 1999Oct 23, 2001John W. GoetzMultiple-casualty incident patient tracking
US6308205 *Oct 22, 1998Oct 23, 2001Canon Kabushiki KaishaBrowser-based network management allowing administrators to use web browser on user's workstation to view and update configuration of network devices
US6335795 *Sep 15, 1997Jan 1, 2002International Business Machines CorporationMethod for customizing print attribute choices based on selected model, media, and printer
US6356949 *Jan 29, 1999Mar 12, 2002Intermec Ip Corp.Automatic data collection device that receives data output instruction from data consumer
US6360255 *Jun 25, 1998Mar 19, 2002Cisco Technology, Inc.Automatically integrating an external network with a network management system
US6378069 *Nov 4, 1998Apr 23, 2002Nortel Networks LimitedApparatus and methods for providing software updates to devices in a communication network
US6389464 *Jun 27, 1997May 14, 2002Cornet Technology, Inc.Device management system for managing standards-compliant and non-compliant network elements using standard management protocols and a universal site server which is configurable from remote locations via internet browser technology
US6398105 *Jan 29, 1999Jun 4, 2002Intermec Ip CorporationAutomatic data collection device that intelligently switches data based on data type
US6409661 *Feb 27, 1998Jun 25, 2002Remote Diagnostic Technologies LimitedDiagnostic apparatus
US6457883 *Jun 30, 2000Oct 1, 2002Silverbrook Research Pty LtdInteractive printer reward scheme
US6460070 *Jun 3, 1998Oct 1, 2002International Business Machines CorporationMobile agents for fault diagnosis and correction in a distributed computer environment
US6473788 *Nov 15, 1996Oct 29, 2002Canon Kabushiki KaishaRemote maintenance and servicing of a network peripheral device over the world wide web
US6473798 *Dec 15, 1998Oct 29, 2002Cisco Technology, Inc.Method and system for testing a layer-2 tunnel in a data communication network
US6507856 *Jan 5, 1999Jan 14, 2003International Business Machines CorporationDynamic business process automation system using XML documents
US6539422 *May 3, 1999Mar 25, 2003Intermec Ip Corp.Automatic data collection device having a network communications capability
US6540142 *Jul 17, 2002Apr 1, 2003Zih Corp.Native XML printer
US6568596 *Oct 2, 2000May 27, 2003Symbol Technologies, Inc.XML-based barcode scanner
US6571215 *Jan 21, 1997May 27, 2003Microsoft CorporationSystem and method for generating a schedule based on resource assignments
US6587684 *Jul 28, 1998Jul 1, 2003Bell Atlantic Nynex MobileDigital wireless telephone system for downloading software to a digital telephone using wireless data link protocol
US6597465 *Apr 27, 1998Jul 22, 2003Intermec Ip Corp.Automatic mode detection and conversion system for printers and tag interrogators
US6614804 *Mar 22, 1999Sep 2, 2003Webtv Networks, Inc.Method and apparatus for remote update of clients by a server via broadcast satellite
US6618162 *Jan 26, 1999Sep 9, 2003Intermec Ip Corp.Apparatus and method to configure a device, such as a printer, over a network
US6764009 *May 30, 2002Jul 20, 2004Lightwaves Systems, Inc.Method for tagged bar code data interchange
US6857013 *Jan 29, 1999Feb 15, 2005Intermec Ip.Corp.Remote anomaly diagnosis and reconfiguration of an automatic data collection device platform over a telecommunications network
US6908034 *Jun 20, 2003Jun 21, 2005Zih Corp.XML system
US20030058469 *Sep 26, 2001Mar 27, 2003International Business Machines CorporationMethod and apparatus for printing XML directly using a formatting template
US20040040023 *Aug 22, 2002Feb 26, 2004Ellis David G.Remote identification loader
US20050034029 *Sep 3, 2004Feb 10, 2005Intermec Ip Corp.Remote anomaly diagnosis and reconfiguration of an automatic data collection device platform over a telecommunications network
Referenced by
Citing PatentFiling datePublication dateApplicantTitle
US7761864Aug 9, 2005Jul 20, 2010Intermec Ip Corp.Method, apparatus and article to load new instructions on processor based devices, for example, automatic data collection devices
US7873957 *Jul 27, 2006Jan 18, 2011Microsoft CorporationMinimizing user disruption during modification operations
US8037198 *May 18, 2009Oct 11, 2011Wyse Technology Inc.Firmware upgrade for thin clients using one or more servers
US8046755Oct 25, 2011Sap AgDeploying software based on a calculated deployment risk level
US8069369Nov 29, 2011Intermec Ip Corp.Remote anomaly diagnosis and reconfiguration of an automatic data collection device platform over a telecommunications network
US8112165 *Feb 7, 2012Abb AbMethod for evaluating, an automation system and a controller
US8138934Nov 21, 2008Mar 20, 2012Trilliant Networks, Inc.System and method for false alert filtering of event messages within a network
US8144596Nov 21, 2008Mar 27, 2012Trilliant Networks, Inc.Communication and message route optimization and messaging in a mesh network
US8171364Nov 21, 2008May 1, 2012Trilliant Networks, Inc.System and method for power outage and restoration notification in an advanced metering infrastructure network
US8207822Jun 26, 2012Microsoft CorporationSupport for batching of events, and shredding of batched events in the RFID infrastructure platform
US8225303 *Jul 17, 2012Sap AgSystem and method for providing software upgrades
US8234639 *Dec 31, 2007Jul 31, 2012International Business Machines CorporationAutonomic auto-configuration using prior installation configuration relationships
US8245219Aug 14, 2012Microsoft CorporationStandardized mechanism for firmware upgrades of RFID devices
US8271968 *Dec 12, 2006Sep 18, 2012Dell Products L.P.System and method for transparent hard disk drive update
US8289182Nov 21, 2008Oct 16, 2012Trilliant Networks, Inc.Methods and systems for virtual energy management display
US8319658Mar 11, 2010Nov 27, 2012Trilliant Networks, Inc.Process, device and system for mapping transformers to meters and locating non-technical line losses
US8332055Dec 11, 2012Trilliant Networks, Inc.Energy use control system and method
US8334787Oct 27, 2008Dec 18, 2012Trilliant Networks, Inc.Gas meter having ultra-sensitive magnetic material retrofitted onto meter dial and method for performing meter retrofit
US8370697Feb 5, 2013Trilliant Networks, Inc.System and method for power outage and restoration notification in an advanced metering infrastructure network
US8402455 *Mar 19, 2013Landis+Gyr Innovations, Inc.Methods and systems for distributing firmware through an over-the-air network
US8452860May 23, 2008May 28, 2013Microsoft CorporationRFID device groups
US8502640Nov 21, 2008Aug 6, 2013Trilliant Networks, Inc.System and method for transmitting and receiving information on a neighborhood area network
US8699377Sep 4, 2009Apr 15, 2014Trilliant Networks, Inc.System and method for implementing mesh network communications using a mesh network protocol
US8725274Nov 8, 2012May 13, 2014Trilliant Networks, Inc.Energy use control system and method
US8832428Nov 15, 2011Sep 9, 2014Trilliant Holdings Inc.System and method for securely communicating across multiple networks using a single radio
US8856323Feb 9, 2012Oct 7, 2014Trilliant Holdings, Inc.Device and method for facilitating secure communications over a cellular network
US8943493 *Nov 18, 2008Jan 27, 2015Red Hat, Inc.Automation of application deployment
US8944332Aug 3, 2007Feb 3, 2015Intermec Ip Corp.Testing automatic data collection devices, such as barcode, RFID and/or magnetic stripe readers
US8970394Jan 24, 2012Mar 3, 2015Trilliant Holdings Inc.Aggregated real-time power outages/restoration reporting (RTPOR) in a secure mesh network
US9001787Sep 19, 2012Apr 7, 2015Trilliant Networks Inc.System and method for implementing handover of a hybrid communications module
US9013173Sep 13, 2011Apr 21, 2015Trilliant Networks, Inc.Process for detecting energy theft
US9041349Mar 7, 2012May 26, 2015Trilliant Networks, Inc.System and method for managing load distribution across a power grid
US9075680 *May 18, 2009Jul 7, 2015Wyse Technology L.L.C.Firmware upgrade for thin clients using one or more servers
US9084120Aug 26, 2011Jul 14, 2015Trilliant Networks Inc.System and method for interference free operation of co-located transceivers
US9158527 *May 17, 2012Oct 13, 2015Samsung Electronics Co., Ltd.Upgrade system and method having adaptive changeable upgrade process
US9189822Oct 19, 2012Nov 17, 2015Trilliant Networks, Inc.Process, device and system for mapping transformers to meters and locating non-technical line losses
US9282383Jan 13, 2012Mar 8, 2016Trilliant IncorporatedProcess, device and system for volt/VAR optimization
US20050060530 *Sep 12, 2003Mar 17, 2005Giga-Byte Technology Co., LtdMethod for displaying information of updating BIOS
US20070157195 *Dec 30, 2005Jul 5, 2007Bettina Gaa-FrostDeploying software based on a calculated deployment risk level
US20070282983 *Jun 5, 2006Dec 6, 2007Manoj GujarathiSystem and Method for Information Handling System Management With a Directory Service Tool Box
US20080001710 *Jul 28, 2006Jan 3, 2008Microsoft CorporationSupport for batching of events, and shredding of batched events in the rfid infrastructure platform
US20080001711 *Jul 28, 2006Jan 3, 2008Microsoft CorporationReliability of execution for device provider implementations
US20080028391 *Jul 27, 2006Jan 31, 2008Microsoft CorporationMinimizing user disruption during modification operations
US20080141235 *Dec 12, 2006Jun 12, 2008Russell WoodburySystem and Method for Transparent Hard Disk Drive Update
US20080148255 *Dec 31, 2007Jun 19, 2008Ramachandran Puthukode GAutonomic auto-configuration using prior installation configuration relationships
US20080163227 *Jun 27, 2007Jul 3, 2008Samsung Electronics Co., Ltd.Server and client, and update supporting and performing methods thereof
US20080174404 *Jan 23, 2007Jul 24, 2008Microsoft CorporationDynamic updates in rfid manager
US20080184151 *Jan 25, 2007Jul 31, 2008Microsoft CorporationStandardized mechanism for firmware upgrades of rfid devices
US20080288625 *May 23, 2008Nov 20, 2008Microsoft CorporationRfid device groups
US20080319555 *Sep 2, 2008Dec 25, 2008Mikael MeyerMethod For Evaluating, An Automation System And a Controller
US20090017812 *Jul 11, 2007Jan 15, 2009Weng Chong ChanMethod and system for restoring user settings after over-the-air update of mobile electronic device software
US20090144721 *Nov 30, 2007Jun 4, 2009Sap AgSystem and method for providing software upgrades
US20090228868 *Jun 4, 2008Sep 10, 2009Max DrukmanBatch configuration of multiple target devices
US20090235246 *Mar 17, 2008Sep 17, 2009Cellnet Innovations, Inc.Methods and Systems for Distributing Firmware Through an Over-the-Air Network
US20090282128 *May 18, 2009Nov 12, 2009Wyse Technology Inc.Firmware upgrade for thin clients using one or more servers
US20090282157 *Nov 12, 2009Wyse Technology Inc.Firmware upgrade for thin clients using one or more servers
US20100125840 *Nov 18, 2008May 20, 2010Schneider James PAutomation of application deployment
US20100251232 *Mar 8, 2010Sep 30, 2010Kiyohiko ShinomiyaImage processing apparatus, software delivery system, and install processing method
US20100281474 *Nov 4, 2010Eason Patrick CFirmware updating
US20120079474 *Sep 24, 2010Mar 29, 2012Stephen GoldReimaging a multi-node storage system
US20130086231 *Apr 4, 2013Samsung Electronics Co., Ltd.Upgrade system and method having adaptive changeable upgrade process
US20130167133 *Jan 17, 2011Jun 27, 2013Zte CorporationMethod, terminal and system for upgrading software version
US20140047425 *Aug 7, 2012Feb 13, 2014Microsoft CorporationInitiating update operations
WO2009067258A1 *Nov 21, 2008May 28, 2009Trilliant Networks, Inc.Upgrade process system and method
Classifications
U.S. Classification717/172
International ClassificationG06F15/177, H04L29/08, G06F9/44, G06F9/445
Cooperative ClassificationH04L67/34, H04L67/325, G06F8/65
European ClassificationG06F8/65, H04L29/08N33, H04L29/08N31T