DE19748536C2 - Datenverarbeitungsgestütztes elektronisches Steuerungssystem, insbesondere für ein Kraftfahrzeug - Google Patents

Description

Die Erfindung bezieht sich auf ein datenverarbeitungsgestütztes elektronisches Steuerungssystem mit einem Anwendungsfunktionen ausführenden Steuergeräteverbund mit mehreren, verteilt angeord­ neten Steuergeräten und einem diese verbindenden Datenübertra­ gungsnetzwerk. Der Begriff Steuerungssystem ist hierbei in sei­ nem weiteren, auch Regelungssysteme umfassenden Sinne zu verste­ hen.

Derartige Steuerungssysteme werden beispielweise in Kraftfahr­ zeugen eingesetzt, um dort die fahrzeugtypischen Steuerungsfunk­ tionen auszuführen. In herkömmlichen Systemen werden die Steuer­ geräte jeweils spezifisch für eine oder mehrere Anwendungsfunk­ tionen ausgelegt. Die Implementierung einer neuen Fahrzeugfunk­ tion erfordert den Entwurf eines zugehörigen neuen Steuergerätes und dessen Einbau im Fahrzeug zusammen mit einer neuen Sensor- und Aktuatorkonfiguration. Zwar sind die Steuergeräte in moder­ neren Konfigurationen z. B. über einen CAN-Bus vernetzt, jedoch existieren keine expliziten Schnittstellen für den Zugriff auf einzelne Funktionsteile, so daß die jeweilige Anwendungsfunktion aus Sicht des Steuergerätes nur als Ganzes in Erscheinung tritt. Zur Realisierung von neuen, auf existierende Funktionen aufge­ bauten, sogenannten rekombinierten Funktionen müssen diese folg­ lich mit hohem Aufwand von Hand an existierende Funktionen ange­ schlossen werden, z. B. durch Definition oder Änderung entspre­ chender CAN-Botschaften. In ungünstigen Fällen macht dies für die Hinzufügung einer einzelnen neuen Funktion die Änderung al­ ler anderen Steuergeräte nötig. Dies führt zusammen mit dem Trend zu immer mehr elektronisch realisierten Funktionen im Kraftfahrzeug und deren zunehmender Kopplung untereinander zu einer stark anwachsenden Komplexität und zu entsprechenden Schwierigkeiten bei der Entwicklung und Beherrschung der gesam­ ten Fahrzeugelektronik sowie zu einem steigenden Bedarf an Re­ chenleistung und Speicherumfang. Zudem ergibt sich durch die steigende Komplexität bei gleichzeitig immer mehr Baureihen und kürzeren Entwicklungszeiten für dieselben der Bedarf, Komponen­ ten vermehrt baureihenübergreifend wiederverwenden zu können.

Von reinen Datenverarbeitungssystemen, z. B. zur Bürokommunika­ tion und in Großrechenanlagen, mit verteilten Rechnerkapazitäten ist es bekannt, sogenannte Client/Server-Architekturen vorzuse­ hen, um einen jeweiligen Dienst von einem hierauf ausgelegten Server für diesen Dienst aufrufende Clients zentralisiert zu er­ bringen. Bei diesen Systemen ist im allgemeinen keine Echtzeit­ verarbeitung gegeben.

In dem Zeitschriftenaufsatz D. Kuschke, Softwareschnittstelle SPS-Interbus-S, Elektrie, Berlin 48 (1994) 1, Seite 26 ist die Verwendung einer Client/Server-Architektur für den Anwendungs­ bereich von speicherprogrammierbaren Steuerungen mit über Feld­ bussysteme angeschlossener Peripherie offenbart. Wie üblich, erfolgt dabei direkt eine Kommunikation zwischen jeweils einem dienstanfordernden Client und einem den Dienst erbringenden Server.

In dem Textbuch R. Orfali und D. Harkey, Client/Server Program­ ming with OS/2 2.0, 1992, Van Nostrand Reinhold, New York sind Client/Server-Architekturen speziell für Datenverarbeitungssy­ steme beschrieben. Dabei können jeweils nicht nur mehrere Cli­ ents, sondern auch mehrere Server vorgesehen sein. In diesem Fall ist eine Vermittlungs- bzw. Verbindungsschicht in Form ei­ nes Netzwerkresourcenlokalisators vorgesehen, der es den Clients ermöglicht, ihre benötigten Server zu finden. Dieser Lokalisa­ tor kann z. B. durch einen "Gelbe Seiten"-Service realisiert sein, bei dem ein Serverprozeß als Vermittlungstelle fungiert, die eine Datenbasis über bekannte Dienste enthält und Netzwerk­ teilnehmern dienstbezogene Informationen zukommen läßt, wenn sie danach gefragt wird.

Der Erfindung liegt als technisches Problem die Bereitstellung eines insbesondere auch für Kraftfahrzeuge anwendbaren Steue­ rungssystems der eingangs genannten Art zugrunde, das sich zur Durchführung der Anwendungsfunktionen in Echtzeit und auch mit relativ knappen Rechenkapazitäten eignet und möglichst flexibel, standardisiert und offen ausgelegt ist, um Änderungen und/oder Ergänzungen, insbesondere hinsichtlich Implementierung neuer und/oder Modifikationen bestehender Anwendungsfunktionen, mit vergleichweise geringem Aufwand realisieren zu können.

Die Erfindung löst dieses Problem durch die Bereitstellung eines Steuerungssystems mit den Merkmalen des Anspruchs 1. Bei diesem datenverarbeitungsgestützten elektronischen Steuerungssystem sind die vom System durchzuführenden Anwendungsfunktionen in Form einer Client/Server-Architektur in den Steuergeräteverbund implementiert. Die Client/Server-Architektur wird vorliegend in einem sogenannten Embedded-System verwendet, d. h. einem System, in welchem die elektronische Datenverarbeitungsfunktionalität in ein übergeordnetes System, wie z. B. eine Fahrzeugfunktionen aus­ führende Fahrzeugelektronik, dieses stützend eingebettet ist und dem Anwender nicht direkt in Erscheinung tritt. Durch die Über­ tragung der aus Datenverarbeitungssystemen bekannten Client/Ser­ ver-Architektur auf das vorliegende Steuerungssystem wird ein Modell zur Strukturierung verteilter Anwendungen bereitgestellt, das besonders gut zur Beschreibung ereignisorientierter Systeme geeignet ist, wobei im Unterschied zu konventionellen Systemen die Schnittstellen zwischen Client- und Server-Prozessen primär an Diensten und nicht an Daten orientiert sind.

Mit dem vorliegenden System können die Anwendungsfunktionen hardwareunabhängig entwickelt und relativ einfach zwecks Erzeu­ gung neuer, höherwertiger Anwendungsfunktionen rekombiniert wer­ den. Im Rahmen der Client/Server-Architektur werden die Anwen­ dungsfunktionen beschrieben, die über definierte Anwendungspro­ tokoll-Schnittstellen miteinander kommunizieren, wozu zum Ent­ wurfszeitpunkt noch keine Aussage über die Art der physikali­ schen Kommunikation gemacht wird. Damit lassen sich durch das erfindungsgemäße Steuerungssystem Anwendungsfunktionen in Echt­ zeit durchführen und vergleichsweise einfach in verschiedene Systemauslegungen, z. B. bei verschiedenen Fahrzeugbaureihen, implementieren. Die elektronische Infrastruktur des Steuerungs­ systems besitzt durch die Verwendung des Client/Server-Archi­ tekturmodells eine flexible, standardisierte und offene Basis und eignet sich insbesondere auch für Systeme mit vergleichswei­ se geringen Rechenleistungsressourcen und statischer Software- Konfiguration.

Die Client/Server-Architektur beinhaltet für eine jeweilige An­ wendungsfunktion eine zwischen einer Clientebene und einer Ser­ verebene liegende Funktionsmonitorebene, in welcher ein entspre­ chender Funktionsmonitor den globalen Zustand der Anwendungs­ funktion verwaltet und somit als deren zentrale Schaltstelle oder Gedächtnis fungiert.

