WO2008052901A1 - Verfahren zum betreiben einer rechneranordnung - Google Patents

Verfahren zum betreiben einer rechneranordnung Download PDF

Info

Publication number
WO2008052901A1
WO2008052901A1 PCT/EP2007/061271 EP2007061271W WO2008052901A1 WO 2008052901 A1 WO2008052901 A1 WO 2008052901A1 EP 2007061271 W EP2007061271 W EP 2007061271W WO 2008052901 A1 WO2008052901 A1 WO 2008052901A1
Authority
WO
WIPO (PCT)
Prior art keywords
computer
functions
module
arrangement
designed
Prior art date
Application number
PCT/EP2007/061271
Other languages
English (en)
French (fr)
Inventor
Rainer Lucas
Josef Newald
Stjepan Dujmovic
Original Assignee
Robert Bosch 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 Robert Bosch Gmbh filed Critical Robert Bosch Gmbh
Publication of WO2008052901A1 publication Critical patent/WO2008052901A1/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/5017—Task decomposition

Definitions

  • the invention relates to a method for operating a computer arrangement, a module which interacts with a computer arrangement, a computer arrangement, a computer program and a computer program product.
  • the AUTOSAR network an association of automotive manufacturers and, in particular, electronic automotive components, has set itself the goal of facilitating the replacement of automotive software in cooperation scenarios between original equipment manufacturers (OEMs) and suppliers.
  • OEMs original equipment manufacturers
  • components, in particular software components, regarding an infrastructure as well as specific interfaces are defined.
  • an exchange of data and messages between the components should be specified.
  • VFB Virtual Function Bus
  • RTE run-time environment
  • the VFB specifies the properties of the components at development time. This includes, in particular, the communication requirements for the components, that is, which messages are required to ensure the correct functioning of the components, and which messages a component makes available to other components. Similarly, the functional requirements of individual components are specified. In general, each component describes the services (services) that are normally available as C functions and that they need from outside. Similarly, services that describe the component in train.
  • the RTE is generated from the VFB. In this case, the RTE is statically assigned to a runtime of the communication layer. Via this communication layer, the individual components provided according to AUTOSAR are interconnected with one another and with underlying basic services, usually basic software.
  • Document DE 10 2004 039 633 A1 describes a device for exchanging vehicle-specific information.
  • This device includes a vehicle application program interface (VAPI) that is at least partially logical between drivers of vehicle networks and a service framework with application programs.
  • the vehicle application program interface is formed with at least one interface to the service framework, wherein the vehicle application program interface is formed with low-level connectors for communication with vehicle-specific low-level sources.
  • the device comprises an object management with a database in which vehicle-specific information is stored object-specifically, the assignment of the object-specific data (VAPI data objects) to the assigned low-level connectors being performed by a low-level mapping and the Vehicle application program interface in a profile includes definitions of data objects and mappings that can be implemented by a rule engine.
  • the vehicle application program interface is assigned a middleware mapping, which provides the vehicle application program interface object-specific data in middleware-specific languages and protocols for applications and services. Disclosure of the invention
  • the invention relates to a method for operating a computer arrangement in which functions of the computer arrangement are dynamically distributed to at least one computer node of the computer arrangement by means of a module which interacts with the computer arrangement.
  • this module is designed in particular as middleware.
  • the functions are dynamically distributed during the runtime of the functions and / or the computer arrangement and thus the computer nodes, wherein the functions can be moved between the computer nodes.
  • the at least one computer node is assigned a currently required function. It is also possible that the module provides communication between the functions but also the computer nodes.
  • the functions can be stored in at least one function memory designed to store the functions.
  • the at least one function memory can be managed by the module, which may mean, for example, that the functions are stored and deleted by the module.
  • communication between the function memory and the computer nodes can be made possible by the module.
  • the module according to the invention interacts with a computer arrangement and is designed to dynamically distribute functions of the computer arrangement to at least one computer node of the computer system.
  • This module is formed in one embodiment of the invention as middleware, further it can also be designed as a computer node and constructed modular taking into account the functions.
  • the computer arrangement according to the invention has at least one module which is designed to dynamically distribute functions of the computer arrangement to at least one computer node of the computer system.
  • the computer nodes of the computer arrangement can be designed to interact with electromechanical devices, in particular with sensors or actuators, such electromechanical devices being connected to the computer nodes.
  • the computer arrangement may have at least one function memory for storing the functions.
  • the computer program with program code means according to the invention is designed to perform all the steps of a method according to the invention when the computer program is executed on a computer or a corresponding computing unit, in particular in a computer arrangement according to the invention.
  • the computer program product according to the invention with program code means which are stored on a computer-readable data carrier is designed to carry out all the steps of a method according to the invention when the computer program is executed on a computer or a corresponding computing unit, in particular in a computer arrangement according to the invention.
  • the module described in the context of the invention which, for example, can be embodied as a middleware layer, is in particular designed to distribute functions to different computer nodes in a computer arrangement at runtime.
  • This module can be used in the design of AUTOSAR applications.
  • the module is typically designed as automotive middleware, in particular for use in AUTOSAR applications in the automotive sector.
  • This middleware module can be, for example, an intermediate application or a protocol or protocol bundle and thus a distribution platform within the computer system or a corresponding computer system.
  • the computer arrangement can have at least one arithmetic unit.
  • at least one computer node can be designed as computing devices. It can be provided that individual components of the computer arrangement form a control unit for a motor vehicle. Several mutually cooperating control devices can in turn be combined to form a computer system according to the invention.
  • the module specified here designed in particular as a middleware or middleware layer, connects different electromechanical devices, for example sensors and / or actuators, to one another via the computer nodes of the computer arrangement.
  • electromechanical devices may, for example, also include optical or chemical sensors or actuators.
  • An object of the module is to enable the dynamic distribution of at least one functionality or at least one function on different computer nodes. Accordingly, the module for a coordination of the computing power of the computer arrangement, an administration of
  • a computer node is usually assigned only the functions that it currently requires, which, when operating the computer arrangement, generally requires less computing power.
  • the invention results in this case the possibility of optimizing a utilization of the computer arrangement and thus individual computer nodes and an optimization of existing resources. This may mean that functions that only work in certain situations be used or calculated, so-called “dead codes", no longer be permanently provided or kept.
  • computer nodes can be arranged more flexibly in the vicinity of electromechanical devices, usually sensors and / or actuators, and connected to them.
  • electromechanical devices usually sensors and / or actuators, and connected to them.
  • the complexity and a communication requirement of an overall system comprising the computer arrangement can be reduced.
  • an optimization of an interface of the computer node to the hardware can be brought about.
  • the computer nodes and the functions functions can be easily integrated and configured due to the definable communication and distribution mechanisms. Therefore, the middleware provides a platform for plug-and-play of ECU functions.
  • ECU functions may be functions of a so-called electronic control unit and thus a computer arrangement designed as a control unit or microcontroller or functions of a so-called engine control unit or a control unit of an engine.
  • the middleware concept in addition to commercial offering of systems, offers the possibility of defining a service platform for distributing and executing software functions. Furthermore, working with the module and thus the middleware can be realized by suitable adapters.
  • a subsequent functional extension can be made at any time within the scope of the invention.
  • the computer arrangement of the vehicle could be provided and loaded with new functions at service stations, for example at petrol stations or in workshops, without requiring manipulation of the computer arrangement and thus also of control devices.
  • the proposed computer arrangement which is suitable for a possible realization of the mid-level software concept, regularly consists of the at least three components described below:
  • a central module which in the present embodiment is designed as a middleware layer
  • Each computer node of the computing device typically includes a microcontroller and an operating system, which may also be designed as a mini-operating system depending on the application of the microcontroller.
  • the operating system is embedded in a runtime environment required by the functions and / or adapted to such a runtime environment.
  • the computer node knows and manages the resources that are assigned to it directly, for example from a RAM or flash memory, or indirectly, for example from electromechanical devices.
  • a time-dependent administration or scheduling of functions can be carried out with the computer node. If several functions one
  • Computer nodes are assigned, this can decide independently which function is processed or calculated at what time.
  • the computer node can be used to communicate with the middleware. This can mean that the computer node logs in or out of the middleware.
  • the computer node can also be suitable for providing the middleware with information about its resources and / or its current status, if, for example, there is a failure of the computer node.
  • the computer node can be designed to monitor or monitor itself and other components, so that the computer node can detect its own status and detect possible failures.
  • the computer system usually has a distribution network for providing communication.
  • the computer nodes can connect the electromechanical devices to such computer arrangements or networks.
  • Performing functions on a particular hardware usually requires a binary code that is typically executable only on a particular hardware platform. This means that the binary code is not portable.
  • a first option gives binary compatibility. In this case, only computers of a particular family are used in the computer arrangement and thus a middleware network, which are binary compatible with each other. Although the computing nodes have different resource properties with regard to their equipment, they can all process the same binary code. In this case, the function memory contains the binary code suitable only for the selected computer family.
  • a second option has a binary incompatibility.
  • different computer platforms that are not binary compatible are used.
  • Virtual Machine is used, which is designed to execute a platform-independent bytecode.
  • Such a byte code is designed as a computer-independent binary code, which is shown for execution by the virtual machine on the underlying computer or an underlying computing unit.
  • Such a procedure is analogous to Java or C # executable. In this case, only the bytecode is stored in the function memory.
  • the at least one function memory is designed as a memory device or container for all ECU functions that are assigned dynamically at runtime to specific computer nodes for processing or calculation.
  • the at least one function memory is managed and controlled by the middleware, so that the function memory is typically not itself designed to actively execute programs or functions. This also means that the at least one functional memory usually interacts only passively with a computer environment.
  • the at least one function memory is designed as a central memory device which is connected directly or possibly also indirectly to the module or the middleware.
  • the at least one function memory may alternatively include a plurality of decentralized memory devices, which in turn are all directly or indirectly connected to the module.
  • the at least one functional memory with the computer nodes at least two alternatives can be realized. These two alternatives can also be combined.
  • a first alternative relates to a physical function transfer in which individual functions of the at least one functional memory are moved and / or copied via the module into a memory of the computer node or of a computer node memory.
  • the computer node is designed to execute a locally present on the computer node memory copy of the function.
  • a direct execution of the function is provided in the function memory.
  • the compute node receives from the module a memory address in the function memory. Therefore, no physical code is required for the compute node.
  • the computer node thus calculates the function using its addresses directly in the function memory, without having a local copy of the function.
  • the module according to the invention is designed to carry out at least one step of the method according to the invention.
  • the module is a distribution of individual functions on the different components of the
  • Computer node monitored In this case, it can alternatively and / or additionally be provided that the module communicates both with individual computer nodes and / or electromechanical devices and with the function memory.
  • the module and thus the middleware can be designed as a computer node with special properties, in particular as a so-called intelligent computer node.
  • the module is designed for distributing functions and for communication with the computer nodes and the function memory.
  • Management of the function memory by the module includes storage of new functions as well as deletion of functions no longer required in the function memory.
  • a behavior of the module is defined by a number of defined rules and criteria, these can either be defined statically and / or be dynamically changeable itself.
  • a so-called resource registry for all computers and functions can be provided for the module. This means on a regular basis that the module all the computer nodes including their current states and capabilities and the functions in the function memory are known with their requirements for correct execution.
  • the module or the middleware can be designed as a so-called add-on, ie addition or extension to AUTOSAR.
  • the extension in particular a middleware add-on, is designed to carry out the dynamic distribution of the functions on the components and in particular the computer nodes.
  • a middleware may be provided which is configured to switch between a static distribution according to AUTOSAR and a dynamic distribution.
  • this can mean that, for example, statically assigned functions are calculated.
  • the module can be used to switch over to a dynamic assignment of functions to computer nodes.
  • at least a part of the static functions performed during normal operation can be performed dynamically.
  • previous static functions can consist of at least one computer node or one arithmetic unit the computer assembly removed and replaced with new dynamically-assigned functions.
  • functions can be loaded dynamically in a reserved area of at least one computer node, while a further area of the computer node is not affected.
  • an AUTOSAR share and at the same time a middleware share is provided for a computer node.
  • FIG. 1 shows a diagram for an example of one defined according to AUTOSAR
  • FIG. 2 shows a schematic representation of an example of a computer arrangement.
  • Figure 1 shows the diagram for an AUTOSAR architecture 2 as defined by AUTOSAR. This comprises a first software component 4, a second software component 6 and an nth software component 8, a runtime environment 10 determined by AUTOSAR (run-time environment, RTE), basic software 12 and an abstraction 14 of a microcontroller.
  • AUTOSAR run-time environment
  • the base software 12 usually has transmission layers for various communication technologies, such as, for example, CAN, LIN and the like, network management, which usually comprises diagnostic protocols, and NVRAM management for non-erasable random access memories.
  • various communication technologies such as, for example, CAN, LIN and the like
  • network management which usually comprises diagnostic protocols, and NVRAM management for non-erasable random access memories.
  • FIG. 2 shows a schematic representation of an embodiment of a computer arrangement 20 according to the invention.
  • This comprises a module 22 embodied here as middleware, and a function memory 24, which in this embodiment is designed to store ECU functions.
  • this computer arrangement 20 has a plurality of computer nodes 26.
  • 26 electromechanical devices, which are designed here as sensors 28, connected to two of these computer nodes.
  • Electromechanical devices, which are designed here as actuators 30, are connected to two further computer nodes 26.
  • functions of the computer arrangement 20 are dynamically distributed by the module 22 to at least one computer node 26 of the computer system 22 during runtime.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zum Betreiben einer Rechneranordnung (20), bei dem Funktionen der Rechneranordnung (20) mittels eines Moduls (22), das mit der Rechneranordnung (20) zusammenwirkt, auf mindestens einen Rechnerknoten (26) der Rechneranordnung (20) dynamisch verteilt werden.

