WO2012177597A1 - Éléments de mise en réseau utilisés en tant que plate-forme de distribution de correctifs pour domaines d'automatisation et de commande distribués - Google Patents

Éléments de mise en réseau utilisés en tant que plate-forme de distribution de correctifs pour domaines d'automatisation et de commande distribués Download PDF

Info

Publication number
WO2012177597A1
WO2012177597A1 PCT/US2012/043084 US2012043084W WO2012177597A1 WO 2012177597 A1 WO2012177597 A1 WO 2012177597A1 US 2012043084 W US2012043084 W US 2012043084W WO 2012177597 A1 WO2012177597 A1 WO 2012177597A1
Authority
WO
WIPO (PCT)
Prior art keywords
network element
patch
downstream network
downstream
software patch
Prior art date
Application number
PCT/US2012/043084
Other languages
English (en)
Inventor
Mohammad Abdullah Al Faruque
Livio Dalloro
Hartmut Ludwig
Joerg Claus
Robert Fröhlich
Ismail BUTUN
Original Assignee
Siemens Aktiengesellschaft
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens Aktiengesellschaft filed Critical Siemens Aktiengesellschaft
Publication of WO2012177597A1 publication Critical patent/WO2012177597A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates

Definitions

  • This invention relates generally to industrial and other automation systems, and more particularly to methods, systems and computer readable media for distributing software patches to automation devices and associated network elements.
  • a software patch is a piece of software code designed to fix problems with, or update, a computer program or its supporting data. Patches are typically used to add new functionality or usability features to software currently installed in a device, and to increase the performance and stability of the overall system. Patches may also be used to fix security vulnerabilities and other problems with installed software. Patches are used in any system in which software is used, including industrial control systems, building automation systems, factory automation systems and other automation systems.
  • Patch management is a system management tool for overseeing the installation of patches in a system that includes multiple devices running multiple programs.
  • patch management involves the following: system and vulnerability assessment, patch aggregation, patch testing, and distribution and installation (deployment) of multiple patches to an administered computing/control system.
  • Patch management may further include maintaining current knowledge of the available patches, deciding which patches are appropriate for each individual connected system, ensuring that patches are installed properly, post-installation testing, and documenting all the associated procedures as required by the specific configurations.
  • patch management involves the following types of patches: operating system patches, application patches and configuration update patches. Patches may be distributed in three ways: (1) patch as a source code of a program requiring re-compilation; (2) patch to the compiled binary code; and (3) patch as a complete file(s) replacement.
  • PLC Programmable Logic Controllers
  • the present invention addresses the needs described above by providing a method for distributing software patches in an automation network.
  • the automation network includes an intermediate network element, first and second downstream network elements downstream of the intermediate network element, and a first automation device downstream of the first downstream network element.
  • the software patch is copied from the second downstream network element to the first downstream network element, and is transmitted from the first downstream network element to the first automation device for installation.
  • the automation network may additionally include a second automation device downstream of the first downstream element. In that case, it is determined that a second software patch is available for second firmware installed on the second automation device, and that the second software patch is not stored on either the first or the second downstream network elements. The second software patch is then requested and received from from a patch management server, and is stored on the first downstream network element. The second software patch is transmitted from the first downstream network element to the second automation device for installation.
  • a downstream network element includes a non-transitory computer-usable medium having computer readable instructions stored thereon for execution by a processor to perform methods for distributing software patches as described above.
  • FIG. 1 is a schematic diagram of a presently used patch distribution mechanism.
  • FIG. 2 is a screen shot of a firmware update interface of a presently used patch distribution mechanism.
  • FIG. 3 is a schematic diagram of a patch distribution system in accordance with one embodiment of the invention.
  • FIG. 4 is a life cycle time sequence of a computer software patch, showing a reduction in patch distribution time in accordance with one embodiment of the invention.
  • FIG. 5 is a schematic diagram of a patch distribution system illustrating a server-router-device model in accordance with one embodiment of the invention.
  • FIG. 6 is an activity diagram of a patch distribution system in accordance with one embodiment of the invention.
  • FIG. 7 is an information flow diagram of a patch distribution system illustrating a server-router-device model in accordance with one embodiment of the invention.
  • FIG. 8 is a schematic diagram of a patch distribution system illustrating a peer-to-peer model in accordance with one embodiment of the invention.
  • FIG. 9 is a detailed sequence diagram of a patch distribution system in accordance with the invention.
  • FIG. 10 is a schematic diagram showing a computer system for instantiating a system in accordance with one embodiment of the invention.
  • the present disclosure describes a patch management system and method in which the functionality of existing network elements is exploited to achieve higher performance in terms of parallel patching of multiple devices, scalability, resiliency in terms of natural redundancy of patch files at the device locations and increased safety due to patch maintenance close to the end automation devices.
  • switch and “router” are used as examples of network elements.
  • a “network element” is any component having a processor, a memory and a network interface, that is programmed to perform one or more network operations.
  • One architecture is a switch/server construct, in which the server, such as a SINEMA Server manufactured by Siemens, is a dedicated patch management server.
  • the other architecture is a peer-to-peer solution based on network element configurations.
  • SCALANCE X may be used in the presently disclosed system as the main patch distribution platform.
  • the complete patch distribution function is thus distributed throughout the already-deployed network elements.
  • the miniaturization of transistors has facilitated higher computational power and storage capability within networking elements. It is therefore possible to perform additional computation on top of the existing routing functionalities within a router.
  • the advantages of porting part of the patch distribution functionality to the network elements level are higher performance, higher scalability, increased resiliency, and greater safety.
  • the presently described patch distribution scheme is an agent-based scheme where network elements such as switches are used as the intermediate drivers for the patch distribution to the automation devices.
  • network elements such as switches are used as the intermediate drivers for the patch distribution to the automation devices.
  • two different types of patch distribution architectures are proposed herein: a) a server- switch-device patch distribution architecture; and b) a highly distributed peer-to-peer (end-device to end-device) patch distribution architecture, in which there is no server involvement.
  • Several issues are also discussed below, including rollover file transfer protocol, scheduling constraints related to proposed patch distribution, memory issues for the networking elements, and patch distribution functionalities.
  • FIG. 1 An example of a current-technology patch distribution system, in which the control system 100 of the physical plant is connected to the Internet 105, is illustrated in FIG. 1.
  • the driver of the patch distribution system is a server 110 that is administering all the connected automation devices within the local network, such as PLCs, industrial PCs, Human Machine Interfaces (HMIs) and Motion Controllers (MCs).
  • the server 110 may, for example, be a Siemens SINEMA Server, or Siemens STEP 7 engineering system connected to a plant network such as a one using PROFIBUS communication protocol that may also initiate the patch updating.
  • the server 110 receives a notification through the Internet 105 from a vendor regarding the availability of new patches, it downloads the patches from the vendor Website to the server-specific database at the server.
  • the assigned server 110 sorts and selects the patches, and distributes them based on system configuration to each of the connected devices.
  • the patches are installed at each of the automation devices 120 sequentially from the patch management server.
  • the plant network is connected to cyberspace, it may not be possible to patch all the connected devices online because many legacy devices do not support online firmware updates.
  • firmware updates had been performed exclusively offline, which required additional steps to configure the device to use default parameters.
  • a newer version of STEP 7, version V5.5 allows for some new modules to be updated online and for the remainder of the legacy modules to be updated offline using a memory card, because those devices do not support online update.
  • the two methods to update the devices from STEP 7 V5.5 are elaborated below.
  • the screenshot 200 shown in FIG. 2 illustrates a dialog box presented by STEP 7 V5.5 for selecting the firmware file to be uploaded to a displayed target module.
  • the properties of the selected target modules that STEP 7 can identify online are displayed in a target module box 210. Those properties may include the order number, current firmware version, module name, node address and slot.
  • modules support a firmware update in redundant mode (e.g.
  • both target modules are shown as a right target module and a left target module in the target module box 210. That function is only possible with an active backplane bus in the H system. The firmware update is then automatically transferred to the redundant module.
  • Another special case for using the target module box is firmware update for H CPUs (only in HW configuration). If two CPUs (for example, CPU 417-4H) are in redundant mode, the data listed above is displayed in the target module box 210 for both CPUs (CPU in rack). After the "Run” button is clicked, a "Firmware update wizard" supports the user during the update on both H-CPUs. The update is "bump less”; in other words, the execution of the program continues.
  • a firmware file selection box 220 is provided for entering the path to the required firmware file.
  • STEP 7 can enter the path automatically via the "Find" button.
  • Up-to-date firmware can be obtained on the Internet at a vendor Web site. Once the path has been defined, the firmware version as well as a table showing the modules suitable for update with this firmware and the firmware version of these modules is shown in a lower portion of the firmware file selection box 220.
  • a checkbox 230 is provided to activate the firmware after download. An operator enables this check box to reset the module automatically after the file is loaded. The module will now operate with the new firmware. If the check box 230 is not enabled, the Old' firmware will remain active until the module is reset (e.g. after POWER OFF - POWER ON). The new firmware will not be active unless the module has been reset. [35] If the corresponding CPU is in RUN mode, activating the firmware may lead to an access error or station failure and can set the CPU to STOP. After one has enabled the check box 230, the station performs a warm restart. When operating with F I/O, for example, that has the effect that the modules are passivity and need to be deactivated subsequently. During that time the safety program cannot be executed.
  • a second STEP 7 V5.5 updating method will now be discussed, in which a new firmware version or new operating system version is transferred to a module or a CPU off-line by means of a memory card.
  • the update requires the following two steps: (1) creating an "update memory card” by transferring the update files to a memory card with the programming device or PC with an external PROM burning device (or
  • the transfer process of the updated files to a memory card includes creating a new directory, and transferring the desired update file to that directory and unzipping it there.
  • the directory will then contain the UPD file.
  • An S7 memory card is inserted into the programming device or prommer.
  • the contents of the memory card is deleted (menu command: File > S7 Memory Card > Delete in the SIMATIC Manager).
  • the PLC is then selected using the Update Operating System menu command in the SIMATIC Manager.
  • the operating system of the automation device is then updated using the programmed memory card, as follows.
  • the power supply unit for the CPU is switched off.
  • the prepared memory card with the update is then inserted into the CPU, and the power for the CPU is switched back on.
  • the operating system is then transferred from the S7 memory card to the internal FLASH EPROM. During this time, all LEDs on the CPU are lit.
  • the update is finished.
  • the STOP LED on the CPU flashes slowly, indicating a system request for memory reset.
  • the power is switched off at the power supply unit, and, where appropriate, the S7 memory card that is intended for the operation is inserted.
  • the power is then switched back on, and the CPU executes an automatic memory reset. After that, the CPU is ready for operation.
  • Another problem with the above-described current model of patch distribution is that it has a single point of failure. As most of the time only a single server is responsible for distributing the related patches to individual devices, it may be a single point of failure in critical situations. In such scenarios, the complete system may remain exposed to security vulnerabilities for an increased amount of time.
  • the above- described current model may also have safety issues. Typically, in an automation and control domain, it is preferred to keep the automation device access as close as possible to the device. In a model where a single server or only a few servers are responsible for patch distribution, the system may suffer from additional safety issues including malicious access to the automation devices during patching.
  • the presently described patch distribution model overcomes those problems, providing increased performance and scalability, by porting part of the patch distribution functionality to the network element level.
  • An illustration of a router-based patch distribution system 300 according to the present disclosure is depicted in FIG. 3.
  • Patch management servers (not shown) download from the Internet 310 patches that are required by devices in the system. Those patches are pushed to network elements such as the switches 315, 330 for storage and installation on automation devices such as device 320. Patch storage is typically at a network element along a path to the automation device, and as close as possible to the device.
  • the following sequence illustrates the operation of the system shown in
  • FIG. 3 An instance of an S7-300 device 325 that is already known to the network is attached to the system by connecting to the switch 315. That switch 315 does not have the patches for that particular device. The switch 315 therefore sends a request to the top-level switch 350 for available patches for the S7-300 device. The top-level switch 350 forwards the request for available patches to a switch 330 that already has the patches stored. The required patches are then forwarded from the switch 330 to the switch 315 to be installed on the newly connected device 325.
  • the presently described patch management system has several advantages over the state of the art. For example, the presently described system has improved performance.
  • patches are uploaded to each of the end devices in a sequential manner. That process consumes a significant amount of time.
  • a state-of-the-art patch distribution system such as that shown in FIG. 1
  • the state-of-the-art patch distribution scheme performs the following steps from the user point of view: an operator initiates uploading the patches to the first device. When the first patch uploading is finished, the operator starts uploading patches for the next device. Those steps are repeated sequentially for each of the devices. Therefore, there may be a patch distribution latency of 50X for a scheme.
  • the scheme also requires direct human interaction for patch distribution.
  • the patches are distributed over the network in a proactive and automatic way.
  • the patches are stored at downstream network elements that are either located in the automation network close to end network elements, or are themselves end network elements.
  • End network elements are network elements that are connected in an upstream direction to intermediate and higher level network elements, but have no additional network elements downstream.
  • Automation devices are connected downstream of end network elements.
  • Downstream network elements are network elements connected downstream of intermediate network elements, but there may be additional network elements downstream of the downstream network elements.
  • the described patch distribution scheme also yields higher scalability and easier integration.
  • the integration of new devices to the system will not create additional bottlenecks in the network.
  • the patches In the current patch distribution system described above, when a newly added device must be updated, the patches must be downloaded from the server. If the patch is not available at the server, it must be fetched and downloaded from a vendor server.
  • the presently described patch distribution scheme when a known device is added, it can be patched from already available patches in other network elements, as described above with reference to FIG. 3. In a large network, the probability that the required patch files may be found in a lower spatial distance is higher in the current-technology approach.
  • patches may be stored only at the end network elements of the network, such as switches or routers. Patches required to update the firmware of the switch itself will be stored at the switch level. Only pointers to the original patches need be stored at intermediate and high-level network elements, although the patches themselves may be stored there. Further, the network elements function as a caching medium for both the version information of the available patches from the patch management server side and current firmware versions at the device side, as discussed below with reference to FIG. 9. The distributed storage of the patches creates a natural redundancy that increases the overall resiliency of the control system. If the patch management server is down at a particular time and a device must be patched
  • the proposed network-element-based patch distribution scheme will provide the required solution, as patches are locally stored close to the end devices.
  • a typical patch management life cycle 400 is shown in Figure 4. After a patch is announced from the vendor, it is the responsibility of the patch distribution system of the control network to distribute the patches to the corresponding end-devices. As discussed earlier, in the state-of-the-art server-based model, it requires significant amount of time, due to the nature of sequential distribution, to distribute the patches among the end-devices. A goal of the presently described scheme is to reduce that distribution time (indicated by ellipse 410 of FIG. 4) by exploiting the computation and storage capability of the intermediate networking elements.
  • Patch management architectures may be classified into two different classes based on the existence of the software agents running on the patch
  • an agent-based patch management architecture an agent-less patch management architecture.
  • an agent-less patch management architecture There are several advantages and disadvantages for both the agent-based and the agent-less patch management architectures.
  • agent-based architecture there is a central server that can serve patch files, and an agent that is installed on the end devices to perform local tasks.
  • Agent-based patching can use either a push (interrupt) type or a pull (polling) type of patching model. Patches can be pushed as soon as they are available for deployment. Alternatively, agents can check in to pull patches at regular intervals, or during a device-side event such as a re -booting or re-joining a cyber-network.
  • Agent-based architectures can scan a large network very quickly and typically minimize the use of network bandwidth while scanning devices and vendor servers.
  • the disadvantages of an agent-based scheme include the requirement that software agents be installed, running and managing on all the participating devices. If an agent is not running due to failure or misconfiguration, the device may not be patched. Agents furthermore must have administrator or root privileges. That creates the possibility of remote attacks against agents that give attackers administrator privileges.
  • agent-less patch management architectures require no additional software to be installed on the device/client. Generally standard remote administration tools are used for that purpose. Agent-less architectures, however, are limited to pushing patches to the end-device, using an "interrupt" approach wherein patches are pushed when they arrive. Without limitation of the disclosure, an agent- based patch management architecture is used in the exemplary system described herein.
  • FIG. 5 An example of the proposed server-switch-device architecture, which uses networking elements as the patch distribution platform, is shown in FIG. 5.
  • a server 510 manages the initial part of the patch management and downloading functionality from the vendor server (not shown).
  • a SINEMA server from Siemens may be used, but the scheme is orthogonal to any server.
  • the server 510 announces a patch whenever it is downloadable.
  • An agent program is executed on a network element such as one of the switches 520, 530. The agent pulls the available patches and sorts them according to the end-device needs. Finally, agent pushes the patches to the automation devices 540, 550 and causes them to install the patches whenever they are ready.
  • At least one of the network elements 520, 530 keeps a cached copy of the patch.
  • Other network elements upstream in the network architecture may maintain pointers to the cached copies.
  • the network element closest to an automation device may manage the updating of the device firmware using the patch.
  • a detailed example activity diagram 600 of the present patch distribution scheme is presented in FIG. 6.
  • the patch distribution server initially views patch relationships at the system level (610) and determines whether a patch is required (612). If no patch is required, the flow returns to step 610. If a patch is required, then patch binaries are created (614) and patch relationships are validated at the system level (616). If the patch cannot be validated (618), then flow returns to step 610. If the patch is valid, then the server updates the patch model (620) and activates and announces the patch (622).
  • a network element such as a switch or a router, listens to the patch announcements (640) to determine whether a new patch has arrived (642). If so, then patch relationships are viewed at the automation device level (644), and determination is made whether the patch has been requested (646). If so, then the patch is downloaded (648) and the patch relationships are validated at the automation device level (650). If the patch is valid (652) then it is transmitted to the automation device.
  • the system is then checked for stability and consistency (684). If the system is stable (686), then the device is restarted (692), if required. Device restart may be triggered by the network element. If the system is not stable, then the system is restored using the backup files (688), and the instability is logged and reported to an administrator (690) before the device is restarted (692).
  • FIG. 7 A diagram of the server-switch-device patch distribution architecture 700 is presented in FIG. 7.
  • the end network element or switch 720 "pulls" patches and patch information from the server 710, and "pushes” patches to the automation device 730.
  • the patch distribution scheme of the present disclosure may also utilize a peer-to-peer patch distribution architecture 800, shown in FIG. 8.
  • patch distribution is deployed to the network elements 810.
  • network elements are connected peer to peer, and there is no dedicated server.
  • an agent program is executed at the network elements 810.
  • the network elements share the downloaded patches.
  • a mechanism similar to the push-pull mechanism of the previous model is also applicable to the peer- to-peer model.
  • a major difference in the peer-to-peer model is that patches are pulled from vendor servers through the Internet and/or peers 820 rather than through a dedicated server.
  • a detailed sequence diagram 900 for the presently disclosed patch management system is shown in FIG. 9.
  • Major sequences performed by the system are shown in separate sections 920-950 of the sequence diagram 900.
  • Current version extraction 920 gathers the current version information of firmware installed in the automation devices. The sequence is initiated by the patch management server 910, which requests information about the operating system, applications and configuration versions of the devices. That request is relayed by a downstream network element or switch 914 to the automation device 916. The device 916 replies by providing information about the firmware installed. The downstream switch 914 and/or the intermediate switch 912 store or cache the information related to the installed version, and forward it to the patch management server 910. Some devices do not provide information about the installed firmware version. In those cases, the end network elements gather that information from the patch management server, or extract the information from a log file of the previous version installed on the device 916.
  • the "available patch info" sequence 925 provides the up-to-date available patch version to downstream network elements close to the automation device 916.
  • Available patch information is provided by the server 910 to an intermediate switch 912 as a catalog of available relevant patches.
  • the intermediate switch 912 then provides a refined subset of the available patches to the switch 914 close to the device 916.
  • An intermediate switch 912 forwards the request to the patch management server 910.
  • the patch management server 910 downloads the patches from a vendor server, validates the downloaded patches, and forwards them through the intermediate switch 912 to the switch 914. Only those patches for firmware in devices close to a particular switch are forwarded to that switch.
  • the downstream switch stores the patch and confirms successful downloading of the patch. No patch file is stored at the intermediate switches. Instead, the intermediate switches keep pointers to the locations of the patch files downstream in the topology.
  • Patch updating 935 to the devices 916 is initiated by a downstream switch
  • the device 914 which transmits the patch to the device 916.
  • the device then provides the switch 914 with feedback regarding successful transfer of the patch to the device.
  • the device 916 then transfers to the switch 914 image files for those files that will be updated with the patch. If the device updates are not successful, then the device 916 uses the image files stored on the downstream switch 914 to roll back to the previous state. If the update is successful, then the switch 914 is notified, and a re-start of the device 916 from the switch 914 is performed, if necessary.
  • the switch 914 uploads the backup image files to the device 916, which restores its firmware using the image files. The device then confirms the successful rollback.
  • the system additionally handles the attachment 950 of a new device 916 in the automation network at a point close to a downstream switch 914. In that case, the new device requests a new patch from the switch 914. If the switch does not have the required patch, it forwards the request upstream in the topology. If the patch is not present in the network, then the patch management server downloads the patch from a vendor server and transmits the patch through the network to the switch 914 in a manner similar to that described above with reference to patch uploading 930. It is possible, however, that the patch is stored at another downstream switch in the network. If that is so, then a pointer to that patch will be stored on one of the intermediate switches or on the patch management server. The pointer is used to locate the patch at the other server, and the patch is then transmitted from other downstream switch to the downstream switch 914.
  • the proposed patch distribution scheme reduces the cost to the company in terms of automatic patching, because no physical transportation of new patches from one plant to another plant is required.
  • heterogeneous file transfer protocols are necessary.
  • One example of such a protocol is Trivial File Transfer Protocol (TFTP).
  • TFTP Trivial File Transfer Protocol
  • TFTP Trivial File Transfer Protocol
  • patches are stored at network elements close to the devices to patch the connected devices. Intermediate network devices may hold only pointers to the existence of the available patches downstream in the topology. In practice, network elements may also need to be patched. To solve that particular problem, there are two options: (1) storing the patch files in the network elements that must be patched; and (2) driving the patches from the next-highest level network elements.
  • the first option in which the patch files for network elements are stored in the network elements themselves, is actually a peer-to-peer patch distribution architecture.
  • the peer-to-peer patch distribution architecture there is no server involvement; therefore, keeping the patch files at each network element will provide higher performance in terms of locality.
  • the patch files required to update the software/firmware of a network element are kept within the element itself.
  • the server-switch-device patch distribution architecture it must be assumed that the network element will be a hotspot in terms communication, patch storage, and distribution; therefore, due to safety and performance reasons it may be advantageous to keep the required patch files for the network elements within themselves.
  • FIG. 10 An exemplary automation network system 1000 is shown in FIG. 10.
  • a patch distribution server 1010, an intermediate network element 1020, an end network element 1030 and an automation device 1040 are linked in a topology wherein the automation device 1040 is in a downstream location and the intermediate network element 1020 is in an upstream location.
  • the patch distribution server 1010 is shown upstream of the intermediate network elementl 020, but may be placed elsewhere in the network.
  • Actual implementations of the system 100 typically include multiple automation devices 1040 connected to a single end network element 1030, multiple end network elements 1030 connected to a single intermediate network element 1020, etc.
  • the patch distribution sever 1010 may be a commercial automation server, mainframe computer, a desktop or laptop computer or any other device capable of processing data.
  • the intermediate network element 1020 and the end network element 1030 may be routers, switches or any other network elements capable of communicating, processing and storing data.
  • the automation device 1040 may be a programmable logic controller, an industrial PC, a CNC controller, a building automation controller, or any building, process or machine controller that requires firmware updates.
  • the patch distribution server 1010 receives data from any number of data sources that may be connected, including a wide area data network (WAN) 1050 such as the Internet.
  • WAN wide area data network
  • Each of the elements 1010, 1020, 1030, 1040 includes a central processing unit (CPU) 1012 and a memory 1014.
  • One or more of the elements may be connected to an input and/or output device such as a personal computer 1048 capable of transmitting and receiving information to and from the element.
  • the input may be a mouse, network interface, touch screen, etc.
  • the output may be a liquid crystal display (LCD), cathode ray tube (CRT) display, printer, etc.
  • commands containing input/output data may be passed via the automation network 1000 and the network 1050.
  • the elements 1010, 1020, 1030, 1040 can be configured to operate and display information by using, e.g., the input and output devices to execute certain tasks.
  • the CPUs 1012 when configured using software according to the present disclosure, include modules that are configured for performing one or more methods for patch distribution as discussed herein.
  • the memory 1014 may include a random access memory (RAM) and a read-only memory (ROM).
  • the memory may also include removable media such as a disk drive, tape drive, memory card, etc., or a combination thereof.
  • the RAM functions as a data memory that stores data used during execution of programs in the CPU 1012; the RAM is also used as a work area.
  • the ROM functions as a program memory for storing a program executed in the CPU 1012.
  • the program may reside on the ROM or on any other tangible or non-volatile computer-usable medium as computer readable instructions stored thereon for execution by the CPU or another processor to perform the methods of the invention.
  • the ROM may also contain data for use by the program or other programs.
  • program modules include routines, objects, components, data structures and the like that perform particular tasks or implement particular abstract data types.
  • program as used herein may connote a single program module or multiple program modules acting in concert.
  • the disclosure may be implemented on a variety of types of computers, including programmable logic controllers, personal computers (PCs), hand-held devices, multiprocessor systems, microprocessor-based programmable consumer electronics, network PCs, mini-computers, mainframe computers and the like.
  • the disclosure may also be employed in distributed computing environments, where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, modules may be located in both local and remote memory storage devices.
  • An exemplary processing module for implementing the methodology above may be hardwired or stored in a separate memory that is read into a main memory of a processor or a plurality of processors from a computer readable medium such as a ROM or other type of hard magnetic drive, optical storage, tape or flash memory.
  • a computer readable medium such as a ROM or other type of hard magnetic drive, optical storage, tape or flash memory.
  • execution of sequences of instructions in the module causes the processor to perform the process steps described herein.
  • the embodiments of the present disclosure are not limited to any specific combination of hardware and software and the computer program code required to implement the foregoing can be developed by a person of ordinary skill in the art.
  • a computer-readable medium refers to any tangible machine-encoded medium that provides or participates in providing instructions to one or more processors.
  • a computer-readable medium may be one or more optical or magnetic memory disks, flash drives and cards, a read-only memory or a random access memory such as a DRAM, which typically constitutes the main memory.
  • Such media excludes propagated signals, which are not tangible. Cached information is considered to be stored on a computer-readable medium.
  • Common expedients of computer-readable media are well-known in the art and need not be described in detail here.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

L'invention concerne un système de gestion de correctifs et un procédé permettant d'augmenter la performance, l'extensibilité, la résilience et la sécurité par le déploiement de la partie principale de la distribution de correctifs au moyen de la puissance de calcul existante des éléments de mise en réseau, tels que des commutateurs ou des routeurs au niveau de l'emplacement d'une installation. La fonction de gestion de correctifs dans un réseau d'automatisation est décentralisée et décalée en aval, à une position plus proche des dispositifs d'automatisation. Les correctifs sont distribués dans une topologie pair-à-pair ou une topologie serveur-routeur-dispositif.
PCT/US2012/043084 2011-06-24 2012-06-19 Éléments de mise en réseau utilisés en tant que plate-forme de distribution de correctifs pour domaines d'automatisation et de commande distribués WO2012177597A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201161500800P 2011-06-24 2011-06-24
US61/500,800 2011-06-24

Publications (1)

Publication Number Publication Date
WO2012177597A1 true WO2012177597A1 (fr) 2012-12-27

Family

ID=46420549

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2012/043084 WO2012177597A1 (fr) 2011-06-24 2012-06-19 Éléments de mise en réseau utilisés en tant que plate-forme de distribution de correctifs pour domaines d'automatisation et de commande distribués

Country Status (1)

Country Link
WO (1) WO2012177597A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200293660A1 (en) * 2017-11-30 2020-09-17 Abb Schweiz Ag Update of gateway in substation
US20230168878A1 (en) * 2021-11-29 2023-06-01 Trane International Inc. Method and apparatus for maintaining software of a control unit for an industrial control system

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080028046A1 (en) * 2006-07-26 2008-01-31 Fujitsu Limited Program distributing apparatus and program distributing system

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080028046A1 (en) * 2006-07-26 2008-01-31 Fujitsu Limited Program distributing apparatus and program distributing system

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200293660A1 (en) * 2017-11-30 2020-09-17 Abb Schweiz Ag Update of gateway in substation
US11615189B2 (en) * 2017-11-30 2023-03-28 Abb Schweiz Ag Update of gateway in substation
US20230168878A1 (en) * 2021-11-29 2023-06-01 Trane International Inc. Method and apparatus for maintaining software of a control unit for an industrial control system
US11726766B2 (en) * 2021-11-29 2023-08-15 Trane International Inc. Method and apparatus for maintaining software of a control unit for an industrial control system

Similar Documents

Publication Publication Date Title
KR102443172B1 (ko) 멀티테넌트 어플리케이션 서버 환경에서 패치를 지원하는 시스템 및 방법
US9442813B2 (en) Replaying jobs at a secondary location of a service
EP2354875B1 (fr) Échange de ressources de données de poste à poste dans un système de contrôle
US9250672B2 (en) Cloning target machines in a software provisioning environment
US7698391B2 (en) Performing a provisioning operation associated with a software application on a subset of the nodes on which the software application is to operate
WO2016095537A1 (fr) Procédé, dispositif et système de gestion de mise à niveau d'élément de réseau
US20130117441A1 (en) Upgrading enterprise managers
US20160092197A1 (en) Circular buffer of software versions
EP2817725B1 (fr) Maintenance d'images de micrologiciel système à distance au moyen d'un protocole de système de fichiers distribués
JP7345921B2 (ja) マスタースレーブアーキテクチャのｏｔａ差分更新方法とシステム
US9043779B2 (en) Loading remote binaries onto a write-protected device
JP6028851B2 (ja) 情報処理装置、プログラム更新方法、及びプログラム
CN116820493A (zh) 一种镜像文件部署方法、系统、设备及存储介质
US20200358648A1 (en) Continuous monitoring of network devices during maintenance
US11176002B2 (en) Methods, apparatuses and systems for cloud-based disaster recovery
WO2012177597A1 (fr) Éléments de mise en réseau utilisés en tant que plate-forme de distribution de correctifs pour domaines d'automatisation et de commande distribués
US11178221B2 (en) Methods, apparatuses and systems for cloud-based disaster recovery
EP3734445A1 (fr) Mise à jour à distance sécurisée et fiable d'un dispositif de commande dans un ascenseur
CN108170439B (zh) 用于管理多个分布式服务器上的机器镜像的系统和方法
JP4882291B2 (ja) モジュール更新プログラム
JP5670935B2 (ja) 分散データ管理システムおよびその動作方法
CN113872808B (zh) 应用处理方法及装置
US20240036852A1 (en) In-service software upgrade centralized database versioning and migration
US20230386657A1 (en) Medical software for displaying and analyzing blood glucose data for use in a heterogeneous computing network in medical practices
JP2004078550A (ja) ソフトウェア更新システム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12731250

Country of ref document: EP

Kind code of ref document: A1

DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12731250

Country of ref document: EP

Kind code of ref document: A1