In weiterer Ausgestaltung dieser Struktur sind nach Anspruch 2 eine oder mehrere dieser drei Ebenen in spezieller Weise weiter strukturiert. Die Clientebene kann hierbei aus Requestoren als Quellen von Dienstanforderungen und nachgeschalteten primären Clients bestehen, während analog dazu die Serverebene aus primä­ ren Servern und nachgeschalteten Fulfillern aufgebaut sein kann. Ein primärer Client und der zugehörige Requestor bzw. ein primä­ rer Server und der zugehörige Fulfiller werden stets auf demsel­ ben Steuergerät angeordnet. Die Monitorebene beinhaltet einen mit den primären Clients kommunizierenden Funktionsmonitor, der den globalen Zustand der Anwendungsfunktion verwaltet, und von diesem abhängige Monitore für die Verwaltung von Teilfunktionen.

Der Funktionsentwurf basiert auf einer Menge von definierten De­ signelementen für Methoden und Protokolle, Service-Access-Points und Service-Access-Point-Interfaces, Ports und Portinterfaces, Verbindungen, Prozessen, Frames und Firmwareprozessen. In Wei­ terbildung der Erfindung nach Anspruch 3 sind die Service- Access-Points charakteristischerweise so ausgelegt, daß sie Schnittstellen von Anwendungsprozessen zur Schicht 7 des ISO/­ OSI-Referenzmodells bilden und je ein Protokoll in Client- und in Serverrolle enthalten. In einer Ausgestaltung der Erfindung nach Anspruch 4 sind die Ports als Ankerpunkte für bidirekionale Client/Server-Kommunikationsverbindungen zur Implementierungs­ zeit ausgelegt und stellen eine horizontale Kommunikations- Schnittstelle auf der Schicht 7 des ISO/OSI-Referenzmodells dar.

In weiterer Ausgestaltung der Erfindung nach Anspruch 5 sind die Prozesse als Designelemente, welche die eigentliche Anwendungs­ software beinhalten, in spezieller Weise aus einer äußeren Schnittstelle, einer inneren Struktur und einem spezifischen Verhalten auf eingehende Dienstanforderungen aufgebaut.

In Weiterbildung der Erfindung nach Anspruch 6 besitzt das Steuerungssystem ein echtzeitfähiges Multitasking-Betriebssystem in den Steuergeräten, und die Client/Server-Prozesse sind so implementiert, daß sie ohne direkten Hardwarezugriff nur die Dienste des Betriebssystems und einer zugehörigen Kommunikati­ onsschicht nutzen, die auf der sogenannten Remote-Procedure-Call (RPC)-Technik basiert, wie sie der Art nach von Datenverarbei­ tungssystemen mit Client/Server-Architektur für eine solche Kom­ munikation zwischen Client/Server-Prozessen bekannt ist.

In weiterer Ausgestaltung der Erfindung ist nach Anspruch 7 vor­ gesehen, daß in einer entsprechenden RPC-Bibliothek ein voll­ ständiger Server-Code enthalten ist, der pro Steuergerät genau einmal eingebunden ist und von allen Client- und Server-Prozes­ sen abgearbeitet wird. Dies minimiert den Ressourcenbedarf und maximiert gleichzeitig die Wiederverwendungsfähigkeit.

Gemäß einer Weiterbildung der Erfindung nach Anspruch 8 ist der Remote-Procedure-Call (RPC) als synchroner RPC, asynchroner RPC oder Oneway-RPC realisiert.

In Weiterbildung der Erfindung nach Anspruch 9 ist eine minimale bzw. resourcenoptimierte Protokollimplementierung vorgesehen, die jeder Methode eine identifizierende Dienstnummer zuweist und bei der in den Nutzdaten der versendeten Nachrichten sowohl der Nachrichtentyp als auch die Dienstnummer und die übergebenden Daten codiert sind. Das so implementierte Protokoll ist z. B. auf einem CAN-Bus verwendbar.

Vorteilhafte Ausführungsformen der Erfindung sind in den Zeich­ nungen dargestellt und werden nachfolgend beschrieben. Hierbei zeigen:

Fig. 1 eine ausschnittweise Blockdiagramm-Darstellung eines Steuergeräteverbundes eines Kraftfahrzeug-Steuerungs­ systems,

Fig. 2 eine Blockdiagramm-Darstellung der Entwurfsstruktur ei­ ner im Steuerungssystem von Fig. 1 implementierten Cli­ ent/Server-Architektur,

Fig. 3 eine Darstellung des graphischen Erscheinungsbildes der inneren Struktur einer Prozeßklasse für die Client/­ Server-Architektur,

Fig. 4 eine graphische Darstellung der Einbettung eines endli­ chen Automaten in eine Prozeßklasse der Client/Server- Architektur,

Fig. 5 eine graphische Darstellung des Client/Server-Designs am Beispiel einer Rückfahrscheinwerfer-Anwendungsfunk­ tion,

Fig. 6 ein Blockdiagramm der für die Client/Server-Architektur verwendeten Steuergeräte-Software,

Fig. 7 eine blockdiagrammatische Darstellung der Prozeßkommu­ nikation der Client/Server-Architektur mittels Proto­ kollen auf Anwendungsschichtebene,

Fig. 8 ein Blockdiagramm eines prinzipiellen ORPC-Ablaufs in der Client/Server-Architektur,

Fig. 9 ein Flußdiagramm des Server-Arbeitsablaufs in der Cli­ ent/Server-Architektur,

Fig. 10 ein Flußdiagramm des Ablaufs einer Server-Initiali­ sierungsphase,

Fig. 11 ein Flußdiagramm einer synchronen RPC-Implementierung,

Fig. 12 ein Flußdiagramm einer Oneway-RPC-Implementierung und

Fig. 13 eine schematische Blockdiagramm-Darstellung des imple­ mentierten Protokolls der Client/Server-Architektur.

Fig. 1 zeigt ausschnittweise und blockdiagrammatisch mehrere, verteilt angeordnete Steuergeräte 1a, 1b, 1c und ein diese ver­ bindendes Datenübertragungsnetzwerk mit einem Datenbus 2, z. B. einem CAN-Bus, eines Steuergeräteverbunds zur Ausführung von An­ wendungsfunktionen in einem Kraftfahrzeug. In dem Steuergeräte­ verbund dieses Steuerungssystems sind die Anwendungsfunktionen in Form einer Client/Server-Architektur (CSA) implementiert, die dafür sorgt, daß alle Systemschnittstellen beschrieben sind und nur über selbige mit den Objekten kommuniziert wird und Da­ ten ausgetauscht werden. Soweit diese Client/Server-Architektur in ihrer Struktur und ihren Komponenten den herkömmlichen Cli­ ent/Server-Architekturen entspricht, wird darauf im folgenden nicht näher eingegangen, sondern auf die betreffende Literatur verwiesen und die entsprechende Terminologie verwendet. Durch diese Architektur wird eine Portabilität der Software zwischen verschiedenen Hardware-Plattformen erreicht. Die Nutzung eines von herkömmlichen objektorientierten Methoden bekannten Con­ struction-from-Parts-Ansatzes kann dafür sorgen, daß sich einmal spezifizierte, implementierte und getestete Programmteile immer wieder verwenden lassen. Weiter wird durch Realisierung der Kom­ munikation auf Basis eines Remote-Procedure-Calls (RPC) gewähr­ leistet, daß einzelne Prozesse beliebig im Steuergerätenetzwerk verteilt werden können, ohne die Funktionsentwürfe oder die im­ plementierte Software manuell anpassen zu müssen. Fig. 1 veran­ schaulicht beispielhaft, wie auf diese Weise eine Applikation aus einem Client-Prozeß 3, einem Funktionsmonitor 3b und einem Server-Prozeß 4a, 4b auf den Steuergeräten 1a, 1b, 1c verteilt werden kann. Ein weiterer Server 4a gehört nicht zu dieser Cli­ ent/Server-Kette. Der Funktionsmonitor 3b fungiert sowohl als Server (gegenüber Client 3) wie auch als Client (gegenüber Ser­ ver 4b).