Description

Beschreibung
Titel
Verfahren zum Betreiben einer Rechneranordnung
Die Erfindung betrifft ein Verfahren zum Betreiben einer Rechneranordnung, ein Modul, das mit einer Rechneranordnung zusammenwirkt, eine Rechneranordnung, ein Computerprogramm und ein Computerprogrammprodukt.
Stand der Technik
Der AUTOSAR-Verbund, ein Zusammenschluss von Herstellern von Kraftfahrzeugen und insbesondere elektronischen Kraftfahrzeugkomponenten, hat sich zum Ziel gesetzt, den Austausch automotiver Software in Kooperationsszenarien zwischen Originalteileherstellern (Original Equipment Manufacturers, OEMs) und Zulieferern zu erleichtern. Dazu ist vorgesehen, dass Komponenten, insbesondere Software- Komponenten, was eine Infrastruktur sowie konkrete Schnittstellen betrifft, definiert werden. Zudem soll ein Austausch von Daten und Nachrichten zwischen den Komponenten spezifiziert werden.
Zur Realisierung ist u. a. der sogenannte Virtual Function Bus (VFB), also eine virtuelle Sammelleitung für Funktionen, sowie eine automatisch generierte Implementierung des VFB durch ein Run-Time Environment (RTE) als Laufzeitumgebung vorgesehen. Der VFB spezifiziert zur Entwicklungszeit die Eigenschaften der Komponenten. Dazu gehören insbesondere die Kommunikationsanforderungen für die Komponenten, d.h. welche Nachrichten (Messages) benötigt werden, um eine korrekte Funktion der Komponenten zu gewährleisten, und welche Nachrichten eine Komponente anderen Komponenten zur Verfügung stellt. Auf ähnliche Weise werden auch die funktionalen Anforderungen einzelner Komponenten spezifiziert. In der Regel beschreibt jede Komponente die Dienste (Services), die normalerweise als C-Funktionen vorliegen und die sie von außerhalb benötigt. Ebenso sind Dienste zu beschreiben, die die Komponente im Gegen- zug zur Verfügung stellt. Das RTE wird aus dem VFB generiert. Dabei ist das RTE zu einer Laufzeit der Kommunikationsschicht statisch zugeordnet. Über diese Kommunika- tionsschicht sind die einzelnen gemäß AUTOSAR vorgesehen Komponenten untereinander als auch mit darunter liegenden Basis- Diensten, üblicherweise Basis-Software, verbunden.
Bislang ist es bei einer Definition von AUTOSAR lediglich möglich, dass die Zuordnung von Komponenten zu bestimmten Rechnerknoten statisch ist und insbesondere zur Laufzeit nicht mehr geändert oder angepasst wird. Durch diese Einschränkung ist ein dynamisches Verschieben von Funktionalitäten oder Funktionen von einem Rechnerknoten auf einen anderen ausgeschlossen. Es ist demnach erforderlich, dass alle möglichen Funktionen permanent auf einem Steuergerät vorgehalten werden. Dies betrifft auch Funktionen, die nur in speziellen Situationen benötigt und somit genutzt werden. Dies kann bedeuten, dass zwei Funktionen, die sich eigentlich gegenseitig ausschlie- ßen, gleichzeitig in einem Steuergerät abgelegt sind.
Die Druckschrift DE 10 2004 039 633 Al beschreibt eine Vorrichtung zum Austausch fahrzeugoriginärer Informationen. Diese Vorrichtung umfasst eine Fahrzeug- Anwendungsprogramm-Schnittstelle (VAPI), die mindestens teilweise logisch zwischen Treibern von Fahrzeugnetzwerken und einem Dienste- Framework mit Anwendungsprogrammen liegt. Die Fahrzeug-Anwendungsprogramm-Schnittstelle ist mit mindestens einer Schnittstelle zu dem Dienste- Framework ausgebildet, wobei die Fahrzeug- Anwendungsprogramm-Schnittstelle mit Low- Level- Konnektoren zur Kommunikation mit fahrzeugspezifischen Low-Level-Quellen ausgebildet ist. Des weiteren umfasst die Vorrichtung ein Objekt- Management mit einer Datenbank, in der fahrzeugoriginäre Informationen objektspezifisch abgelegt sind, wobei die Zuordnung der objektspezifischen Daten (VAPI-Datenobjekte) zu den zugeordneten Low- Level- Konnektoren durch ein Low- Level- Mapping erfolgt und die Fahrzeug-Anwendungsprogramm-Schnittstelle in einem Profil Definitionen von Datenobjekten und Mappings umfasst, die durch ein Re- gelwerk umsetzbar sind. Dabei ist der Fahrzeug- Anwendungsprogramm-Schnittstelle ein Middleware-Mapping zugeordnet, das die objektspezifischen Daten der Fahrzeug- Anwendungsprogramm-Schnittstelle in middlewarespezifische Sprachen und Protokollen für Anwendungen und Dienste zur Verfügung stellt. Offenbarung der Erfindung
Die Erfindung betrifft ein Verfahren zum Betreiben einer Rechneranordnung, bei dem Funktionen der Rechneranordnung mittels eines Moduls, das mit der Rechneranord- nung zusammenwirkt, auf mindestens einen Rechnerknoten der Rechneranordnung dynamisch verteilt werden.
Dabei ist dieses Modul insbesondere als Middleware ausgebildet. In Ausgestaltung der Erfindung werden die Funktionen zur Laufzeit der Funktionen und/oder der Rechneran- Ordnung und somit den Rechnerknoten dynamisch verteilt, wobei die Funktionen zwischen den Rechnerknoten verschoben werden können.
In weiterer Ausgestaltung wird dem mindestens einem Rechnerknoten eine aktuell benötigte Funktion zugewiesen. Außerdem ist es möglich, dass durch das Modul eine Kommunikation zwischen den Funktionen aber auch den Rechnerknoten bereitgestellt wird.
Bei einer Variante der Erfindung können die Funktionen in mindestens einem zum Speichern der Funktionen ausgebildeten Funktionsspeicher gespeichert werden. In diesem Zusammenhang kann der mindestens eine Funktionsspeicher durch das Modul verwaltet werden, was bspw. bedeutet kann, dass die Funktionen durch das Modul gespeichert und gelöscht werden. Außerdem kann durch das Modul eine Kommunikation zwischen dem Funktionsspeicher und den Rechnerknoten ermöglicht werden.
Das erfindungsgemäße Modul wirkt mit einer Rechneranordnung zusammen und ist dazu ausgebildet, Funktionen der Rechneranordnung auf mindestens einen Rechnerknoten der Rechneranordnung dynamisch zu verteilen.
Dieses Modul ist in einer Ausführungsform der Erfindung als Middleware ausgebildet, des weiteren kann es auch als Rechnerknoten ausgebildet und unter Berücksichtigung der Funktionen modular aufgebaut sein. Die erfindungsgemäße Rechneranordnung weist mindestens ein Modul auf, das dazu ausgebildet ist, Funktionen der Rechneranordnung auf mindestens einen Rechnerknoten der Rechneranordnung dynamisch zu verteilen.
Die Rechnerknoten der Rechneranordnung können in weiterer Ausgestaltung dazu ausgebildet sein, mit elektromechanischen Vorrichtungen, insbesondere mit Sensoren oder Aktoren, zusammenzuwirken, wobei derartige elektromechanische Vorrichtungen an die Rechnerknoten angeschlossen sind.
Außerdem kann die Rechneranordnung mindestens einen Funktionsspeicher zum Speichern der Funktionen aufweist.
Das erfindungsgemäße Computerprogramm mit Programmcodemitteln ist dazu ausgebildet, alle Schritte eines erfindungsgemäßen Verfahrens durchzuführen, wenn das Computerprogramm auf einem Computer oder einer entsprechenden Recheneinheit, insbesondere in einer erfindungsgemäßen Rechneranordnung, ausgeführt wird.
Das erfindungsgemäße Computerprogrammprodukt mit Programmcodemitteln, die auf einem computerlesbaren Datenträger gespeichert sind, ist zur Durchführung aller Schritte eines erfindungsgemäßen Verfahrens ausgebildet, wenn das Computerprogramm auf einem Computer oder einer entsprechenden Recheneinheit, insbesondere in einer erfindungsgemäßen Rechneranordnung, ausgeführt wird.
Das im Rahmen der Erfindung beschriebenen Modul, das bspw. als Middleware-Schicht ausgebildet sein kann, ist insbesondere dazu ausgebildet, in einer Rechneranordnung zur Laufzeit Funktionen auf verschiedene Rechnerknoten zu verteilen. Dieses Modul kann in Ausgestaltung bei AUTOSAR-Anwendungen eingesetzt werden.
Das Modul ist typischerweise als automotive Middleware, insbesondere für einen Ein- satz bei AUTOSAR-Anwendungen im Kraftfahrzeugbereich, ausgebildet. Bei diesem als Middleware ausgebildeten Modul kann es sich bspw. um eine Zwischenanwendung oder ein Protokoll bzw. Protokollbündel und somit eine Verteilungsplattform innerhalb der Rechneranordnung oder eines entsprechenden Rechnersystems handeln. In diesem Fall ist das Modul zur Bereitstellung einer Kommunikation zwischen den Rechner- knoten der Rechneranordnung geeignet. Die Rechneranordnung kann mindestens eine Recheneinheit aufweisen. Weiterhin kann mindestens ein Rechnerknoten als Recheneinrichtungen ausgebildet sein. Es kann vorgesehen sein, dass einzelne Komponenten der Rechneranordnung ein Steuergerät für ein Kraftfahrzeug bilden. Mehrere miteinan- der zusammenwirkende Steuergeräte können wiederum zu einer Ausgestaltung einer erfindungsgemäßen Rechneranordnung zusammengefasst sein.
Das hier spezifizierte, insbesondere als Middleware oder Middleware-Schicht ausgebildete, Modul verbindet unterschiedliche elektromechanische Vorrichtungen, bspw. Sen- soren und/oder Aktoren über die Rechnerknoten der Rechneranordnung miteinander. Dabei können diese elektromechanischen Vorrichtungen bspw. auch optische oder chemische Sensoren oder Aktoren umfassen. Eine Aufgabe des Moduls besteht darin, die dynamische Verteilung von mindestens einer Funktionalität oder mindestens einer Funktion auf verschiedene Rechnerknoten zu ermöglichen. Demnach ist das Modul für eine Koordination der Rechenleistung der Rechneranordnung, eine Verwaltung von
Funktionen und für eine Verteilung von Funktionen auf die Rechnerknoten vorgesehen. Auf diese Weise können Funktionen flexibel und zur Laufzeit, insbesondere der Laufzeit der Rechneranordnung, aktuell gültigen Randbedingungen angepasst werden.
Durch ein Middleware- Konzept, das durch eine Ausführung des Verfahrens realisiert werden kann, und die Möglichkeit der dynamischen Verteilung von Funktionalitäten zur Laufzeit ermöglicht, können Zuverlässigkeit und Sicherheit der Rechneranordnung erhöht werden. Bei einem Ausfall eines Rechnerknotens können wesentliche Funktionen auf andere Rechnerknoten verschoben werden. Dies ist bei derzeit verfügbaren An- Wendungen, insbesondere im automotiven Bereich und somit auch bei AUTOSAR- Anwendungen, nicht möglich.
Einem Rechnerknoten werden bei einer Ausgestaltung der Erfindung üblicherweise nur die Funktionen zugewiesen, die er aktuell benötigt, was bei Betrieb der Rechneranord- nung insgesamt weniger Rechenleistung erfordert. Mit der Erfindung ergibt sich in diesem Fall die Möglichkeit einer Optimierung einer Auslastung der Rechneranordnung und somit einzelner Rechnerknoten sowie einer Optimierung von vorhandenen Ressourcen. Dies kann bedeuten, dass Funktionen, die nur in bestimmten Situationen be- nutzt oder gerechnet werden, sog. "tote Codes", nicht mehr dauerhaft bereitgestellt oder vorgehalten werden müssen.
Des weiteren können bei einer Variante der Erfindung, Rechnerknoten flexibler in der Nähe von elektromechanischen Vorrichtungen, üblicherweise Sensoren und/oder Aktoren, angeordnet und mit diesen verbunden sein. Dadurch kann die Komplexität und ein Kommunikationsbedarf eines Gesamtsystems, das die Rechneranordnung umfasst, verringert werden. Auf diese Weise kann eine Optimierung einer Schnittstelle des Rechnerknotens zur Hardware herbeigeführt werden.
Mit dem Verfahren und somit dem Middleware- Konzept ergibt sich u. a. bereits während einer Entwicklung der Rechneranordnung und insbesondere bei einer damit verbundenen Softwareentwicklung die Möglichkeit, für das Modul, die Rechnerknoten und/oder die Funktionen eine modulare Struktur bereitzustellen. Somit ist es möglich, dass jede als Softwarefunktion vorgesehene Funktion auf unterschiedlichen Rechnern oder Rechenanordnungen lauffähig ist, so dass derartige Funktionen modul- bzw. midd- lewarekonform sind. Auf diese Weise kann eine Nutzung monolithischer Softwarefunktionen vermieden werden.
Durch den in einer Ausgestaltung der Erfindung vorgesehenen modularen Aufbau des Moduls, der Rechnerknoten sowie der Funktionen können aufgrund der definierbaren Kommunikations- und Verteilungsmechanismen Funktionen einfach integriert und konfiguriert werden. Daher bietet die Middleware eine Plattform für das Plug-and-Play von ECU-Funktionen. Bei ECU-Funktionen kann es sich um Funktionen einer sog. Electro- nie Control Unit und demnach einer als Steuergerät oder Mikrocontroller ausgebildeten Rechneranordnung oder um Funktionen einer sog. Engine Control Unit bzw. einem Steuergerät eines Motors handeln.
Da mit demselben Modul und somit derselben Middleware sowohl einfache als auch umfangreiche und komplexe Funktionen angeboten bzw. bereitgestellt werden können, ist auch eine Skalierbarkeit des Moduls gegeben.
In einer weiteren Ausführungsform des Verfahrens ist eine Integration von sog. Legacy Software möglich. In dem Modul können durch eine geeignete Kapselung Funktionen koexistieren, die sich in unterschiedlichen Entwicklungsphasen befinden, somit ist es z. B. möglich, dass eine neue Funktion mit alter Software zusammenarbeitet. Dadurch wird gleichzeitig die Wiederverwendung alter Software gefördert.
Durch das im Rahmen der Erfindung u. a. vorgesehen Middleware- Konzept bietet sich zusätzlich zu einem kommerziellen Anbieten von Systemen die Möglichkeit, eine Service-Plattform für das Verteilen und Ausführen von Software- Funktionen zu definieren. Des weiteren kann ein Arbeiten mit dem Modul und somit der Middleware durch geeignete Adapter realisiert werden.
Außerdem kann im Rahmen der Erfindung jederzeit eine nachträgliche funktionale Erweiterung vorgenommen werden. So ist es insbesondere mit dem Middleware- Konzept möglich, neue Funktionalitäten zur Laufzeit der Software hinzuzufügen. Bezogen auf ein Fahrzeug könnten der Rechneranordnung des Fahrzeugs bei Servicestationen, bspw. an Tankstellen oder in Werkstätten, neue Funktionen bereitgestellt und geladen werden, ohne das dazu eine Manipulation der Rechneranordnung und somit auch von Steuergeräten notwendig ist.
Die vorgeschlagene Rechneranordnung, die zu einer möglichen Realisierung des Midd- leware- Konzepts geeignet ist, besteht regelmäßig aus den mindestens drei nachfolgend beschriebenen Bestandteilen:
- einer Anzahl Rechnerknoten, an die elektromechanische Vorrichtungen, in der Regel Sensoren und/oder Aktoren angeschlossen sein können,
- einem zentralen Modul, das in vorliegender Ausführungsform als Middleware-Schicht ausgebildet ist,
- mindestens einem Funktionsspeicher, in dem ECU-Funktionen gespeichert sind.
Jeweils ein Rechnerknoten der Rechneranordnung, der middleware-kompatibel ist, umfasst typischerweise einen Mikrocontroller und ein Betriebssystem, das je nach Anwendung des Mikrocontrollers auch als ein Mini- Betriebssystem ausgebildet sein kann. Das Betriebssystem ist in eine Laufzeitumgebung, die von den Funktionen benötigt wird, eingebettet und/oder an eine derartige Laufzeitumgebung angepasst.
Eine Aufgaben des Rechnerknotens besteht in einer Verwaltung von Ressourcen. Der Rechnerknoten kennt und verwaltet die Ressourcen, die ihm direkt, bspw. von einem RAM- oder Flashspeicher, oder indirekt, bspw. von elektromechanischen Vorrichtungen, zugeordnet werden.
Außerdem kann mit dem Rechnerknoten eine zeitabhängige Verwaltung oder Planung (Scheduling) von Funktionen durchgeführt werden. Falls mehrere Funktionen einem
Rechnerknoten zugeordnet sind, kann dieser eigenständig entscheiden, welche Funktion zu welchem Zeitpunkt verarbeitet oder gerechnet wird.
Mit dem Rechnerknoten kann eine Kommunikation mit der Middleware durchgeführt werden. Dies kann bedeuten, dass sich der Rechnerknoten bei der Middleware an- bzw. abmeldet. Der Rechnerknoten kann auch dazu geeignet sein, der Middleware Auskunft über seine Ressourcen und/oder seinem aktuellen Status zu geben, sofern bspw. ein Ausfall des Rechnerknotens vorliegt.
Ergänzend kann der Rechnerknoten zu einer Überwachung bzw. einem Monitoring von sich selbst sowie anderen Komponenten ausgebildet sein, so dass der Rechnerknoten einen eigenen Zustand erfassen und mögliche Ausfälle erkennen kann.
Die Rechneranordnung weist zur Bereitstellung einer Kommunikation üblicherweise ein Verteilungsnetzwerk auf. Über die Rechnerknoten können die elektromechanischen Vorrichtungen an derartige Rechneranordnungen oder Netzwerke angebunden sein.
Zur Ausführung von Funktionen auf einer bestimmten Hardware ist normalerweise ein Binärcode notwendig, der in der Regel nur auf einer bestimmten Hardwareplattform lauffähig ist. Dies bedeutet, dass der Binärcode nicht portabel ist. Um dieses Problem zu umgehen, sind in Ausgestaltung der Erfindung zumindest zwei Optionen vorgesehen. Bei einer ersten Option ist eine Binär- Kompatibilität gegeben. In diesem Fall werden in der Rechneranordnung und somit einem Middleware- Netzwerk ausschließlich Rechner einer bestimmten Familie verwendet, die untereinander binär-kompatibel sind. Die Rechenknoten weisen bezüglich ihrer Ausstattung zwar unterschiedliche Ressourcenei- genschaften auf, können jedoch aber alle denselben Binärcode verarbeiten. In diesem Fall enthält der Funktionsspeicher den ausschließlich für die gewählte Rechnerfamilie geeigneten Binärcode.
Bei einer zweiten Option liegt eine Binär-Inkompatibilität vor. In diesem Fall kommen unterschiedliche Rechnerplattformen, die nicht binärkompatibel sind, zum Einsatz. In einer Ausführungsform ist hierbei vorgesehen, dass auf jedem Rechnerknoten zusätzlich eine sog. Virtual Machine zum Einsatz kommt, die dazu ausgebildet ist, einen plattformunabhängigen Bytecode auszuführen. Ein derartiger Bytecode ist als ein rechnerunabhängiger Binärcode ausgebildet, der zur Ausführung von der Virtual Machine auf den darunter liegenden Rechner bzw. eine darunter liegende Recheneinheit abgebildet ist. Ein derartiges Vorgehen ist analog zu Java oder C# ausführbar. In diesem Fall wird im Funktionsspeicher ausschließlich der Bytecode abgelegt.
Der mindestens eine Funktionsspeicher ist als Speichereinrichtung oder Container für alle ECU- Funktionen, die zur Laufzeit bestimmten Rechnerknoten zur Bearbeitung oder Berechnung dynamisch zugeordnet werden, ausgebildet. Dabei wird der mindestens eine Funktionsspeicher von der Middleware verwaltet und gesteuert, so dass der Funktionsspeicher typischerweise selber nicht zur aktiven Ausführung von Programmen o- der Funktionen ausgebildet ist. Dies bedeutet auch, dass der mindestens eine Funkti- onsspeicher in der Regel nur passiv mit einer Rechnerumgebung zusammenwirkt.
Im Normalfall ist der mindestens eine Funktionsspeicher als eine zentrale Speichereinrichtung ausgebildet, die direkt oder ggf. auch indirekt an das Modul bzw. die Middleware angebunden ist. Der mindestens eine Funktionsspeicher kann jedoch alternativ auch mehrere dezentrale Speichereinrichtungen umfassen, die wiederum alle direkt oder indirekt mit dem Modul verbunden sind. Für ein Zusammenwirken des mindestens einen Funktionsspeichers mit den Rechnerknoten sind zumindest zwei Alternativen realisierbar. Diese beiden Alternativen können auch kombiniert werden.
Eine erste Alternative betrifft einen physikalischen Funktionstransfer, bei dem einzelnen Funktionen des mindestens einen Funktionsspeichers über das Modul in einen Speicher des Rechnerknotens bzw. eines Rechnerknotenspeichers verschoben und/oder kopiert werden. In diesem Fall ist der Rechnerknoten dazu ausgebildet, eine auf dem Rechnerknotenspeicher lokal vorliegende Kopie der Funktion auszuführen.
Bei einer zweiten Alternative ist eine direkte Ausführung der Funktion im Funktionsspeicher vorgesehen. Bei dieser Alternative erhält der Rechnerknoten von dem Modul eine Speicheradressen in dem Funktionsspeicher. Daher ist für den Rechnerknoten kein physischer Code erforderlich. Der Rechnerknoten rechnet somit die Funktion mit Hilfe ihrer Adressen direkt im Funktionsspeicher, ohne eine lokale Kopie der Funktion zu besitzen.
Das erfindungsgemäße Modul ist zur Durchführung mindestens eines Schritts des erfindungsgemäßen Verfahrens ausgebildet. Hierbei ist u. a. vorgesehen, dass das Modul eine Verteilung einzelnen Funktionen auf den unterschiedlichen Komponenten der
Rechnerknoten überwacht. Dabei kann alternativ und/oder ergänzend vorgesehen sein, dass das Modul sowohl mit einzelnen Rechnerknoten und/oder elektromechanischen Vorrichtungen als auch mit dem Funktionsspeicher kommuniziert.
Das Modul und somit die Middleware kann als ein Rechnerknoten mit speziellen Eigenschaften, insbesondere als ein sog. intelligenter Rechnerknoten ausgebildet sein. Dabei ist das Modul zum Verteilen von Funktionen und für eine Kommunikation mit den Rechnerknoten und dem Funktionsspeicher ausgebildet.
Eine Verwaltung des Funktionsspeicher durch das Modul umfasst eine Speicherung von neuen Funktionen als auch eine Löschung von nicht mehr benötigten Funktionen im Funktionsspeicher. Ein Verhalten des Moduls ist in Ausgestaltung durch eine Reihe von definierten Regeln und Kriterien festgelegt, diese können entweder statisch definiert werden und/oder selber auch dynamisch veränderbar sein.
Zudem kann für das Modul ein sog. Ressourcen- Registry für alle Rechner und Funktionen vorgesehen sein. Dies bedeutet regelmäßig, dass dem Modul alle Rechnerknoten einschließlich ihrer aktuellen Zustände und Fähigkeiten sowie die Funktionen im Funktionsspeicher mit ihren Anforderungen für eine korrekte Ausführung bekannt sind.
Im Zusammenhang mit AUTOSAR-Anwendungen sind unterschiedliche Szenarien zur Realisierung der Erfindung denkbar. So ist es bspw. möglich, AUTOSAR in das Modul bzw. die Middleware zu integrieren. In diesem Fall ist das Modul für die Verteilung von Funktionen und für die Kommunikation der Funktionen untereinander zuständig. Auf diese Weise können AUTOSAR- Konzepte, insbesondere wenn diese eine Kommuni- kation betreffen, vollständig in das Modul integriert werden.
In weiterer, alternativer Ausgestaltung kann das Modul bzw. die Middleware als sog. Add-On, also Zusatz oder Erweiterung zu AUTOSAR, ausgebildet sein. In dieser Ausgestaltung ist es bspw. möglich, dass AUTOSAR derart für eine Kommunikation zwi- sehen verschiedenen Funktionen oder Funktionskomponenten ausgebildet ist, dass die dynamische Verteilung von derartigen Funktionen oder Funktionskomponenten bei dieser Anwendung nicht durch AUTOSAR erfolgt. Dafür ist die Erweiterung, insbesondere ein Middleware Add-On, zur Durchführung der dynamischen Verteilung der Funktionen auf die Komponenten und insbesondere die Rechnerknoten ausgebildet.
Alternativ kann auch eine Middleware vorgesehen sein, die dazu ausgebildet ist, zwischen einer statischen Verteilung gemäß AUTOSAR und einer dynamischen Verteilung umzuschalten. Dies kann für einen Normalbetrieb des Fahrzeugs bedeuten, dass bspw. statisch zugeordnete Funktionen gerechnet werden. Insbesondere bei Eintreten ggf. zu definierender Ausnahmesituationen kann durch das Modul auf eine dynamische Zuordnung von Funktionen zu Rechnerknoten umgeschaltet werden. Bei einer derartigen Umschaltung kann zumindest ein Teil der im Normalbetrieb statisch ausgeführten Funktionen dynamisch ausgeführt werden. Dazu können bei einer Ausführung bisherige statischen Funktionen aus wenigstens einem Rechnerknoten oder einer Recheneinheit der Rechneranordnung entfernt und durch neue dynamisch-zugeordnete Funktionen ersetzt werden. Alternativ dazu können in einem reservierten Bereich mindestens eines Rechnerknotens dynamisch Funktionen geladen werden, während ein weiterer Bereich des Rechnerknotens davon nicht betroffen ist. Bei dieser Ausführung ist für einen Rechnerknoten ein AUTOSAR-Anteil und gleichzeitig ein Middleware-Anteil vorgesehen.
Kurze Beschreibung der Zeichnungen
Figur 1 zeigt ein Diagramm für ein Beispiel einer nach AUTOSAR definierten
AU TOS AR- Architektur.
Figur 2 zeigt in schematischer Darstellung ein Bespiel für eine Rechneranordnung.
Ausführungsform der Erfindung
Figur 1 zeigt das Diagramm für eine AUTOSAR-Architektur 2, wie sie durch AUTOSAR festgelegt ist. Diese umfasst eine erste Softwarekomponente 4, eine zweite Software- komponente 6 sowie eine n-te Softwarekomponente 8, eine durch AUTOSAR bestimmte Laufzeitumgebung 10 (Run-Time Environment, RTE), Basissoftware 12 und eine Abstraktion 14 eines Mikrocontrollers.
Dabei weist die Basissoftware 12 in der Regel Übertragungsschichten für verschiedene Kommunikationstechnologien, wie bspw. CAN, LIN und dergleichen, ein Netzwerk Management, das in der Regel Diagnoseprotokolle aufweist, und ein NVRAM- Management für nicht löschbare Arbeitsspeicher auf.
Bei dieser AUTOSAR-Architektur 2 ist vorgesehen, dass eine Zuordnung der voranste- hend erwähnten Komponenten innerhalb der AUTOSAR-Architektur 2 zu bestimmten Rechnerknoten statisch festgelegt ist, so dass es zur Laufzeit nicht möglich ist, innerhalb der AUTOSAR-Architektur 2 Änderungen oder Anpassungen vorzunehmen. Figur 2 zeigt in schematischer Darstellung eine Ausführungsform einer erfindungsge- mäßen Rechneranordnung 20. Diese umfasst ein hier als Middleware ausgebildetes Modul 22, und einen Funktionsspeicher 24, der in dieser Ausführungsform zum Speichern von ECU- Funktionen ausgebildet ist. Außerdem weist diese Rechneranordnung 20 mehrere Rechnerknoten 26 auf. Dabei sind an zwei dieser Rechnerknoten 26 elekt- romechanische Vorrichtungen, die hier als Sensoren 28 ausgebildet sind, angeschlossen. An zwei weitere Rechnerknoten 26 sind elektromechanische Vorrichtungen, die hier als Aktoren 30 ausgebildet sind, angeschlossen.
Bei einem Betrieb der Rechneranordnung 20 werden Funktionen der Rechneranordnung 20 mittels des Moduls 22 auf mindestens einen Rechnerknoten 26 der Rechneranordnung 22 zur Laufzeit dynamisch verteilt.

