DE10129446A1

DE10129446A1 - Verfahren zur Initialisierung einer verteilten Software Architektur und elektronisches System

Info

Publication number: DE10129446A1
Application number: DE10129446A
Authority: DE
Inventors: Vasco Vollmer; Matthias Hofmann
Original assignee: Robert Bosch GmbH
Current assignee: Robert Bosch GmbH
Priority date: 2001-06-19
Filing date: 2001-06-19
Publication date: 2003-01-02
Also published as: US7565420B2; EP1428116A2; WO2002103516A2; WO2002103516A3; US20060089963A1; JP2004538559A

Abstract

Die Erfindung betrifft ein Verfahren zur Initialisierung einer verteilten Softwarearchitektur sowie ein elektronisches System. Ein Steuerungsmodul für eine Netzwerkfunktion wird in Form eines DCM zur Verfügung gestellt. Dieses Steuerungsmodul wird in einer Registry (24) als DCM registriert. Die Erfindung erlaubt es, eine verteilte Softwarearchitektur z. B. des HAVi Standards um Netzwerk- und Systemverwaltungsfunktionen zu erweitern, die insbesondere eine Anwendung für Kraftfahrzeuge erlauben.

Description

Die Erfindung betrifft ein Verfahren zur Initialisierung einer verteilten Softwarearchitektur, insbesondere für ein Bussystem für Kraftfahrzeuge, und ein entsprechendes elektronisches System.
Aus dem Stand der Technik sind verschiedene verteilte Softwarearchitekturen bekannt. Aus "The HAVi specification, Specification of the home audio/video interoperability (HAVi) architecture", HAVi specification 1.0, HAVi organisation, 18. Januar 2000, ist eine solche verteilte Softwarearchitektur zur Implementierung in sogenannten Consumer Electronics (CE) Geräten und Computern, wie z. B. sogenannten Personal Digital Assistants und anderen elektronischen Geräten, die einen Computer aufweisen, bekannt. Die HAVi Architektur beinhaltet Dienste, die die Interoperabilität und die Entwicklung von verteilten Anwendung in Hausnetzwerken vereinfachen. Eine bevorzugte Anwendung der HAVi Architektur betrifft CE Geräte, die den IEEE 1394 und / oder IEC 61883 Interfacestandards entsprechen.
In der verteilten Softwarearchitektur nach dem HAVi Industriestandard erfolgt die Steuerung der einzelnen Geräte über Steuerungsmodule, sogenannte Device Control Moduls (DCM). Bei einem DCM handelt es sich um ein HAVi Softwareelement, welches eine Schnittstelle zur Steuerung der Funktionen eines bestimmten Gerätes zur Verfügung stellt. Ein DCM ist also jeweils spezifisch für ein bestimmtes Gerät oder eine bestimmte Geräteklasse.
Die Fig. 1 zeigt ein Beispiel für HAVi Softwareelemente, die eine Mittelschicht zwischen plattformspezifischen Application Programming Interfaces (API) und plattformunabhängigen Anwendungen bilden. Das Beispiel der Fig. 1 ist aus "HAVi, The A/V Digital Network Revolution", HAVi Organisation, 1999 (http:/ / www.HAVi.org) bekannt.
Die verteilte Softwarearchitektur ist zwischen einer plattformspezifischen API 1 und einer Interoperbilitäts-API 2 realisiert. Unterhalb der plattformspezifischen API 1 befindet sich eine herstellerabhängige Plattform 3; oberhalb der Interoperabilitäts-API 2 befinden sich Anwendungen 4 sowie sogenannte Havlets 5. Bei einem Havlet handelt es sich um eine HAVi Java Anwendung, die auf Anfrage eines Steuerungsgeräts von einem DCM oder Anwendungsmodul geladen wird.
Die eigentlichen HAVi-Komponenten können als einzelne Module im System als Softwareelemente adressiert werden. Die Softwareelemente können dabei im Allgemeinen sowohl zentral als auch verteilt angeordnet sein, das heißt, eine Implementierung mit nur einer Instanz eines bestimmten Softwareelements bis hin zu einer Implementierung, die in jedem Gerät eine solche Instanz vorsieht, ist möglich. Im einzelnen beinhaltet das System die folgenden Softwareelemente:
Streammanager 6: Der Streammanager dient dem Auf- und Abbau und der Verwaltung von Verbindungen zwischen Softwareelementen oder Geräten. Der Streammanager kann wie eine Registry als verteiltes System aufgebaut sein. Dabei können spezielle Befehle dazu dienen, den Zustand aller Streammanager oder eines bestimmtes Streammanagers abzufragen.
Eventmanager 7: Der Eventmanager transportiert Mitteilung über Zustandsänderungen im System zu den Kommunikationsteilnehmern.
Registry 8: Die Registry beinhaltet Informationen über jedes im Netzwerk verfügbares Softwareelement und jedes verfügbare Gerät. Informationen über die einzelnen Softwareelemente werden dabei in Attributen abgelegt. Zusätzlich zu den vordefinierten Attributen ist es möglich, weitere hinzuzufügen. Die Architektur der Registry erlaubt eine Verteilung im System, das heißt, jedes Gerät kann einen Teil der gesamten Registry beinhalten; sie kann aber auch zentral gehalten werden. Für den Zugriff auf die Registry ist dies unsichtbar, da die verschiedenen Instanzen der Registry innerhalb des Netzwerkes gegebenenfalls die angeforderten Information selbsttätig austauschen.
Resource Manager 9: Der Resource Manager führt die Belegung und Freigabe von Resourcen - das heißt Geräten und Softwareelementen - durch und speichert geplante Vorgänge wie z. B. Videorecorderaufnahmen.
DCM Manager 10: Der DCM Manager ist verantwortlich für die Installierung und Deinstallieren von DCMs bei entsprechend geeigneten Geräten. Dabei wird ein standardisiertes Verfahren zur Installation von DCMs im Java-Byte-Code-Format angeboten. Eine Installation von nativem Code (binär) ist nicht in dem HAVi Standard beschrieben, kann jedoch als proprietäre Lösung hinzugefügt werden.
Device Control Module (DCM) 11: Ein DCM ist ein Softwareelement, das ein oder mehrere sogenannte Functional Control Moduls (FCM) zu einem Gerätetreiber zusammenführt.
Functional Control Modul (FCM): Ein FCM ist ein Softwareelement mit dem eine funktionale Einheit eines Gerätes (z. B. ein CD-Laufwerk oder ein UKW-Tuner) angesteuert wird. Ein DCM wird dabei aus den allen DCMs gemeinsam Grundfunktionen und gerätespezifischen FCMs gebildet.
Diese verteilten oder in einem bestimmten Gerät implementierten Module bilden eine einheitliche lnteroperabilitäts API 2. Durch diese einheitlich Schnittstelle wird eine Interoperabilität zwischen den Applikationen 4 und Geräten verschiedener Hersteller erreicht.
Die HAVi Softwarearchitektur beinhaltet ferner ein Messaging System 12, welches zum Austausch von Mitteilungen zwischen den verschiedenen HAVi Softwareelementen dient. Der Communication Media Manager 13 erlaubt anderen Geräten oder Softwareelementen asynchrone oder isochrone Kommunikation über das Netzwerk zu betreiben. Vorzugsweise bedient der Communication Media Manager 13 den IEEE-1394 Standard.
Der Erfindung liegt die Aufgabe zu Grunde, ein verbessertes Verfahren zur Initialisierung einer verteilten Software Architektur und ein verbessertes elektronisches System mit einer verteilten Softwarearchitektur sowie ein entsprechendes Computerprogrammprodukt, insbesondere zum Einsatz in Fahrzeugen, zu schaffen.
Die der Erfindung zu Grunde liegende Aufgabe wird jeweils mit den Merkmalen der unabhängigen Patentansprüche gelöst. Bevorzugte Ausführungsformen der Erfindung sind in den abhängigen Patentansprüchen angegeben.
Die Erfindung erlaubt es, zusätzliche Verwaltungs- und Kontrollfunktionen für Netzwerk, insbesondere für den Einsatz in Fahrzeugen, in ein verteiltes System, insbesondere ein System nach dem HAVi Standard, nahtlos zu integrieren. Die entsprechenden Netzwerkfunktionen werden dabei als Steuerungsmodule in Form von DCMs in ein oder mehreren der Netzwerkteilnehmer zur Verfügung gestellt. Dabei haben die Steuerungsmodule für Netzwerksfunktionen lediglich die Form eines DCMs, unterscheiden sich aber wesentlich von der Funktionalität eines aus dem Stand der Technik an sich bekannten DCMs, insofern als durch ein erfindungsgemäßes Steuerungsmodul Netzwerkfunktionen, insbesondere Verwaltungs- und Kontrollfunktionen, beispielsweise in einem automobilen Netzwerk, und nicht lediglich gerätespezifische Funktionen gesteuert werden. Von besonderem Vorteil ist dabei, dass die Registrierung des Steuerungsmoduls in einer Registry als DCM erfolgen kann, wobei auf die an sich aus dem Stand der Technik bekannten Abläufe zur Registrierung zurückgegriffen werden kann.
Gemäß einer bevorzugten Ausführungsform der Erfindung besteht ein erfindungsgemäßes Steuerungsmodul aus funktionalen Modulen für Netzfunktionen, wobei jedes der funktionalen Module die Form eines FCMs hat. Im Unterschied zu den aus dem Stand der Technik an sich bekannten FCMs dienen die lediglich in der Form von FCMs realisierten funktionalen Module gemäß der Erfindung nicht lediglich gerätespezifischen, sondern Netzwerkfunktionen.
Dabei kann es sich unter anderem um Funktionen wie die Verwaltung von Stromsparmodi im Netz, die Durchführung von Fehlererkennungs- und Fehlerbeseitigungsmechanismen, die Durchführung von Authentifizierung und die Steuerung einer Zugriffskontrolle im Netz, die Durchführung eines erweiterte Verbindungsmanagements zur Verwaltung der Übertragungskapazität und die Verwaltung einer Datenverschlüsselung bei der Übertragung von Daten zwischen Geräten im Netz handeln.
Diese Netzwerkfunktionen sind besonders für den Einsatz in Fahrzeugen vorteilhaft. Dabei können konform zu den im HAVi-Standard beschriebenen Methoden zum Hinzufügen von spezifischen Gerätetreibern (DCMs) zusätzliche Netzwerk- und Systemverwaltungsfunktionen mittels einer der HAVi Methoden hinzugefügt werden, wenn diese zusätzlichen Funktionsmodule die Form von DCMs haben.
Ein erfindungsgemäßes Steuerungsmodul hat dabei je nach der Ausprägung von dessen funktionalen Modulen die Rolle eines System Master oder eines System Slaves, welcher auch als System Manager bezeichnet wird. Im ersteren Falle einer System Master DCM betrifft die Netzwerkfunktion die zentrale Steuerung von Netzwerkelementen; im zweiten Fall beinhalten die funktionalen Module auf die entsprechenden Funktionen der System Master DCM abgestimmte Funktionen zur lokalen Steuerung in einem Gerät als "Slave".
Nach einer bevorzugten Ausführungsform der Erfindung beinhaltet ein erfindungsgemäßes Steuerungsmodul weitere Kommunikationsfunktionen, um mit anderen Steuerungsmodulen zu interagieren. Diese Kommunikationsfunktionen dienen beispielsweise der Feststellung der System Master DCM oder der Ersetzung eines System Maser DCM durch eine andere System Master DCM oder Teilen hiervon.
Im Weiteren wird ein bevorzugtes Ausführungsbeispiel der Erfindung mit Bezug auf die Zeichnungen näher erläutert. Es zeigen:
Fig. 1 die aus dem Stand der Technik bekannte HAVi Softwarearchitektur,
Fig. 2 ein Ausführungsbeispiel eines erfindungsgemäßes elektronischen Systems,
Fig. 3 ein Ausführungsbeispiel für die Struktur einer System Master DCM und einer System Manager DCM,
Fig. 4 ein Objekt-Interaktionsdiagramm bezüglich der Registrierung einer System Master DCM,
Fig. 5 ein Objekt-Interaktionsdiagramm hinsichtlich der teilweisen Ersetzung einer registrierten System Master DCM durch eine andere System Master DCM oder Teilen hiervon,
Fig. 6 ein Objekt-Interaktionsdiagramm zur Registrierung einer System Master DCM, wenn der Busmanager keine System Maser DCM aufweist.
Die Fig. 2 zeigt ein elektronisches System mit einem Bus 20, der die Netzwerkteilnehmer 21, 22, 23 und 24 sowie weitere in der Fig. 2 nicht gezeigte Netzwerkteilnehmer miteinander verknüpft. Bei den Netzwerkteilnehmern kann es sich um unterschiedlichste Geräte handeln. Für Anwendungen hinsichtlich Multimedia, Informations- und Unterhaltungsdiensten im Zusammenhang mit Internetdiensten, kann es sich dabei beispielsweise um CD-Player, MP3-Player, DVD-Player, UMTS und / oder GSM Module für die Datenübertragung, Internetbrowser, Anzeigegeräte, wie beispielsweise sogenannte Flat-Panel- Displays, Eingabegeräte, Benutzeroberflächen und dergleichen handeln.
Der Netzwerkteilnehmer 21 beinhaltet eine DCM zur Realisierung von gerätespezifischen Treibern. Der Netzwerkteilnehmer hat ferner eine System Manager DCM, jedoch keine System Master DCM.
Die Netzwerkteilnehmer 22 und 23 beinhalten dagegen jeweils zusätzlich eine erfindungsgemässe System Master DCM. Die System Master DCMs in den Netzwerkteilnehmern 22 und 23 können dabei voneinander verschieden sein, beispielsweise unterschiedliche Versionen und/oder unterschiedliche Funktionalitäten aufweisen.
Der Netzwerkteilnehmer 24 beinhaltet die Registry zur Registrierung der verschiedenen Geräte und Softwareelemente. Alternativ kann die Registry auch in den Netzwerkteilnehmern verteilt realisiert sein.
Die Fig. 3 zeigt die Struktur einer System Master DCM 1000. Diese beinhaltet ein funktionales Modul 1001 zur Verwaltung von Stromsparmodi im Netz ("System Power Master FCM"). Ferner beinhaltet die System Master DCM 1000 ein funktionales Modul 1002 zur Durchführung von Fehlererkennungs- und Fehlerbeseitigungsmechanismen ("System Error Handling FCM").
Des Weiteren beinhaltet die System Master DCM 1000 ein funktionales Modul 1003 zur Authentifizierung und Steuerung einer Zugriffskontrolle im Netzwerk ("System Security Master FCM"). Ferner beinhaltet die System Master DCM 1000 ein funktionales Modul 1004 zur Verwaltung der Datenverschlüsselung bei der Übertragung von Daten zwischen Geräten im Netz ("System Encryption Master FCM").
Die Fig. 3 zeigt ebenfalls die Struktur der entsprechenden System Manager DCM 2000, die als "Slave" mit der System Master DCM 1000 interagiert. Entsprechend den funktionalen Modulen 1001 bis 1004 der System Master DCM 1000 beinhaltet die System Manager DCM 2000 die funktionalen Module 2001 "Local Power Manager FCM"; 2002 "Local Security Manager FCM", 2003 "Local Encryption Manager FCM" und 2004 "Firewall FCM", jeweils für die lokale Realisierung der entsprechenden von der System Master DCM vorgegebenen Funktionen.
Die Fig. 4 zeigt ein Objekt-Interaktionsdiagramm, wobei die in der Fig. 4 gezeigten Objekte, welchen Elemente der Fig. 2 entsprechen, mit den Bezugszeichen der Fig. 2 bezeichnet sind.
In dem Schritt 40 wird zunächst ein sogenannter Busreset durchgeführt. Die Netzwerkteilnehmer, die durch den Bus 20 (vgl. Fig. 2) miteinander verbunden werden, können nach dem Busreset versuchen Busmanager zu werden. Dabei kann ein Verfahren gemäß IEEE 1394 verwendet werden.
In dem Ausführungsbeispiel der Fig. 4 wird der Netzwerkteilnehmer 23 in dem Schritt 41 Busmanager. Der Busmanager registriert daraufhin in dem Schritt 42 dessen System Master DCM in der Registry 24 mittels des Kommandos "RegisterElement". Dabei werden die Software Element ID (SEID) sowie weitere Attribute der System Master DCM des Netzwerkteilnehmers 23 als Argumente an die Registry 24 übertragen, um dort in die Registrierung eingetragen zu werden.
In dem Schritt 43 greift der Netzwerkteilnehmer 22, der nicht Busmanager geworden ist, auf die Registry 24 zu, um abzufragen, ob dort eine System Master DCM registriert worden ist. Dies erfolgt mit dem Kommando "GetElement_req", wobei als Attribut ein Suchbegriff für die System Master DCM verwendet wird.
Diese Anfrage wird von der Registry 24 dahingehend beantwortet, dass eine Nachricht "GetElement_cnf" an den Netzwerkteilnehmer 22 zurückübertragen wird, die als Argument die SEID der zuvor registrierten System Master DCM des Netzwerkteilnehmers 23 aufweist. Aufgrund dieser Beantwortung der Anfrage des Schritts 43 in dem Schritt 44 erhält der Netzwerkteilnehmer 22 die Information, dass bereits eine System Master DCM registriert worden ist, sowie auch die SEID der registrierten System Master DCM. Aufgrund dessen ist der Netzwerkteilnehmer 22 in die Lage versetzt, die registrierte System Master DCM mittels deren SEID zu adressieren.
Das Objekt-Interaktionsdiagramm der Fig. 5 entspricht dem Ausführungsbeispiel der Fig. 4, wobei jedoch nach Ausführung des Schritt 44 weitere Schritte ausgeführt werden. Dabei kommen insbesondere weitere in den System Master DCMs realisierte Kommunikationsfunktionen zum tragen:
In dem Schritt 45 richtet der Netzwerkteilnehmer 22, das heißt, dessen System Master DCM, eine Nachricht an die System Master DCM des Netzwerkteilnehmers 23. Diese Nachricht "ElementProposal" beinhaltet die SEID und die Attribute der System Master DCM des Netzwerkteilnehmers 22. Der Netzwerkteilnehmer 23 bzw. dessen System Master DCM kann dann einen entsprechenden Vergleich der beiden System Master DCMs vornehmen, z. B. hinsichtlich deren Versionen und der beinhalteten funktionalen Module.
Hat beispielsweise die System Master DCM des Netzwerkteilnehmers 22 eine neuere Versionsnummer, so kann entschieden werden, dass die System Master DCM des Netzwerkteilnehmers 22 an die Stelle der zuvor registrierten System Master DCM des Netzwerkteilnehmers 23 treten soll.
Alternativ können auch lediglich bestimmte funktionale Module in der System Master DCM des Netzwerkteilnehmers 22 ausgewählt werden, um die zuvor registrierte System Master DCM des Netzwerkteilnehmers 23 entsprechend zu ergänzen oder ein bestimmtes funktionales Modul in der bereits registrierten System Master DCM auszutauschen.
Nach der Entscheidung des Netzwerkteilnehmers 23 bzw. dessen System Master DCM hinsichtlich der Registrierung der System Master DCM des Netzwerkteilnehmers 22 bzw. von Teilen davon, wird - falls es zu einem Austausch kommen soll - in dem Schritt 46 eine Nachricht an die Registry 24 gesendet, die die SEID der System Master DCM des Netzwerkteilnehmers 22 bzw. die SEIDs der zu ergänzenden oder auszutauschenden funktionalen Module sowie der entsprechenden Attribute als Argumente beinhaltet. Aufgrund dessen erfolgt in der Registry 24 die Registrierung der neuen System Master DCM des Netzwerkteilnehmers 22 bzw. von deren funktionalen Modulen.
In dem Schritt 47 erfolgt eine Bestätigung von der System Master DCM des Netzwerkteilnehmers 23 an die System Master DCM des Netzwerkteilnehmers 22 hinsichtlich der Registrierung. Dabei wird als Argument die SEID der neu registrierten System Master DCM des Netzwerkteilnehmers 22 bzw. die SEIDs der ausgewählten funktionalen Module der System Master DCM des Netzwerkteilnehmers 22 zurückübertragen. Aufgrund dessen kann die System Master DCM des Netzwerkteilnehmers 22 die entsprechenden Softwareelemente der gültigen System Master DCM, so wie sie in der Registry 24 erfasst sind, adressieren.
Die Fig. 6 zeigt ein weiteres Ausführungsbeispiel für ein Objekt- Interaktionsdiagramm entsprechend den Fig. 4 und 5. Als Objekte sind dabei die Netzwerkteilnehmer 21, 22 und 24 (vgl. Fig. 2) dargestellt. Diejenigen Schritte der Fig. 6, die Schritten in den Fig. 4 und 5 entsprechen, sind mit den selben Bezugszeichen bezeichnet.
Im Unterschied zu den Ausführungsbeispielen der Fig. 4 und 5 wird in dem Ausführungsbeispiel der Fig. 6 ein Netzwerkteilnehmer Busmanager - Netzwerkteilnehmer 21 -, der keine System Master DCM beinhaltet. In diesem Fall kann der Busmanager keine System Master DCM in der Registry 24 registrieren (vgl. Schritt 42 Fig. 4 und 5). Aufgrund dessen kann als Argument der Nachricht in dem Schritt 44 auf die Anfrage der System Master DCM des Netzwerkteilnehmers 22 keine SEID übertragen werden.
Dadurch ist der System Master DCM des Netzwerkteilnehmers 22 signalisiert, dass bisher keine System Master DCM in der Registry 24 registriert worden ist. In dem Schritt 45 wird daher eine Nachricht von der System Master DCM des Netzwerkteilnehmers 22 an die Registry 24 gesendet, welche zur Registrierung der System Master DCM des Netzwerkteilnehmers 22 in der Registry 24 dient. Diese Nachricht "RegisterElement" beinhaltet als Argumente die SEID der System Master DCM des Netzwerkteilnehmers 22 sowie deren Attribute. Nach Empfang dieser Nachricht erfolgt in der Registry eine entsprechende Registrierung. Bezugszeichenliste 1 plattformspezifische API
2 Interoperabilitäts-API
3 herstellerabhängige Plattform
4 Anwendung
5 havlet
6 System Manager
7 Event Manager
8 Registry
9 Resource Manager
10 DCM Manager
11 DCM
12 Messaging System
13 Communication Media Manager
20 Bus
21 Netzwerkteilnehmer
22 Netzwerkteilnehmer
23 Netzwerkteilnehmer
24 Netzwerkteilnehmer