Fig. 2 zeigt im Blockdiagramm den Systementwurf einer jeweiligen Anwendungsfunktion im Rahmen der erfindungsgemäß verwendeten Client/Server-Architektur. Gemäß diesem Systementwurf ist die jeweilige Anwendungsfunktion in eine Clientebene 5, eine Server­ ebene 6 und eine zwischenliegende Funktionsmonitorebene 7 struk­ turiert. Die Clientebene 5 beinhaltet einen oder mehrere primäre Clients 5a mit vorgeschaltetem Requestor 5b. Die Requestoren 5b repräsentieren ereignisauslösende Hardwareeinheiten, wie Senso­ ren, und die zugehörige Steuergeräte-Firmware. Sie stellen die Quellen von Dienstanforderungen der modellierten Anwendungsfunk­ tion dar. Die primären Clients 5a verwalten die Requestoren, nehmen deren Dienstanforderungen entgegen und setzen gegebenen­ falls weitere Aufträge an die Funktionsmonitorebene 7 ab. Die primären Clients 5a werden stets auf demselben Steuergerät wie der zugehörige Requestor 5b angesiedelt und erlauben es, die Dienstanforderung auch über Kommunikationsmedien weiterzuleiten, wozu der Requestor 5b nicht ausgelegt ist. Die Funktionsmonitor­ ebene 7 beinhaltet für jede Anwendungsfunktion einen Funktions­ monitor 7a, der die Dienstanforderungen von primären Clients 5a und gegebenenfalls von Funktionsmonitoren übergeordneter Anwen­ dungsfunktionen entgegennimmt und bearbeitet. Er kann dazu wei­ tere Dienste von ihm untergeordneten Monitoren oder primären Servern in Anspruch nehmen. Der Funktionsmonitor 7a verwaltet den globalen Zustand der Anwendungsfunktion und bildet damit de­ ren zentrale Schaltstelle und Gedächtnis. Dem Funktionsmonitor 7a sind innerhalb der Funktionsmonitorebene 7 gegebenenfalls ein oder mehrere Monitore 7b nachgeschaltet, die Teilfunktionen ver­ walten und sich vom Funktionsmonitor 7a dadurch unterscheiden, daß sie nicht direkt mit primären Clients 5a und Funktionsmoni­ toren 7a anderer Anwendungsfunktionen kommunizieren. Die Server­ ebene 6 beinhaltet einen oder mehrere primäre Server 6a und ei­ nen jeweils zugehörigen Fulfiller 6b. Die Fulfiller 6b repräsen­ tieren ausführende Hardware-Einheiten, wie Aktuatoren, und die zugehörige Steuergeräte-Firmware. Sie stellen die Senken von Dienstanforderungen der modellierten Anwendungsfunktion dar. Die primären Server 6a verwalten die Fulfiller 6b und beauftragen diese mit der Ausführung von Diensten. Sie sind stets auf dem­ selben Steuergerät wie der zugehörige Fulfiller 6b angesiedelt und erlauben es, Dienstanforderungen von entfernten Monitoren 7b entgegenzunehmen, worauf die Fulfiller 6b nicht ausgelegt sind.

Die Pfeile in Fig. 2 repräsentieren Client/Server-Beziehungen, wobei der Pfeil vom Client zum jeweiligen Server verläuft und für ein bestimmtes Anwendungsprotokoll steht. Normalerweise ver­ hält sich ein Server dabei synchron zu den aufrufenden Clients. Die Richtung der Pfeile deutet auf diese Betriebsart hin. In Ausnahmesituationen ist es jedoch auch möglich, daß ein Server 6a asynchron Informationen an einen oder mehrere seiner Clients 5a sendet. In diesem Ausnahmebetrieb findet eine Umkehr der je­ weiligen Rollen statt, für die ein eigenes Protokoll zu verein­ baren ist.

Der Funktionsentwurf für die Client/Server-Architektur mit der in Fig. 2 dargestellten Anwendungs-Entwurfsstruktur basiert auf einer Menge von hierfür geeignet definierten Designelementen. Die Entwurfsmethodik sieht dabei eine spezielle graphische Nota­ tion für die Designelemente vor, wodurch sie von graphischen Entwurfswerkzeugen unterstützt werden kann, was die Lesbarkeit von Entwürfen sowie das Erlernen der Methodik verglichen mit rein textuellen Notationen erleichtert. Speziell sind als De­ signelemente den Requestoren 5b eine Sensor-Firmware, den Ful­ fillern 6b eine Aktuator-Firmware, den Client/Server-Beziehungen Verbindungen und den primären Clients 5a, den Funktionsmonitoren 7a, den Monitoren 7b und den primären Servern 6a Prozeßklassen zugeordnet.

Allgemein sind als Designelemente Methoden und Protokolle, Ser­ vice-Access-Points (SAP) und Service-Access-Point-Interfaces (SAPIF), Ports und Port-Interfaces (PortIF), Verbindungen, Da­ tenelemente, Prozesse, Frames und Firmware-Prozesse vorgesehen. Methoden stellen in diesem Zusammenhang Funktionalität dar, die eine Prozeßklasse anderen Prozeßklassen als Dienste an den SAPs in Serverrolle zur Verfügung stellt. Andererseits kann dieselbe Prozeßklasse an SAPs in Clientenrolle Dienste anfordern, die von anderen Prozeßklassen als Methoden an SAPs in Serverrolle ange­ boten werden. Methoden haben wie herkömmliche Funktionsaufrufe eine Typ und Argumente, wobei der Typ angibt, welches Datenfor­ mat der Rückgabewert der Methode hat. Für die Anwendung ist es transparent, ob die Dienstanforderung als Remote-Procedure-Call mittels Senden/Empfangen über ein externes physikalisches Kommu­ nikationsmedium, mittels Interprozeßkommunikation oder mittels Eventmechanismus vom Client zum Server kommuniziert wird. Proto­ kolle dienen der Aggregierung von Methoden. Zu diesem Zweck be­ inhalten sie eine Liste von Methoden, die aus Sicht des Anwen­ dungsentwicklers eine funktionale Einheit darstellen. Des weite­ ren können Protokolle hierarchisch strukturiert werden, d. h. es kann eine Hierarchie von Protokollen dergestalt aufgebaut wer­ den, daß ausgehend von einem Null-Protokoll, das keine Methoden enthält, eine Baumstruktur von Protokollen entsteht, in der ein neu hinzugefügtes Protokoll alle Methoden des zur Wurzel des Baumes hin nächstliegenden Protokolles erbt und gegebenenfalls weitere hinzufügt.

Die SAPs sind die Schnittstellen von Anwendungsprozessen zur Schicht 7 des ISO/OSI-Referenzmodells und beinhalten je ein Pro­ tokoll in Client- und in Serverrolle. Die SAPs haben eine Vor­ zugsrichtung, die entweder der Client- oder der Serverrolle ent­ spricht. Da SAPs Endpunkte von mehreren Client/Server-Kommuni­ kationsverbindungen sein können, beinhalten sie eine entspre­ chende Anzahl an Ports, die der Verankerung der einzelnen Kommu­ nikationsverbindungen dienen. SAPIFs machen SAP-Funktionalität an Prozeß- und Frameklassen-Schnittstellen verfügbar, wobei ein SAP innerhalb einer Prozeßklasse Verbindungen zu mehreren SAPIFs haben kann. Dies bietet unter anderem die Möglichkeit, den SAPIFs entsprechende Namen zu geben, z. B. Rückfahrlicht rechts, Rückfahrlicht links, und damit den gezielten Anschluß weiterer Komponenten zu ermöglichen, obwohl die Funktionalität von einem einzigen SAP erfüllt wird. SAPIFs existieren nur während des hierarchischen Systementwurfs. Nach Auflösung der Hierarchie vor der Instanziierung besteht keine Notwendigkeit mehr, diesem De­ signelement eine Entsprechung in der Implementierung zu geben.

