WO2016180550A1 - Verfahren zur aktualisierung von komponenten in automatisierungssystemen - Google Patents

Verfahren zur aktualisierung von komponenten in automatisierungssystemen Download PDF

Info

Publication number
WO2016180550A1
WO2016180550A1 PCT/EP2016/053807 EP2016053807W WO2016180550A1 WO 2016180550 A1 WO2016180550 A1 WO 2016180550A1 EP 2016053807 W EP2016053807 W EP 2016053807W WO 2016180550 A1 WO2016180550 A1 WO 2016180550A1
Authority
WO
WIPO (PCT)
Prior art keywords
status
functional unit
uef
updated
automation
Prior art date
Application number
PCT/EP2016/053807
Other languages
English (en)
French (fr)
Inventor
Daniel LECHNER
Ralf MOSSHAMMER
Original Assignee
Siemens Ag Österreich
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens Ag Österreich filed Critical Siemens Ag Österreich
Publication of WO2016180550A1 publication Critical patent/WO2016180550A1/de

Links

Classifications

    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00—Programme-control systems
    • G05B19/02—Programme-control systems electric
    • G05B19/04—Programme control other than numerical control, i.e. in sequence controllers or logic controllers
    • G05B19/042—Programme control other than numerical control, i.e. in sequence controllers or logic controllers using digital processors
    • G05B19/0426—Programming the control sequence
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B15/00—Systems controlled by a computer
    • G05B15/02—Systems controlled by a computer electric
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/20—Pc systems
    • G05B2219/26—Pc applications
    • G05B2219/2639—Energy management, use maximum of cheap power, keep peak load low
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/06—Energy or water supply