Claims

1. Verfahren zur Initialisierung einer verteilten Softwarearchitektur mit folgenden Schritten:

- Zurverfügungstellung eines Steuerungsmoduls für eine Netzwerkfunktion in Form eines DCM,

- Registrierung des Steuerungsmoduls in einer Registry als DCM.

2. Verfahren nach Anspruch 1, bei dem das Steuerungsmodul funktionale Module beinhaltet und die funktionalen Module jeweils die Form eines FCM haben.

3. Verfahren nach Anspruch 1 oder 2, bei dem das Steuerungsmodul ein oder mehrere der folgenden Netzwerkverwaltungsfunktionen beinhaltet:

- Verwaltung von Stromsparmodi im Netzwerk,

- Durchführung von Fehlererkennungs- und Fehlerbeseitigungsmechanismen,

- Durchführung von Authentifizierung und/oder Steuerung einer Zugriffskontrolle im Netzwerk,

- Durchführung eines erweiterten Verbindungsmanagements zur Verwaltung einer Übertragungskapazität,

- Verwaltung einer Datenverschlüsselung bei der Übertragung von Daten zwischen Geräten im Netzwerk.

4. Verfahren nach Anspruch 1, 2 oder 3, bei dem das Steuerungsmodul kraftfahrzeugspezifische Netzwerkfunktionen beinhaltet.