Ports sind Ankerpunkte für bidirektionale Client/Server-Kommuni­ kationsverbindungen zur Implementierungszeit. In dieser Eigen­ schaft stellen sie eine horizontale Kommunikationsschnittstelle auf Schicht 7 des ISO/OSI-Referenzmodells dar. An den Ports wird der eigentliche Kommunikationsmechanismus verankert, d. h. das Senden/Empfangen über externe physikalische Kommunikationsmedi­ en, die Interprozeßkommunikation und ein Eventmechanismus für die effektive Kommunikation mit Firmware-Prozessen. Von einem SAP ausgehende Dienstanforderungen können folglich über unter­ schiedliche Kommunikationsmechanismen weitergeleitet werden, je nachdem, mit welchem Kommunikationsmechanismus der jeweils gera­ de angesprochene Port hinterlegt ist. Analog zu den SAPIFs ma­ chen die PortIFs Port-Funktionalität an Schnittstellen von nach­ folgend beschriebenen Prozeß- und Frameklassen verfügbar. Die PortIFs gehören entweder zur Schnittstelle eines gerade entwor­ fenen Frames oder zur Schnittstelle eines darin enthaltenen Fra­ mes oder Prozesses.

Jede Prozeßklasse kann Datenelemente enthalten, welche sie im Sinne der Objektorientierung kapselt. Ein Datenelement hat einen Datentyp und kann durch einen Initialisierungswert vorbelegt werden. Es kann konstant oder variabel sein und ist dementspre­ chend in einem ROM oder RAM angeordnet. Ferner werden die Da­ tenelemente als private oder public klassifiziert. Die Initiali­ sierung von private-Datenelementen hat direkt beim Entwurf der Prozeßklasse zu erfolgen, während diejenige von public-Datenele­ menten auf einer hierarchisch höheren Designebene geschieht, wenn der entsprechende Kontext bekannt ist, in welchem die Pro­ zeßklasse verwendet wird. Die in der Prozeßinstanz gekapselten Datenelemente können nur von der Prozeßinstanz selbst geändert werden.

Ein Prozeß im Rahmen der vorliegenden Client/Server-Architektur hat Schnittstellen, über die er mit anderen Prozessen oder Fra­ mes verbunden werden kann. Er bietet Dienste an SAPIFs in Ser­ verrolle an und nutzt Dienste von anderen Prozessoren an SAPIFs in Clientrolle. Das Verhalten einer Prozeßklasse wird mittels endlicher Automaten beschrieben. Jede Prozeßklasse kann als Sum­ me dreier Komponenten betrachtet werden, und zwar einer äußeren Schnittstelle, einer inneren Struktur und des Verhaltens. Fig. 3 zeigt ein Beispiel des graphischen Erscheinungsbildes der inne­ ren Struktur einer Prozeßklasse mit einer zugehörigen äußeren Schnittstelle. Das Verhalten einer Prozeßklasse als Reaktion auf eine eingehende Dienstanforderung gliedert sich in drei Teil­ aspekte, und zwar in die Änderung des inneren Zustands z der Prozeßklasse, d. h. eines endlichen Automaten FSM, der das Ver­ halten der Prozeßklasse repräsentiert, in die Modifikationen an den gekapselten Datenelementen (process data set) und die Aus­ führung von Aktionen und gegebenenfalls Wechsel des Prozesses in Clientrolle, um Dienste von anderen Prozessen in Anspruch zu nehmen. Fig. 4 zeigt die Einbettung des endlichen Automaten, d. h. der Finite State Machine (FSM), in die Prozeßklasse. Wie aus Fig. 4 erkennbar, können eingehende Dienstanforderungen so­ wohl den x-Vektor des endlichen Automaten als auch den Process Data Set beeinflussen. Ändert sich der x-Vektor, wird gemäß der Definition des endlichen Automaten geprüft, ob gegebenenfalls ein neuer Zustand erreicht wird und entsprechende Aktionen aus­ geführt werden müssen. Welche Aktionen ausgeführt werden, ergibt sich aus der Interpretation des y-Vektors. Das Ausführen der Ak­ tionen kann weitere Änderungen am Process Data Set und den Wech­ sel in die Clientrolle mit Anforderung von Diensten anderer Pro­ zesse bedeuten. Weiter ist der Fig. 4 die charakteristische Maß­ nahme entnehmbar, die SAPs in Server- und Client-Modus auf An­ wendungsebene zu implementieren.

Um einen hierarchischen Softwareentwurf zu ermöglichen, sind Frames als weitere Designelemente vorgesehen, die in ihrer in­ ternen Struktur weitere Frames, Prozesse und notwendige Verbin­ dungen kapseln können. Ein Frame hat wie ein Prozeß Schnittstel­ len, über die er mit anderen Prozessen oder Frames verbunden werden kann. Er bietet Dienste an SAPIFs in Serverrolle an und nutzt Dienste von anderen Prozessen an SAPIFs in Clientrolle. Prinzipiell können Frames zusätzlich mit einer Verhaltensbe­ schreibung versehen sein, was schließlich ein Zusammenfallen mit Prozessen bedeuten kann, so daß nur noch eines dieser beiden De­ signelemente auf Designebene benötigt wird. In diesem Fall müs­ sen für die Implementierung einer Anwendung für alle Prozeßklas­ sen auf hierarchisch unterster Designebene explizite Verhaltens­ beschreibungen existieren, während dies für Prozeßklassen auf hierarchisch höheren Ebenen optional ist, wobei dann deren Ver­ haltensbeschreibung mit derjenigen der in ihr enthaltenen Pro­ zeßklassen niedrigerer Ebene zusammenpassen muß.

Als weiteres Designelement sind Firmware-Prozesse vorgesehen, mit denen Firmware charakteristischerweise als Prozesse be­ schrieben wird und die das Bindeglied zwischen einer jeweiligen Hardwarekomponente und genau einem zugeordneten primären Client oder Server bilden. Sie kommunizieren mit letzteren über Anwen­ dungsprotokolle, wie sie auch zur Kommunikation zwischen den Prozessen verwendet werden und besitzen demzufolge ebenfalls mindestens ein SAPIF. Im Unterschied zu Prozessen werden jedoch weder innere Struktur, noch Verhalten von Firmware-Prozessen be­ schrieben, es können jedoch Datenelemente verwendet werden.

Fig. 5 zeigt am Beispiel der typischen fahrzeugspezifischen An­ wendungsfunktion "Rückfahrscheinwerfer" beispielhaft die prinzi­ pielle Vorgehensweise beim Funktionsentwurf gemäß dem vorliegen­ den Client/Server-Modell. Die graphische Darstellung von Fig. 5 zeigt hierzu ein äußeres Frame 8, das zwei innere Frames 9, 10 und einen durch die Graphik seiner äußeren Schnittstelle 11 dar­ gestellten Prozeß beinhaltet. Im ersten Schritt erfolgt die Identifikation der beteiligten Sensorik und Aktuatorik und damit die Festlegung der primären Clients und Server. Im gezeigten Beispiel wird die Funktion durch einen Schalter an der Schaltku­ lisse eines Automatgetriebes aktiviert. Als Aktuator wird am Fahrzeugheck eine Glühlampe eingeschaltet. Als Endpunkte dieses Client/Server-Szenarios ergeben sich damit ein primärer Client zur Überwachung des Rückfahrschalters und ein primärer Server zur Ansteuerung der digitalen Lampenendstufe für den Rückfahr­ scheinwerfer. Die eigentliche Funktionslogik befindet sich in einem Monitor, der in diesem Fall lediglich den Schaltzustand mit der Zündklemmeninformation verknüpft, so daß der Rückfahr­ scheinwerfer bei ausgeschalteter Zündung nicht eingeschaltet wird.

Nachdem auf diese Weise die Struktur der Funktion festliegt, werden im nächsten Schritt die Protokolle zwischen den Clients und Servern definiert. Ein Protokoll besteht dabei aus einer An­ zahl von Diensten, die der Server dem Client anbietet. Im Bei­ spielfall eines binären Schalters ist zwischen primärem Client und Monitor nur die Information "Schalter eingeschaltet" oder "Schalter ausgeschaltet" auszutauschen. Bei der Aktuatorikan­ steuerung ergeben sich ebenfalls nur zwei Dienste, die der pri­ märe Server dem Funktionsmonitor anbieten muß, nämlich "Endstufe einschalten" und "Endstufe ausschalten".

