WO2016092006A1 - Firmware-management-system sowie firmware-management-verfahren zum update von firmware von geräten - Google Patents

Firmware-management-system sowie firmware-management-verfahren zum update von firmware von geräten Download PDF

Info

Publication number
WO2016092006A1
WO2016092006A1 PCT/EP2015/079228 EP2015079228W WO2016092006A1 WO 2016092006 A1 WO2016092006 A1 WO 2016092006A1 EP 2015079228 W EP2015079228 W EP 2015079228W WO 2016092006 A1 WO2016092006 A1 WO 2016092006A1
Authority
WO
WIPO (PCT)
Prior art keywords
firmware
information
devices
firmware management
data
Prior art date
Application number
PCT/EP2015/079228
Other languages
English (en)
French (fr)
Inventor
Michael HARNISCHFEGER
Original Assignee
Schneider Electric Automation Gmbh
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 Schneider Electric Automation Gmbh filed Critical Schneider Electric Automation Gmbh
Publication of WO2016092006A1 publication Critical patent/WO2016092006A1/de

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

  • the invention relates to a firmware management system for updating firmware of the devices integrated in a network according to the preamble of claim 1 and to a firmware management method according to the preamble of claim 6.
  • At least one access means for accessing a first data memory and a control / regulating device with a second data memory are provided for the functionalization of control / regulating devices, in particular engine control units, wherein the first data memory has at least one function module, by which a function and / or functionality of the control / regulating device is executable.
  • the access means and the first data memory at least one functional module can be selectively transferred to the second data memory and / or stored for execution, wherein the overall functionality of the control / regulating device can be flexibly adapted by means of selection of one or more functional modules as required.
  • one or more functional modules stored in a database of the first data memory are selectively loaded into the engine control unit on the basis of a functionally selected function selection performed as required by the method. For this purpose, it is necessary that, in a first step, a preparatory function selection according to needs from a plurality of offered functions is performed by a user.
  • a method for updating firmware FW1... FWn of devices D1... Dn according to the prior art is shown purely schematically in FIG.
  • the devices Dl ... Dn are designed, for example, as control devices, sensors, load switches, drives and / or programmable controllers, each of which contains a firmware FW1... FWn, which may need to be updated during the operating time of the device.
  • each of the devices D is assigned a specific charging tool LT1 ... LTn, which must be coupled by a user C to the device Dl ... Dn whose firmware is to be updated.
  • An example of a loading tool is the "Multi-Loader VW3 A8 121" or "Unity Loader” from Schneider Electric Automation GmbH.
  • a firmware file FWF is provided as shown in FIG. 2 and loaded into the loading tool LT.
  • Loading information LI is stored in the loading tool LT, which contains, for example, information about dependencies of firmware files, an installation environment, method steps for carrying out the update, communication information and device property information such as device type, firmware type and communication capabilities of the device ,
  • the charging tool LT is connected to the device D, wherein via a specific charging interface and charging service LS a communication with the device D is made to load the firmware file FWF in the device D and, if necessary, the installation to monitor the firmware file.
  • a disadvantage of the known method is that for different devices Dl ... Dn each own charging tool LT1 ... LTn or a charging software must be used, which is connected for the user C with high time and cost ,
  • the object of the present invention is to refine a method of the type mentioned at the beginning in such a way that the firmware update of different devices is made possible and substantially simplified.
  • the firmware management device has a firmware management tool which is designed to detect devices integrated in the network and to record device-specific charging information stored in the devices and to store them in a database a second data store in the form of a list of devices and / or network topology store and that the firmware management tool has means for the same from the device-specific charging information with contained in the at least one data packet firmwarespezifischen charging information, taking into account corresponding charging -Information an automatic update of the firmware of the devices on the at least one loading tool is feasible.
  • the firmware management tool is connected to the network via a modular network interface, wherein in the modular network interface various communication protocols such as Modbus, EtherNet / IP, FTP and / or Communication mechanisms such as USB as a direct connection to the device can be implemented as plug-ins.
  • various communication protocols such as Modbus, EtherNet / IP, FTP and / or Communication mechanisms such as USB as a direct connection to the device can be implemented as plug-ins.
  • the firmware management tool is provided via a data interface with a software update client via which an automatic download of desired data packets from a software update server is executable.
  • the firmware management tool has a modular loading interface, comprising one or more loading tools, which can be implemented as plug-ins in the loading interface LI. This allows the integration of existing loading tools and loading mechanisms.
  • At least one of the charging tools has a device service infrastructure for service-oriented communication with the devices.
  • the invention relates to a firmware management method for updating firmware of at least one network-integrated device, such as an automation device and / or energy management device, comprising the method steps:
  • the charging information is provided as firewall-specific charging information and / or device-specific charging information that the device-specific charging information from the device to be updated as a first external data source via a communication command in the load Tool are loaded and that the firmware-specific loading information stored together with the firmware files in a data packet as a second external data source and loaded into the loading tool.
  • the device-specific charging information can be provided together with the firmware-specific charging information in the data packet and loaded into the charging tool.
  • the firmware-specific loading information preferably contains information such as type and identification number of the target devices, firmware version, type of communication protocols, type of loading modes and / or installation information and the loading tool to be used ("Plu-in") or to Loading Mechanism Implementation - There may be multiple load options in a package, including different protocols as well as different loading modes.
  • the device-specific charging information preferably includes information such as device ID, current firmware version, status information, storage information, communication protocols used, device-specific charging modes, installation information and / or dependencies, and compatibility information or notices.
  • the data packet may also contain script files containing information about an adaptation of the loading process to z. For example, contain specific properties or behaviors of target devices.
  • the firmware-specific charging information and the device-specific charging information is interpreted by the charging tool prior to the start of the charging process, wherein a charging process with compatible charging information supported by the device and the data packet is selected by adjusting the charging information, and a uniform service communication interface of the loading tool is set according to the matching loading information.
  • the information provided enables a compatibility and dependency check.
  • the invention is based on the idea of causing the load tools to gain knowledge of load information and device property information in connection with the firmware update, based on this information, the firmware download method, and the Adapt the format of the data flexibly to the respective conditions, without having to adapt the software of the loading tool or to use dedicated loading tools for the respective target devices.
  • the advantage over the prior art that the firmware update of any device with a single loading tool is made possible without adaptations of the software of the loading tool must be made.
  • the software had to be the loading tools for every new device type or version of a product or product Product family, or a new loading tool had to be developed and used.
  • the inventive method allows for updating firmware from different devices with very different device properties without customizing the software of the loading tools.
  • a uniform service communication interface with generic services is used for uniform communication between charging tool and device, which define a common set of device services, via the data and / or information in the form of service Operations are sent to and received from the automation device.
  • protocol-independent device services implements a uniform approach to communication between the charging tool and devices.
  • the device services may be divided into groups such as connection service, information service, data exchange service, notification service and / or diagnostic service.
  • a service is defined to contain one or more operations, where the service describes an abstract destination, such as "Device Information Area,” and an operation describes a specific use case, such as "Reader Information.”
  • the device services are mapped or implemented on different communication protocols to cover a variety of device types and bus systems.
  • PLC Programmable Logic Controller
  • the device services will be used for various areas such as firmware management, application management or configuration management.
  • the method according to the invention is further distinguished from the state of the art in that knowledge and information required by the loading tool for implementing services for communication with the devices are outsourced.
  • the information is provided by the device connected to the charging tool in the form of device-specific charging information and is supplied as firmware-specific charging information together with the data packet to be exchanged with the device.
  • the data package provides the firmware-specific loading information, i. H. Information about what you can do with the data.
  • the device provides the device-specific charging information, which then forms a set of options available for the actual charging process.
  • the approach avoids the need to update the load tool software for new types of devices because no device-specific software parts are implemented in the load tool.
  • the device services provide various non-operational data exchange approaches to installing z. For example, firmware files, application files, parameter files, configuration files as well as diagnostics and other applications are addressed with only one communication interface
  • firmware files, application files, parameter files, configuration files as well as diagnostics and other applications are addressed with only one communication interface
  • a uniform behavior of the device is achieved despite different device properties and communication interfaces. All devices that implement the device services behave in a similar way, regardless of which communication protocol or transport mechanism is used.
  • Required device-dependent specializations are achieved by device-level device information or packet-level metadata metadata, which is provided to the load tool and management tool, and then interpreted. This approach covers a wide range of device types and device classes in a consistent manner.
  • the device-specific specializations also include standardized data that can be generally understood or uniformly interpreted correctly.
  • Fig. 1 is a schematic representation of a method for updating
  • Fig. 2 is a schematic representation of a system for updating
  • Fig. 3 is a schematic representation of a first embodiment of a
  • Fig. 4 is a schematic representation of a second embodiment
  • Firmware management system a schematic representation of an application and service layi architecture of the load tool, a schematic representation of service domains of a device service infrastructure of the load tool,
  • 9 is a schematic representation of a method for loading
  • FIG. 3 shows a schematic representation of a first embodiment of a firmware management system FMS1 for loading firmware files FWF via a loading tool LT into devices D1 ... Dn with different device properties and / or device requirements.
  • the devices Dl ... Dn can be designed as simple sensors or actuators, programmable logic controllers (PLC), drives, measuring devices such as power meters for measuring current and voltage or switching devices.
  • the firmware files FWF used depend on the device platform used and are not uniform.
  • the charging tool LT is designed such that the firmware-specific charging information FWI and / or the device-specific charging information DI contained in the device properties or device requirements associated with the loading of the firmware file needed to load from external data sources. Based on this information or the knowledge obtained by the information, the download method and the data format used can be specialized without adaptation of a software of the loading tool LT, that is, adapted to the respective conditions of the target device.
  • the device characteristic information DI can be provided in the device Dl... Dn and by a defined communication command, which is supported by each individual device Dl... Dn, by the charging tool LT be called and loaded.
  • firmware designers and / or device experts it is possible for firmware designers and / or device experts to include all the loading information LI necessary for the loading together with the firmware files FWF in a data packet DP at the time of the creation of the firmware FW, which then enters the loading tool LT is loaded. Before the actual loading of the firmware, the loading information LI is then interpreted by the loading tool LT.
  • a device service infrastructure DSI with generic device services DS is implemented in the loading tool LT, which sets a common set define service domains, such as charging service LS, information service IS, connection service CS, notification service NS and / or discovery service DCS, which are used to transfer data and information from and to one of the devices D1 ... to send or receive Dn.
  • service domains such as charging service LS, information service IS, connection service CS, notification service NS and / or discovery service DCS, which are used to transfer data and information from and to one of the devices D1 ... to send or receive Dn.
  • 4 shows purely schematically a self-inventing second embodiment of a firmware management system FMS2 for updating firmware FW of devices D1, D2, D3 such as automation devices, in particular actuators, sensors and / or control devices and energy management devices, in particular switching devices.
  • the firmware management system FMS2 comprises a firmware management device FMU, such as a personal computer with an engineering system or a mobile handheld device, comprising a data processing unit, such as MikrocontroUer MC, in which a firmware management tool FMT is implemented.
  • the firmware management tool FMT has access to data memories DR1, DR2, which can be integrated in the firmware management device FMU or designed as external data memories.
  • the firmware management device FMU comprises a data interface Dil, via which data packets DP can be imported into a database DPDB of the data memory DPI.
  • the data packets DP each include firmware files FWF, firmware-specific loading information FWI and data packet information DPI.
  • the firmware management device FMU comprises a customizable network interface NI into which various communication protocols Nil, NI2, NI3 such as Modbus, EtherNet / IP or FTP can be implemented as so-called "plug-ins.”
  • the network interface NI is connected via a network N to the devices Dl, D2, D3.
  • the firmware management tool FMT comprises a charging tool interface LTI for implementing various charging tools LTI, LT2, LT3, which provide various communication and transport mechanisms for downloading the data packets to the devices D1, D2, D3.
  • data packets DP imported via the data interface Dil or via the data interface DI2 are stored in the database DPDB of the data memory DR1.
  • a further inventive feature provides that at least one of the network interfaces Nil, NI2, NI3 is designed to recognize according to the nature of the network N, devices Dl, D2, D3 of the network N and their device-specific load information Dil, DI2, To capture DI3.
  • the detected devices D1, D2, D3 and their device-specific loading information Dil, DI2, DI3 are stored as a device list DL or network topology NT in a database DLDB of the second data memory DR2.
  • the firmware management tool FMT analyzes the information contained in the databases DLDB, DPDB based on the device information Dil, DI2, DI3, which device ID information, current firmware version information, device type Information, memory information and / or load information included, as well as the firmware-specific information FWI, which contains the information which charging tool is to be used, a selection is made, in which device Dl, D2, D3, with which charging parameters and which charging "Plug-in" the firmware FWI, FW2, FW3 should be updated.
  • the firmware management tool FMT After selecting a desired data packet DP, the corresponding information DI from the database DLDB, which is suitable for loading the firmware onto the device, is selected by the firmware management tool FMT. The selection is made on the basis of data packet information DPI and firmware-specific load information FI, which are stored together with the firmware files FWF in the data packet DP.
  • the firmware-specific Charging information for example, target device information, firmware information, communication information, as well as charging information and knowing which charging plug-in should be used.
  • the selected data packets or DPs are then loaded by the firmware management tool FMT via the loading interface LI and a corresponding loading tool LT1, LT2 or LT3 in the target device Dl, D2, D3.
  • the FMT firmware management tool offers the option of automatically requesting and loading firmware updates for a device.
  • the automatic reception can take place via a request "Subscribe" to the software update client SUC, which searches on a software update server SUS for a data packet DP with the corresponding firmware updates.
  • Subscribe here means that one Registered for a device and automatically receive new updates on the next automated (regular, cyclic) query.
  • Suitable data packets DP can then be loaded or imported via the software update client SUC into the database DPDB of the firmware management tool FMT.
  • the uniform or shared database DPDB enables all data within a database to be managed based on the intelligent data packets DP.
  • the database can also be available externally and does not need to be on the same engineering system, eg. B. Cloud for mobile devices or on a server on the intranet.
  • Intelligent data packet DP here means that the packets contain data packet information DPI and firmware-specific load information FI that can be evaluated, so that the data packets DP can be selected for the corresponding destination devices.
  • the data management comprises the storage of the data packets DP, DL, NT in a common environment, ie the databases DPDB, DLDB and the provision of a common or uniform set of information in the form of Data packet information DPI and / or firmware specific load information FWI for the various types of data contents.
  • a selection of a common or unified database can be replicated and used offline. Consequently, data recovery can be facilitated by introducing selection criteria based on data packet information DPI contained in the data packet as packet metadata.
  • the firmware management tool FMT Due to the modular structure of the firmware management tool FMT, in particular the possibility of implementing network interfaces Nil, NI2, NI3 as so-called “plug-ins", the firmware management tool FMT is capable of various types of communication paths, To integrate or use communication approaches, communication protocols or communication mechanisms to interact with various devices D1, D2, D3 or various networks N, thereby reducing the complexity of data processing relating to the device communication and also supporting compatibility with older devices, namely by using the "plug-in” concept, which allows the embedding of older loading mechanisms or loading tools.
  • the firmware management tool FMT can be used to generate a topology of different networks N, whereby z. B. the available devices are reflected in a system. It is also possible to create and archive a snapshot of the current network configuration. This allows the restoration of previous configurations of different networks or work without ever being connected to a network, for. B. to prepare an update of the firmware of various devices in a maintenance phase.
  • the firmware management tool FMT offers the options of a data provider, eg. B. in an intranet to offer the processed and stored data to other customers or clients. From the above, it can be seen that the firmware management tool FMT provides a unique experience, support and maintenance of a complete life cycle of data regarding the device domain. The firmware management tool improves the acquisition and management of all the information needed to download / deploy. Thus, the complexity is reduced for different areas of the information and data flow.
  • FIG. 5 shows purely schematically an architecture of the loading tool LT, comprising an application layer AL with application software AS and a service layer SL with device services DS.
  • the application software AS defines sequences and behavior concerning a defined flowchart such as:
  • the applications software AS contains information regarding the use of device services DS to load the firmware files into the corresponding automation device Dl ... Dn.
  • the service layer SL represents the device service infrastructure DSI with the generic device services DS such as charging service LS, information service IS, connection service CS, notification service NS or discovery service DS, via the generic operations To be defined.
  • generic device services DS such as charging service LS, information service IS, connection service CS, notification service NS or discovery service DS, via the generic operations To be defined.
  • Fig. 6 shows purely schematically various service domains of the device service infrastructure DSI. Each service domain serves a specific purpose. There are dependencies between the service operations and the service Areas. For example, without the service "Connect” no service “Get Device Information” can be executed. For a firmware loading, therefore, several service operations must be combined. The individual service operations are explained below.
  • a connection between the loading tool LT and the device is opened or closed via the connection service CS and the authorization is queried.
  • the information service IS allows a protocol-independent communication with the device Dl ... Dn; Communication commands such as Get Device Information or Get Device Status query various types of static or dynamic device information in the device.
  • the load service LS executes operations such as "download”, “upload”, “send command”, and “get progress info”, e.g. to load a data packet DP or data files from the loading tool LT into the device Dl ... Dn. It is also possible to download data or files from the device Dl ... Dn, z. For example, to create a backup from the device Dl ... Dn. Commands are sent to the device Dl ... Dn via the "Send Command" command, and the "Get Progress Info" command can be used to request progress information during the loading sequence.
  • the notification service NS By means of the notification service NS, messages can be sent to the device Dl ... Dn via the operation "Send Notification.”
  • the notification approach uses a different charging method, which is the charging services, information services, compared to the usual charging methods
  • the device itself can decide what the follow-up activity is, eg downloading the firmware file from a server or after a confirmation input made by the user.
  • FIG. 7 a shows purely schematically a communication between the application software AS of the loading tool LT with the device D 1... Dn via the device service infrastructure DSI implemented in the loading tool LT based on the cached loading.
  • the application software AS queries the device information property of the device Dl... Dn via the "Get Device Information" command of the information service IS.
  • the information is collated, in particular, finding common charging capabilities, independently of which a compatibility check is made to determine if the firmware update is ever intended and installed for the device.
  • the data packet DP is loaded into the device by the loading tool LT by the operation "Download” of the loading service LS, then commands are sent to the device via the "Send Command” operation in order to change the status into a status Set the mode that allows data transfer and firmware installation.
  • the installation command is sent via the application software AS of the loading tool LT of the operation "Send Command" to the device Dl ... Dn, with which the installation of the firmware in the device is started
  • a "Get Progress Info” command can be sent to query the status of the firmware update.
  • the application software AS uses the information service to send the "Get Device Information" command to check whether the update process of the firmware has been successful.
  • Fig. 7b shows purely schematically an alternative communication between the application software AS of the loading tool LT and the device Dl ... Dn, in which the loading process with the available customization options to the individual Conditions of the target device are adjusted.
  • a script file is contained in the data packet DP, via which the loading process of the firmware file can be controlled according to the characteristics and special features of the device.
  • the further method steps correspond to the method steps described in accordance with FIG. 7a).
  • Fig. 8 shows purely schematically a service architecture SAL for performing a protocol implementation (mapping).
  • Mapping means that the generic device service operations are mapped to specific protocols to enable communication about operations on a particular protocol. It uses per-protocol-specific commands as well as data formats to which both the service operations and the operation-specific data are converted. Access by a tool / software to the mapped protocol still takes place via the generic service interface and not via the protocol implementation.
  • the service architecture SAL comprises the service layer SL known from FIG. 5 and, subordinated to it, a mapping layer ML, a protocol layer PL and a transport layer TL. Overall, the individual layers of the service architecture SAL are coupled via a service data model SDM and a security model SM.
  • the device services DS of the service layer SL are in turn protocol-independent in order to enable a uniform communication mechanism.
  • the device services DS can be mapped or implemented on various protocols such as MODBUS, FTP (S), EtherNet / IP and LWM2M using service data mapping information DMI of the mapping layer ML.
  • the individual communication protocols such as MODBUS, FTP (S) and EtherNet / IP provide transport mechanisms such as SL, USB and / or TCP / IP of the transport layer TL.
  • UDP is used as the transport mechanism.
  • USB stick or SD card
  • the method according to the invention makes it possible in a simple manner to expand to other protocols and transport mechanisms.
  • the invention relates to a standardized description of data such as application files, configuration files and / or firmware files in the form of a standardized data packet ADP, CDP, FWDP.
  • data packets ADP, CDP, FWDP are defined, which contain the data in the form of application files AF, configuration files CF and firmware files FWF, and which are additionally accompanied by package metadata MD, which includes the content as well as the structuring describe the content of the data packets ADP, CDP, FWDP in general form.
  • package metadata MD which includes the content as well as the structuring describe the content of the data packets ADP, CDP, FWDP in general form.
  • the data packets ADP, CDP, FWDP contain information about the intended use and special feature (dependencies, compatibility aspects) of their contents.
  • This information is contained in the data packet by means of an extended or specialized metadata description. The information is depending on the type of content. This means that each type has its own standardized metadata description schema or syntax defined.
  • special rooting paths z For example, for submodules or subnetworks in the data packet description.
  • the data packets also contain information about how the data is to be used or applied, e.g. For example, how the data or data packet can be exchanged with devices, or how a software library can be installed on the target device.
  • command lists may be included in the data packets that enable the processing tool SPT, CST, FLT or the respective device to execute a sequence of necessary steps.
  • the data packets ADP, CDP, FWDP also describe which necessary requirements for using or applying the content of the data packets with the target device are to be observed.
  • the data packet contains information about the compatibility and dependencies to be considered when the content is used.
  • a common package frame defines the internal file organization and appearance.
  • the data packets are defined as basic and detailed parts. This allows extensibility for new domains or requests in a simple way.
  • a data packet may describe different types of data contents in a conventional manner, such as: For example, firmware updates, software libraries, configuration data, or device applications.
  • data packets can be combined in a container package to z.
  • B Data content for various target devices such as for all automation devices of a production system or area to provide.
  • the data packets according to the invention it is possible to describe different data content types in a general manner and manner, so that all components or instances involved in the communication process know exactly how to interpret the data in order to obtain the required or required information.
  • the data packets are intelligent in nature, as they both describe their content and contain information about how to interpret and handle the content.
  • the data packets provide different types of information in order to be able to carry out the data content as well.
  • the knowledge about the data and its use are provided with the data packet itself and not by the processing tool SPT, CST or FLT.
  • the tool only needs to provide the required generic services as well as their general (base) expiration or invocation sequences.
  • FIG. 11 shows a schematic representation of the structure of the data packets ADP, CDP, FWDP and their integration into a container packet CP.
  • the container package contains package metadata PMD, which contain user-specific information about what a user can do with the individual data packets ADP, CDP, FWDP.
  • package metadata PMD contain user-specific information about what a user can do with the individual data packets ADP, CDP, FWDP.
  • an assignment layer AL an assignment to the desired data packets ADP, CDP, FWDP takes place via the address ADR.
  • packet metadata PMD which refer within the data packet to specific or detailed metadata such as firmware metadata FWMD or application metadata AMD, which contain a detailed description of content, such as in the respective data packets ADP, CDP, FWDP-containing files, such as firmware files FWF or application files AF, are to be treated, in particular which loading mechanisms are to be considered or for application data, which dependencies are to be considered.

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