5. Verfahren nach einem der vorhergehenden Ansprüche 1 bis 4, bei dem ein erstes Steuerungsmodul durch einen ersten Netzwerkteilnehmer und ein zweites Steuerungsmodul durch einen zweiten Netzwerkteilnehmer zur Verfügung gestellt wird und eine Auswahl zwischen dem ersten und dem zweiten Steuerungsmodul erfolgt.

6. Verfahren nach Anspruch 5 mit folgenden weiteren Schritten:

- Auswahl eines der Netzwerkteilnehmer als Busmanager,

- wenn der Busmanager ein Steuerungsmodul beinhaltet: Registrierung des Steuerungsmoduls des Busmanagers in einer Registry.

7. Verfahren nach Anspruch 6, bei dem nur solche Netzwerkteilnehmer als Busmanager ausgewählt werden, die ein Steuerungsmodul aufweisen.

8. Verfahren nach Anspruch 5, 6 oder 7, mit folgenden weiteren Schritten:

- Abfrage der Registry durch die Netzwerkteilnehmer, die ein Steuerungsmodul haben, ob bereits ein Steuerungsmodul in der Registry registriert ist,

- für den Fall, dass ein Steuerungsmodul in der Registry registriert ist: Senden einer Software Element ID des registrierten Steuerungsmoduls an die betreffenden Netzwerkteilnehmer.