Ein Blick in eine während der Entwicklung entstandene Parts-Bib­ liothek kann zeigen, daß bereits ein Protokoll zur Übertragung binärer Information existiert, das im Beispielfall sowohl für die Kommunikation zwischen primärem Client und Monitor als auch zwischen Monitor und primärem Server genutzt werden kann. Die entsprechenden Prozesse und Protokolle zur Einspeisung der Zünd­ klemmeninformation in dieses Funktionsszenario sind ebenfalls bereits in der Parts-Bibliothek enthalten, wobei in diesem Fall eine Kommunikationsverbindung zu demjenigen Client genügt, der die aktuelle Zündklemme an den Funktionsmonitor weitergibt.

Nachfolgend wird detaillierter auf die Implementierung der Cli­ ent/Server-Architektur im Fahrzeug eingegangen. Eine grundlegen­ de Komponente bildet das verwendete Betriebssystem. Um die Por­ tabilität der Client/Server-Prozesse auf unterschiedliche Hard­ ware-Plattformen sicherzustellen, ist auf den Steuergeräten eine Betriebssystemschicht realisiert, welche die Abhängigkeiten der Software zur Hardware kapselt und eine abstrakte Programmier­ schnittstelle (Application Programming Interface; API) bereit­ stellt. Voraussetzung für den Einsatz der Client/Server-Archi­ tektur in einem Steuergerät ist ein echtzeitfähiges Multitas­ king-Betriebssystem. Beispielsweise kann das Echtzeit-Betriebs­ system OSEK mit der Conformance-Class ECC1 gewählt werden, da für die Kommunikation der Event-Mechanismus notwendig ist. Die gegenseitige Unterbrechbarkeit einzelner Tasks, d. h. preemptives Scheduling, ist nicht zwingend erforderlich. Fig. 6 zeigt die Struktur von Software-Modulen auf einem Steuergerät mit der vor­ liegenden Client/Server-Architektur sowie die Koexistenz zu kon­ ventionellen Applikationen, wobei zusätzlich die Schichten des ISO/OSI-Referenzmodells zu Vergleichszwecken dargestellt sind. Aus Fig. 6 ist ersichtlich, daß die Client/Server-Prozesse nicht direkt auf die Hardware zugreifen, sondern die Dienste des Be­ triebssystems und der ORPC-Kommunikationsschicht und damit des OSEK COM nutzen, wobei die Kommunikationsbeziehungen zwischen Client/Server-Prozessen mit gestrichelten Linien wiedergegeben sind. Die gebogene Linie repräsentiert eine Client/Server-Kom­ munikation auf demselben Gerät, während die gerade Linie eine solche zwischen verschiedenen Geräten symbolisiert. Durch diese Struktur läßt sich eine Verschiebbarkeit der Client/Server-An­ wendung zwischen verschiedenen Steuergeräten erreichen, die alle über entsprechende OSEK OS-, OSEK COM- und ORPC-OXDR-Implemen­ tierungen verfügen. In Fig. 7 ist die vorliegend getroffene Maß­ nahme veranschaulicht, die SAPs und die Ports für das Zusammen­ spiel von Prozessen mittels Protokollen auf dem Niveau von Schicht 7 des ISO/OSI-Referenzmodells zu implementieren.

Wie gesagt, greifen die Client/Server-Anwendungen auf Dienste einer Kommunikationsschicht zurück. Dabei setzt die ORPC(OSEK- basierter Remote-Procedure-Call)-Schicht auf den Timer- und Event-Diensten des Betriebssystems und den Kommunikationsrouti­ nen der OSEK COM-Ebene auf. Die OSEK COM-Schicht stellt Kommuni­ kationsroutinen bereit, über die Tasks miteinander Daten austau­ schen können. Die Kommunikation zweier Tasks erfolgt konfigura­ tionsabhängig innerhalb desselben Adressraums oder zwischen ver­ schiedenen Adressräumen über ein entsprechendes Transportmedium, wobei für die Anwendung die tatsächliche Realisierung der Kommu­ nikation verborgen bleibt. Die Kommunikationsebenen ORPC, OSEK COM, Gerätetreiber und Hardware bilden die Schichten 6 bis 1 des ISO/OSI-Referenzmodells, während Schicht 7, d. h. die Anwendungs­ schicht, direkt von der Client/Server-Anwendung bzw. den Anwen­ dungsprotokollen übernommen wird.

Die Prozeßstruktur der Clients und Server beschreibt das System­ verhalten innerhalb der Architektur, womit allerdings im Unter­ schied zu konventionellen Client/Server-Systemen keine Interak­ tion mit der Außenwelt modelliert wird. Diese Schnittstelle zur Umwelt wird in der vorliegenden CSA durch zusätzliche Software­ bausteine, die sogenannte Firmware, gebildet. Diese Firmware trennt die hardwareabhängigen Teile der Funktion von der logi­ schen Funktion des Client/Server-Systems. In ihr werden die Ein- und Ausgabeoperationen des Steuergerätes behandelt. Normalerwei­ se sind dies die Ansteuerung von I/O-Pins des Prozessors mit de­ finiertem Timing. Die Firmware wird hardwarenah speziell für das Steuergerät z. B. in Assembler oder C implementiert. Zur Client/­ Server-Umgebung stellt die Firmware eine Schnittstelle über An­ wendungsprotokolle ähnlich denen von Client/Server-Prozessen be­ reit. Diejenigen Client- bzw. Server-Prozesse, die Aufträge aus der Firmware entgegennehmen oder diese beauftragen, werden als die primären Clients bzw. Server bezeichnet, so daß diese primä­ ren Prozesse direkt auf dem Steuergerät laufen, an dem auch die entsprechende Hardware angeschlossen ist. Über diese Zwischen­ schicht ist auch eine Kommunikation zu anderen als den Client/­ Server-Prozessen denkbar, indem für die betreffende Applikation eine Schnittstelle zur Client/Server-Umgebung in Form von ent­ sprechender Firmware realisiert wird.

Zwischen zwei Client/Server-Prozessen findet die Kommunikation zum Datenaustausch über zwei asynchrone, unidirektionale Punkt- zu-Punkt-Kanäle statt. Sie basieren auf dem Prinzip des aus der Bürokommunikations-Datenverarbeitung bekannten Remote-Procedure- Call (RPC), wobei dieser Mechanismus für den Anwendungsfall von Kraftfahrzeugen auf die dort vorhandenen, begrenzten Ressourcen angepaßt und vereinfacht ist. So stehen z. B. keine Name-Services oder Security-Functions zur Verfügung, und es wird im allgemei­ nen auch keine sichere Kommunikation für den Nachrichtenaus­ tausch vorausgesetzt. Der prinzipielle Ablauf des verwendeten OSEK-basierten Remote-Procedure-Call (ORPC) ist in Fig. 8 darge­ stellt. Bei einer Anforderung (Request) von einem Client- zu ei­ nem Server-Prozeß codiert eine Stub-Routine zunächst die Argu­ mente in eine netzwerkneutrale, normalisierte Form. Der in der ORPC-Runtime-Bibliothek bereitgestellte Timed-RPC sorgt für die Übertragung des Requests über das Netzwerk oder über Kommunika­ tionsobjekte im selben Adressraum zum Server. Dort decodiert die entsprechende Server-Stub-Routine die Argumente, ruft mit diesen Parametern die Dienstimplementierung auf und nimmt daraufhin die Ergebnisse entgegen. Diese werden wieder in die normalisierte Darstellung umgewandelt und zum Client zurückgesendet. Die Cli­ ent-Stub-Routine sorgt für die Decodierung der Ergebnisse und gibt sie schließlich an den entsprechenden Prozeß zurück.