Claims

Ansprüche
1. Verfahren zum Betreiben einer Rechneranordnung (20), bei dem Funktionen der Rechneranordnung (20) mittels eines Moduls (22), das mit der Rechneranordnung (20) zusammenwirkt, auf mindestens einen Rechnerknoten (26) der Rech- neranordnung (20) dynamisch verteilt werden.
2. Verfahren nach Anspruch 1, bei dem die Funktionen mittels eines als Middleware ausgebildeten Moduls (22) dynamisch verteilt werden.
3. Verfahren nach Anspruch 1 oder 2, bei dem die Funktionen zur Laufzeit dynamisch verteilt werden.
4. Verfahren nach einem der voranstehenden Ansprüche, bei dem eine Kommunikation zwischen den Funktionen durch das Modul (22) bereitgestellt wird.
5. Verfahren nach einem der voranstehenden Ansprüche, bei dem die Funktionen in mindestens einem zum Speichern der Funktionen ausgebildeten Funktionsspeicher (24) gespeichert werden.
6. Verfahren nach Anspruch 5, bei dem der mindestens eine Funktionsspeicher (24) durch das Modul (22) verwaltet wird.
7. Modul, das mit einer Rechneranordnung (20) zusammenwirkt und dazu ausgebildet ist, Funktionen der Rechneranordnung (20) auf mindestens einen Rechner- knoten (26) der Rechneranordnung (20) dynamisch zu verteilen.
8. Modul nach Anspruch 7, das als Middleware ausgebildet ist.
9. Rechneranordnung, die Rechnerknoten (26) und mindestens ein Modul (22) aufweist, das dazu ausgebildet ist, Funktionen der Rechneranordnung (20) auf mindestens einen Rechnerknoten (26) der Rechneranordnung (20) dynamisch zu verteilen.
10. Rechneranordnung nach Anspruch 9, bei der die Rechnerknoten (26) dazu ausgebildet sind, mit elektromechanischen Vorrichtungen zusammenzuwirken.
11. Rechneranordnung nach Anspruch 9 oder 10, die mindestens einen Funktions- Speicher (24) zum Speichern der Funktionen aufweist.
12. Computerprogramm mit Programmcodemitteln, um alle Schritte eines Verfahrens nach einem der Ansprüche 1 bis 6 durchzuführen, wenn das Computerprogramm auf einem Computer oder einer entsprechenden Recheneinheit, insbesondere in einer Rechneranordnung (20) nach Anspruch 7 oder 8, ausgeführt wird.
13. Computerprogrammprodukt mit Programmcodemitteln, die auf einem computerlesbaren Datenträger gespeichert sind, um alle Schritte eines Verfahrens nach einem der Ansprüche 1 bis 6 durchzuführen, wenn das Computerprogramm auf einem Computer oder einer entsprechenden Recheneinheit, insbesondere in einer Rechneranordnung (20) nach Anspruch 7 oder 8, ausgeführt wird.
PCT/EP2007/061271 2006-10-30 2007-10-22 Verfahren zum betreiben einer rechneranordnung WO2008052901A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE200610051210 DE102006051210A1 (de) 2006-10-30 2006-10-30 Verfahren zum Betreiben einer Rechneranordnung
DE102006051210.3 2006-10-30