9. Verfahren nach einem der vorhergehenden Ansprüche 5 bis 8 mit folgenden weiteren Schritten:

1. Abfrage der Registry durch die Netzwerkteilnehmer, die ein Steuerungsmodul aufweisen, ob ein Steuerungsmodul in der Registry registriert ist,

- wenn kein Steuerungsmodul in der Registry registriert ist: Registrierung des Steuerungsmoduls eines Netzwerkteilnehmers, der nicht Busmanager ist, in der Registry.

10. Verfahren nach einem der vorhergehenden Ansprüche 5 bis 9 mit folgenden weiteren Schritten:

1. Senden von Informationen betreffend einer Eigenschaft des Steuerungsmoduls eines Netzwerkteilnehmers, dessen Steuerungsmodul nicht in der Registry registriert ist, an denjenigen Netzwerkteilnehmer, dessen Steuerungsmodul in der Registry registriert ist,

- Entscheidung des Netzwerkteilnehmers, dessen Steuerungsmodul in der Registry registriert ist, hinsichtlich der Auswahl des Steuerungsmoduls des Netzwerkteilnehmers, dessen Steuerungsmodul nicht in der Registry registriert ist, oder von Teilen hiervon, insbesondere hinsichtlich der Auswahl von einem oder mehreren funktionalen Modulen.