Für den Fall, daß bei der Übertragung über ein Medium zwischen verschiedenen Adressräumen eine Nachricht verloren geht, ist im ORPC ein Mechanismus implementiert, der Nachrichten wiederholen kann. Dazu ist für jede Nachricht definiert, bis zu welchem Zeitpunkt nach dem Versenden des Requests die Antwort (Reply) erwartet wird. Kann diese Zeit nicht eingehalten werden, geht der Client davon aus, daß entweder seine Request-Nachricht oder der Reply darauf verloren ging. Er sendet deshalb den Request erneut aus. Zusätzlich ist eine Maximalanzahl für die Wiederho­ lungen definiert, nach denen der Client mit einer entsprechenden Fehlermeldung über die Nichterfüllung des Dienstes benachrich­ tigt wird. Mit diesem Mechanismus können nur idempotente Dienste realisiert werden, bei denen eine Wiederholung eines bereits ausgeführten Dienstes keinen Einfluß auf das Gesamtergebnis oder den Systemzustand hat.

Im Unterschied zu herkömmlichen Implementierungen von RPC-Mecha­ nismen für die Bürokommunikation ist bei der vorliegenden CSA weitaus mehr Funktionalität innerhalb der ORPC-Bibliotheksrouti­ nen realisiert und standardisiert. Gängige RPC-Implementierungen stellen der Anwendung lediglich die benötigten Kommunikations­ funktionen in Form einer Bibliothek zur Verfügung und ermögli­ chen darüber hinaus nur die Generierung eines primitiven Gerüsts für die eigentliche Server-Funktionalität. Wenn dies, wie meist der Fall, nicht ausreicht, muß der Anwendungsprogrammierer den benötigten Server-Code selbst schreiben. Im Gegensatz dazu bein­ haltet vorliegend die ORPC-Bibliothek neben den Kommunikations­ routinen auch den vollständigen Server-Code. Dieser wird von al­ len Client- und Server-Prozessen abgearbeitet, d. h. er wird pro Steuergerät genau einmal eingebunden. Dies erfüllt in vorteil­ hafter Weise die Anforderungen nach minimalem Ressourcenbedarf und maximaler Wiederverwendungsfähigkeit. Dieser Server-Code wird von der Anwendung lediglich mit den jeweiligen prozeßspezi­ fischen Daten aufgerufen und arbeitet diese nach einem festge­ legten Verfahren ab. Das zugehörige Server-Zustandsdiagramm ist in Fig. 9 dargestellt. Nach Aufruf durch die Anwendung durch­ läuft der Server eine Initialisierungsphase, die sich in vier einzelne Phasen gliedert, wie im zugehörigen Initialisierungs­ diagramm in Fig. 10 dargestellt. Zunächst werden die anwendungs­ spezifischen Prozeßdaten initialisiert, wozu aus dem Server-Code heraus eine anwendungsspezifische Funktion aufgerufen wird, wel­ che der Anwendungsprogrammierer zur Verfügung stellt. Dann er­ folgt die Initialisierung der Kommunikationskanäle und der zuge­ hörigen Datenobjekte. Der Server-Prozeß ist nun empfangsbereit und kann Anforderungen, d. h. Requests, von seinen Clients entge­ gennehmen. Der Prozeß geht daraufhin für eine einstellbare Zeit in eine Wartestellung, bis ein Request empfangen wird oder die eingestellte Zeit abgelaufen ist. Diese Maßnahme dient der Last­ verteilung beim Anlauf des Systems bzw. dazu, unwichtigere Pro­ zesse zu blockieren, bis sie tatsächlich benötigt werden. Zu­ letzt überprüft der Server, ob er alle notwendigen Initialisie­ rungsinformationen hat. Ist dies nicht der Fall, fordert er sie selbsttätig, d. h. ohne Mitwirkung der Anwendung, bei den ent­ sprechenden Clients an. Liegt nach einer einstellbaren Anzahl von Versuchen noch keine gültige Initialisierung vor, verzweigt der Server in eine Notlauf-Funktion, ansonsten betritt der Ser­ ver eine Schleife, in der er die eingegangenen Anforderungen nacheinander abarbeitet.

Anstehende Requests werden dem Server-Prozeß über einen vom Be­ triebssystem bereitgestellten Signalisierungsmechanismus ange­ zeigt. Anhand dieses Signals kann der Server zwischen verschie­ denen Quellen unterscheiden und die entsprechende Bearbeitungs­ methode anstoßen. Quelle dieser Signale können hierbei Nicht- CSA-Funktionen, wie Firmware, oder Betriebssystemfunktionen, wie Zeitgeber oder Interrupt-Mechanismen, oder andere CSA-Prozesse, wie Client-Prozesse, sein. Anhand des empfangenen Signals wird vom Server-Code über eine Tabelle am entsprechenden SAP eine Stub-Routine aufgerufen. Die Stub-Routinen werden anhand der In­ formationen zu den Anwendungsprotokollen automatisch generiert und rufen die vom Anwendungsprogrammierer zur Verfügung gestell­ te Dienstimplementierung auf. Bei den Signalen wird zwischen so­ genannten Application Events und den ORPC-Events unterschieden. Die Application Events werden zur Anbindung der Firmware und für Betriebssystemfunktionen genutzt und direkt in einen entspre­ chenden Aufruf umgesetzt. Die ORPC-Events sind durch den reali­ sierten RPC-Mechanismus vorgegeben und dienen zur Anbindung an­ derer CSA-Prozesse.

Für die Realisierung des RPC kommen drei Varianten in Betracht, von denen der gebräuchlichste ein sogenannter synchroner RPC ist, der durch die Funktion Timed-RPC der ORPC-Bibliothek reali­ sert ist. Fig. 11 zeigt das Flußdiagramm dieser Funktion. Nach der Initialisierung der lokalen Daten der Funktion werden in ei­ ner Schleife die für diese Methode konfigurierten Aufrufversuche (Attemps) abgearbeitet. Bei jedem Versuch wird hierzu zunächst ein Zeitgeber mit dem entsprechenden Timeout-Wert geladen. Im Anschluß daran wird der Request versendet und auf den Ausgang dieser Sende-Operation gewartet. War das Senden des Requests er­ folgreich, betritt die Funktion eine Schleife, in der sie auf die Antwort, d. h. den Reply, wartet. Wird die Antwort nicht in­ nerhalb der vorgegebenen Zeitspanne empfangen, startet ein er­ neuter Übertragungsversuch, sofern die Anzahl möglicher Versuche noch nicht überschritten ist. Läuft der Zeitgeber ab, bevor ein erfolgreicher Ausgang der Sendeoperation signalisiert wurde, wird ohne Warten auf Anwort der nächste Versuch gestartet. Auf Server-Seite wird durch den Empfang eines Requests eine entspre­ chende Server-Stub-Routine aufgerufen, welche ihrerseits die ei­ gentliche Dienstimplementierung aufruft und nach deren Abarbei­ tung eine entsprechende Antwort an den Client-Prozeß zurücksen­ det. Abhängig vom Ausgang liefert die Funktion einen entspre­ chenden Fehlercode sowie im Erfolgsfall das zugehörige Ergebnis an die aufrufende Funktion, in diesem Fall eine Client-Stub-Rou­ tine, zurück. Innerhalb der Anwendung muß bei einem RPC zunächst dieser Fehlercode betrachtet werden, bevor im Erfolgsfall mit dem zurückgelieferten Ergebnis gearbeitet werden kann. Für den Fall, daß ein RPC-Vorgang fehlschlägt, ist eine entsprechende Fehlerbehandlung vom Anwendungsprogrammierer vorzusehen.

Als weitere Variante kann ein sogenannter asynchroner RPC vorge­ sehen sein. Dieser entspricht einer Modifikation des synchronen RPC dahingehend, daß von der Server-Stub-Routine eine Antwort gesendet wird, bevor die eigentliche Dienstimplementierung auf­ gerufen wird. Der Client-Prozeß kann dadurch asynchron zu dem von ihm beauftragten Server-Prozeß weiterarbeiten. Der Server- Prozeß bzw. die aufgerufene Stub-Routine bestätigt hierbei durch den Reply lediglich den korrekten Empfang des entsprechenden Re­ quests, nicht jedoch die erfolgte Bearbeitung. Infolgedessen ist diese Art des RPC nur für Methoden zulässig, die kein Ergebnis, d. h. einen Rückgabewert vom Typ "void", haben. Die Unterschei­ dung zwischen synchronem und asynchronem RPC erfolgt allein in der Server-Stub-Routine, während die verwendeten Client-Stub- Routinen in beiden Fällen identisch sind. Auch wird in beiden Fällen zur Kommunikation die Funktion Timed-RPC aufgerufen.