Publications (1)

Publication Number Publication Date
WO2008052901A1 true WO2008052901A1 (de) 2008-05-08

Family

ID=38961118

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2007/061271 WO2008052901A1 (de) 2006-10-30 2007-10-22 Verfahren zum betreiben einer rechneranordnung

Country Status (2)

Country Link
DE (1) DE102006051210A1 (de)
WO (1) WO2008052901A1 (de)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102011075868A1 (de) * 2011-05-16 2012-11-22 Continental Automotive Gmbh Sensordatenauswertegerät und Anordnung mit einem Sensordatenauswertegerät, das mit Steuergeräten verbunden ist.

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006004276A (ja) * 2004-06-18 2006-01-05 Masahiro Ito ３ｄ描画ミドルウェア
US20060173993A1 (en) * 2005-01-28 2006-08-03 Henseler David A Management of software images for computing nodes of a distributed computing system

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006004276A (ja) * 2004-06-18 2006-01-05 Masahiro Ito ３ｄ描画ミドルウェア
US20060173993A1 (en) * 2005-01-28 2006-08-03 Henseler David A Management of software images for computing nodes of a distributed computing system

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
C. SØRENSEN , M. WU, T. SIVAHARAN ET AL: "A Context-Aware Middleware for Applications in Mobile Ad Hoc Environments", PROCEEDINGS OF THE 2ND WORKSHOP ON MIDDLEWARE FOR PERVASIVE AND AD-HOC COMPUTING, 2004, Toronto, Ontario, Canada, pages 107 - 110, XP002466417, Retrieved from the Internet <URL:http://delivery.acm.org/10.1145/1030000/1028510/p107-sorensen.pdf?key1=1028510&key2=6558051021&coll=GUIDE&dl=GUIDE&CFID=13936134&CFTOKEN=57145566> [retrieved on 20070128] *
H. HEINECKE, J. BIELEFELD ET AL: "AUTOSAR ? Current results and preparations for exploitation", 7TH EUROFORUM CONFERENCE SOFTWARE IN THE VEHICLE, 4 May 2006 (2006-05-04), Stuttgart, Germany, pages 1 - 8, XP002466416, Retrieved from the Internet <URL:http://www.autosar.org/download/AUTOSAR_Euroforum_2006.pdf> [retrieved on 20070128] *