Die Erfindung bezieht sich auf ein Firmware-Management-System (FMS2) sowie auf ein Firmware-Management-Verfahren zur Aktualisierung von Firmware (FW1, FW2, FW3) von in einem Netzwerk (N) eingebundener Geräte (D1, D2, D3) wie Automatisierungsgeräte und/oder Energie-Management-Geräte, umfassend ein Firmware-Management-Gerät (FMU) für den Zugriff auf zumindest einen ersten Datenspeicher (DR1) sowie zumindest eines der Geräte (D1, D2, D3), wobei der zumindest eine erste Datenspeicher (DR1) wenigstens ein Datenpaket (DP) mit zumindest einer Firmware-Datei (FWF) aufweist und wobei im Zusammenwirken des Firmware-Management-Geräts (FMU) und dem zumindest einen ersten Datenspeicher (DR1) selektiv zumindest ein Datenpaket (DP) in zumindest ein Gerät (D1, D2, D3) ladbar ist. Um das Firmware-Management unterschiedlicher Geräte in einem Netzwerk zu ermöglichen und zu vereinfachen ist vorgesehen, dass das Firmware-Management-Gerät (FMU) ein Firmware-Management-Tool aufweist, welches ausgebildet ist, um in dem Netzwerk (N) eingebundene Geräte (D1, D2, D3) zu erkennen und in den Geräten (D1, D2, D3) gespeicherte gerätespezifische Lade-Informationen (DI1, DI2, DI3) zu erfassen und diese in einer Datenbank (DLDB) eines zweiten Datenspeicher (DR2) in Form einer Geräteliste (DL) und/oder Netzwerk-Topologie (NT) zu speichern und dass das Firmware-Management-Tool Mittel zum Abgleich der gerätespezifischen Lade-Informationen (DI1, DI2, DI3) mit in dem zumindest einen Datenpaket (DP) enthaltenen firmwarespezifischen Lade-Informationen (FWI) aufweist, wobei unter Berücksichtigung korrespondierender Lade-Informationen ein automatischer Update der Firmware (FW1, FW2, FW3) der Geräte (DI1, DI2, DI3) über das zumindest eine Lade-Tool (LT1, LT2, LT3) durchführbar ist.