Definitions

  • the present invention relates to a method for updating functional units, such as automation functions, of components in automation systems for electrical networks.
  • the electrical grids to which the method according to the invention is applied may in particular be low-voltage grids. These are part of the electricity distribution network that distributes electrical energy to most of the final electrical consumers consisting of low voltage equipment. In order to avoid voltage losses, low-voltage networks are limited in the spatial extent to a range of some 100 m to a few kilometers. They are therefore fed regionally via transformer stations from a higher-level medium-voltage network. In Europe, they are usually operated with a mains voltage of 230 V (between each phase conductor and the neutral conductor) or 400 V (between the three external conductors), but in any case only up to 1000 V.
  • Rated power of individual local network transformers can vary depending on the target network planning of the respective
  • Distribution system operators vary, but are typically 250 or 400 kVA for rural areas and 630 or 800 kVA for inner-city areas.
  • the method according to the invention is applied to so-called “smart grids", ie intelligent grids, which provide for communicative networking and control of power grids. generating, storing, electrical consumers and network resources in energy transmission and distribution networks of the electricity supply.
  • the method according to the invention can also be applied to smaller electrical low-voltage networks, for example those within so-called “Smart Buildings”, also referred to as intelligent houses or intelligent buildings.
  • Smart buildings include, for example, fluctuating producers (eg photovoltaic systems, small wind turbines), flexible consumers and storage for electrical energy, or for example the charging infrastructure for electric vehicles, the building becomes “smart” or intelligent through the use of a modern building automation system (CEMS - Customer Energy Management System).
  • Building automation encompasses the entirety of monitoring, control, regulation and optimization facilities in buildings. The goal is to carry out functional sequences independent of the component (automatically) and according to preset settings (parameters). All sensors, actuators, controls, consumers and other technical units in the building are networked together.
  • Characteristic feature is the continuous networking by means of a bus system.
  • the building automation systems of the Smart Buildings, or the energy management systems as part of the building automation systems can usually optimize the internal needs of electrical and thermal energy for the individual components of the building, create local (building-related) forecasts and flexible tariff specifications, the market or ., also have network-specific shares.
  • Components of a low-voltage network may be: generators (eg photovoltaic systems, small wind turbines), storage (eg batteries, heat pumps), such as charging stations for electric vehicles, flexible consumers (eg electric storage heaters, buildings / households with and without building automation system) and network resources (transformers, lines, fuses , Measuring devices such as smart meters, transformer step dividers, etc.).
  • generators eg photovoltaic systems, small wind turbines
  • storage eg batteries, heat pumps
  • charging stations for electric vehicles eg electric vehicles, flexible consumers (eg electric storage heaters, buildings / households with and without building automation system) and network resources (transformers, lines, fuses , Measuring devices such as smart meters, transformer step dividers, etc.).
  • Many of the components or devices in a smart grid or smart building can be integrated in a common automation system and each have one or more functional units, in particular automation functions, implemented as software units.
  • the present invention thus relates to the maintenance, supply and configuration of extremely distributed components in an automation system or the functional units of the components, in particular in a critical operating environment, such as in smart grids or smart buildings.
  • a critical operating environment such as in smart grids or smart buildings.
  • these automation systems In order for these automation systems to be operated safely, it may only be a few or short
  • IED intelligent electronic devices
  • a common functional unit or automation function in smart grid components is, for example, the so-called optimizer or optimizer, which operates in dependence on sensor input data of its host system, e.g. an algorithm for voltage regulation or a function for charge management of electric cars. If these components or their functional units constantly receive a stream of data, they can not work efficiently immediately after being turned on. Instead, they will build up over time, structured memory representation of their environmental conditions, e.g. the amount of electrical voltage over the last quarter of an hour, or the number of electric cars to be charged. Now, if a new or updated functional unit or automation function is introduced into the automation system, this knowledge should be transferred as far as possible to the new functional unit or automation function so that it can start its work as quickly as possible.
  • This task can be easily solved with two structurally identical components of an automation system.
  • the task can be more complex when a new state is introduced, a state is transformed, or it no longer exists in the new automation function.
  • a transformation component - usually in the form of a software-implemented module - must be made available. This transformation component translates a status information from one functional unit or automation function to the other functional unit or automation function.
  • Extracting the current status of an operating unit or automation function in operation can basically be done on two levels: by the program environment (deployment platform), which operates the automation function, such as the operating system or the JVM (Java Virtual Machine), or at the level of the functional unit or automation function itself.
  • the program environment deployment platform
  • the automation function such as the operating system or the JVM (Java Virtual Machine)
  • the JVM Java Virtual Machine
  • At least one transfer function is created, which describes the transition of the individual status variables of the status of an earlier functional unit to the status variables of the status of the updated functional unit, the status describing the prevailing operating conditions of the functional unit,
  • the transfer function is applied to the status of the previous functional unit, if it is not active, and
  • Applying a transfer function ensures that the functional unit affected by an upgrade can quickly resume work based on its known state after the upgrade. Since the application of the transfer function takes place when the affected functional unit is not working or is not "online" in the automation system, it is ensured that interim changes of the status variables do not create undefined states.
  • a test of the updated functional unit may take place after the updated status has been supplied and before the updated functional unit has been activated.
  • a test of the updated functional unit takes place in any case as part of the function activation.
  • Update Manager This own software unit is referred to below as Update Manager.
  • Update Manager The separation of detection of the status on the one hand and application of the transfer function on the other hand makes it possible to perform several update steps in succession, ie in one step - while the affected functional unit is only inactive once.
  • Update Manager in the software unit for transmission - i. in Update Manager - several transfer functions for different functional units or automation functions and / or for various updated versions of a functional unit or automation function are stored.
  • the application of the transfer function is triggered by a mechanism for functional activation, such as a mechanism for continuous integration and / or a version management.
  • each applied transfer function is saved, for example in the Update Manager, the update process can be checked afterwards. If several updates are to occur immediately after one another, several transfer functions can be used in one update step. This reduces downtime of a functional unit, which can be caused by several updates.
  • the method according to the invention is used in particular when the automation system is integrated in a smart grid or a smart building.
  • the subject invention also relates to a computer program product.
  • This computer program product comprises a program and can be loaded directly into a memory of a computer (eg a specific control or regulation unit of a component or a device of the low-voltage network) of the automation system of a low-voltage network, with program means for carrying out all steps of the method according to the invention when the program is executed by the computer.
  • a computer eg a specific control or regulation unit of a component or a device of the low-voltage network
  • program means for carrying out all steps of the method according to the invention when the program is executed by the computer.
  • the dynamic properties of a functional unit or automation function can be described as a set S of an arbitrary number N of status variables sl, s2, sN.
  • Each state variable may also be identified by some or all of the following attributes:
  • mapping For all properties that are specific to a particular application (a particular programming language or a particular pro- identical, then the status variables are identical as well. If all status variables in the set S that represent the status of the functional unit are identical, then the transfer from the old status Soi d to the new status S new can be done by a simple mapping - a so-called mapping:
  • This transfer function transfers the transformation of each status variable of the old record S 0 i d to the corresponding status tag in the new record S new -
  • the following transformations can take place:
  • mapping to the new status variable is a simple rename process
  • a new status variable is introduced, which has no relation to old status variables: the new status variable is filled with a suitable default value.
  • the value range of the new status variable is different than that of the old status variables: if the new value range is smaller, a corresponding logic must be provided if the old value range outside the new lies. For example, a three - level status "clear - suspicious - alert" could be provided instead of "on / off", or vice versa.
  • a new status variable is introduced, which is composed of several old status variables: a corresponding combination logic must be provided.
  • An old status variable is divided into several new status variables, possibly with new value ranges: a corresponding logic must be made available.
  • Continuous integration describes in software development the process of continuously assembling components into an application.
  • the goal of continuous integration is to increase software quality.
  • Typical actions are the translation and linking of the application parts, but in principle also any other operations for generating derived information can be performed.
  • Typical actions are the translation and linking of the application parts, but in principle also any other operations for generating derived information can be performed.
  • Typical actions are the translation and linking of the application parts, but in principle also any other operations for generating derived information can be performed.
  • the entire process is usually triggered automatically by checking in the version management. This is used to record changes to documents or files. All versions are saved in an archive with timestamp and user ID and can be restored later. Versioning systems are typically used to manage source code.
  • a trigger in the continuous integration or versioning applications triggers the automatic validation of all status variables for changes in meaning compared to previously enabled or confirmed versions.
  • the system designer would then be notified if transfer functions are missing, in the meantime so-called skeletons of transfer functions or, in the case of simple transformations, also complete transfer functions can be made available automatically.
  • a skeleton is an automatically generated structure (usually a source text), which can then be expanded further. Skeletons can often already be compiled and tested.
  • the integration test is a concerted series of individual tests that serve to test different interdependent components of a system in interaction with each other.
  • a successful update for an electronic component or electronic device integrated into an automation system includes, for example, the following steps:
  • Update Manager which now knows how to transform the old set of status variables (that of the old functional unit) to the new set of status variables (that of the new functional unit).
  • the Update Manager can add multiple have locally stored transfer functions which differ in each case by the functional unit to which they belong and the transfer step (migration step), eg, ("from 1.11 to 1.12beta").
  • the input data stream supplied to the old functional unit is truncated to prevent the status of the old functional unit from changing while the update (update) of the functional unit is being performed. In most cases, the input data stream is buffered until the new functional unit of the component starts to work, so that no relevant events are missed.
  • the execution of the old functional unit is stopped because it could continue to work without external signals, for example due to timers, and thus could change its status.
  • the status of the old functional unit is extracted and saved.
  • the transfer function is applied to the stored state to generate the input status for the new functional unit.
  • the new status ie the new set of status variables, will be used in the new functional unit.
  • the input data stream is routed to the new functional unit and it starts to work.
  • the old functional unit If the old functional unit is still used, it must also be reconnected to the input data stream and restarted.
  • the status is transferred at the level of the application, that is to say at the level of the individual functional unit, by means of a software of its own, functional unit, the update manager.
  • This has the advantage over more integrated solutions the detection of the current status of a function entity from the actual transfer of the status to a new functional unit or a new version of the functional unit takes place separately. This in turn facilitates testing. A resort to other solutions and thus a use of system resources on the platform concerned (here in the operating system DP) are spared.
  • An update of the transfer process itself also affects only a specific component and not all updatable components in the automation system.
  • the update manager and the status transfer procedure are independent of the execution environment or the programming language.
  • the method of updating or transmitting the status of a functional unit is closely involved in the development or activation level. Human errors are detected as far as possible by checking the correct transmission of the status when the new functional unit is activated offline. Additional mostly software implemented tools can be provided to facilitate the implementation of the transfer functions.
  • FIG. 1 shows a schematic representation of a process according to the invention. procedure for updating functional units of components of an automation system.
  • the figure shows an exemplary structure of a component (or device) that is part of a smart grid or a smart building. For the sake of simplicity, only the elements essential to the invention are shown.
  • the component has an operating system DP, from which several functional units or automation functions are controlled.
  • the exemplified component e.g. two functional units, namely two automation functions SA_A and SA_B, and an inventive Update Manager UM driven by the operating system DP.
  • the automation function SA_A is in version # 1
  • the automation function SA_B is already in version # 3.
  • the component is embedded in an automation system and receives from it a command B for updating its functional units SA_A, SA_B, namely for updating the automation function SA_A to version # 2.
  • the automation function SA_A in the second version # 2 itself is transmitted to the Update Manager UM.
  • the transfer instruction MI-A for updating the automation function SA_A from the version # 1 to the version # 2 is transmitted to the version directory VR.
  • the transfer instruction MI-A for updating the automation function SA_A from the version # 1 to the version # 2 triggers the formation of a transfer function UEF_A, #l -># 2, which is transmitted to the update manager UM.
  • a version directory VR which is part of a version management, stores all versions # 1, # 2, # 3 of the automation functions SA_A, SA_B. Versioning triggers the update manager to begin updating UM when the versioning service is next active.
  • the new automation function SA_A, # 2 and the transfer function UEF_A, # l -> # 2 are therefore loaded into the component of the automation system to be updated.
  • the transfer function UEF_A, # l -> # 2 is installed in the Update Manager UM.
  • the Update Manager UM now knows how to transform the old set of status variables (that of the old automation function SA_A, # 1) to the new set of status variables (that of the new automation function SA_A, # 2).
  • the update manager UM can have several transfer functions stored locally, which differ in each case by the automation function SA_A, SA_B, to which they belong, and the transfer step, that is to say the version numbers # 1, # 2,.
  • the input data stream supplied to the old automation function SA_A, # 1 is truncated by the Update Manager UM to prevent the status of the old automation function SA_A, # 1 from changing while updating the automation function.
  • the input data stream is buffered until the new automation function SA_A, # 2 starts to work so that no relevant events are missed.
  • the execution of the old automation function SA_A, # 1 is stopped because it could continue working without external signals. Meanwhile, the automation function SA_B, # 3 can continue to run.
  • the status of the old automation function SA_A, # 1 is extracted and stored locally in the device.
  • the transfer function UEF_A, # 1 -># 2 is applied to the stored status to generate the input status for the new automation function SA_A, # 2.
  • the new status ie the new set of status variables, is then inserted into the new automation function SA_A, # 2. Then the input data stream is routed to the new automation function SA_A, # 2 and it starts to work.
  • MI_A transfer instruction (Migration Instructions)

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Economics (AREA)
  • Automation & Control Theory (AREA)
  • Human Resources & Organizations (AREA)
  • Strategic Management (AREA)
  • Quality & Reliability (AREA)
  • Operations Research (AREA)
  • Educational Administration (AREA)
  • Tourism & Hospitality (AREA)
  • Marketing (AREA)
  • General Business, Economics & Management (AREA)
  • Development Economics (AREA)
  • Theoretical Computer Science (AREA)
  • Game Theory and Decision Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Stored Programmes (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zur Aktualisierung von Funktionseinheiten bzw. Automatisierungsfunktionen (SA_A, SA_B) einer Komponente in einem Automatisierungssystem für elektrische Netze, wobei - zumindest eine Übertragungsfunktion (UEF_A, UEF_B) erstellt wird, welche den Übergang der einzelnen Statusvariablen des Status einer früheren Funktionseinheit (SA_A, #1) auf die Statusvariablen des Status der aktualisierten Funktionseinheit (SA_A, #2) beschreibt, wobei der Status die herrschenden Betriebsbedingungen der Funktionseinheit beschreibt, - die Übertragungsfunktion (UEF_A) auf den Status der frühe- ren Funktionseinheit (SA_A, #1) angewendet wird, wenn dieser nicht aktiv ist, und - der aktualisierte Status der aktualisierten Funktionseinheit (SA_A, #2) zugeführt und die aktualisierte Funktionseinheit aktiviert wird.

Description

Besehreibung
Verfahren zur Aktualisierung von Komponenten in Automatisierungssystemen
Gebiet der Erfindung
Die vorliegende Erfindung betrifft ein Verfahren zur Aktualisierung von Funktionseinheiten, wie Automatisierungsfunktionen, von Komponenten in Automatisierungssystemen für elektrische Netze.
Die elektrischen Netze, auf die das erfindungsgemäße Verfahren angewendet wird, können insbesondere Niederspannungsnetze sein. Diese sind ein Teil des Stromnetzes zur Verteilung der elektrischen Energie an den größten Teil der elektrischen Endverbraucher, der aus Niederspannungsgeräten besteht. Um Spannungsverluste zu vermeiden, sind Niederspannungsnetze in der räumlichen Ausdehnung auf einen Bereich von einigen 100 m bis zu einigen wenigen Kilometern beschränkt. Sie werden daher regional über Transformatorenstationen aus einem übergeordneten Mittelspannungsnetz gespeist. Sie werden in Europa üblicherweise mit einer Netzspannung von 230 V (zwischen jedem Außenleiter und dem Neutralleiter) bzw. 400 V (zwischen den drei Außenleitern), jedenfalls aber nur bis zu 1000 V betrieben. Bemessungsleistungen einzelner Ortsnetztransformatoren können je nach Zielnetzplanung des jeweiligen
Verteilnetzbetreibers variieren, liegen aber typischer Weise bei 250 oder 400 kVA für ländliche Gebiete und 630 oder 800 kVA für innerstädtische Gebiete.
Insbesondere wird das erfindungsgemäße Verfahren auf sogenannte „Smart Grids", also intelligente Netze, angewendet, welche eine kommunikative Vernetzung und Steuerung von Strom- erzeugern, Speichern, elektrischen Verbrauchern und Netzbetriebsmitteln in Energieübertragungs- und Energieverteilungsnetzen der Elektrizitätsversorgung verwirklichen.
Das erfindungsgemäße Verfahren kann aber auch auf kleinere elektrische Niederspannungsnetze angewendet werden, etwa auf solche innerhalb sogenannter „Smart Buildings", auch als intelligente Häuser oder intelligente Gebäude bezeichnet. Diese Smart Buildings umfassen etwa fluktuierende Erzeuger (z.B. Photovoltaikanlagen, Kleinwindkraftanlagen) , flexible Verbraucher und Speicher für elektrische Energie, oder zum Beispiel die Ladeinfrastruktur für Elektrofahrzeuge . Das Gebäude wird „smart" bzw. intelligent durch den Einsatz eines modernen Gebäudeautomationssystems (CEMS - Customer Energy Management System) . Gebäudeautomation umfasst die Gesamtheit von Überwachungs- , Steuer-, Regel- und Optimierungseinrichtungen in Gebäuden. Ziel ist es, Funktionsabläufe komponentenübergreifend selbstständig (automatisch) und nach vorgegebenen Einstellwerten (Parametern) durchzuführen. Alle Sensoren, Aktoren, Bedienelemente, Verbraucher und andere technische Einheiten im Gebäude werden miteinander vernetzt. Abläufe können in Szenarien zusammengefasst werden. Kennzeichnendes Merkmal ist die durchgängige Vernetzung mittels eines Bussystems. Die Gebäudeautomationssysteme der Smart Buildings, bzw. die Energiemanagementsysteme als Teil der Gebäudeautomationssysteme, können in der Regel für die einzelnen Komponenten des Gebäudes den Eigenbedarf elektrischer und thermischer Energie optimieren, lokale (auf das Gebäude bezogene) Prognosen erstellen und flexible Tarifvorgaben, die markt- bzw. auch netzspezifische Anteile aufweisen, berücksichtigen.
Die zunehmend von Netzbetreibern gewünschte Automatisierung des Niederspannungsnetzes erzeugt aufgrund der sehr großen Anzahl zu automatisierender Komponenten und deren unterschiedlicher technischer Beschaffenheit eine massive Herausforderung. Die Anbindung messtechnisch interessanter Komponenten, wie Messzähler (Smart Meter) oder Wechselrichteranla- gen, an Datenzentren zwecks Automatisierung ist nicht nur netzwerk- und kommunikationstechnisch anspruchsvoll.
Komponenten eines Niederspannungsnetzes können sein: Stromerzeuger (z.B. Photovoltaikanlagen , Kleinwindkraftanlagen), Speicher (z.B. Batterien, Wärmepumpen), wie Ladestationen für Elektrofahrzeuge, flexible Verbraucher (z.B. elektrische Speicherheizungen, Gebäude/Haushalte mit und ohne Gebäudeautomationssystem) und Netzbetriebsmittel (Transformatoren, Leitungen, Sicherungen, Messgeräte wie Smart Meter, Transformator-Stufensteiler, usw.).
Viele der Komponenten oder Geräte in einem Smart Grid oder Smart Building können in ein gemeinsames Automatisierungssystem eingebunden sein und selbst jeweils über ein oder mehrere - meist als Softwareeinheiten realisierte - Funktionseinheiten, insbesondere Automatisierungsfunktionen, verfügen.
Die vorliegende Erfindung betrifft also die Instandhaltung, die Versorgung und die Konfiguration von extrem verteilten Komponenten in einem Automatisierungssystem bzw. der Funktionseinheiten der Komponenten, insbesondere in einem kritischen Betriebsumfeld, wie eben bei Smart Grids oder Smart Buildings. Damit diese Automatisierungssysteme sicher betrieben werden können, darf es nur wenige bzw. kurze
Stillstandszeiten der einzelnen Komponenten des Automatisierungssystems während einer, meist automatischen, Aktualisierung - einem so genannten Update - oder der Instandhaltung geben .
Stand der Technik
Viele Funktionseinheiten bzw. Automatisierungsfunktionen, die man in intelligenten elektronischen Geräten (intelligent electronic devices, IED) findet, zeichnen sich durch ein Wissen über die Betriebsumgebung aus. Das heißt, sie halten einen internen Status fest, der die gerade herrschenden Betriebsbedingungen beschreibt. Dieser interne Status ändert sich über die Lebenszeit der Funktionseinheit. Bei einer Aktualisierung des statischen (strukturellen) Teils einer Komponente, insbesondere bei als Software realisierten Komponenten wie z.B. dem Quelltext (Sourcecode) oder dem Bytecode, ist es wünschenswert, dass von der aktualisierten Komponente nahtlos der Betrieb der ersetzten Komponente fortgesetzt wird. Die gleiche Aufgabe stellt sich auch bei einem Übergang des Betriebs zwischen Komponenten mit hoher Komplexität.
Eine gängige Funktionseinheit bzw. Automatisierungsfunktion in Smart Grid Komponenten ist etwa der so genannte Optimierer oder Optimizer, der in Abhängigkeit von Sensoreingangsdaten seines Hostsystems arbeitet, also z.B. ein Algorithmus zur Spannungsregelung oder eine Funktion zum Lademanagement von Elektroautos. Wenn diese Komponenten bzw. ihre Funktionseinheiten dauernd einen Strom von Daten erhalten, können diese sofort nach dem Einschalten nicht effizient arbeiten. Stattdessen werden sie über die Zeit strukturierte Daten (memory representation) über ihre Umgebungsbedingungen aufbauen, z.B. die Höhe der elektrischen Spannung über die letzte Viertelstunde, oder die Anzahl der zu ladenden Elektroautos. Wenn nun eine neue oder aktualisierte Funktionseinheit bzw. Automatisierungsfunktion in das Automatisierungssystem eingeführt wird, sollte dieses Wissen soweit wie möglich an die neue Funktionseinheit bzw. Automatisierungsfunktion übertragen werden, damit diese ihre Arbeit so schnell wie möglich aufnehmen kann.
Diese Aufgabe ist bei zwei strukturell gleichen Komponenten eines Automatisierungssystems einfach zu lösen. Die Aufgabe kann komplexer sein, wenn ein neuer Status eingeführt wird, ein Status transformiert wird oder in der neuen Automatisierungsfunktion gar nicht mehr existent ist. In solchen Fällen muss eine Transformationskomponente - üblicherweise in Form eines Software-realisierten Moduls - zur Verfügung gestellt werden. Diese Transformationskomponente übersetzt eine Statusinformation von einer Funktionseinheit bzw. Automatisierungsfunktion auf die andere Funktionseinheit bzw. Automatisierungsfunktion übersetzt.
Das Extrahieren des aktuellen Status einer in Betrieb befindlichen Funktionseinheit oder Automatisierungsfunktion kann grundsätzlich auf zwei Ebenen erfolgen: durch die Programmumgebung (deployment platform) , welche die Automatisierungsfunktion betreibt, also etwa das Betriebssystem oder die JVM (Java Virtual Machine) , oder auf Ebene der Funktionseinheit bzw. Automatisierungsfunktion selbst.
Das Einfrieren des aktuellen Status einer Funktionseinheit ist sehr verbreitet und kommt mehrere tausend Mal in jedem Multitasking-System vor, zumindest wenn die Anzahl der Tasks die Anzahl der verfügbaren Recheneinheiten übersteigt, dies wird als „thread migration" bezeichnet. Es können aber nur Programme mit exakt der gleichen internen Statusrepräsentation ihre Ausführung nach Wiederherstellung des Status wieder aufnehmen. Normalerweise hat das übergeordnete Automatisierungssystem kein Wissen über die Struktur der gespeicherten Statusinformation. Das übergeordnete Automatisierungssystem weiß nur, wo der Status abgespeichert ist. Dies bedeutet, dass es schwer ist, den Status zu migrieren, wenn ein neuer Status eingeführt wird, ein alter Status nicht mehr existiert oder transformiert worden ist. Da die laufenden Funktionseinheiten ihren internen Status kennen, ist die Verwaltung und Übertragung (migration) des Status auf dieser Ebene viel einfacher. In objektorientierten Sprachen ist das Anfertigen eines Schnappschusses des aktuellen Status einer Funktionseinheit auch als „object
serialization" bekannt. Viele objektorientierte Sprachen sehen dazu entsprechende vorgefertigte Mechanismen vor. Zusätzlich gibt es oft Konfigurationsmöglichkeiten für eine Übersetzung des Status in unterschiedliche Formate, so auch in für Menschen lesbare Formate.
Es existieren auch bereits Vorschläge zur Übertragung eines gespeicherten Status, wenn die Aktualisierung der Funktionseinheit bzw. Automatisierungsfunktion nicht kompatibel ist. Der Nachteil bestehender Lösungen ist, dass sie entweder an eine bestimmte Programmiersprache oder Ausführungsumgebung gebunden ist. Zusätzlich mangelt es an einer Möglichkeit, die Übertragung des Status offline durchzuführen. Das heißt, wenn weder die alte Version noch die aktualisierte Version einer Funktionseinheit aktiviert ist oder läuft. Solche Lösungen können daher schwer in ein Automatisierungssystem integriert werden, in welchem ein automatisches und sicheres Update seiner Komponenten bzw. der Funktionseinheiten bzw. Automatisierungsfunktionen dieser Komponenten durchgeführt werden soll.
Darstellung der Erfindung
Es ist somit eine Aufgabe der Erfindung, ein Verfahren anzu- geben, mit welchem ein automatisches und sicheres Update ei- ner Funktionseinheit bzw. einer Automatisierungsfunktion von Komponenten eines Automatisierungssystems durchgeführt werden kann . Diese Aufgabe wird durch ein Verfahren nach Anspruch 1 gelöst, welches vorsieht, dass
- zumindest eine Übertragungsfunktion erstellt wird, welche den Übergang der einzelnen Statusvariablen des Status einer früheren Funktionseinheit auf die Statusvariablen des Status des aktualisierten Funktionseinheit beschreibt, wobei der Status die herrschenden Betriebsbedingungen der Funktionseinheit beschreibt,
- die Übertragungsfunktion auf den Status der früheren Funktionseinheit angewendet wird, wenn dieser nicht aktiv ist, und
- der aktualisierte Status der aktualisierten Funktionseinheit zugeführt und der aktualisierte Funktionseinheit aktiviert wird.
Durch das Anwenden einer Übertragungsfunktion wird sichergestellt, dass die von einer Aktualisierung betroffene Funktionseinheit nach der Aktualisierung rasch wieder die Arbeit auf Basis des bekannten Status fortsetzen kann. Da das Anwenden der Übertragungsfunktion erfolgt, wenn die betroffene Funktionseinheit nicht arbeitet bzw. im Automatisierungssystem nicht „online" ist, ist sichergestellt, dass zwischenzeitliche Änderungen der Statusvariablen keine Undefinierten Zustände schaffen.
Um weiterhin sicherzustellen, dass die Übertragungsfunktion keine Fehler aufweist, kann vorgesehen sein, dass nach dem Zuführen des aktualisierten Status und vor dem Aktivieren der aktualisierten Funktionseinheit ein Test der aktualisierten Funktionseinheit stattfindet. Ist das erfindungsgemäße Verfahren in eine Funktionsaktivierung integriert, wie z.B. in eine kontinuierliche Integration (continuous Integration) und/oder in eine Anwendung zur Versionsverwaltung (version control) , so findet ein Test der aktualisierten Funktionseinheit ohnehin im Rahmen der Funktionsaktivierung statt.
Von Vorteil, weil einfacher, ist, wenn sowohl das Erfassen des Status der früheren Funktionseinheit als auch die Anwendung der Übertragungsfunktion auf Ebene der Funktionseinheit erfolgt, wobei die Anwendung der Übertragungsfunktion unabhängig von der Erfassung durch eine eigene als Software realisierte Einheit erfolgt. Diese eigene Software-Einheit wird im Folgenden als Update-Manager bezeichnet. Das Trennen von Erfassen des Status einerseits und Anwendung der Übertragungsfunktion andererseits ermöglicht es, mehrere Aktualisierungsschritte nacheinander, also in einem Schritt durchzuführen - während die betroffene Funktionseinheit nur einmal inaktiv ist.
Insbesondere in dieser Hinsicht kann vorgesehen sein, dass in der Software-Einheit zur Übertragung - d.h. im Update-Manager - mehrere Übertragungsfunktionen für verschiedene Funktionseinheiten bzw. Automatisierungsfunktionen und/oder für verschiedene aktualisierte Versionen einer Funktionseinheit bzw. Automatisierungsfunktion abgespeichert sind.
Um ein einfaches automatisches Testen der aktualisierten Funktionseinheit durchführen zu können, kann vorgesehen sein, dass das Anwenden der Übertragungsfunktion durch einen Mechanismus für die Funktionsaktivierung, wie einen Mechanismus für die kontinuierliche Integration und/oder eine Versionsverwaltung, ausgelöst wird.
Wenn jede angewendete Übertragungsfunktion abgespeichert wird, etwa im Update-Manager, kann im Nachhinein der Aktualisierungsvorgang überprüft werden. Wenn mehrere Aktualisierungen unmittelbar hintereinander erfolgen sollen, können bei einem Aktualisierungsschritt mehrere Übertragungsfunktionen angewendet werden. Damit werden Ausfallszeiten einer Funktionseinheit, welche durch mehrere Aktualisierungen entstehen können, reduziert.
Das erfindungsgemäße Verfahren wird insbesondere dann angewendet, wenn das Automatisierungssystem in ein Smart Grid oder ein Smart Building integriert ist.
Schließlich betrifft die gegenständliche Erfindung auch ein Computerprogrammprodukt. Dieses Computerprogrammprodukt um- fasst ein Programm und ist direkt in einen Speicher eines Rechners (z.B. einer bestimmten Steuer- oder Regeleinheit einer Komponente bzw. eines Geräts des Niederspannungsnetzes) des Automatisierungssystems eines Niederspannungsnetzes ladbar, mit Programm-Mitteln, um alle Schritte des erfindungsgemäßen Verfahrens auszuführen, wenn das Programm vom Rechner ausgeführt wird.
Die dynamischen Eigenschaften einer Funktionseinheit bzw. Automatisierungsfunktion können als Satz S einer beliebigen Anzahl N von Statusvariablen sl, s2, sN beschrieben werden. Jede Statusvariable kann darüber hinaus durch einige oder alle der folgenden Attribute gekennzeichnet werden:
- einzigartiger Name oder Identifikator
- Datentyp
- erlaubter Wertebereich
- Sichtbarkeit
- Bedeutung, also die aktuelle Bedeutung des Werts für die betroffene Funktionseinheit
Sind alle Eigenschaften, welche für eine bestimmte Anwendung (eine bestimmte Programmiersprache oder eine bestimmte Pro- grammierumgebung) relevant sind, identisch, dann sind auch die Statusvariablen identisch. Wenn alle Statusvariablen im Satz S, die den Status der Funktionseinheit repräsentieren, identisch sind, dann kann die Übertragung vom alten Status Soid auf den neuen Status Snew durch eine einfache Abbildung - ein so genanntes Mapping - erfolgen:
Snew *~ S0ld
Wenn zumindest eine Statusvariable andere Eigenschaften auf- weist, dann muss eine Übertragungsfunktion F(S) eingeführt werden :
Snew F ( S0ld )
Diese Übertragungsfunktion übernimmt die Transformation jeder Statusvariablen des alten Satzes S0id auf die entsprechende Statusvariable im neuen Satz Snew - Dabei können die folgenden Transformationen stattfinden:
- der einzigartige Name oder Identifikator hat sich geändert: dann ist die Abbildung auf die neue Statusvariable ein einfacher Umbenennungsprozess
- der Status existiert nicht mehr oder ist nicht mehr relevant für die Automatisierungsfunktion: dann wird dieser Status im neuen Satz von Statusvariablen gelöscht.
- eine neue Statusvariable wird eingeführt, die keine Beziehung zu alten Statusvariablen hat: die neue Statusvariable wird mit einem passenden Defaultwert besetzt.
- die Datenformate zwischen alter und neuer Statusvariable sind unterschiedlich: eine entsprechende Transformation muss durchgeführt werden (z.B. wird „0/1" in Hinkunft durch das Boolesche „true/false" repräsentiert)
- der Wertebereich der neuen Statusvariablen ist anders als jener der alten Statusvariablen: wenn der neue Wertebereich kleiner ist, muss eine entsprechende Logik zur Verfügung gestellt werden, wenn der alte Wertebereich außerhalb des neuen liegt. Z.B. könnte eine dreistufiger Status „clear - suspicious - alert" vorgesehen werden statt „on/off", oder umgekehrt.
- eine neue Statusvariable wird eingeführt, die aus mehreren alten Statusvariablen zusammengesetzt ist: eine entsprechende Kombinationslogik muss zur Verfügung gestellt werden .
- eine alte Statusvariable wird in mehrere neue Statusvariablen aufgeteilt, möglicher Weise mit neuen Wertebereichen: eine entsprechende Logik muss zur Verfügung gestellt werden.
- die Bedeutung einer Statusvariablen hat sich geändert: dies ist ein besonders gefährlicher Fall, weil eine automatische Überprüfung dies nicht erkennen kann, sondern nur eine - kaum machbare - komplette Analyse der Funktion. Eine Übertragung (migration) der Statusvariablen muss in diesem Fall manuell durchgeführt werden, nicht mittels Softwareunterstützung.
Aus all dem ergibt sich, dass eine automatische Aktualisierung von Funktionseinheiten bzw. Automatisierungsfunktionen fehleranfällig ist. Wenn man keine Übertragungsfunktion F(S) vorsieht, so führt dies sehr wahrscheinlich zu einem Versagen beim Ausführen der neuen, aktualisierten Funktionseinheit. Wird aber die Änderung der Bedeutung einer Statusvariablen nicht übertragen, kann dies zu schleichenden Fehlern führen, die lange Zeit nicht auffallen.
Deshalb wird der Vorgang des Implementierens der Übertragung des Status am besten mit einem bestehenden Mechanismus für die Funktionsaktivierung verbunden bzw. in diesen integriert, wie z.B. in die kontinuierliche Integration (auch fortlaufende oder permanente Integration genannt, englisch continuous Integration, CI) und/oder in eine Anwendung zur Versionsver- waltung (englisch version control) . Die kontinuierliche Integration beschreibt in der Software-Entwicklung den Prozess des fortlaufenden Zusammenfügens von Komponenten zu einer An wendung. Das Ziel der kontinuierlichen Integration ist die Steigerung der Softwarequalität. Typische Aktionen sind das Übersetzen und Verknüpfen der Anwendungsteile, prinzipiell können aber auch beliebige andere Operationen zur Erzeugung abgeleiteter Informationen durchgeführt werden. Üblicherweis wird dafür nicht nur das Gesamtsystem neu gebaut, sondern es werden auch automatisierte Tests durchgeführt. Der gesamte Vorgang wird meist automatisch ausgelöst durch Einchecken in die Versionsverwaltung. Diese dient der Erfassung von Änderungen an Dokumenten oder Dateien. Alle Versionen werden in einem Archiv mit Zeitstempel und Benutzerkennung gesichert und können später wiederhergestellt werden. Versionsverwal- tungssysteme werden typischerweise zur Verwaltung von Quelltexten verwendet.
Ein Auslöser in den Anwendungen zur kontinuierlichen Integration oder zur Versionsverwaltung triggert die automatische Überprüfung aller Statusvariablen in Bezug auf Änderungen der Bedeutung verglichen mit zuvor aktivierten oder bestätigten Versionen. Der Systementwickler würde dann verständigt werden, wenn Übertragungsfunktionen fehlen, in der Zwischenzeit können so genannte Skeletons von Übertragungsfunktionen oder, bei einfachen Transformationen, auch vollständige Übertragungsfunktionen automatisch zur Verfügung gestellt werden. Ein Skeleton ist eine automatisch generierte Struktur (meist ein Quelltext), die dann weiter ausgebaut werden können. Skeletons können oft auch bereits kompiliert und getestet werden .
Bei der automatischen Überprüfung der Statusvariablen im Rah- men der kontinuierlichen Integration bzw. VersionsVerwaltung kann zwar wahrscheinlich eine Änderung der Bedeutung einer Statusvariablen nicht erkannt werden, aber sich daraus ergebende Fehler können bei der - im Rahmen der kontinuierlichen Integration bzw. Versionsverwaltung durchgeführten - anschließenden, automatisch durchgeführten Tests der Funktionsoder Software-Einheiten und der Integrationstest gefunden werden. Beim Integrationstest erfolgt eine aufeinander abgestimmte Reihe von Einzeltests, die dazu dienen, verschiedene voneinander abhängige Komponenten eines Systems im Zusammenspiel miteinander zu testen.
Damit so ein Verfahren eingesetzt werden kann, müssen die verschiedenen Versionen der meist als Software realisierten Funktionseinheiten, also der einzelnen Automatisierungsfunktionen, gespeichert werden. Nur so kann die Anwendung informiert werden, dass eine oben beschriebene Überprüfung der Statusvariablen ordnungsgemäß abgeschlossen worden ist. Sobald dann eine Übertragungsfunktion vollständig implementiert ist, wird diese als separates Modul beibehalten, dass in einen Update-Manager geladen wird, der sich am betreffenden elektronischen Gerät im Niederspannungsnetz befindet.
Eine erfolgreiche Aktualisierung für eine elektronische Komponente bzw. ein elektronisches Gerät, das in ein Automatisierungssystem eingebunden ist, umfasst zum Beispiel die folgenden Schritte:
1) Die neue Funktionseinheit bzw. Automatisierungsfunktion und die Übertragungsfunktion werden in die Komponente bzw. das Gerät geladen.
2) Die Übertragungsfunktion wird im Update-Manager installiert, dieser weiß nun, wie der alte Satz von Statusvariablen (jener der alten Funktionseinheit) auf den neuen Satz von Statusvariablen (jener der neuen Funktionseinheit) transformiert wird. Der Update-Manager kann mehre- re Übertragungsfunktionen lokal gespeichert haben, die sich jeweils durch die Funktionseinheit, zu der sie gehören, und den Übertragungsschritt (migration step) , also z.B. („von 1.11 zu 1.12beta") unterscheiden.
Der Eingangsdatenstrom, welcher der alten Funktionseinheit zugeführt wird, wird abgeschnitten, um zu verhindern, dass sich der Status der alten Funktionseinheit ändert, während die Aktualisierung (das Update) der Funktionseinheit durchgeführt wird. Meist wird der Eingangsdatenstrom zwischengespeichert, bis die neue Funktionseinheit der Komponente zu arbeiten beginnt, damit keine relevanten Ereignisse versäumt werden.
Die Ausführung der alten Funktionseinheit wird gestoppt, da diese ja auch ohne externe Signale weiterarbeiten könnte, etwa aufgrund von Timern, und dadurch ihren Status ändern könnte.
Der Status der alten Funktionseinheit wird extrahiert und gespeichert.
Die Übertragungsfunktion wird auf den gespeicherten Status angewendet, um den Input-Status für die neue Funktionseinheit zu generieren.
Der neue Status, also der neue Satz von Statusvariablen, wird in die neue Funktionseinheit eingesetzt.
Der Eingangsdatenstrom wird zur neuen Funktionseinheit geleitet und diese beginnt zu arbeiten.
Falls auch die alte Funktionseinheit noch verwendet wird, muss diese ebenfalls wieder an den Eingangsdatenstrom angebunden und neu gestartet werden.
Beim erfindungsgemäßen Verfahren erfolgt die Übertragung des Status auf der Ebene der Anwendung, also z.B. auf Ebene der einzelnen Funktionseinheit, durch eine eigene Software realisierte, funktionale Einheit, den Update-Manager. Dies bringt im Vergleich zu weiter integrierten Lösungen den Vorteil, dass das Erfassen des aktuellen Status einer Funktionsemhei von der tatsächlichen Übertragung des Status auf eine neue Funktionseinheit bzw. eine neue Version der Funktionseinheit getrennt erfolgt. Dadurch wird wiederum das Testen erleichtert. Ein Zurückgreifen auf andere Lösungen und damit ein Einsatz von Systemressourcen an der betreffenden Plattform (hier beim Betriebssystem DP) werden geschont. Weil der Status offline übertragen wird, besteht die Möglichkeit, mehrer Aktualisierungsschritte auf einmal durchzuführen ohne dass jede Zwischenversion einzeln aktiviert und ausgeführt werden muss. Eine Aktualisierung (Update) des Übertragungsvorgangs selbst betrifft darüber hinaus nur eine bestimmte Komponente und nicht alle aktualisierbaren Komponenten im Automatisierungssystem. Der Update-Manager und das Verfahren der Status Übertragung sind unabhängig von der Ausführungsumgebung oder der Programmiersprache.
Das Verfahren des Aktualisierens bzw. der Übertragung des Status einer Funktionseinheit, also etwa einer Automatisierungsfunktion, ist eng in die Entwicklungs- oder Aktivierungsebene eingebunden. Menschliche Fehler werden - soweit möglich - durch eine Überprüfung der korrekten Übertragung des Status erkannt, wenn die neue Funktionseinheit offline aktiviert wird. Zusätzliche meist Software realisierte Werkzeuge können zur Verfügung gestellt werden, um die Implementierung der Übertragungsfunktionen zu erleichtern.
Kurze Beschreibung der Figur
Zur weiteren Erläuterung der Erfindung wird im nachfolgenden Teil der Beschreibung auf die Figur Bezug genommen, aus der weitere vorteilhafte Einzelheiten und mögliche Einsatzgebiete der Erfindung zu entnehmen sind. Dabei zeigt die Figur eine schematische Darstellung eines erfindungsgemäßen Verfahrens- ablaufes zur Aktualisierung von Funktionseinheiten von Komponenten eines Automatisierungssystems.
Wege zur Ausführung der Erfindung
Die Figur zeigt eine beispielhafte Struktur bzw. Architektur einer Komponente (bzw. eines Gerätes), welche Teil eines Smart Grids oder eines Smart Buildings ist. Der Einfachheit halber sind dabei nur die für die Erfindung wesentlichen Elemente dargestellt. Die Komponente verfügt über ein Betriebssystem DP, von welchem mehrere Funktionseinheiten bzw. Automatisierungsfunktionen gesteuert werden. In der beispielhaft dargestellten Komponente werden z.B. zwei Funktionseinheiten, nämlich zwei Automatisierungsfunktionen SA_A und SA_B, und ein erfindungsgemäßer Update Manager UM vom Betriebssystem DP angesteuert. Die Automatisierungsfunktion SA_A liegt dabei in der Version #1 vor, während die Automatisierungsfunktion SA_B bereits in der Version #3 vorliegt.
Die Komponente ist in ein Automatisierungssystem eingebettet und erhält von diesem einen Befehl B zur Aktualisierung seiner Funktionseinheiten SA_A, SA_B, nämlich zur Aktualisierung der Automatisierungsfunktion SA_A auf die Version #2. Es wird dabei die Automatisierungsfunktion SA_A in der zweiten Version #2 selbst an den Update Manager UM übermittelt. Weiterhin wird die Übertragungsanweisung MI-A zum Aktualisieren der Automatisierungsfunktion SA_A von der Version #1 auf die Version #2 an das Versionsverzeichnis VR übermittelt.
Die Übertragungsanweisung MI-A zum Aktualisieren der Automatisierungsfunktion SA_A von der Version #1 auf die Version #2 stößt die Bildung einer Übertragungsfunktion UEF_A, #l->#2 an, die an den Update Manager UM übermittelt wird. Ein Versionsverzeichnis VR, welches Teil einer Versionsverwaltung ist, speichert alle Versionen #1, #2, #3 der Automatisierungsfunktionen SA_A, SA_B. Durch die Versionsverwaltung ein Beginn der Aktualisierung beim Update Manager UM ausgelöst wird, und zwar dann, wenn die Versionsverwaltung von sich aus das nächste Mal tätig wird.
Die neue Automatisierungsfunktion SA_A, #2 und die Übertragungsfunktion UEF_A,#l->#2 werden also in die zu aktualisierende Komponente des Automatisierungssystems geladen. Die Übertragungsfunktion UEF_A,#l->#2 wird im Update-Manager UM installiert. Der Update-Manager UM weiß nun, wie der alte Satz von Statusvariablen (jener der alten Automatisierungsfunktion SA_A,#1) auf den neuen Satz von Statusvariablen (jener der neuen Automatisierungsfunktion SA_A,#2) transformiert wird. Der Update-Manager UM kann mehrere Übertragungsfunktionen lokal gespeichert haben, welche sich jeweils durch die Automatisierungsfunktion SA_A, SA_B, zu der sie gehören, und den Übertragungsschritt, also die Versionsnummer #1, #2, ... unterscheiden .
Der Eingangsdatenstrom, welcher der alten Automatisierungsfunktion SA_A,#1 zugeführt wird, wird durch den Update Manager UM abgeschnitten, um zu verhindern, dass sich der Status der alten Automatisierungsfunktion SA_A,#1 ändert, während die Aktualisierung (das Update) der Automatisierungsfunktion erfolgt. Es wird der Eingangsdatenstrom zwischengespeichert, bis die neue Automatisierungsfunktion SA_A, #2 zu arbeiten beginnt, damit keine relevanten Ereignisse versäumt werden.
Die Ausführung der alten Automatisierungsfunktion SA_A, #1 wird gestoppt, da diese ja auch ohne externe Signale weiterarbeiten könnte. Die Automatisierungsfunktion SA_B, #3 kann währenddessen aber weiter laufen. Der Status der alten Automatisierungsfunktion SA_A, #1 wird extrahiert und lokal im Gerät gespeichert. Die Übertragungsfunktion UEF_A,#l->#2 wird auf den gespeicherten Status ange- wendet, um den Input-Status für die neue Automatisierungsfunktion SA_A, #2 zu generieren. Der neue Status, also der neue Satz von Statusvariablen, wird anschließend in die neue Automatisierungsfunktion SA_A, #2 eingesetzt. Dann wird der Eingangsdatenstrom zur neuen Automatisierungsfunktion SA_A,#2 geleitet und diese beginnt zu arbeiten.
Die bereits früher angewendeten Übertragungsfunktionen, also hier die Übertragungsfunktionen UEF_B,#l->#2 und UEF_B,#2->#3 sind bereits am Gerät abgespeichert, die soeben angewendete Übertragungsfunktion UEF_A,#l->#2 wird dort ebenfalls gespeichert .
Es kann auch der Fall auftreten, dass vor der Durchführung der Aktualisierung von Version #1 auf Version #2 der Automa- tisierungsfunktion SA_A ein weiterer Befehl B für die Aktualisierung von Version #2 auf Version #3 einlangt (was hier nicht dargestellt ist) . Dann würde die Automatisierungsfunktion SA_A in einem Schritt, von Version #1 auf Version #3 aktualisiert werden. Das hat den Vorteil, dass ein eigener Test unterbleiben kann, ob die Version #2 fehlerlos funktioniert. Stattdessen muss nur getestet werden, ob die Version #3 fehlerlos arbeitet, gegebenenfalls ersetzt also die Automatisierungsfunktion SA_A,#3 gleich die Automatisierungsfunktion SA A, #1. Bezugszeichenliste :
B Befehl für Aktualisierung
DP Betriebssystem (Deployment Platform)
MI_A Übertragungsanweisung (Migration Instructions)
SA_A Funktionseinheit A (Automatisierungsfunktion A)
SA_B Funktionseinheit B (Automatisierungsfunktion B)
UM Update Manager (Software-Einheit zur Anwendung der
Übertragungsfunktion)
UEF_A Übertragungsfunktion für Automatisierungsfunktion A UEF_B Übertragungsfunktion für Automatisierungsfunktion B VR Versionsverzeichnis (Version Record)
#n, n=l, 2, 3 Version der Automatisierungsfunktion SA

Claims

Patentansprüche
1. Verfahren zur Aktualisierung von Funktionseinheiten
(SA_A, SA_B) , wie Automatisierungsfunktionen, von Kompo- nenten in Automatisierungssystemen für elektrische Netze, wobei
- zumindest eine Übertragungsfunktion (UEF_A, UEF_B) erstellt wird, welche den Übergang der einzelnen Statusvariablen des Status einer früheren Funktionseinheit
(SA_A,#1) auf die Statusvariablen des Status der aktualisierten Funktionseinheit (SA_A, #2) beschreibt, wobei der Status die herrschenden Betriebsbedingungen der Funktionseinheit beschreibt,
- die Übertragungsfunktion (UEF_A) auf den Status der früheren Funktionseinheit (SA_A,#1) angewendet wird, wenn dieser nicht aktiv ist, und
- der aktualisierte Status der aktualisierten Funktionseinheit (SA_A,#2) zugeführt und die aktualisierte Funktionseinheit aktiviert wird.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass nach dem Zuführen des aktualisierten Status und vor dem Aktivieren der aktualisierten Funktionseinheit (SA_A,#2) ein Test der aktualisierten Funktionseinheit (SA_A,#2) durchgeführt wird.
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass sowohl das Erfassen des Status der früheren Funktionseinheit (SA_A,#1) als auch die Anwendung der Übertragungsfunktion (UEF_A) auf Ebene der Funktionseinheit erfolgt, wobei die Anwendung der Übertragungsfunktion (UEF_A) unabhängig von der Erfassung durch eine eigene
Software-Einheit (UM) erfolgt.
4. Verfahren nach Anspruch 3, dadurch gekennzeichnet, dass in der Software-Einheit (UM) zur Übertragung mehrere Übertragungsfunktionen (UEF_A, UEF_B) für verschiedene Funktionseinheiten (SA_A, SA_B) und/oder für verschiedene aktualisierte Versionen (#1, #2, #3) einer Funktionseinheit (SA_A, SA_B) abgespeichert sind.
5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass das Anwenden der Übertragungsfunktion (UEF_A, UEF_B) durch einen Mechanismus für die Funktions- aktivierung, wie einen Mechanismus für die kontinuierliche Integration und/oder die Versionsverwaltung, ausgelöst wird.
6. Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass jede angewendete Übertragungsfunktion (UEF_A, UEF_B) abgespeichert wird.
7. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass bei einem Aktualisierungsschritt mehrere Übertragungsfunktionen (UEF_A, UEF_B) angewendet werden .
8. Verfahren nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass das Automatisierungssystem in ein Smart Grid oder ein Smart Building integriert ist.
9. Computerprogrammprodukt, welches ein Programm umfasst und direkt in einen Speicher eines Rechners des Automatisie- rungssystems eines Niederspannungsnetzes ladbar ist, mit
Programm-Mitteln, um alle Schritte des Verfahrens nach einem der Ansprüche 1 bis 8 auszuführen, wenn das Programm vom Rechner ausgeführt wird.
PCT/EP2016/053807 2015-05-12 2016-02-24 Verfahren zur aktualisierung von komponenten in automatisierungssystemen WO2016180550A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
AT503932015 2015-05-12
ATA50393/2015 2015-05-12

Publications (1)

Publication Number Publication Date
WO2016180550A1 true WO2016180550A1 (de) 2016-11-17

Family

ID=55538176

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2016/053807 WO2016180550A1 (de) 2015-05-12 2016-02-24 Verfahren zur aktualisierung von komponenten in automatisierungssystemen

Country Status (1)

Country Link
WO (1) WO2016180550A1 (de)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19810814A1 (de) * 1998-03-12 1999-09-16 Ericsson Telefon Ab L M Zustandskopierverfahren für eine Software-Aktualisierung
US20010010032A1 (en) * 1998-10-27 2001-07-26 Ehlers Gregory A. Energy management and building automation system
EP1431898A2 (de) * 2002-12-18 2004-06-23 Siemens Aktiengesellschaft Automatisierungssystem und Verfahren zum Betrieb eines Automatisierungssystems
US20050232145A1 (en) * 2004-04-15 2005-10-20 Cooper Cameron Corporation Systems and methods of providing redundant communication to an electronic device
US20100299653A1 (en) * 2009-05-20 2010-11-25 Microsft Corporation Serviceability and configuration management

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19810814A1 (de) * 1998-03-12 1999-09-16 Ericsson Telefon Ab L M Zustandskopierverfahren für eine Software-Aktualisierung
US20010010032A1 (en) * 1998-10-27 2001-07-26 Ehlers Gregory A. Energy management and building automation system
EP1431898A2 (de) * 2002-12-18 2004-06-23 Siemens Aktiengesellschaft Automatisierungssystem und Verfahren zum Betrieb eines Automatisierungssystems
US20050232145A1 (en) * 2004-04-15 2005-10-20 Cooper Cameron Corporation Systems and methods of providing redundant communication to an electronic device
US20100299653A1 (en) * 2009-05-20 2010-11-25 Microsft Corporation Serviceability and configuration management

Similar Documents

Publication Publication Date Title
EP2684335B1 (de) Energieautomatisierungsanlage und verfahren zum betreiben einer energieautomatisierungsanlage
EP3336995B1 (de) Verfahren, steuereinrichtung und system zum ermitteln von zustandswerten zur beschreibung von betriebszuständen in einem teilnetz eines energieversorgungsnetzes
EP3070556B1 (de) Verfahren, recheneinrichtung, benutzer-einheit und system zum parametrieren eines elektrischen gerätes
EP2828522B1 (de) Verfahren zum konfigurieren einer windenergieanlage, sowie windenergieanlage
WO2005119381A1 (de) System zum bedienen einer anlage durch editieren von grafischen objekten
EP2118712A1 (de) Scada-einheit
EP3161928B1 (de) Energiemanagementsystem zur steuerung einer einrichtung, computersoftwareprodukt und verfahren zur steuerung einer einrichtung
WO2018162198A1 (de) Verfahren und system zum bestimmen einer erwarteten lebensdauer eines elektrischen betriebsmittels
EP2713463A1 (de) Energiespeichersystem
CN109962529B (zh) 一种电气二次设备的在线监测与运维装置
EP3588277A1 (de) Firmware-aktualisierungsverfahren
WO2016180550A1 (de) Verfahren zur aktualisierung von komponenten in automatisierungssystemen
EP2883294B1 (de) Verfahren zur rechnergestützten steuerung eines elektrischen energieverteilnetzes aus einer vielzahl von netzknoten
AT514384B1 (de) Wechselrichter mit Programmierschnittstelle
EP2765667B1 (de) Verfahren und Vorrichtung zum Betreiben eines Stromnetzes
EP2537232A1 (de) Verfahren zum betrieb eines energieautomatisierungssystems und energieautomatisierungssystem
DE102018007954A1 (de) Fernkonfigurierbare Datenerfassung von Windenergieanlagen
KR20210046263A (ko) 배전 해석을 위한 응용프로그램의 배전운영시스템
EP3404500A1 (de) Verfahren zur überwachung von funktionsmodulen
EP3988384B1 (de) Computerimplementiertes verfahren und vorrichtung zum lokalen lastmanagement von ladestationen zum laden von elektrofahrzeugen in einem ladestationssystem
EP4105810A1 (de) Verfahren zur modellierung einer netztopologie eines niederspannungsnetzes
EP3716442A1 (de) Einrichtung, system und verfahren zum betrieb eines elektrischen energieversorgungsnetzes
EP3869652A1 (de) Versorgung einer industrieanlage mit elektrischer energie
DE102018109046A1 (de) Absicherung von öffentlichen Stromnetzen durch Micro-Grids
WO2022002486A1 (de) System und verfahren zur optimierung eines schaltzustandes einer schaltanordnung einer elektrischen verteilanordnung

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

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16710103

Country of ref document: EP

Kind code of ref document: A1