Als dritte Variante kann der sogenannte Oneway-RPC vorgesehen sein, bei welchem im Gegensatz zu den beiden vorigen Mechanismen keine Antwort vom Server an den Client generiert wird. Dieser Mechanismus ist ebenfalls nur für Funktionen zulässig, die kein Ergebnis liefern. Im Unterschied zu Timed-RPC realisiert die verwendete Kommunikationsfunktion Oneway-RPC keinen Timeout- Retransmit-Mechanismus und wartet nicht auf eine Antwort des Servers. Das zu dieser RPC-Variante gehörige Flußdiagramm ist in Fig. 12 dargestellt.

Neben dem Aufruf der entsprechenden Kommunikationsfunktion bzw. Dienstimplementierung sind die Client- und Server-Stub-Routinen auch für das sogenannte Marshalling, d. h. die Konvertierung ei­ nes einfachen Datentyps aus einer prozessorspezifischen Darstel­ lung in das zur Kommunikation verwendete normalisierte Format, und Unmarshalling, d. h. der Datenkonvertierung vom normalisier­ ten Format in die prozessorabhängige Darstellung, der zugehöri­ gen Parameter und Rückgabewerte verantwortlich. Dabei werden Byte- und Bit-Ordering und die Länge der Darstellung berücksich­ tigt. Die Client- und Server-Stub-Routinen werden anhand der Signatur einer Methode, d. h. unter Berücksichtigung von Anzahl, Reihenfolge und Typ der Parameter sowie des Rückgabewertes, au­ tomatisch generiert. Die Stub-Routinen enthalten die entspre­ chende Aufruf-Sequenz von Konvertierungsroutinen für einfache Datentypen. Während bei den herkömmlichen Realisierungen der An­ wendungsprogrammierer selbst Funktionen für das Marshalling bzw. Unmarshalling bereitstellen und an die Stub-Routine übergeben muß, wird diese Funktionalität hierdurch beim vorliegenden Sy­ stem vollständig innerhalb der Stubs gekapselt und bleibt der Anwendung verborgen. Dadurch ist der in der vorliegenden CSA realisierte RPC bezüglich der Schnittstelle für den Anwendungs­ programmierer transparent, d. h. durch die gewählte Vorgehenswei­ se ist die Schnittstelle der Anwendung zu den Stub-Routinen so gestaltet, daß diese exakt derjenigen bei einem lokalen Funk­ tionsaufruf entspricht. Für jede Signatur existiert genau ein Paar von Stub-Routinen, wobei Methoden mit gleicher Signatur dieselben Stub-Routinen verwenden. Dies ist von der methoden­ spezifischen Generierung von Stub-Routinen herkömmlicher Reali­ sierungen zu unterscheiden. Die vorliegende CSA macht im Unter­ schied zu herkömmlichen Architekturen von der Möglichkeit einer (Wieder-)Verwendung von Stub-Routinen durch mehrere Methoden Ge­ brauch.

Eine Randbedingung für die normalisierte Darstellung in einem Netzwerk ist, daß auf den eingesetzten Microcontrollern der Auf­ wand für die Umsetzung möglichst gering ist. Anstelle herkömmli­ cher Realisierungen einer External-Data-Representation wurde daher für das vorliegende System eine eigenständige normalisier­ te Darstellung in Form einer OXDR (OSEK-basierte externe Daten­ representation) definiert. Konvertierungsroutinen für einfache Datentypen werden in einer Bibliothek zur Verfügung gestellt. OXDR zeichnet sich durch eine Trennung von Marshalling- und Unmarshalling-Routinen aus, was selektives Einbinden der benö­ tigten Module und somit minimalen ROM-Bedarf ermöglicht. Außer­ dem können für die Datenkonvertierung Quell- und Zieldatenbe­ reich identisch sein, was den RAM-Bedarf der Konvertierungsrou­ tinen minimiert.

Für die Protokollimplementierung erhält jede Methode eines An­ wendungsprotokolls eine eindeutige, als Dienstnummer bezeichnete Nummer. Mit dieser identifiziert sowohl der Client den gewünsch­ ten Dienst als auch der Server die dazugehörende Dienstimplemen­ tierung. In den Nachrichten sind in den Nutzdaten sowohl der Nachrichtentyp, d. h. Request, Reply oder Error, als auch die Dienstnummer und die übergebenen Daten kodiert. Fig. 13 zeigt eine Darstellung des so realisierten Protokolls. Dabei bedeuten Bit 7 ein Error-Flag, Bit 6 Reply-Flag und die Bits 5 bis 0 die Service-ID zwischen 0 bis 63. Die Anfangsbits "00 .." bedeuten einen Request für den Dienst mit der anschließenden Nummer, die Anfangsbits "01 ..." einen Reply auf den Dienstaufruf mit der anschließenden Nummer und die Anfangsbits "11 ..." einen Fehler bei der Verarbeitung des Dienstes mit der anschließenden Nummer. Mit Application-Data sind die beim Aufruf der Methode übergebe­ nen Daten bzw. die Antwort darauf bezeichnet. Der Client sendet also eine Nachricht mit einer Dienstnummer an seinen Server, der anhand der gelöschten Bits 6 und 7 und der Dienstnummer prüft, ob es sich um einen Request handelt und ob er diesen Dienst er­ bringen kann. Nach der erfolgreichen Verarbeitung des Dienstes sendet der Server die Ergebnisse unter derselben Dienstnummer mit dem gesetzten Bit 6 an den Client zurück. Dieser erkennt an der Dienstnummer, dem gesetzten Bit 6 und dem gelöschten Bit 7, daß es sich um ein gültiges Ergebnis zum aufgerufenen Dienst handelt. Falls der Server einen geforderten Dienst nicht erbrin­ gen kann, beantwortet er den Request mit einer Fehlernachricht, indem er die Bit 6 und 7 setzt und in den Anwendungsdaten den entsprechenden Fehler kodiert.

Im Ergebnis steht somit für das Steuerungssystem ein objektori­ entierter Ansatz zur Verfügung, bei der alle in der CSA verwen­ deten Prozesse eine oder mehrere definierte Schnittstellen in Form von SAPs bzw. SAPIFs haben, über die mit Ihnen mittels An­ wendungsprotokollen kommuniziert wird. Die Prozesse können loka­ le Daten besitzen, die nur über die Anwendungsprotokolle modifi­ ziert werden können, und sie besitzen einen inneren Zustand, da das Verhalten eines solchen Prozesses über einen einfachen Auto­ maten (FSM) festgelegt ist. Damit folgt der Entwurf mit der Cli­ ent/Server-Methode den wesentlichen Paradigmen des objektorien­ tierten Designs. Das Design der Anwendung erfolgt auf Klassen­ ebene durch Aufbau von Kommunikationsbeziehungen zwischen den Prozeßklassen. Zur Generierungszeit werden aus diesen kommuni­ zierenden Prozeßklassen die Prozeßinstanzen erzeugt und mit ent­ sprechenden Daten vorbelegt, wobei auch Polymorphismus durch Überschreiben der Dienstimplementierungen an dieser Stelle mög­ lich ist. Als hierarchische Strukturierungsmittel finden Frames Verwendung, die andere Frames oder Prozeßklassen, Firmware und Kommunikationsverbindungen enthalten können, sogenannte Con­ struction of Parts. Aus diesen Frames kann dann nach der Bottom- up-Designmethode, d. h. durch Construction from Parts, die Anwen­ dung zusammengebaut werden. Ein einmal angelegtes, implementier­ tes und getestetes Frame läßt sich in beliebig vielen Anwendun­ gen wiederverwenden, so daß eine erhebliche Effizienz- und Ef­ fektivitätssteigerung gegenüber dem konventionellen Entwurf er­ möglicht wird. Durch die vorliegend realisierte CSA ist eine ho­ he Flexibilität auch im Bereich der Kraftfahrzeugelektronik ge­ geben, die eine baureihenübergreifende Verwendung der Anwen­ dungsfunktionen oder zumindest von Teilen derselben erlaubt. Wird beispielsweise bei einer neuen Baureihe eine Anwendungs­ funktion nur hinsichtlich ihrer Funktionslogik, nicht aber ihrer zugehörigen Sensorik oder Aktuatorik verändert, reicht eine Mo­ difizierung des entsprechenden Funktionsmonitors aus. Durch die vorliegende Strukturierung von Funktionen wird folglich auch die Wartungsfähigkeit verbessert.

