DE102006051210A1

DE102006051210A1 - Verfahren zum Betreiben einer Rechneranordnung

Info

Publication number: DE102006051210A1
Application number: DE200610051210
Authority: DE
Inventors: Josef Newald; Rainer Lucas; Stjepan Dujmovic
Original assignee: Robert Bosch GmbH
Current assignee: Robert Bosch GmbH
Priority date: 2006-10-30
Filing date: 2006-10-30
Publication date: 2008-05-08
Also published as: WO2008052901A1

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

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 Gegenzug zur Verfügung stellt. Das RTE wird aus dem VFB generiert. Dabei ist das RTE zu einer Laufzeit der Kommunikationsschicht statisch zugeordnet. Über diese Kommunikationsschicht 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 A1 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 Regelwerk 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 Rechneranordnung 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 Rechneranordnung 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 Einsatz 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 Rechnerknoten 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 miteinander 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. Sensoren 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 Anwendungen, 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 Rechneranordnung 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 benutzt 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. middlewarekonform 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-Plag von ECU-Funktionen. Bei ECU-Funktionen kann es sich um Funktionen einer sog. Electronic 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 Middleware-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 Ressourceneigenschaften 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 oder Funktionen ausgebildet ist. Dies bedeutet auch, dass der mindestens eine Funktionsspeicher 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 Kommunikation 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 zwischen 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 defnierender 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
1 zeigt ein Diagramm für ein Beispiel einer nach AUTOSAR definierten AUTOSAR-Architektur.
2 zeigt in schematischer Darstellung ein Bespiel für eine Rechneranordnung.
Ausführungsform der Erfindung
1 zeigt das Diagramm für eine AUTOSAR-Architektur 2, wie sie durch AUTOSAR festgelegt ist. Diese umfasst eine erste Softwarekomponente 4, eine zweite Softwarekomponente 6 sowie eine n-te Softwarekomponente 8, eine durch AUTOSAR bestimmte Laufzeitumgebung 10 (Run-Time Enviroment, 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 voranstehend 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.
2 zeigt in schematischer Darstellung eine Ausführungsform einer erfindungsgemäß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 elektromechanische 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

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.
Verfahren nach Anspruch 1, bei dem die Funktionen mittels eines als Middleware ausgebildeten Moduls (22) dynamisch verteilt werden.
Verfahren nach Anspruch 1 oder 2, bei dem die Funktionen zur Laufzeit dynamisch verteilt werden.
Verfahren nach einem der voranstehenden Ansprüche, bei dem eine Kommunikation zwischen den Funktionen durch das Modul (22) bereitgestellt wird.
Verfahren nach einem der voranstehenden Ansprüche, bei dem die Funktionen in mindestens einem zum Speichern der Funktionen ausgebildeten Funktionsspeicher (24) gespeichert werden.
Verfahren nach Anspruch 5, bei dem der mindestens eine Funktionsspeicher (24) durch das Modul (22) verwaltet wird.
Modul, das mit einer Rechneranordnung (20) zusammenwirkt und dazu ausgebildet ist, Funktionen der Rechneranordnung (20) auf mindestens einen Rechnerknoten (26) der Rechneranordnung (20) dynamisch zu verteilen.
Modul nach Anspruch 7, das als Middleware ausgebildet ist.
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.
Rechneranordnung nach Anspruch 9, bei der die Rechnerknoten (26) dazu ausgebildet sind, mit elektromechanischen Vorrichtungen zusammenzuwirken.
Rechneranordnung nach Anspruch 9 oder 10, die mindestens einen Funktionsspeicher (24) zum Speichern der Funktionen aufweist.
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.
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.