Description

Beschreibung
Firmware-Management-System sowie Firmware-Management- Verfahren zum Update von Firmware von Geräten
Die Erfindung bezieht sich auf ein Firmware-Management-System zur Aktualisierung von Firmware der in einem Netzwerk eingebundenen Geräten nach dem Oberbegriff des Anspruchs 1 sowie auf ein Firmware-Management- Verfahren nach dem Oberbegriff des Anspruchs 6.
Ein System sowie ein Verfahren der eingangs genannten Art ist in der DE 10 2006 044 182 AI beschrieben. Zur bedarfsgerechten Funktionalisierung von Steuer- /Regeleinrichtungen, insbesondere von Motorsteuergeräten, ist wenigstens ein Zugriffsmittel zum Zugriff auf einen ersten Datenspeicher sowie eine Steuer- /Regeleinrichtung mit einem zweiten Datenspeicher vorgesehen, wobei der erste Datenspeicher wenigstens ein Funktionsmodul aufweist, durch welches eine Funktion und/oder Funktionalität der Steuer-/Regeleinrichtung ausführbar ist. Im Zusammenwirken von Zugriffsmittel und erstem Datenspeicher ist selektiv wenigstens ein Funktionsmodul in den zweiten Datenspeicher übertragbar und/oder zur Ausführung speicherbar, wobei die Gesamtfunktionalität der Steuer-/Regeleinrichtung durch bedarfsgemäße Selektion eines oder mehrerer Funktionsmodule flexibel anpassbar ist. Zur bedarfsgerechten Funktionalisierung des Motorsteuergeräts werden anhand einer verfahrensvorbereitend durchgeführten bedarfsgemäßen Funktionsauswahl ein oder mehrere in einer Datenbank des ersten Datenspeichers abgelegte Funktionsmodule selektiv in das Motorsteuergerät geladen. Dazu ist notwendig, dass in einem ersten Schritt eine vorbereitende bedarfsgemäße Funktionsauswahl aus mehreren angebotenen Funktionen durch einen Anwender durchgeführt wird.
Sind in einem Netzwerk mehrere Geräte mit verschiedenen Geräteeigenschaften eingebunden, ist es für einen Anwender sehr schwierig, fast unmöglich zu wissen, welche der angeschlossenen Automatisierungsgeräte welches Firmware-Update benötigt.
Ergänzend ist zu berücksichtigen, dass Geräte verschiedener Hersteller unterschiedliche Lade-Tools und Lademethoden verwenden, so dass das bekannte System zum Firmware-Update verschiedener Geräte nicht geeignet ist.
Ein Verfahren zum Update von Firmware FW1 ... FWn von Geräten Dl ... Dn nach dem Stand der Technik ist rein schematisch in Fig. 1 dargestellt. Die Geräte Dl ... Dn sind beispielsweise als Steuergeräte, Sensoren, Lastschalter, Antriebe und/oder programmierbare Steuerungen ausgebildet, die jeweils eine Firmware FW1 ...FWn enthalten, die während der Betriebsdauer des Geräts ggfs. aktualisiert werden muss.
Da die Geräte Dl ... Dn unterschiedlicher Art sind und unterschiedliche Eigenschaften aufweisen, ist jedem der Geräte D ein spezifisches Lade-Tool LT1 ... LTn zugeordnet, das von einem Anwender C jeweils an das Gerät Dl ... Dn angekoppelt werden muss, dessen Firmware aktualisiert werden soll. Ein Beispiel für ein Lade-Tool ist der „Multi-Loader VW3 A8 121" oder„Unity Loader" der Schneider Electric Automation GmbH.
Bei dem bekannten Verfahren wird gemäß Fig. 2 eine Firmware-Datei FWF bereitgestellt und in das Lade-Tool LT geladen. In dem Lade-Tool LT sind Lade- Informationen LI abgelegt, die beispielsweise Informationen über Abhängigkeiten von Firmware-Dateien, eine Installationsumgebung, Verfahrensschritte zur Durchführung des Updates, Kommunikations-Informationen sowie Geräteeigenschafts-Informationen wie Geräteart, Firmware- Art sowie Kommunikationsfähigkeiten des Gerätes enthalten.
Das Lade-Tool LT wird mit dem Gerät D verbunden, wobei über eine spezifische Lade- Schnittstelle und Lade-Service LS eine Kommunikation mit dem Gerät D hergestellt wird, um die Firmware-Datei FWF in das Gerät D zu laden und ggfs. die Installation der Firmware-Datei zu überwachen. Nachteilig bei dem bekannten Verfahren ist, dass für unterschiedliche Geräte Dl ... Dn jeweils ein eigenes Lade-Tool LT1 ... LTn bzw. eine Lade-Software verwendet werden muss, was für den Anwender C mit hohem Zeit- und Kostenaufwand verbunden ist.
Davon ausgehend liegt der vorliegenden Erfindung die Aufgabe zu Grunde, ein Verfahren der eingangs genannten Art derart weiterzubilden, dass das Firmware-Update unterschiedlicher Geräte ermöglicht und wesentlich vereinfacht wird.
Die Aufgabe wird erfindungsgemäß dadurch gelöst, dass das Firmware-Management- Gerät ein Firmware-Management-Tool aufweist, welches ausgebildet ist, um in dem Netzwerk eingebundene Geräte zu erkennen und in den Geräten gespeicherte gerätespezifische Lade-Informationen zu erfassen und diese in einer Datenbank eines zweiten Datenspeicher in Form einer Geräteliste und/oder Netzwerk-Topologie zu speichern und dass das Firmware-Management-Tool Mittel zum Ab gleich der gerätespezifischen Lade-Informationen mit in dem zumindest einen Datenpaket enthaltenen firmwarespezifischen Lade-Informationen aufweist, wobei unter Berücksichtigung korrespondierender Lade-Informationen ein automatischer Update der Firmware der Geräte über das zumindest eine Lade-Tool durchführbar ist.
Gegenüber dem Stand der Technik wird der Vorteil erreicht, dass mit nur einem einzigen Firmware-Management-Tool ein standardisiertes Firmware-Update von Geräten mit unterschiedlichen Geräteeigenschaften ermöglicht wird.
Zur Unterstützung von neueren und älteren Geräten ist vorgesehen, dass das Firmware-Management- Tool über ein modulares Netzwerk-Interface mit dem Netzwerk verbunden ist, wobei in das modular aufgebaute Netzwerk-Interface verschiedene Kommunikationsprotokolle wie Modbus, EtherNet/IP, FTP und/oder Kommunikationsmechanismen wie USB als direkte Verbindung zum Gerät als Plug-ins implementierbar sind.
Zur automatischen Aktualisierung von Firmware ist vorgesehen, dass das Firmware- Management-Tool über eine Datenschnittstelle mit einem Software-Update-Client verbunden ist, über den ein automatischer Download von gewünschten Datenpaketen von einem Software-Update-Server ausführbar ist.
Zur Verarbeitung von Ladevorgängen mit verschiedenen Lade-Parametern weist das Firmware-Management- Tool ein modular aufgebautes Lade-Interface auf, umfassend ein oder mehrere Lade-Tools, die als Plug-ins in das Lade-Interface LI implementierbar sind. Dies ermöglicht die Integration von bestehenden Lade-Tools und Lade-Mechanismen.
Des Weiteren ist vorgesehen, dass zumindest eines der Lade-Tools eine Device-Service- Infrastruktur zur Service-orientierten Kommunikation mit den Geräten aufweist.
Zudem bezieht sich die Erfindung auf ein Firmware-Management- Verfahren zur Aktualisierung von Firmware von zumindest einem in einem Netzwerk eingebundenen Gerät wie Automatisierungsgerät und/oder Energie-Management-Gerät, umfassend die Verfahrensschritte:
- Download zumindest eines eine Firmware-Datei aufweisenden Datenpakets in eine Datenbank eines Datenspeichers eines Firmware- Management- S y stems ,
- Selektieren eines Datenpakets und
- Laden des Datenpakets über ein Lade-Tool in zumindest eines der Geräte.
Das erfindungs gemäße Verfahren zeichnet sich durch die weiteren Verfahrens schritte aus:
- Erkennen der in dem Netzwerk vorhandenen Geräte mittels eines in dem Firmware-Management-Gerät implementierten Firmware-Management- Tools,
- Erfassen von gerätespezifischen Lade-Informationen der erkannten Geräte,
- Speichern der erkannten Geräte und deren gerätespezifischen Lade- Informationen in einer Datenbank, - Selektieren zumindest eines eine Firmware-Datei enthaltenden Datenpakets aus der ersten Datenbank auf der Grundlage der gerätespezifischen Lade-Informationen,
- Laden des selektierten Datenpakets über das Lade-Tool in das zumindest eine entsprechende Zielgerät und vorzugsweise
- Handhabung von Geräte-Information sowie Datenpaket in Form von z.
B. Firmware-Update-Datei durch Kompatibilitäts-Überprüfung,
- Verwaltung von Geräte-Information sowie Datenpaket in Form von z. B.
Firmware-Update-Datei und/oder
- Bereitstellung und Abfrage von Datenpaketen.
Gemäß einer bevorzugten Verfahrensweise ist vorgesehen, dass die Lade- Informationen als firmenwarespezifische Lade- Informationen und/oder gerätespezifische Lade-Informationen bereitgestellt werden, dass die gerätespezifischen Lade-Informationen von dem zu aktualisierenden Gerät als erste externe Datenquelle über einen Kommunikations-Befehl in das Lade-Tool geladen werden und dass die firmwarespezifischen Lade-Informationen zusammen mit den Firmware-Dateien in einem Datenpaket als zweite externer Datenquelle gespeichert und in das Lade-Tool geladen werden.
Gemäß einer alternativen Verfahrensweise können die gerätespezifischen Lade- Informationen zusammen mit den firmwarespezifischen Lade-Informationen in dem Datenpaket bereitgestellt und in das Lade-Tool geladen werden.
Die firmwarespezifischen Lade- Informationen enthalten vorzugsweise Informationen wie Art und Identifikationsnummer der Zielgeräte, Firmware- Version, Art der Kommunikationsprotokolle, Art der Lademodi und/oder Installations-Informationen sowie das zu verwendende Lade-Tool („Plu-in") bzw. die zu verwendende Lade- Mechanismus-Implementierung. In einem Paket können mehrere Lade-Optionen vorhanden sein. Das beinhaltet sowohl unterschiedliche Protokolle als auch verschiedene Lade-Modi. Die gerätespezifischen Lade-Informationen enthalten vorzugsweise Informationen wie Geräte-ID, aktuelle Firmware- Version, Statusinformationen, Speicherinformationen, verwendete Kommunikationsprotokolle, gerätespezifische Lade-Modi, Installations- Informationen und/oder Abhängigkeiten und Kompatibilitäts-Informationen bzw. -Hinweise.
Bei einer weiteren bevorzugten Verfahrensweise kann das Datenpaket auch Skript- Dateien enthalten, die Informationen über eine Anpassung des Ladevorgangs an z. B. spezielle Eigenschaften oder Verhaltensweisen von Zielgeräten enthalten.
Vorzugsweise werden die firmwarespezifischen Lade-Informationen und die gerätespezifischen Lade-Informationen vor dem Start des Ladevorgangs durch das Lade-Tool interpretiert, wobei durch Abgleich der Lade-Informationen ein Ladevorgang mit von dem Gerät und dem Datenpaket unterstützten, kompatiblen Lade-Informationen ausgewählt wird und eine einheitliche Service-Kommunikationsschnittstelle des Lade- Tools entsprechend der übereinstimmenden Lade-Informationen eingestellt wird. Zudem ist durch die bereitgestellten Informationen ein Komptabilitäts- und Abhängigkeitsüberprüfung möglich.
Der Erfindung liegt die Idee zu Grunde, die Lade-Tools zu veranlassen, Kenntnis über Lade-Informationen und Geräte-Eigenschafts-Informationen im Zusammenhang mit dem Firmware-Update zu erlangen, um auf der Grundlage dieser Informationen das Firmware-Download- Verfahren und das Format der Daten flexibel an die jeweiligen Bedingungen anzupassen, ohne eine Adaption der Software des Lade-Tools vornehmen zu müssen bzw. dezidierte Lade-Tools für die jeweiligen Ziel-Geräte verwenden zu müssen.
Durch das erfindungsgemäße Verfahren wird gegenüber dem Stand der Technik der Vorteil erreicht, dass der Firmware-Update beliebiger Geräte mit einem einzigen Lade- Tool ermöglicht wird, ohne dass Adaptionen der Software des Lade-Tools vorgenommen werden müssen. Nach dem Stand der Technik musste die Software der Lade-Tools für jeden neuen Geräte-Typ oder jede neue Version eines Produktes oder Produktfamilie angepasst werden, oder es musste ein neues Lade-Tool entwickelt und genutzt werden.
Folglich erlaubt das erfindungsgemäße Verfahren eine Aktualisierung von Firmware von unterschiedlichen Geräten mit sehr unterschiedlichen Geräteeigenschaften ohne Anpassung der Software der Lade-Tools.
Gemäß einer weiteren bevorzugten Verfahrensweise ist vorgesehen, dass zur einheitlichen Kommunikation zwischen Lade-Tool und Gerät eine einheitliche Service-Kommunikationsschnittstelle mit generischen Services verwendet wird, die einen gemeinsamen Satz von Device-Services definieren, über die Daten und/oder Informationen in Form von Service-Operationen von und zu dem Automatisierungsgerät gesendet bzw. empfangen werden.
Diese Device-Services sind protokollunabhängig. Durch das Konzept der protokollunabhängigen Device-Services wird ein einheitlicher Ansatz für die Kommunikation zwischen Lade-Tool und Geräten realisiert.
Zur Steuerung verschiedener Aktivitäten können die Device-Services in Gruppen wie Verbindungs-Service, Informations-Service, Datenaustausch-Service, Notifikations- Service und/oder Diagnose-Service unterteilt werden. Ein Service ist so definiert, dass dieser eine oder mehrere Operationen enthält, wobei der Service ein abstraktes Ziel wie beispielsweise „Bereich Geräte- Informationen" und eine Operation einen konkreten Anwendungsfall wie„Lesegeräte-Informationen" beschreibt.
Zur Unterstützung unterschiedlicher Kommunikations-Protokolle ist vorgesehen, dass die Device-Services auf verschiedene Kommunikations-Protokolle abgebildet bzw. umgesetzt werden, um eine Vielzahl von Geräte-Typen und Bussystemen abdecken zu können.
Die Flexibilität der Unterstützung für verschiedene Kommunikationsprotokolle wie MODBUS, FTP oder EtherNet/IP und Kommunikations- und/oder Transportmedien wie Feldbus, WLAN, USB oder Datenträger, ermöglicht die Adressierung der individuellen Geräteeigenschaften, wie beispielsweise Automatisierungsgeräte mit begrenzten Ressourcen und Rechenleistungen, wie Sensoren, bis hin zu intelligenten Automatisierungsgeräten wie Programmable Logic Controller (PLC).
Des Weiteren ist vorgesehen, dass die Device-Services für verschiedene Bereiche wie Firmware-Management, Anwendungs-Management oder Konfigurations-Management verwendet werden.
Das erfindungs gemäße Verfahren zeichnet sich gegenüber dem Stand der Technik weiterhin dadurch aus, dass Wissen und Information, welche von dem Lade-Tool zur Implementierung von Services zur Kommunikation mit den Geräten benötigt werden, ausgelagert werden.
Die Information wird von dem mit dem Lade-Tool verbundenen Gerät in Form von gerätespezifischer Lade-Informationen bereitgestellt und wird als firmwarespezifische Lade-Informationen zusammen mit dem Datenpaket geliefert, welches mit dem Gerät ausgetauscht werden soll. Das Datenpaket liefert die firmwarespezifische Lade- Information, d. h. Informationen, was man mit den Daten machen kann. In dem Gerät werden die gerätespezifischen Lade- Informationen bereitgestellt, durch die dann eine Gruppe von Möglichkeiten gebildet wird, die für den tatsächlichen Ladevorgang zur Verfügung stehen.
Der Ansatz vermeidet die Notwendigkeit, die Software des Lade-Tools für neue Typen von Geräten aktualisieren zu müssen, da keine gerätespezifischen Software-Teile in das Lade-Tool implementiert sind. Über die Device-Services werden verschiedene nichtoperative Datenaustausch- An Wendungen in Bezug auf Installation von z. B. Firmware- Dateien, Anwendungs-Dateien, Parameter-Dateien, Konfigurations-Dateien sowie Diagnose und andere Anwendungen mit nur einem Kommunikations-Schnittstelle angesprochen Durch das erfindungs gemäße Verfahren wird ein einheitliches Verhalten der Geräte trotz unterschiedlicher Geräteeigenschaften und Kommunikations-Schnittstellen erreicht. Alle Geräte, in denen die Device-Services implementiert sind, verhalten sich gleichartig, unabhängig davon, welches Kommunikationsprotokoll oder welcher Transportmechanismus verwendet wird. Erforderliche geräteabhängige Spezialisierungen werden durch Geräte-Informationen auf Geräteebene oder Datenpaket-Metadaten auf Paketebene erreicht, die dem Lade-Tool als auch dem Management-Tool zur Verfügung gestellt und anschließend interpretiert werden. Durch diesen Ansatz wird ein weiter Bereich von Geräte-Typen und Geräte-Klassen in einheitlicher Weise abgedeckt. Die geräteabhängigen Spezialisierungen beinhalten auch standardisierte Daten, die allgemein verstanden oder einheitlich korrekt interpretiert werden können.
Weitere Einzelheiten, Vorteile und Merkmale der Erfindung ergeben sich nicht nur aus den Ansprüchen, den diesen zu entnehmenden Merkmalen -für sich und/oder in Kombination-, sondern auch aus der nachfolgenden Beschreibung von den Figuren zu entnehmenden bevorzugten Ausführungsbeispielen.
Es zeigen:
Fig. 1 eine schematische Darstellung eines Verfahrens zum Updaten von
Firmware von Geräten nach dem Stand der Technik,
Fig. 2 eine schematische Darstellung eines Systems zum Updaten von
Firmware eines Gerätes nach dem Stand der Technik,
Fig. 3 eine schematische Darstellung einer ersten Ausführungsform eines
Firmware-Management-Systems zum Updaten von Firmware eines Gerätes gemäß der Erfindung,
Fig. 4 eine schematische Darstellung einer zweiten Ausführungsform
Firmware-Management-Systems, eine schematische Darstellung einer Anwendungs- und Service-Layi Architektur des Lade-Tools, eine schematische Darstellung von Service-Domains einer Device- Service-Infrastruktur des Lade-Tools,
Fig.7a), b) schematische Darstellungen von Kommunikations-Diagrammen zwischen Lade-Tool und Automatisierungsgerät,
Fig. 8 eine schematische Darstellung einer Service-Architektur-Schicht,
Fig. 9 eine schematische Darstellung eines Verfahrens zum Laden von
Anwendungs-, Konfigurations- und/oder Firmware-Dateien über unterschiedliche Lade-Tools nach dem Stand der Technik, eine schematische Darstellung eines Verfahrens zum Laden von Datenpaketen über unterschiedliche Lade-Tools gemäß der Erfindung und eine schematische Darstellung einer Datenstruktur von Datenpaketen umfassend Paket-Meta-Daten sowie Firmware-, Konfigurations- und/oder Anwendungs-Dateien.
Fig. 3 zeigt in schematischer Darstellung eine erste Ausführung eines Firmware- Management-Systems FMS1 zum Laden von Firmware-Dateien FWF über ein Lade- Tool LT in Geräte Dl ... Dn mit unterschiedlichen Geräteeigenschaften und/oder Geräteanforderungen. Die Geräte Dl ... Dn können als einfache Sensoren oder Aktoren, Programmable Logic Controller (PLC), Antriebe (Drives), Messgeräte wie Power Meter zum Messen von Strom und Spannung oder Schaltgeräte ausgebildet sein. Die verwendeten Firmware-Dateien FWF sind von der verwendeten Geräte-Plattform abhängig und sind nicht einheitlich. Gemäß der Erfindung ist vorgesehen, dass das Lade-Tool LT derart ausgebildet ist, um die firmwarespezifische Lade-Information FWI und/oder die in den Geräteeigenschaften bzw. Geräteanforderungen enthaltenen gerätespezifischen Lade-Informationen DI, die im Zusammenhang mit dem Laden der Firmware-Datei benötigt werden, aus externen Datenquellen zu laden. Basierend auf diesen Informationen bzw. dem durch die Informationen erhaltenen Wissen kann das Download- Verfahren und das verwendete Datenformat ohne Anpassung einer Software des Lade-Tools LT spezialisiert, d.h., an die jeweiligen Bedingungen des Ziel-Gerätes angepasst werden.
Gemäß dem in Fig. 3 dargestellten Ausführungsbeispiel können die Geräte- Eigenschafts-Informationen DI in dem Gerät Dl ... Dn bereitgestellt und über einen definierten Kommunikationsbefehl, welcher von jedem einzelnen individuellen Gerät Dl ... Dn unterstützt wird, durch das Lade-Tool LT aufgerufen und geladen werden.
Alternativ besteht die Möglichkeit, dass Firmware-Designer und/oder Geräteexperten sämtliche für den Ladevorgang notwendigen Lade-Informationen LI zusammen mit den Firmware-Dateien FWF in ein Datenpaket DP zum Zeitpunkt der Erstellung der Firmware FW aufnehmen, welches sodann in das Lade-Tool LT geladen wird. Vor dem eigentlichen Ladevorgang der Firmware wird sodann die Lade-Information LI von dem Lade-Tool LT interpretiert.
Zur Bereitstellung einer protokollunabhängigen Kommunikation über eine Datenverbindung N zwischen dem Lade-Tool LT und den jeweiligen Geräten Dl ... Dn ist in dem Lade-Tool LT eine Device-Service-Infrastruktur DSI mit generischen Device-Services DS implementiert, die ein gemeinsames Set von Service-Domains definieren, wie beispielsweise Lade-Service LS, Informations-Service IS, Verbindungs- Service CS, Notifikations-Service NS und/oder Discovery-Service DCS, die verwendet werden, um Daten und Informationen von und zu einem der Geräte Dl ... Dn zu senden bzw. zu empfangen. Fig. 4 zeigt rein schematisch eine eigenerfinderische zweite Ausführungsform eines Firmware-Management-Systems FMS2 zur Aktualisierung von Firmware FW von Geräten Dl, D2, D3 wie Automatisierungsgeräten, insbesondere Aktoren, Sensoren und/oder Steuerungsgeräte sowie Energie-Management-Geräte, insbesondere Schaltgeräte. Das Firmware-Management-System FMS2 umfasst ein Firmware- Management-Gerät FMU wie Personal Computer mit Engineering-System oder mobiles Handgerät, umfassend eine Datenverarbeitungseinheit wie MikrocontroUer MC, in der ein Firmware-Management- Tool FMT implementiert ist. Das Firmware-Management- Tool FMT hat Zugriff auf Datenspeicher DR1, DR2, die in dem Firmware- Management-Gerät FMU integriert oder als externe Datenspeicher ausgebildet sein können.
Des Weiteren umfasst das Firmware-Management-Gerät FMU ein Daten-Interface Dil, über welches Datenpakete DP in eine Datenbank DPDB des Datenspeichers DPI importiert werden können. Die Datenpakete DP umfassen jeweils Firmware-Dateien FWF, firmwarespezifische Lade-Informationen FWI sowie Datenpaket-Informationen DPI.
Alternativ besteht die Möglichkeit, die Datenpakete DP auf einem Software-Update- Server SUS abzulegen und diese über einen Software-Update-Client SUC über ein zweites Daten-Interface DI2 des Firmware-Management-Tools FMT in die Datenbank DPDB zu laden. Dieser Vorgang kann eine manuelle als auch automatisiert (zyklische) Überprüfung oder Abfrage nach neuen oder noch nicht vorhandenen (gemäß der Geräteliste) Updates beinhalten.
Des Weiteren umfasst das Firmware-Management-Gerät FMU ein anpassbares Netzwerk- Interface NI, in das verschiedene Kommunikationsprotokolle Nil, NI2, NI3 wie beispielsweise Modbus, EtherNet/IP oder FTP als sogenannte „Plug-ins" implementierbar sind. Das Netzwerk-Interface NI ist über ein Netzwerk N mit den Geräten Dl, D2, D3 verbunden. Ferner umfasst das Firmware-Management-Tool FMT ein Lade-Tool-Interface LTI zur Implementierung verschiedener Lade-Tools LTI, LT2, LT3, die verschiedene Kommunikations- und Transportmechanismen zum Download der Datenpakete in die Geräte Dl, D2, D3 zur Verfügung stellen.
Gemäß eines erfinderischen Gedankens ist vorgesehen, dass über das Daten-Interface Dil oder über das Daten-Interface DI2 importierten Datenpakete DP in der Datenbank DPDB des Datenspeichers DR1 gespeichert werden.
Ein weiteres erfinderisches Merkmal sieht vor, dass zumindest eines der Netzwerk- Interfaces Nil, NI2, NI3 ausgebildet ist, entsprechend der Ausprägung des Netzwerkes N, Geräte Dl, D2, D3 des Netzwerks N zu erkennen und deren gerätespezifischen Lade- Information Dil, DI2, DI3 zu erfassen. Die erkannten Geräte Dl, D2, D3 sowie deren gerätespezifischen Lade-Informationen Dil, DI2, DI3 werden als eine Geräteliste DL bzw. Netzwerktopologie NT in einer Datenbank DLDB des zweiten Datenspeichers DR2 gespeichert.
Durch das Firmware-Management-Tool FMT erfolgt eine Analyse der in den Datenbanken DLDB, DPDB enthaltenen Informationen wobei auf der Grundlage der Geräteinformationen Dil, DI2, DI3, welche Geräte-ID-Informationen, aktuelle Firmware- Versions-Informationen, Geräte-Typ-Informationen, Speicherinformationen und/oder Lade-Informationen enthalten, sowie der firmwarespezifischen Informationen FWI, welche die Informationen enthält, welches Lade-Tool verwendet werden soll, eine Auswahl getroffen wird, bei welchem Gerät Dl, D2, D3, mit welchen Ladeparametern und welches Lade„Plug-in" die Firmware FWI, FW2, FW3 aktualisiert werden soll.
Nach Auswahl eines gewünschten Datenpakets DP werden durch das Firmware- Management-Tool FMT die entsprechenden Informationen DI aus der Datenbank DLDB selektiert, welche für den Ladevorgang der Firmware auf das Gerät geeignet sind. Die Auswahl erfolgt auf der Grundlage von Datenpaket-Informationen DPI sowie firmwarespezifischen Lade-Informationen FI, die zusammen mit den Firmware-Dateien FWF in dem Datenpaket DP gespeichert sind. Dabei enthalten die firmwarespezifischen Ladeinformationen beispielsweise Zielgerät-Informationen, Firmware-Informationen, Kommunikations-Informationen sowie Lade-Informationen und das Wissen welches Lade„Plug-in" verwendet werden soll bzw. muss.
Das oder die ausgewählten Datenpakete DP werden dann durch das Firmware- Management-Tool FMT über das Lade-Interface LI und ein entsprechendes Lade-Tool LT1, LT2 oder LT3 in das Zielgerät Dl, D2, D3 geladen.
Durch die Analyse der Geräteliste DL mit zugehörigen gerätespezifischen Lade- Informationen DI sowie der Analyse der Datenpakete DP bietet das Firmware- Management-Tool FMT die Möglichkeit, Firmware-Updates für ein Gerät, automatisch abzufragen und zu laden. Dabei kann der automatische Empfang über eine Anfrage „Subscribe" an den Software-Update-Client SUC erfolgen, der auf einem Software- Update-Server SUS nach einem Datenpaket DP mit den entsprechenden Firmware- Updates sucht.„Subscribe" bedeutet hier, dass man sich für ein Gerät registriert und automatisch neue Updates bei der nächsten automatisierten (regelmäßigen, zyklischen) Abfrage erhält. Geeignete Datenpakete DP können sodann über den Software-Update- Client SUC in die Datenbank DPDB des Firmware-Management- Tools FMT geladen bzw. importiert wird.
Die einheitliche bzw. gemeinsame Datenbank DPDB ermöglicht, dass alle Daten innerhalb einer Datenbank basierend auf den intelligenten Datenpaketen DP verwaltet werden. Die Datenbank kann auch extern verfügbar sein und muss sich nicht auf demselben Engineering System befinden, z. B. Cloud für mobile Geräte oder auf einem Server im Intranet. Intelligentes Datenpaket DP bedeutet hierbei, dass die Pakete Datenpaket-Informationen DPI sowie firmwarespezifische Lade-Informationen FI enthalten, die ausgewertet werden können, so dass die Datenpakete DP für die entsprechenden Zielgeräte ausgewählt werden können.
Die Daten Verwaltung umfasst die Speicherung der Datenpakete DP, DL, NT in einer gemeinsamen Umgebung, d. h. den Datenbanken DPDB, DLDB und die Bereitstellung eines gemeinsamen bzw. einheitlichen Satzes von Informationen in Form der Datenpaket-Informationen DPI und/oder firmwarespezifischen Lade-Informationen FWI für die verschiedenen Arten von Dateninhalten.
Eine Auswahl einer gemeinsamen bzw. einheitlichen Datenbank kann nachgebildet und offline benutzt werden. Folglich kann eine Datenwiederherstellung durch Einführung von Auswahlkriterien basierend auf Datenpaket-Informationen DPI, die in dem Datenpaket als Paket-Metadaten enthalten sind, vereinfacht werden.
Durch den modularen Aufbau des Firmware-Management- Tools FMT, insbesondere die Möglichkeit der Implementierung von Netzwerk- Interfaces Nil, NI2, NI3 als sogenannte „Plug-ins" ist das Firmware-Management-Tool FMT in der Lage, verschiedene Arten von Kommunikationswegen, Kommunikationsansätzen, Kommunikationsprotokolle oder Kommunikationsmechanismen zu integrieren bzw. zu nutzen, um mit verschiedenartigen Geräten Dl, D2, D3 bzw. verschiedenen Netzwerken N zu interagieren. Dadurch wird die Komplexität der Datenverarbeitung betreffend die Gerätekommunikation reduziert. Auch wird eine Kompatibilität zu älteren Geräten unterstützt, nämlich durch Verwendung des „Plug In"-Konzeptes, welches die Einbettung älterer Lade-Mechanismen bzw. Lade-Tools erlaubt.
Unabhängig davon kann mit dem Firmware-Management-Tool FMT eine Topologie von verschiedenen Netzwerken N erzeugt werden, wodurch z. B. die verfügbaren Geräte in einer Anlage widergespiegelt werden. Ferner besteht die Möglichkeit, eine Momentaufnahme der aktuellen Netzwerkkonfiguration zu erzeugen und zu archivieren. Dies ermöglicht die Wiederherstellung früherer Konfigurationen von verschiedenen Netzwerken oder das Arbeiten, ohne überhaupt mit einem Netzwerk verbunden zu sein, um z. B. eine Aktualisierung der Firmware verschiedener Geräte in einer Wartungsphase vorzubereiten.
Des Weiteren bietet das Firmware-Management-Tool FMT die Optionen eines Daten- Providers, z. B. in einem Intranet zu agieren, um die verarbeiteten und gespeicherten Daten weiteren Kunden oder Auftraggebern anzubieten. Aus obigem ergibt sich, dass das Firmware-Management-Tool FMT eine eindeutige Erfahrung, Unterstützung und Betreuung eines vollständigen Lebenszyklus von Daten betreffend die Geräte-Domäne bereitstellt. Das Firmware-Management-Tool verbessert die Akquirierung und Verwaltung aller für den Download/Bereitstellung wichtiger Informationen. Somit wird die Komplexität für verschiedene Bereiche des Informationsund Datenflusses reduziert.
Fig. 5 zeigt rein schematisch eine Architektur des Lade-Tools LT, umfassend eine An wendungs schicht AL mit Anwendungs-Software AS sowie eine Service-Schicht SL mit Device-Services DS. Die Anwendungs-Software AS definiert Sequenzen und Verhalten betreffend eines definierten Ablaufschemas wie:
Cached loading (Firmware-Dateien bzw. Pakete werden zuerst auf Geräte abgelegt und anschließend von dort installiert),
Direct Streamed loading (Die Firmware-Dateien werden in einzelnen Dateien nach und nach übertragen und installiert) und/oder
Laden via SD-Card oder USB-Strick des Firmware-Updates (Firmware- Dateien/Paket werden auf ein tragbares Medium kopiert und anschließend in das Zielgerät eingesteckt und von dort aus per Kommunikationsbefehl oder Geräteneustart installiert).
Des Weiteren enthält die Applications-Software AS Informationen betreffend die Anwendung von Device-Services DS, um die Firmware-Dateien in das entsprechende Automatisierungsgerät Dl ... Dn zu laden.
Der Service-Layer SL repräsentiert die Device-Service-Infrastruktur DSI mit den generischen Device-Services DS wie Lade-Service LS, Informations-Service IS, Verbindungs-Service CS, Notifikations-Service NS oder Discovery-Service DS, über die generische Operationen definiert werden.
Fig. 6 zeigt rein schematisch verschiedene Service-Domains der Device-Service- Infrastruktur DSI. Dabei dient jede Service-Domain einem bestimmten Zweck. Dabei bestehen Abhängigkeiten zwischen den Service-Operationen und den Service- Bereichen. Beispielsweise kann ohne den Service„Connect" kein Service„Get Device Information" ausgeführt werden. Für ein Firmware-Loading müssen folglich mehrere Service-Operationen miteinander kombiniert werden. Die einzelnen Service- Operationen werden nachfolgend erläutert.
Über den Verbindungs-Service CS wird beispielswiese eine Verbindung zwischen dem Lade-Tool LT und dem Gerät geöffnet oder geschlossen und die Berechtigung abgefragt.
Über den Informations-Service IS wird eine protokollunabhängige Kommunikation mit dem Gerät Dl ... Dn ermöglicht; über Kommunikationsbefehle wie„Get Device Information" oder„Get Device Status" werden verschiedene Arten von statischen oder dynamischen Geräteinformationen in dem Gerät abgefragt.
Über den Lade-Service LS werden Operationen wie„Download",„Upload",„Send Command" sowie„Get Progress Info" ausgeführt, um z.B. ein Datenpaket DP bzw. Datenfiles aus dem Lade-Tool LT in das Gerät Dl ... Dn zu laden. Auch besteht die Möglichkeit, Daten oder Dateien aus dem Gerät Dl ... Dn herunterzuladen, z. B., um ein Backup von dem Gerät Dl ... Dn zu erstellen. Über den Befehl„Send Command" werden Befehle an das Gerät Dl ... Dn gesendet und über den Befehl„Get Progress Info" können Fortschritts-Informationen während der Lade-Sequenz abgefragt werden.
Mittels des Notifikations-Services NS können über die Operation„Send Notification" Nachrichten an das Gerät Dl ... Dn gesendet werden. Der Notifikations- Ansatz verwendet im Vergleich zu den üblichen Ladeverfahren ein abweichendes Ladeverfahren, welches die Lade-Services, Informations-Services sowie Verbindungs- Services benutzt. Je nach eintreffender Nachricht kann das Gerät selbst entscheiden was die Folgeaktivität ist, z. B. das Herunterladen der Firmware-Datei von einem Server oder nach einer vom Benutzer gemachten Bestätigungseingabe.
Über den Discovery-Service DCS, der vollkommen unabhängig von den anderen Services ist, können Geräte einheitlich in einem Netzwerk aufgefunden werden. Fig. 7a) zeigt rein schematisch eine Kommunikation zwischen der Anwendungs- Software AS des Lade-Tools LT mit dem Gerät Dl ... Dn über die in dem Lade-Tool LT implementierte Device-Service-Infrastruktur DSI auf Basis des„Cached Loading". Nach dem obligatorischen Verbindungsaufbau über den Befehl„Connect" (nicht in Figur dargestellt) fragt die Anwendungs-Software AS über den Befehl„Get Device Information" des Informations-Services IS Geräte-Eigenschafts-Informationen des Geräts Dl ... Dn ab. Nach Empfang der Geräte-Eigenschafts-Informationen erfolgt ein Abgleich der Informationen, insbesondere das Auffinden gemeinsamer Lademöglichkeiten. Unabhängig davon wird eine Kompatibilitätsprüfung durchgeführt, um festzustellen, ob das Firmware-Update überhaupt für das Gerät bestimmt und installiert ist.
In einem weiteren Schritt wird das Datenpaket DP von dem Lade-Tool LT durch die Operation„Download" des Lade-Services LS in das Gerät geladen. Anschließend werden über die Operation„Send Command" Befehle an das Gerät gesendet um dieses in einen Status bzw. Modus zu versetzen, der den Datentransfer und die Firmware- Installation ermöglicht.
In der daran anschließenden Initiierungsphase wird der Installationsbefehl über die Anwendungs-Software AS des Lade-Tools LT der Operation„Send Command" an das Gerät Dl ... Dn gesendet, mit dem die Installation der Firmware in dem Gerät gestartet wird. Während der Installation kann ein Befehl„Get Progress Info" gesendet werden, um den Status des Firmware-Updates abzufragen.
Nach Abschluss der Installation sendet die Anwendungs-Software AS über den Informations-Service den Befehl„Get Device Information", um zu überprüfen, ob der Update- Vorgang der Firmware erfolgreich verlaufen ist.
Fig. 7b) zeigt rein schematisch eine alternative Kommunikation zwischen der Anwendungs-Software AS des Lade-Tools LT und dem Gerät Dl ... Dn, bei welcher der Lade- Vorgang mit den verfügbaren Anpassungsmöglichkeiten an die individuellen Gegebenheiten des Ziel-Geräts angepasst werden. Bei dieser Ausführungsform ist in dem Datenpaket DP ergänzend zu den Firmware-Dateien und den firmwarespezifischen Lade-Informationen eine Skript-Datei enthalten, über die der Ladevorgang der Firmware-Datei entsprechend den Merkmalen und Besonderheiten des Gerätes gesteuert werden kann.
Die weiteren Verfahrensschritte entsprechen den gemäß Fig. 7a) beschriebenen Verfahrensschritten.
Fig. 8 zeigt rein schematisch eine Service-Architektur SAL zur Durchführung einer Protokoll-Umsetzung (Mapping). Mapping bedeutet, dass die generischen Device- Service- Operationen auf konkrete Protokolle abgebildet werden, um die Kommunikation über Operationen auf einem speziellen Protokoll zu ermöglichen. Dabei werden pro tokoll- spezifische Befehle als auch Datenformate verwendet, auf die sowohl die Service-Operationen als auch die operations-spezifischen Daten umgewandelt werden. Der Zugriff durch ein Tool / eine Software auf das gemappte Protokoll findet aber immer noch über die generische Service-Schnittstelle statt und nicht über die Protokoll-Umsetzung.
Die Service-Architektur SAL umfasst den aus Fig. 5 bekannten Service-Layer SL sowie - diesem untergeordnet - einen Mapping-Layer ML, einen Protokoll-Layer PL sowie einen Transport-Layer TL. Übergreifend sind die einzelnen Layer der Service- Architektur SAL über ein Service-Datenmodell SDM sowie ein Sicherheits-Modell SM gekoppelt.
Die Device-Services DS des Service-Layer SL sind ihrerseits protokollunabhängig, um einen einheitlichen Kommunikations-Mechanismus zu ermöglichen.
Allerdings können die Device-Services DS auf verschiedene Protokolle wie MODBUS, FTP (S), EtherNet/IP sowie LWM2M unter Verwendung von Service-Data-Mapping- Informationen DMI der Mapping-Layer ML gemappt bzw. umgesetzt werden. Die einzelnen Kommunikationsprotokolle wie MODBUS, FTP (S) sowie EtherNet/IP stellen jeweils Transportmechanismen wie SL, USB und/oder TCP/IP des Transport- Layer TL zur Verfügung. Für das Protokoll LWM2M wird als Transportmechanismus UDP verwendet.
Alternativ besteht auch die Möglichkeit, als Transportmechanismus ein portables Medium wie USB-Stick oder SD-Card zu verwenden. Das erfindungsgemäße Verfahren ermöglicht auf einfache Weise die Erweiterung auf weitere Protokolle und Transportmechanismen.
Gemäß einem eigenständigen Erfindung sgedanken bezieht sich die Erfindung auf eine standardisierte Beschreibung von Daten wie Anwendungs-Dateien, Konfigurations- Dateien und/oder Firmware-Dateien in Form eines standardisierten Datenpakets ADP, CDP, FWDP.
Fig. 9 zeigt die gegenwärtige Situation, bei der Anwendungs-Dateien AF, Konfigurations-Dateien CF sowie Firmware-Datei FWF nur über entsprechende dezidierte Software-Tools SPT, CST, FLT verarbeitet werden können.
Gemäß der Erfindung werden Datenpakete ADP, CDP, FWDP definiert, welche die Daten in Form von Anwendungs-Dateien AF, Konfigurations-Dateien CF sowie Firmware-Dateien FWF enthalten, und denen zusätzlich Paket-Metadaten MD beigefügt sind, die den Inhalt sowie die Strukturierung des Inhalts der Daten-Pakete ADP, CDP, FWDP in allgemeiner Form beschreiben. Dadurch können unterschiedliche Arten von Inhalt in einer einheitlichen Form sowie die Datenpakete in unterschiedlichen Tools SPT, CST, FLT und/oder Systemen einheitlich verwendet werden. Mit anderen Worten: die Metadaten der Datenpakete ADP, CDP, FWDP enthalten Wissen über deren Inhalt.
Des Weiteren enthalten die Datenpakete ADP, CDP, FWDP Informationen über den Verwendungszweck und besondere Merkmal (Abhängigkeiten, Kompatibilitätsaspekte) ihres Inhalts. Diese Informationen sind mittels einer erweiterten bzw. spezialisierten Metadaten-Beschreibung in dem Datenpaket enthalten. Die Informationen sind abhängig vom Typ des Inhalts. Das bedeutet, dass für jeden Typ ein eigenes standardisiertes Metadaten-Beschreibungsschema bzw. -Syntax definiert ist. Dies schließt z. B. die Empfänger- Adresse sowie deren Zweck mit ein. Ergänzend können spezielle Rooting-Pfade z. B. für Sub-Module oder Sub-Netzwerke in der Datenpaket- Beschreibung mitgeliefert werden.
Die Datenpakete enthalten auch Informationen darüber, wie die Daten benutzt oder angewendet werden sollen, z. B. wie die Daten oder das Datenpaket mit Geräten ausgetauscht werden können oder wie eine Software-Library auf dem Zielgerät installiert werden kann. Ferner können in den Datenpaketen Befehlslisten enthalten sein, die das verarbeitende Tool SPT, CST, FLT oder das jeweilige Gerät befähigen, eine Sequenz von notwendigen Schritten auszuführen. Die Datenpakete ADP, CDP, FWDP beschreiben weiterhin, welche notwendigen Anforderungen zur Benutzung oder Anwendung des Inhalts der Datenpakete mit dem Zielgerät zu beachten sind. Des Weiteren enthält das Datenpaket Informationen über die Kompatibilität und Abhängigkeiten, die zu berücksichtigen sind, wenn der Inhalt benutzt wird.
Über einen gemeinsamen Paket-Frame werden die interne Datei-Organisation und die äußere Erscheinung definiert. Jedermann kann das Datenpaket identifizieren und weiß genau, wo bestimmte Dateien in dem Datenpaket platziert sind.
Die Datenpakete sind als Basis- und detaillierte Teile definiert. Dies ermöglicht die Erweiterbarkeit für neue Domains oder Anforderungen in einfacher Weise. Ein Datenpaket kann verschiedene Typen von Dateninhalten in üblicher Art und Weise beschreiben, wie z. B. Firmware-Updates, Software-Libraries, Konfigurations-Daten oder Geräte- Anwendungen.
Des Weiteren können mehrere Datenpakete in ein Container-Paket zusammengefasst werden um z. B. Dateninhalte für verschiedene Zielgeräte wie beispielsweise für sämtliche Automatisierungsgeräte eines Produktionssystems oder Bereichs bereitzustellen. Durch die erfindungs gemäßen Datenpakete ist es möglich, unterschiedliche Dateninhalts-Typen in einer allgemeinen Art und Wise zu beschreiben, so dass alle am Kommunikationsablauf beteiligten Komponenten oder Instanzen genau wissen, wie die Daten zu interpretieren sind, um die erforderlichen oder benötigten Informationen zu erhalten.
Die Datenpakete sind in ihrer Art als intelligent zu bezeichnen, da sie sowohl ihren Inhalt beschreiben als auch Informationen enthalten, wie der Inhalt zu interpretieren und zu handhaben ist. Die Datenpakete liefern unterschiedliche Arten von Informationen, um imstande zu sein, den Dateninhalt auch ausführen zu können. In diesem Zusammenhang ist anzumerken, dass das Wissen über die Daten und deren Nutzung mit dem Datenpaket selbst und nicht durch das Verarbeitungs-Tool SPT, CST bzw. FLT bereitgestellt werden. Das Tool muss nur die benötigten generischen Services als auch deren allgemeine (Basis-) Ablauf- bzw. Aufruf-Sequenzen bereitstellen.
Fig. 11 zeigt in schematischer Darstellung die Struktur der Datenpakete ADP, CDP, FWDP sowie deren Einbindung in ein Container-Paket CP. Das Container-Paket enthält Paket-Metadaten PMD, die User- spezifische Informationen darüber enthalten, was ein Anwender mit den einzelnen Datenpaketen ADP, CDP, FWDP machen kann. Über einen Assignment-Layer AL erfolgt via Adresse ADR eine Zuweisung zu den gewünschten Datenpaketen ADP, CDP, FWDP.
Die zuvor wiedergegebene Inhaltsbeschreibung des jeweiligen Datenpaketes ist in sogenannten Paket-Metadaten PMD enthalten, die innerhalb des Datenpakets auf spezifische bzw. detaillierte Metadaten wie Firmware-Metadaten FWMD oder Anwendungs-Metadaten AMD referenzieren, die eine detaillierte Inhaltsbeschreibung enthalten, wie die in den jeweiligen Datenpaketen ADP, CDP, FWDP enthaltenden Dateien, wie Firmware-Dateien FWF oder Anwendungs-Dateien AF, zu behandeln sind, insbesondere welche Lade-Mechanismen zu beachten sind bzw. bei Applikations- Daten, welche Abhängigkeiten zu berücksichtigen sind.

