DE19748536C2 - Datenverarbeitungsgestütztes elektronisches Steuerungssystem, insbesondere für ein Kraftfahrzeug - Google Patents
Datenverarbeitungsgestütztes elektronisches Steuerungssystem, insbesondere für ein KraftfahrzeugInfo
- Publication number
- DE19748536C2 DE19748536C2 DE19748536A DE19748536A DE19748536C2 DE 19748536 C2 DE19748536 C2 DE 19748536C2 DE 19748536 A DE19748536 A DE 19748536A DE 19748536 A DE19748536 A DE 19748536A DE 19748536 C2 DE19748536 C2 DE 19748536C2
- Authority
- DE
- Germany
- Prior art keywords
- server
- client
- level
- application
- control system
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
- 238000012545 processing Methods 0.000 title description 11
- 238000000034 method Methods 0.000 claims description 144
- 230000008569 process Effects 0.000 claims description 107
- 230000006870 function Effects 0.000 claims description 90
- 238000004891 communication Methods 0.000 claims description 55
- 238000013461 design Methods 0.000 claims description 40
- 230000001360 synchronised effect Effects 0.000 claims description 6
- 230000005540 biological transmission Effects 0.000 claims description 5
- 230000009471 action Effects 0.000 claims description 4
- 230000004048 modification Effects 0.000 claims description 4
- 238000012986 modification Methods 0.000 claims description 4
- 230000002457 bidirectional effect Effects 0.000 claims description 3
- 238000012938 design process Methods 0.000 claims description 2
- 230000000875 corresponding effect Effects 0.000 description 23
- 230000007246 mechanism Effects 0.000 description 15
- 238000010586 diagram Methods 0.000 description 10
- 230000006399 behavior Effects 0.000 description 9
- 238000011161 development Methods 0.000 description 9
- 238000006243 chemical reaction Methods 0.000 description 6
- 230000004044 response Effects 0.000 description 6
- 230000008859 change Effects 0.000 description 5
- 230000001419 dependent effect Effects 0.000 description 3
- 238000007792 addition Methods 0.000 description 2
- 238000013459 approach Methods 0.000 description 2
- 238000010276 construction Methods 0.000 description 2
- 239000002609 medium Substances 0.000 description 2
- 238000000926 separation method Methods 0.000 description 2
- 239000008186 active pharmaceutical agent Substances 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 239000002775 capsule Substances 0.000 description 1
- 150000001768 cations Chemical class 0.000 description 1
- 150000001875 compounds Chemical class 0.000 description 1
- 230000001276 controlling effect Effects 0.000 description 1
- 230000008878 coupling Effects 0.000 description 1
- 238000010168 coupling process Methods 0.000 description 1
- 238000005859 coupling reaction Methods 0.000 description 1
- 230000004069 differentiation Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 239000000945 filler Substances 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 210000004072 lung Anatomy 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 230000007727 signaling mechanism Effects 0.000 description 1
- 238000004088 simulation Methods 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 230000003319 supportive effect Effects 0.000 description 1
- 230000009897 systematic effect Effects 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 239000006163 transport media Substances 0.000 description 1
- 238000011144 upstream manufacturing Methods 0.000 description 1
- 239000011800 void material Substances 0.000 description 1
Classifications
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B19/00—Programme-control systems
- G05B19/02—Programme-control systems electric
- G05B19/418—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM]
- G05B19/4185—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM] characterised by the network communication
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B19/00—Programme-control systems
- G05B19/02—Programme-control systems electric
- G05B19/04—Programme control other than numerical control, i.e. in sequence controllers or logic controllers
- G05B19/042—Programme control other than numerical control, i.e. in sequence controllers or logic controllers using digital processors
- G05B19/0421—Multiprocessor system
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B2219/00—Program-control systems
- G05B2219/20—Pc systems
- G05B2219/25—Pc structure of the system
- G05B2219/25032—CAN, canbus, controller area network bus
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B2219/00—Program-control systems
- G05B2219/30—Nc systems
- G05B2219/31—From computer integrated manufacturing till monitoring
- G05B2219/31136—Name of bus, canbus, controller area network
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B2219/00—Program-control systems
- G05B2219/30—Nc systems
- G05B2219/33—Director till display
- G05B2219/33148—CLS client server architecture, client consumes, server provides services
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02P—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN THE PRODUCTION OR PROCESSING OF GOODS
- Y02P90/00—Enabling technologies with a potential contribution to greenhouse gas [GHG] emissions mitigation
- Y02P90/02—Total factory control, e.g. smart factories, flexible manufacturing systems [FMS] or integrated manufacturing systems [IMS]
Landscapes
- Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Automation & Control Theory (AREA)
- General Engineering & Computer Science (AREA)
- Manufacturing & Machinery (AREA)
- Quality & Reliability (AREA)
- Computer And Data Communications (AREA)
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),
- - 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.
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
DE19748536A DE19748536C2 (de) | 1997-11-03 | 1997-11-03 | Datenverarbeitungsgestütztes elektronisches Steuerungssystem, insbesondere für ein Kraftfahrzeug |
US09/184,858 US6336128B1 (en) | 1997-11-03 | 1998-11-03 | Data-processing-aided electronic control system for a motor vehicle |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
DE19748536A DE19748536C2 (de) | 1997-11-03 | 1997-11-03 | Datenverarbeitungsgestütztes elektronisches Steuerungssystem, insbesondere für ein Kraftfahrzeug |
Publications (2)
Publication Number | Publication Date |
---|---|
DE19748536A1 DE19748536A1 (de) | 1999-05-12 |
DE19748536C2 true DE19748536C2 (de) | 2000-06-29 |
Family
ID=7847478
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE19748536A Expired - Fee Related DE19748536C2 (de) | 1997-11-03 | 1997-11-03 | Datenverarbeitungsgestütztes elektronisches Steuerungssystem, insbesondere für ein Kraftfahrzeug |
Country Status (2)
Country | Link |
---|---|
US (1) | US6336128B1 (de) |
DE (1) | DE19748536C2 (de) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE10162853C1 (de) * | 2001-12-17 | 2003-06-05 | Iav Gmbh | Kraftfahrzeugsteuersystem und Verfahren zur Kraftfahrzeugsteuerung |
DE102005051432A1 (de) * | 2005-10-27 | 2007-05-03 | Bayerische Motoren Werke Ag | Datenübertragungssystem zur Steuerung und Regelung von Betriebsabläufen in Kraftfahrzeugen |
Families Citing this family (22)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE19946096A1 (de) * | 1999-09-27 | 2001-04-12 | Mannesmann Vdo Ag | Steuergerät, insbesondere für ein Kraftfahrzeug |
US6697857B1 (en) * | 2000-06-09 | 2004-02-24 | Microsoft Corporation | Centralized deployment of IPSec policy information |
US20020184348A1 (en) * | 2000-09-20 | 2002-12-05 | Lockheed Martin Corporation | Object oriented framework architecture for sensing and/or control environments |
EP1319203A2 (de) * | 2000-09-20 | 2003-06-18 | Lockheed Martin Corporation | Objekt-orientierte strukturarchitektur für sensor- und/oder steuerungsumgebungen |
DE10108599C2 (de) | 2001-02-22 | 2003-04-30 | Rittal Gmbh & Co Kg | Schaltschrank oder Schaltschrankanordnung mit einer darin angeordneten Überwachungseinrichtung |
SE524110C2 (sv) | 2001-06-06 | 2004-06-29 | Kvaser Consultant Ab | Anordning och förfarande vid system med lokalt utplacerade modulenheter samt kontaktenhet för anslutning av sådan modulenhet |
DE10139610A1 (de) | 2001-08-11 | 2003-03-06 | Daimler Chrysler Ag | Universelle Rechnerarchitektur |
US7181511B1 (en) * | 2002-04-15 | 2007-02-20 | Yazaki North America, Inc. | System and method for using software objects to manage devices connected to a network in a vehicle |
US20040176877A1 (en) * | 2003-03-05 | 2004-09-09 | Scott Hesse | Building automation system and method |
US7433740B2 (en) * | 2003-03-05 | 2008-10-07 | Colorado Vnet, Llc | CAN communication for building automation systems |
US6927546B2 (en) * | 2003-04-28 | 2005-08-09 | Colorado Vnet, Llc | Load control system and method |
US20040218591A1 (en) * | 2003-04-29 | 2004-11-04 | Craig Ogawa | Bridge apparatus and methods of operation |
US7472203B2 (en) * | 2003-07-30 | 2008-12-30 | Colorado Vnet, Llc | Global and local command circuits for network devices |
US20050049726A1 (en) * | 2003-08-29 | 2005-03-03 | Adamson Hugh P. | Input device for building automation |
US20050049730A1 (en) * | 2003-08-29 | 2005-03-03 | Adamson Hugh P. | Keypad for building automation |
US20050283284A1 (en) * | 2004-06-16 | 2005-12-22 | Grenier Alain H | Vehicle services manager |
EP1916578A1 (de) * | 2006-10-24 | 2008-04-30 | Triphase NV | System für Echtzeit-Prozesssteuerung |
US8126605B2 (en) * | 2007-12-05 | 2012-02-28 | Toyota Motor Engineering & Manufacturing North America, Inc. | Computing platform for multiple intelligent transportation systems in an automotive vehicle |
WO2009093217A2 (en) * | 2008-01-25 | 2009-07-30 | Nxp B.V. | Message interface code generator and method of producing an asynchronous message interface code for an audio streaming system |
US8799201B2 (en) | 2011-07-25 | 2014-08-05 | Toyota Motor Engineering & Manufacturing North America, Inc. | Method and system for tracking objects |
US10031904B2 (en) * | 2014-06-30 | 2018-07-24 | International Business Machines Corporation | Database management system based on a spreadsheet concept deployed in an object grid |
CN113791894A (zh) * | 2021-08-16 | 2021-12-14 | 新奇点智能科技集团有限公司 | 一种道路数据处理*** |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5515508A (en) * | 1993-12-17 | 1996-05-07 | Taligent, Inc. | Client server system and method of operation including a dynamically configurable protocol stack |
US5491800A (en) * | 1993-12-20 | 1996-02-13 | Taligent, Inc. | Object-oriented remote procedure call networking system |
US5715453A (en) * | 1996-05-31 | 1998-02-03 | International Business Machines Corporation | Web server mechanism for processing function calls for dynamic data queries in a web page |
-
1997
- 1997-11-03 DE DE19748536A patent/DE19748536C2/de not_active Expired - Fee Related
-
1998
- 1998-11-03 US US09/184,858 patent/US6336128B1/en not_active Expired - Fee Related
Non-Patent Citations (2)
Title |
---|
KUSCHKE, D. Softwareschnittstelle SPS-INTERBUS-S. In: Elektrie Berlin 48 (1994) 1, S.26-30 * |
R. ORFALI, D. HARKEY: Client/Server Programming with 05/2 2.0. Van NOSTRAND Reinhold, New York 1992. S.10-14 u. 165-167 * |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE10162853C1 (de) * | 2001-12-17 | 2003-06-05 | Iav Gmbh | Kraftfahrzeugsteuersystem und Verfahren zur Kraftfahrzeugsteuerung |
DE102005051432A1 (de) * | 2005-10-27 | 2007-05-03 | Bayerische Motoren Werke Ag | Datenübertragungssystem zur Steuerung und Regelung von Betriebsabläufen in Kraftfahrzeugen |
Also Published As
Publication number | Publication date |
---|---|
DE19748536A1 (de) | 1999-05-12 |
US6336128B1 (en) | 2002-01-01 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
DE19748536C2 (de) | Datenverarbeitungsgestütztes elektronisches Steuerungssystem, insbesondere für ein Kraftfahrzeug | |
DE69329577T2 (de) | Verfahren und system für implementierung-unabhängige schnittstellenspezifikation | |
EP0825524B1 (de) | Verfahren zur Verwaltung der Benennung von Objekten | |
DE60211254T2 (de) | Fernereignis Behandlung in ein Paketnetzwerk | |
DE69429686T2 (de) | Transaktionsverwaltung in objektorientiertem System | |
DE19750662C2 (de) | Prozessoreinheit für ein datenverarbeitungsgestütztes elektronisches Steuerungssystem in einem Kraftfahrzeug | |
Reif | Automobilelektronik | |
DE3854361T2 (de) | Programmierbare Protokollvorrichtung. | |
DE102006058818B4 (de) | Vorrichtung und Verfahren zur Umwandlung von Textmitteilungen | |
WO2002013000A2 (de) | Pipeline ct-protokolle und -kommunikation | |
DE68920929T2 (de) | Zeitgeberkanal mit mehreren Zeitgeberreferenzmerkmalen. | |
EP0807883A2 (de) | Kommunikationssystem mit Mitteln zum Austausch von Softwareprozessen | |
DE602004009746T2 (de) | Teilen von Diensten in einem Netz | |
DE60122671T2 (de) | Anforderungsbedingte dynamische Schnittstellengenerierung | |
WO2006005427A1 (de) | Vorrichtung und verfahren zum datenaustausch auf mehreren bussystemen | |
DE69824974T2 (de) | Benachrichtigungssystem in einer telekommunikationssteuereinrichtung | |
DE19850469A1 (de) | Automatisierungssystem und Verfahren zum Zugriff auf die Funktionalität von Hardwarekomponenten | |
DE102008048877B4 (de) | Verfahren zum Laden eines Programmmoduls in eine Netzwerkeinrichtung | |
AT410491B (de) | Kommunikationsverfahren zur realisierung von ereigniskanälen in einem zeitgesteuerten kommunikationssystem | |
DE10134228A1 (de) | Verfahren und System zur Verbesserung von Funktionsfernaufrufen | |
EP1437655A2 (de) | Rechner- und/oder Software-Architektur unter Verwendung von Micro-Kernel- und Multi-Tier-Konzept mit Komponententechnik | |
DE102019002119B4 (de) | Ansteuern von Ausführungseinheiten | |
DE10229879A1 (de) | Datenverarbeitungssystem mit Diensten zur Bereitstellung von Funktionalitäten | |
AT517365A1 (de) | Vorrichtung, Verfahren und Computerprogrammprodukt zur sicheren Datenkommunikation | |
DE60036503T2 (de) | Verfahren zur Kommunikation zwischen Fernobjekten |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
OP8 | Request for examination as to paragraph 44 patent law | ||
8127 | New person/name/address of the applicant |
Owner name: DAIMLERCHRYSLER AG, 70567 STUTTGART, DE INTERNATIO |
|
D2 | Grant after examination | ||
8364 | No opposition during term of opposition | ||
8327 | Change in the person/name/address of the patent owner |
Owner name: DAIMLERCHRYSLER AG, 70327 STUTTGART, DE Owner name: INTERNATIONAL BUSINESS MACHINES CORP., ARMONK,, US |
|
8327 | Change in the person/name/address of the patent owner |
Owner name: INTERNATIONAL BUSINESS MACHINES CORP., ARMONK,, US Owner name: DAIMLER AG, 70327 STUTTGART, DE |
|
8339 | Ceased/non-payment of the annual fee |