11. Verfahren nach Anspruch 10 mit folgenden weiteren Schritten:

1. wenn der Netzwerkteilnehmer, dessen Steuerungsmodul in der Registry registriert ist, eine Entscheidung zur Auswahl des Steuerungsmoduls oder eines Teils hiervon des Netzwerkteilnehmers, dessen Steuerungsmodul nicht in der Registry registriert ist, getroffen hat: Registrierung des ausgewählten Steuerungsmoduls oder des ausgewählten Teils hiervon in der Registry,

- Senden einer Software Element ID bezüglich des ausgewählten Steuerungsmoduls bzw. des ausgewählten Teils.

12. Computerprogrammprodukt zur Ausführung auf einem elektronischem System zur Durchführung eines Verfahrens nach einem der vorhergehenden Ansprüche 1 bis 11, wenn das Computerprogramm auf dem elektronischem System ausgeführt wird.

13. Elektronisches System mit
einem Netzwerkteilnehmer (22, 23), der ein Steuerungsmodul (1000) für eine Netzwerkfunktion in Form eines DCM ausweist,
einer Registry (24) zur Registrierung des Steuerungsmoduls als DCM.

14. Elektronisches System nach Anspruch 13, bei dem das Steuerungsmodul funktionale Module (1001, 1002, 1003, 1004) für Netzwerkfunktionen beinhaltet und die funktionalen Module jeweils die Form eines FCM haben.

15. Elektronisches System nach Anspruch 13 oder 14, bei dem es sich um ein Bussystem für ein Fahrzeug, insbesondere ein Kraftfahrzeug, handelt.

16. Elektronisches System nach Anspruch 13, 14 oder 15 mit mindestens einem ersten Netzwerkteilnehmer (22) mit einem ersten Steuerungsmodul und einem zweiten Netzwerkteilnehmer (23) mit einem zweiten Steuerungsmodul, wobei das erste und das zweite Steuerungsmodul jeweils Kommunikationsfunktionen zur Auswahl eines der Steuerungsmodule oder eines Teils hiervon zur Registrierung in der Registry aufweisen.

17. Elektronisches System nach einem der vorhergehenden Ansprüche 13 bis 16, bei dem das Steuerungsmodul als Mastersteuerungsmodul (1000) ausgebildet ist und die Netzwerkteilnehmer jeweils ein Slavesteuerungsmodul (2000) aufweisen, welches zur Interaktion mit dem Mastersteuerungsmodul ausgebildet ist.

18. Elektronisches System nach Anspruch 17, bei dem die Slavesteuerungsmodule jeweils funktionale Module für lokale Funktionen beinhalten und es sich bei den funktionale Modulen um FCMs handelt.