Also Published As

Publication number Publication date
DE102006051210A1 (de) 2008-05-08

Similar Documents

Publication Publication Date Title
EP2420907B1 (de) Verfahren zur Konfiguration von Feldbusteilnehmern
DE10029645B4 (de) Verfahren zur Adressierung von Netzwerkkomponenten
WO1999030459A2 (de) Verfahren zur koordination von netzwerkkomponenten
DE202008016892U1 (de) Kraftfahrzeug-Steuervorrichtung
EP0825524A1 (de) Verfahren zur Verwaltung der Benennung von Objekten
EP1430369B1 (de) Dynamischer zugriff auf automatisierungsressourcen
EP3929740A1 (de) Verfahren zur orchestrierung einer container-basierten anwendung auf einem endgerät
EP3080950B1 (de) Verfahren und system zur deterministischen autokonfiguration eines gerätes
DE10357118A1 (de) Laden von Software-Modulen
EP3977301A1 (de) Laufzeitserver zum gleichzeitigen ausführen mehrerer laufzeitsysteme einer automatisierungsanlage
EP1653308B1 (de) System und Verfahren zur Speicherung und Bereitstellung von Informationen
DE102004060301A1 (de) Verfahren zum Initialisieren eines elektronischen Systems umfassend mehrere Plug-Ins
EP1643679A1 (de) Konfiguration von Baugruppen in Automatisierungssystemen
WO2008052901A1 (de) Verfahren zum betreiben einer rechneranordnung
WO2005022382A2 (de) Verfahren zur installation einer programmkomponente
EP4160390B1 (de) Verfahren und anordnung zur inbetriebnahme einer aktualisierten anwendung für eine industrielle automatisierungsanordnung
EP2333624A1 (de) Verfahren und Einrichtung zur Konfigurierung einer Komponente in einer industriellen Automatisierungsanordnung
WO2013152826A1 (de) Verfahren zum betreiben eines diagnosesystems und diagnosesystem
WO2008052902A1 (de) Verfahren zum betreiben einer anordnung
EP1536328B1 (de) Datenverarbeitungssystem mit automatisierbarer Verwaltung und Verfahren zur automatisierten Verwaltung eines Datenverarbeitungssystems
EP1997007A2 (de) Verfahren und managementsystem zum konfigurieren eines informationssystems
DE102019211908A1 (de) Verfahren und Vorrichtung zum Verteilen einer Anwendung
WO2021037378A1 (de) Verfahren zum automatischen markieren, cluster-arbeitsknoten, cluster, netzwerk, computerprogramm und computerlesbares medium
EP1819551B1 (de) Verfahren zur strukturierten speicherung von fehlereinträgen
WO2023001437A1 (de) Verfahren zur automatischen anpassung der internen konfiguration einer externen netzwerkschnittstelle, computerprogrammprodukt und vorrichtung

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

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 07821635

Country of ref document: EP

Kind code of ref document: A1