Claims

Patentansprüche Firmware-Management-System sowie Firmware-Management- Verfahren zum Update von Firmware von Geräten
1. Firmware-Management-System (FMS2) zur Aktualisierung von Firmware (FWI, FW2, FW3) von in einem Netzwerk (N) eingebundener Geräte (Dl, D2, D3) wie Automatisierungsgeräte und/oder Energie-Management-Geräte, umfassend ein Firmware-Management-Gerät (FMU) für den Zugriff auf zumindest einen ersten Datenspeicher (DR1) sowie zumindest eines der Geräte (Dl, D2, D3), wobei der zumindest eine erste Datenspeicher (DR1) wenigstens ein Datenpaket (DP) mit zumindest einer Firmware-Datei (FWF) aufweist und wobei im Zusammenwirken des Firmware-Management-Geräts (FMU) und dem zumindest einen ersten Datenspeicher (DR1) selektiv zumindest ein Datenpaket (DP) in zumindest ein Gerät (Dl, D2, D3) ladbar ist,
d a d u r c h g e k e n n z e i c h n e t ,
dass das Firmware-Management-Gerät (FMU) ein Firmware-Management- Tool aufweist, welches ausgebildet ist, um in dem Netzwerk (N) eingebundene Geräte (Dl, D2, D3) zu erkennen und in den Geräten (Dl, D2, D3) gespeicherte gerätespezifische Lade-Informationen (Dil, DI2, DI3) zu erfassen und diese in einer Datenbank (DLDB) eines zweiten Datenspeicher (DR2) in Form einer Geräteliste (DL) und/oder Netzwerk-Topologie (NT) zu speichern und dass das Firmware-Management-Tool Mittel zum Abgleich der gerätespezifischen Lade- Informationen (Dil, DI2, DI3) mit in dem zumindest einen Datenpaket (DP) enthaltenen firmwarespezifischen Lade-Informationen (FWI) aufweist, wobei unter Berücksichtigung korrespondierender Lade-Informationen ein automatischer Update der Firmware (FWI, FW2, FW3) der Geräte (Dil, DI2, DI3) über das zumindest eine Lade-Tool (LT1, LT2, LT3) durchführbar ist.
2. Firmware-Management-System nach Anspruch 1 ,
dadurch gekennzeichnet ,
dass das Firmware-Management-Tool (FMT) über ein modulares Netzwerk- Interface (NI) mit dem Netzwerk (N) verbunden ist, wobei in das modular aufgebaute Netzwerk-Interface (NI) verschiedene Kommunikationsprotokolle bzw. Kommunikations-Mechanismen Nil, NI2, NI3), wie Modbus, Ethernet- IP, FTP als Plug-in implementierbar sind.
3. Firmware-Management-System nach Anspruch 1 ,
dadurch gekennzeichnet ,
dass das Firmware-Management- Tool (FMT) über eine Datenschnittstelle (DI2) mit einem Software-Update-Client (SUC) verbunden ist, über den ein automatischer Download von gewünschten Datenpaketen (DP) von einem Software-Update-Server (SUS) ausführbar ist.
4. Firmware-Management-System nach Anspruch 1 ,
dadurch gekennzeichnet ,
dass das Firmware-Management-Tool (FMT) ein modular aufgebautes Lade- Interface (LI) aufweist, umfassend eine oder mehrere Lade-Tools oder Lade- Mechanismen (LTl, LT2, LT3), die als Plug-in in das Lade-Interface LI implementierbar sind.
5. Firmware-Management-System nach Anspruch 1 ,
dadurch gekennzeichnet ,
dass zumindest eines der Lade-Tools (LTl) eine Device-Service-Infrastruktur (DSI) zur Service-orientierten Kommunikation mit den Geräten (Dl, D2, D3) aufweist.
6. Firmware-Management- Verfahren zur Aktualisierung von Firmware von zumindest einem in einem Netzwerk eingebundenen Gerät wie Automatisierungsgerät und/oder Energie-Management-Gerät, umfassend die Verfahrensschritte:
- Download zumindest eines eine Firmware-Datei aufweisenden Datenpakets in eine Datenbank eines Datenspeichers eines Firmware- Management- S y stems ,
- Selektieren eines Datenpakets und
- Laden des Datenpakets über ein Lade-Tool in das zumindest eine Gerät, gekennzeichnet durch die weiteren Verfahrensschritte:
- Erkennen der in dem Netzwerk vorhandenen Geräte mittels eines in dem Firmware-Management-Gerät implementierten Firmware-Management- Tools,
- Erfassen von gerätespezifischen Lade-Informationen der erkannten Geräte,
- Speichern der erkannten Geräte und deren gerätespezifischen Lade- Informationen in einer Datenbank,
- Selektieren zumindest eines eine Firmware-Datei enthaltenden Datenpakets aus der ersten Datenbank auf der Grundlage der gerätespezifischen Lade-Informationen und
- Laden des selektierten Datenpakets über das Lade-Tool in das entsprechende Automatisierungsgerät.
7. Firmware-Management- Verfahren nach Anspruch 6,
dadurch gekennzeichnet ,
dass das Verfahren die weiteren Verfahrensschritte umfasst:
- Handhabung von Geräte-Information sowie Datenpaket in Form von z.
B. Firmware-Update-Datei durch Kompatibilitäts-Überprüfung
- Verwaltung von Geräte-Information sowie Datenpaket in Form von z. B.
Firmware-Update-Datei und/oder
- Bereitstellung und Abfrage von Datenpaketen .
8. Firmware-Management- Verfahren nach Anspruch 6 oder 7,
dadurch gekennzeichnet , dass die Datenpakete sowie die Geräteliste mit gerätespezifischen Lade- Informationen in einer gemeinsamen Datenbank gespeichert werden.
9. Firmware-Management- Verfahren nach einem der Ansprüche 6 bis 8,
dadurch gekennzeichnet ,
dass die Datenpakete automatisch durch das Firmware-Management- Tool über einen Software-Update-Client angefragt und in die Datenbank importiert werden.
10. Firmware-Management- Verfahren nach zumindest einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet ,
dass Informationen zur Handhabung der Datenpakete und der darin enthaltenden Firmware-Dateien als Metadaten wie Datenpaketinformationen und/oder Firmware-Metadaten wie firmwarespezifische Lade-Informationen in dem Datenpaket gespeichert werden.11. Firmware-Management- Verfahren nach zumindest einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet ,
dass die gerätespezifischen Lade-Informationen zusammen mit den firmwarespezifischen Lade- Informationen in dem Datenpaket bereitgestellt und in das Lade-Tool geladen werden.
11. Firmware-Management- Verfahren nach zumindest einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet ,
die firmwarespezifischen Lade-Informationen Informationen wie Art und Identifikationsnummer der Zielgeräte, Firmware- Versions-Informationen, Kommunikationsprotokoll-Informationen, Gerätemodi-Informationen und/oder Installations-Informationen enthalten.
12. Firmware-Management- Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet ,
dass die gerätespezifischen Lade-Informationen Informationen wie Geräte-ID- Informationen, aktuelle Firmware- Versions-Informationen, Statusinformationen, Speicherinformationen, Kommunikationsprotokoll-Informationen, Lademodi- Informationen und/oder Installations-Informationen enthalten.
13. Firmware-Management- Verfahren nach zumindest einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet ,
dass die firmwarespezifischen Lade-Informationen und die gerätespezifischen Lade-Informationen vor dem Start des Ladevorgangs durch das Lade-Tool interpretiert werden, wobei durch Abgleich der Lade-Informationen ein Ladevorgang mit von dem Gerät und dem Datenpaket unterstützten, kompatiblen Lade-Informationen ausgewählt wird und eine einheitliche Service- Kommunikationsschnittstelle des Lade-Tools entsprechend übereinstimmender Lade- Informationen eingestellt wird.
14. Firmware-Management- Verfahren nach zumindest einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet ,
dass die einheitlichen Kommunikation zwischen dem einen Lade-Tool und dem einen oder mehreren unterschiedlichen Geräten über die einheitliche Service- Kommunikationsschnittstelle mit generischen Services erfolgt, wobei die Services einen gemeinsamen Satz von Device-Services definieren, über die Daten und/oder Informationen in Form von Service-Operationen von und zu dem/den Geräten gesendet bzw. empfangen werden.
15. Firmware-Management- Verfahren nach zumindest einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet ,
dass protokollunabhängige Device-Services verwendet werden.
16. Firmware-Management- Verfahren nach zumindest einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet ,
dass die Device-Services auf verschiedene Kommunikations-Protokolle und Transportmechanismen umgesetzt werden.
17. Firmware-Management- Verfahren nach zumindest einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet ,
dass die Kommunikation des Lade-Tools mit dem Gerät und/oder externen Datenquellen über die Device-Services erfolgt, wobei die Device-Services ein Set von generischen Services wie Verbindungs-Service, Informations-Service, Datenaustausch-Service, Notifikations-Service und/oder Diagnose-Service bereitstellen.
18. Firmware-Management- Verfahren nach zumindest einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet ,
dass das Datenpaket einschließlich Firmware-Dateien und/oder Lade- Informationen über einen drahtgebundenen oder drahtlosen Kommunikationsmechanismus wie Feldbus oder WLAN oder über einen mobilen Datenträger wie USB -Stick oder SD-Card in das Gerät geladen werden.
19. Firmware-Management- Verfahren nach zumindest einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet ,
dass die Device-Services der Device-Service-Infrastruktur für verschiedene Aufgaben wie Firmware-Management, Anwendungs-Management und/oder Konfigurations-Management verwendet werden.
PCT/EP2015/079228 2014-12-12 2015-12-10 Firmware-management-system sowie firmware-management-verfahren zum update von firmware von geräten WO2016092006A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102014118552.8A DE102014118552A1 (de) 2014-12-12 2014-12-12 Firmware-Management-System sowie Firmware-Management-Verfahren zum Update von Firmware von Geräten
DE102014118552.8 2014-12-12