Der Entwicklungsprozeß wird formal durch ein Design- und Imple­ mentierungswerkzeug unterstützt, mit dem der gesamte Desingpro­ zeß und Teile des Implementierungsprozesses unterstützt werden. Damit können in der Designphase die Prozeßklassen mit ihren Schnittstellen und Daten spezifiziert werden. Zusammen mit den entwickelten Anwendungsprotokollen lassen sie sich zu Frames kombinieren, die ihrerseits in anderen Frames genutzt werden können. Am Schluß des Design-Prozesses für eine neue Funktion wird der Kontext festgelegt, in welchem die Frames angewendet werden, z. B. zur Festlegung der Frequenz und des Tastverhältnis­ ses im Fall der Blinkfunktion eines Fahrzeugblinkgebers. Aus den mit Hilfe des Entwicklungswerkzeugs entworfenen Funktionen wird eine Parts-Bibliothek aufgebaut.

Wie die vorstehende Beschreibung eines Anwendungsfalls für ein Kraftfahrzeug zeigt, bietet das erfindungsgemäße Steuerungssy­ stem mit der implementierten Client/Server-Architektur erhebli­ che Vorteile. Der Entwicklungsaufwand wird durch systematische Wiederverwendung und Änderungsfreundlichkeit sowie weitgehende Automatisierung vereinfacht, wozu eine klare Trennung zwischen logischem Entwurf einer Fahrzeugfunktion und deren physikali­ scher Einbettung in die Steuergerätestruktur realisiert ist. Außer Funktionsentwürfen sind auch entsprechende Simulationsmo­ delle und implementierte Software-Module in gleicher Weise fle­ xibel einsetzbar, was den Aufwand nicht nur in der Entwurfspha­ se, sondern auch in der Implementierungs- und in der Integrati­ onsphase verringert. Durch die erfindungsgemäße Systemauslegung ergibt sich ein großer Freiheitsgrad bezüglich der Plazierung einzelner Funktionen auf den Steuergeräten im vernetzen Steuer­ geräteverbund.

Wenngleich die Erfindung im Detail anhand eines Kraftfahrzeug- Steuerungssystems erläutert wurde, versteht es sich, daß sie auch auf andere Arten von datenverarbeitungsgestützten elektro­ nischen Steuerungssystemen mit einem Steuergeräteverbund aus verteilt angeordneten Steuergeräten anwendbar ist.

Claims (9)

1. Datenverarbeitungsgestütztes elektronisches Steuerungssy­ stem, insbesondere für ein Kraftfahrzeug, mit

• - einem Anwendungsfunktionen ausführenden Steuergeräteverbund mit mehreren, verteilt angeordneten Steuergeräten (1a, 1b, 1c) und einem diese verbindenden Datenübertragungsnetzwerk (2),

dadurch gekennzeichnet, daß

• - die Anwendungsfunktionen in Form einer Client/Server-Archi­ tektur in dem Steuergeräteverbund implementiert sind, die eine Client-Ebene (5), eine Server-Ebene (6) und eine zwischenliegen­ de Funktionsmonitorebene (7) beinhaltet, in welcher Dienstanfor­ derungen von der Client-Ebene und/oder von übergeordneten Anwen­ dungsfunktionen empfangen und unter Benutzung von Diensten der Server-Ebene und/oder von untergeordneten Anwendungsfunktionen bearbeitet werden.

2. Steuerungssystem nach Anspruch 1, weiter dadurch gekennzeichnet, daß

• - die Client-Ebene (5) wenigstens einen primären Client (5a) und einen zugehörigen Requestor (5b) enthält, wobei der Requestor ereignisauslösende Hardware-Einheiten und eine zugehörige Steuergeräte-Firmware repräsentiert und der primäre Client den Requestor verwaltet, Diensteanforderungen von ihm entgegen­ nimmt und Aufträge an die Funktionsmonitorebene (7) absetzt, und/oder
• - die Funktionsmonitorebene pro Anwendungsfunktion einen Funkti­ onsmonitor (7a), der Dienstanforderungen der Client-Ebene (5) entgegennimmt und bearbeitet, sowie diesem untergeordnete Mo­ nitore (7b) zur Verwaltung von Teilfunktionen enthält und/oder
• - die Server-Ebene (6) wenigstens einen primären Server (6a) und einen zugehörigen Fulfiller (6b) beinhaltet, wobei die Fulfil­ ler ausführende Hardware-Einheiten und zugehörige Steuergerä­ te-Firmware repräsentieren und der primäre Server den Fulfil­ ler verwaltet und mit der Ausführung von Diensten beauftragt sowie Dienstanforderungen von der Funktionsmonitorebene (7) entgegennimmt.

3. Steuerungssystem nach Anspruch 1 oder 2, weiter dadurch gekennzeichnet, daß es aus entsprechenden Designelementen für den Funktionsentwurf der Client/Server-Architektur gebildete Service-Access-Points (SAPs) enthält, die Anwendungsprozeß-Schnittstellen auf dem Ni­ veau von Schicht 7 des ISO/OSI-Referenzmodells bilden und je ein Protokoll in Client- und Serverrolle beinhalten.

4. Steuerungssystem nach einem der Ansprüche 1 bis 3, weiter dadurch gekennzeichnet, daß es aus entsprechenden Designelementen für den Funktionsentwurf der Client/Server-Architektur gebildete Ports als horizontale Kommunikationsschnittstellen auf Schicht 7 des ISO/OSI-Refe­ renzmodells als Ankerpunkte für die bidirektionale Cli­ ent/Server-Kommunikationsverbindung zur Implementierungszeit enthält.

5. Steuerungssystem nach einem der Ansprüche 1 bis 4, weiter dadurch gekennzeichnet, daß es aus entsprechenden Designelementen für den Funktionsentwurf der Client/Server-Architektur gebildete Prozesse in Form von Prozeßklassen enthält, die eine äußere Schnittstelle, eine inne­ re Struktur und ein Verhalten umfassen, welches Änderungen des internen Zustands (z) der Prozeßklasse, Modifikationen an gekap­ selten Datenelementen und die Ausführung von Aktionen beinhal­ tet.

6. Steuerungssystem nach einem der Ansprüche 1 bis 5, weiter dadurch gekennzeichnet, daß in den Steuergeräten eine Betriebssystemschicht mit einem echt­ zeitfähigen Multitasking-Betriebssystem implementiert ist und als Kommunikationsschicht eine solche vom Remote-Procedure-Call- Typ (RPC) verwendet ist, wobei die Client/Server-Prozesse auf die Dienste des Betriebssystems und der Kommunikationsschicht ohne direkten Hardware-Zugriff zurückgreifen.

7. Steuerungssystem nach Anspruch 6, weiter dadurch gekennzeichnet, daß in einer RPC-Bibliothek ein vollständiger Server-Code abgelegt ist, der pro Steuergerät genau einmal eingebunden ist und von allen Client- und Server-Prozessen abgearbeitet wird.

8. Steuerungssystem nach Anspruch 6 oder 7, weiter dadurch gekennzeichnet, daß der RPC-Vorgang für die Kommunikationsschicht als synchroner, asynchroner oder Oneway-RPC-Vorgang realisiert ist.

9. Steuerungssystem nach einem der Ansprüche 6 bis 8, weiter dadurch gekennzeichnet, daß das Nachrichtenprotokoll Informationen über den Nachrichtentyp, eine Dienstnummer einer jeweiligen Methode eines Anwendungspro­ tokolls und die zu übergebenden Daten enthält.