Publications (1)

Publication Number Publication Date
WO2016092006A1 true WO2016092006A1 (de) 2016-06-16

Family

ID=55304954

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2015/079228 WO2016092006A1 (de) 2014-12-12 2015-12-10 Firmware-management-system sowie firmware-management-verfahren zum update von firmware von geräten

Country Status (2)

Country Link
DE (1) DE102014118552A1 (de)
WO (1) WO2016092006A1 (de)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
LU501705B1 (de) * 2022-03-24 2023-09-25 Phoenix Contact Gmbh & Co Verwaltungs- und Aktualisierungssystem für an ein OT-Netzwerk angeschlossene Automatisierungsgeräte einer Automatisierungsanlage
US12079619B2 (en) 2022-07-27 2024-09-03 T-Mobile Usa, Inc. Firmware-over-the-air (FOTA) update for wireless devices in an internet of things (IoT) network

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080028385A1 (en) * 2006-07-26 2008-01-31 Dell Products L.P. Apparatus and Methods for Updating Firmware
DE102006044182A1 (de) 2006-09-15 2008-03-27 Abb Patent Gmbh System und Verfahren zur bedarfsgerechten Funktionalisierung von Steuer-/Regeleinrichtungen
US20100260066A1 (en) * 2009-04-14 2010-10-14 August Jared P Network discovery and data transfer using snmp in an electric power transmission or distribution system

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007536634A (ja) * 2004-05-04 2007-12-13 フィッシャー−ローズマウント・システムズ・インコーポレーテッド プロセス制御システムのためのサービス指向型アーキテクチャ
US7424327B2 (en) * 2005-02-04 2008-09-09 Rockwell Automation Technologies, Inc. System and method for automatically matching programmable data of devices within an industrial control system
US7734590B2 (en) * 2005-09-30 2010-06-08 Rockwell Automation Technologies, Inc. Incremental association of metadata to production data
US20070233782A1 (en) * 2006-03-28 2007-10-04 Silentclick, Inc. Method & system for acquiring, storing, & managing software applications via a communications network

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080028385A1 (en) * 2006-07-26 2008-01-31 Dell Products L.P. Apparatus and Methods for Updating Firmware
DE102006044182A1 (de) 2006-09-15 2008-03-27 Abb Patent Gmbh System und Verfahren zur bedarfsgerechten Funktionalisierung von Steuer-/Regeleinrichtungen
US20100260066A1 (en) * 2009-04-14 2010-10-14 August Jared P Network discovery and data transfer using snmp in an electric power transmission or distribution system

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
LU501705B1 (de) * 2022-03-24 2023-09-25 Phoenix Contact Gmbh & Co Verwaltungs- und Aktualisierungssystem für an ein OT-Netzwerk angeschlossene Automatisierungsgeräte einer Automatisierungsanlage
WO2023180442A1 (de) * 2022-03-24 2023-09-28 Phoenix Contact Gmbh & Co.Kg Verwaltungs- und aktualisierungssystem für an ein ot-netzwerk angeschlossene automatisierungsgeräte einer automatisierungsanlage
US12079619B2 (en) 2022-07-27 2024-09-03 T-Mobile Usa, Inc. Firmware-over-the-air (FOTA) update for wireless devices in an internet of things (IoT) network

Also Published As

Publication number Publication date
DE102014118552A1 (de) 2016-06-16

Similar Documents

Publication Publication Date Title
EP3230856B1 (de) Verfahren zum update von firmware von geräten
DE102020124789A1 (de) Hyperkonvergente architektur für industrieleitsystem
DE102010029952A1 (de) Verfahren zum Integrieren von zumindest einem Feldgerät in ein Netzwerk der Automatisierungstechnik
DE102010026494A1 (de) Verfahren zur Konfigurierung einer Steuerungseinrichtung
DE102011080538A1 (de) Verfahren und Einrichtung zum Konfigurieren von Endgeräten
EP1430369B1 (de) Dynamischer zugriff auf automatisierungsressourcen
DE102006044182A1 (de) System und Verfahren zur bedarfsgerechten Funktionalisierung von Steuer-/Regeleinrichtungen
DE102009054901A1 (de) Verfahren zur offline Bedienung eines Feldgeräts der Automatisierungstechnik
DE102006062478B4 (de) Verfahren zum Betreiben eines objektbasierten Konfigurationssystems für Feldgeräte der Automatisierungstechnik
DE10251523A1 (de) System und Verfahren zur Bereitstellung von Daten und Diensten für Geräte, sowie Gerät, welches die bereitgestellten Daten und Dienste verwendet
DE102014001462B4 (de) Feldbusmodul, Maschinensteuerung und Verfahren zur Parametrierung eines, insbesondere sicherheitsgerichteten, Feldbusmoduls
EP3650968A1 (de) Verfahren zum betrieb einer produktions- oder werkzeugmaschine und produktions- oder werkzeugmaschine sowie computerprogramm zum betrieb einer produktions- oder werkzeugmaschine
WO2016092006A1 (de) Firmware-management-system sowie firmware-management-verfahren zum update von firmware von geräten
DE112010005509T5 (de) Robotersystemsteuerverfahren und eine Vorrichtung davon
EP3341276A1 (de) Steuervorrichtung, rechner und kommunikationssystem
EP3467600A1 (de) Cloud zentralmodul für eine speicherprogrammierbare steuerung
EP4136824B1 (de) Gerät zum einsatz im internet der dinge
DE102010053486A1 (de) Verfahren zum Betreiben einer Arbeitsmaschine und Arbeitsmaschine
DE10330191A1 (de) System bzw. Verfahren zur Freigabe freigabebedürftigter Softwareprogramme
EP4160390A1 (de) Verfahren und anordnung zur inbetriebnahme einer aktualisierten anwendung für eine industrielle automatisierungsanordnung
EP3617823B1 (de) Verfahren zur integration von datenquellen sowie integrations-middleware
EP3482467B1 (de) Steckverbinderbauteil, steckverbinder, steckverbindersystem und verfahren zum zusammensetzen und betreiben eines steckverbinders
DE102017209493A1 (de) Verfahren und System zur Durchführung eines Setups bei einem industriellen Netzwerk
WO2003026208A2 (de) Datenverarbeitungsanlage, ressourcensteuergerät und verfahren zur fernverwaltung von ressourcen mittels generisch gekennzeichneten ressoucenbeschreibungsdaten
EP4338050A1 (de) Verwaltung von laufzeitcontainern für ein industrielles automatisierungssystem

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: 15832685

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: 15832685

Country of ref document: EP

Kind code of ref document: A1