Die Forderung nach mehr Sicherheit, Wirtschaftlichkeit, Komfort sowie einer besseren umweltverträglichkeit lässt die Mechatronik im Fahrzeug zu einem _mmer bedeutenderen und wettbewerbsbestim- menderen Faktor werden. Wirtschaftliche Fahrzeugentwicklungen und die Beherrschung komplexer Systemstrukturen bei immer kürzer werdenden Produktzyklen erzwingen durchgängige, möglichst weit automatisierte, rechnerunterstützte Entwicklungsprozesse. In der Analysephase können auf der Basis vereinbarter formaler Struktu- rierungs-und Modellierungsregeln des automobilhersteller-und zulief ererneutralen Crdnungskonzepts Canronic modulare, erwei- <BR> <BR> <BR> <BR> terbare Architekturen für"Funktion","Sicherheit"und"Elektro- nik"spezifiziert werden.

Die Forderung nach mehr Sicherheit, Wirtschaftlichkeit, Komfort und einer besseren Umweltverträglichkeit lässt die Mechatronik im Fahrzeug zu einem immer bedeutenderen und wettbewerbsbestim- menderen Faktor im Technologiewandel von der Mechanik aber die Elektronik zur Informationstechnik werden. Bei ständig steigen- der Komplexität der Systeme und gleichzeitig immer kürzer wer- denden Produktzyklen bleibt der Kosten-und Entwicklungsaufwand nur bei Einsatz eines durchgängigen, möglichst weit automat- sierten, rechnerunterstützten sowie weitgehend parallelisierten Arbeits-und Entwicklungsprozesses beherrschbar.

Ein Ansatz zur Lösung der teilweise divergierenden Anforderungen ist die Vernetzung der bisher weitgehend unabhängig voneinander arbeitenden Einzelsysteme zu einem fahrzeugweiten Verbundsystem und die logische Zusammenfassung von Systemkomponenten zu funk- tionalen Einheiten mit standardisierten Schnittstellen. Der Sy- stemverbund bietet die Möglichkeit einer Kooveration und Mehr- fachnutzung von Sensorik sowie AktuaLorik und somit einer Nutz- barmachung emergenter Funktionen.

Die Vernetzung ermöglicht darüber hinaus einen Wandel von rein funktionsorientierten Realisierungen zu Konfigurationen, bei de- nen die Anwendungsfunktionen auf vernetzte Steuergeräte abgebil- det werden. Außerdem können bei partiellen Systemausfällen dyna- mische Verlagerungen von Funktionen auf andere Systeme unter- stützt werden.

Ausgehend von den logischen Funktionseinheiten mit ihren stan- dardisierten Schnittstellen wird es ebenfalls möglich, Funktio- nen unterschiedlichen Ursprungs, verschiedener Automobilherstel- ler und Zulieferer, miteinander zu vernetzen. Ein Funktionslie- ferant muss hierbei garantieren, dass die Funktion auch bei Ver- teilung auf mehrere vernetzte Steuergeräte die geforderte Spezi- fikation einhält.

Die Entwicklung komplexer, vernetzter Systeme setzt einen syste- matischen Prozess mit rekursiven Phasen und den Einsatz rechner- gestützter Werkzeuge voraus, bei dem sowohl der AutomobiLher- steller als auch der Zulieferer alle Anforderungen und Randbe- dingungen an die zu entwickelnde Funktion formulieren, die viel- fältigen Interaktionen mit anderen Funktionen und der Umgebung in allen Anwendungs-und Fehlerfällen analysieren und die Funk- tion in ihrer Auswirkung auf die Sicherheit des Gesamtverbunds bewerten kann. Für die Entwicklung von komplexen, vernetzten Sy- stemen hat sich das V-Modell als Vorgehensmodell auch in der Au- tomobilbranche etabliert. Das V-Modell sieht vor, dass sämtliche Aktivitäten und Abläufe zur Funktionsentwicklung in elf Phasen eingeordnet werden können (Figur 1).

Das V-Modell beschreibt ein Vorgehen, bei dem der Spezifika- tions-und Entwurfsprozess durch die Detaillierung und Verfeine- rung charakterisiert sind und das sich als top-down- Vorgehensweise veranschaulichen lässt. Dagegen sind die Verifi- kations-und Validierungsphasen bottom-up-Vorgehensweisen. We- sentliche Anforderung und Voraussetzung für Qualitätszertifizie- rungen sind hierbei detaillierte Dokumentationsunterlagen für jede einzelne Phase.

Um den Forderungen nach einer wirtschaftlichen Fahrzeugen. twick- lung, der Beherrschung komplexer Sysremstrukturen und einer ad- äquaten Dokumentation gerecht werden zu können, wurde das Ord- nungskonzept Cartronic (siehe Bertram, T., R. Bitzer, R. Mayer und A. Volkar, 1998, CARTRONIC-An open architecture for net- working the control systems of an automobile, Detroit/Michigan U. S. A., SAE 98200, 1-9) entwickelt.

In der ersten Phase der Prozesskette, der Analyse, ermöglicht das auf objektbasierenden Grundgedanken entwickelte Ordnungskon- ze ? t die logische Zusammenfassung von Systemkomponenten zu funk- tionalen Einheiten mit standardisierten logischen Schnittstel- len. Die Beschreibung der Vernetzung der bisher weitgehend unab- hängig voneinander arbeitenden Einzelsysteme eines Kraftfahr- zeugs zu einem fahrzeugweiten Verbundsystem stellt somit ein (Meta-) Modell für eine modular erweiterbare Funktions-, Sicher- heits-und Elektronikarchitektur dar. Ein wesentlicher Vorteil dieser automobilhersteller-und zulieferneutralen Spezifikati- onsmöglichkeit ist die nach kurzer Einarbeitungszeit allen am Entwicklungsprozess Beteiligten verständliche, logische Be- schreibung der Anforderungen schon zu einem sehr frühen Entwick- lungszeitpunkt.

Grafikbasierte Modelle unterstützen als wesentliche Dokumentati- onselemente während aller Entwicklungsphasen eine Kommunikation zwischen allen an der Entwicklung beteiligten Personen sowie nach Abschluss der Entwicklung die Pflege und Weiterentwicklung.

Ergänzend zum klassischen Softwareengineering sind dabei far me- chatronische Systementwicklungen im Kraftfahrzeugbereich als Personengruppen zu unterstützen : Fahrzeughersteller als Benutzer/Kunden sowie Interessente-, die Informationen zur Funktionalität des Systems benötigen, Ingenieur der Fachrichtungen Maschinenbau und Elektrotechnik sowie Informatiker als Entwickler der mechaironischen Komponen- ten auf Hersteller-und Zuliefererseite sowie diejenigen, die <BR> <BR> <BR> <BR> diese nach abgeschlossener Entwicklung modifizieren beziehungs- weise erweitern werden und dazu Verständnis des Gesamtsystems oder seiner Teile benötigen, Manager auf Entwickler-und Kunden- seite, die organisatorische und wirtschaftliche Einzelheiten zur Projektkontrolle, Berechnung von Kosten und Informationen für zukünftig Projekte und Entwicklungen benötigen sowie nicht zu- letzt die Fahrzeugführer als spezielle Endbenutzer, die mit aus- gewählten Funktionalitäten des Systems vertraut gemacht werden müssen.

Ein wesentlicher Schritt am Ende der Analyse-und zu Beginn der Designphase ist die Abbildung der in Cartronic entwickelten Spe- zifikationsmodelle in einen informationstechnischen Entwurf für die Softwareentwicklung. Diese Abbildung trägt zur Erhöhung der Informationsdichte und der Erweiterung des semantischen Gehalts aufgestellter Cartronic-Modelle bei, definiert Teilsysteme in einer Gesamtsystemarchitektur, erhöht die Transparenz des Ge- samtsystems in Zielrichtung dessen Implementierung und schafft wesentliche Grundlagen für eine verteilte Entwicklung und Test- barkeit von mechatronischen Systemen.

Vorliegend wird eine Abbildung von in CARTRONIC erstellten Spe- zifikationsmodellen in eine standardisierte objektorientierte Darstellung vor dem Hintergrund einer möglichst weitgehenden Un- terstützung durch kommerziell verfügbare Software-Entwicklungs- Werkzeuge beschrieben. Eine dafür erforderliche geeignete Nota- tion stellt der von der Object Management Group (OMG) interna- tional standardisierte, objektorientierte Spracnstandard der Unified Modeling Language (UML) dar.

Im folgenden wird eine zusammenfassende Beschreibung der Struk- turelemente und formalen Strukturierungs-sowie Modellierungsre- geln nach CARTRONIC für Funktionsarchitekturen gegeben. Ferner wird auf einer hohen Abstraktionsebene eine Funktionsarcnitektur des Gesamtfahrzeugs mit einer Detaillierung für die Komponente Antrieb vorgestellt. Davon ausgehend erfolgt zunächst die Dar- stellung theoretischer Grundlagen der Modellierung, bevor auf die verwendeten Elemente der objektorientierten Notation mit UML im weiteren Verlauf dieses Abschnitts eingegangen wird. Die Vor- gehensweise für das vorhandene Modell nach CARTRONIC° wird an einem Beispiel aufgezeigt.

Ein bereits in heutigen Fahrzeugen existierendes Beispiel für einen Systemverbund ist die Antriebsschlupfregelung. Diese wird erst durch die Kommunikation des Steuergeräts für die Antriebs- schlupfregelung mit dem Steuergerät für das Motormanagement zur Regelung des Antriebsmoments möglich.

CARTRONIC ist ein Ordnungskonzept für alle Steuerungs-und Re- gelungssysteme eines Fahrzeugs. Das Konzept enthält modulare er- weiterbare Architekturen für"Funktion","Sicherheit"und"Elek- tronik"auf der Basis vereinbarter formaler Strukturierungs-und Modellierungsregeln.

Unter einer Architektur ist hier sowohl die Strukturierungssy- stematik (Regeln) zu verstehen als auch deren Umsetzung in eine konkrete Struktur. Die Funktionsarchitektur umfasst sämtliche im Fahrzeug vorkommenden Steuerungs-und Regelungsaufgaben. Die Aufgaben des Systemverbunds werden logischen Komponenten zuge- ordnet, die Schnittstellen der Komponenten und ihr Zusammenwir- ken werden festgelegt. Die Sicherheitsarchitektur erweitert die Funktionsarchitektur um Elemente, die einen sicheren Betrieb des <BR> <BR> <BR> <BR> Systemverbunds garantieren. Schließlich wird für die Elektronik eine Systematik angegeben, wie der Systemverbund mit bedarfsge- recht optimierter Hardwaretopologien zu realisieren ist.

Die Elemente der Architekturen sind Komponenten und Kommunikati- onsbeziehungen auf der einen und Strukturierungs-und Modellie- rungsregeln auf der anderen Seite. im Rahmen der Strukturierung wird von einem System als einer Zusammenstellung von Komponenten zu einem Ganzen gesprochen, die über Kommunikationsbeziehungen miteinander in Wechselwirkungen stehen. Der Begriff Komponente meint nicht zwangsläufig eine physikalische Einheit im Sinne ei- nes Bauteils, sondern wird als Funktionseinheit verstanden. Bei dem Ordnungskonzept werden drei verschiedene Typen von Komponen- ten unterschieden : O Komponenten mit überwiegend koordinierenden und verteilenden Aufgaben, Q Komponenten mit hauptsächlich operativen und ausführenden Aufgaben und Q Komponenten, die ausschließlich Informationen generieren und bereitstellen.

Bei den Kommunikationsbeziehungen wird zwischen einem Auftrag (mit Rückmeldung), einer Abfrage (mit Hinweis) und einer Anfor- derung unterschieden. Den Auftrag kennzeichnet die Pflicht zur Ausführung ; für den Fall der Nichterfullung muss der Auftragneh- mer eine Rückmeldung an den Auftraggeber absetzen, die den Grund für die Nichtausführung beschreibt. Die Abfrage dient der Be- schaffung von Informationen für eine Auftragsausführung. Für den Fall, dass eine Komponente die abgefragt Information nicht be- reitstellen kann, gibt sie einen Hinweis an die fragende Kompo- nente. Eine Anforderung beschreibt einen Wunsch", dass eine Funktion von einer anderen Komponente ausgeführt wird. An die Anforderung ist allerdings nicht die P-licht zur Erfüllung ge- koppelt, was beispielsweise bei konkurrierenden Anforderungen Berücksichtigung finde.. Folgende Tabelle stell-die Struktu- elemente zusammenfassend dar. STRUKTURELEMENT KURZBESCHREIBUNG Komponente Logische Funktionseinheit. Hülle Von einer detaillierten Komponente bleibt eine Hülle, die die Kommunika- tionen an die Teilkomponenten weiter- leitet sowie eine"ist Teil von"- Beziehung ausdrückt ("Sicht von außen nach innen"). System Ein System besteht aus mehreren Kompo- nenten und (Sub-) Systemen ("Sicht von innen nach außen"). Auftrag (mit Handlungsanweisung mit Pflicht zur Aus- Rückmeldung) führung einer Funktion. Abfrage (mit Ermittlung einer Information. Hinweis) Anforderung Wunsch"auf Ausführung einer Funktion. Regeln Regeln zu : # Kommunikationsbeziehungen Model Modellierungsmustern Die Strukturierungsregeln beschreiben erlaubte Kommunikationsbe- ziehungen innerhalb der Architektur des Gesamtfahrzeugs. Es wer- den Strukturierungsregeln unterschieden, die die Kommunikations- beziehungen auf der gleichen Abstrak-onsebene und in höhere und tiefere Ebenen unter Berücksichtigung angegebener Randbedingun- gen regeln. Ferner klären die Strukturierungsregeln die Weiter- leitung von Kommunikationsbeziehungen von einem System in ein anderes in dessen Detaillierung hinein.

Die Modellierungsregeln beinhalten Muster, die Komponenten und Kommunikationsbeziehungen für die Lösung spezieller, mehrfach vorkommender Aufgaben zusammenfassen. Diese Muster, zum Beispiel ein Energiemanagement, können dann an verschiedenen Stellen in- nerhalb der Struktur des Fahrzeugs wiederverwendet werden.

Eine nach den Strukturierungs-und Modellierungsregeln entwik- kelte Struktur zeichnet sich durch folgende Merkmale aus : O vereinbarte, einheitliche Strukturierungs-und Modellierungs- regeln auf allen Abstraktionsebenen, 0 hierarchische Auftragsflüsse, 0 hohe Eigenverantwortung der einzelnen Komponenten, Bedienelemente, Sensoren und Schätzer sind gleichwertige In- formationsgeber und eine O Kapselung, die jede Komponente für die übrigen Komponenten so sichtbar wie nötig und so unsichtbar wie möglich dargestellt.

Figur 2 stellt beispielhaft die Architekturmerkmale und die er- laubten Kommunikationsbeziehungen dar. Dies sind im Einzelnen- der Einfachheit halber wird nur von Auftrag, Abfrage und Anfor- derung gesprochen, gemeint ist aber die Beziehung, die diese je- weils ermöglichen : -der Auftrag momen : ga (Moment am Getriebeausgang bereitstel- len), der von der Hülle Antrieb an die Eingangskomponente An- triebs-Koordinator weitergeleitet wird, die gleichzeitig auch Koordinator ist, -die Aufträge moment ma (Moment am Motorausgang bereitstellen), stelleKraftschluss und einlegenGang (einlegen eines Ganges) vom Antriebs-Koordinator an Motor, Wandler und Getriebe, -die Anforderung SrGang (Rückwärtsgang) vom Getriebe-Bed. ienfeld an den Antriebs-Koordinator, -die Abfragen ? zustand und ? luftdruck (der Umgebung) an Getrie- be und Umwelt -sowie die Abfragen ? gang (Rückwärtsgang oder nicht) und ? dreh- zahl an die Hülle Antrieb, die diese an die zuständigen Kompo- nenten Motor und Getriebe weiterleitet.

Im klassischen Software-Lebenszyklus werden die streng sequenti- ell zu durchlaufenden Phasen Problemanalyse, Systemspezifikati- on, Entwurf, Implementierung mit Komponenten-, Gesamttest und Einführung sowie Betrieb und Pflege eines Scftwaresystems unter- schieden. In der Praxis ist ein solcher, streng sequentieller Entwicklungsprozess eine nicht einzuhaltende Idealisierung.

Theoretisch klar abgrenzbare Punkte überlappen sich oder sind unter Umständen unterschiedlich weit vorangeschritten, gleich- zeitig schreitet das Know-how auf Seiten aller am Entwicklungs- prozess Beteiligten mit der Systementwicklung weiter voran. Eine objektorientierte Vorgehensweise ermöglicht ein phasenübergrei- fendes Vorgehen mit von Anfang an hoher Wiederverwendbarkeit be- reits entwickelter beziehungsweise vorhandener Anteile und Kon- zepte. Dies wird durch die Verwendung einer rechnerunterstütz- ten, grafische Notation wesentlich erleichtert. Die in der ob- jektorientierten Softwareentwicklung eingesetzten verschiedenen methodischen Vorgehensweisen beinhalten eine speziell für die jeweilige Methode entwickelte grafische Notation. Die UML ist hervorgegangen aus den drei in der industriellen Softwareent- wicklung meist verwendeten Methoden, der Booch-Methode benannt nach Grady Booch, der unter James Rumbaugh entwickelten Object Modeling Technique (OMT) sowie dem unter Ivar Jacobson entwik- kelten Object Oriented Software Engineerin. (OOS-). D_e UML stellt dabei keine weitere, neue, universelle Methode dar, son- dern ein Metamodell zur Konstruktion von Modellen auf verschie- dene Sichten (Figur 3). Sie stellt eine grafische und ergänzend tabellarische und textuelle Notation mit einheitlicher Syntax und eindeutig definierter Semantik dar.

Entwickelte UML-Modelle sind von allen am Entwicklungsprozess beteiligten Personen eindeutig interpretierbar und bieten als wesentliche Vorteile : -die Verwendung eines internationalen Standards, -eine möglichst herstellerunabhängige, toolunterstütze Vorge- hensweise, -eine Aufweichung der starren Einhaltung der klassischen Hin- tereinanderabfolge von Analyse-und Designphase bei der Softwa- reentwicklung ohne Aufgabe des Software-Lebenszyklus-Modells als Grundlage einer ingenieurmäßigen top-down-Vorgehensweise, -möglichst weitgehende Unabhängigkeit von der letztendlich ver- wendeten Programmiersprache auf der logischen Ebene, -die Erhaltung der Konsistenz zwischen Analyse, Designentwurf und Implementierung, sowie -die Möglichkeit einer gleichzeitigen bottom-up Reverse- Engineering-Vorgehensweise.

In der Analysephase entstehen CARTRONIC-Modelle als eine präformal strukturierte Spezifikation, was das mechatronische System leisten soll. Diese Modelle stellen eine objektbasierte Abstraktion der funktional logischen Konzept aus den Fahrzeug- systemstrukturen dar. Durch eine geeignete Abbildung in ein weitaus mächtigeres UML-Modell findet gleichzeitig der Wechsel von der Analyse-in die Design-und Entwurfsphase statt. Dabei werden Grundlagen für die Gesamtarchitektur des Softwaresystems gelegt, Teilsysteme zur Reduktion beziehungsweise Beherrschbar- keit der Komplexität definiert und saubere zwi- schen diesen spezifiziert. Die Hinzufügung vcn mehr und mehr De- tails führt im fortschreitenden Entwurfsprozess in Richtung Im- plementierung. Das Ziel der Design-beziehungsweise Entwurfspha- se besteht in der Festlegung der Systemkomponenten, deren Aufbau und Schnittstellen mit der Definition des zugrundeliegenden lo- gischen Datenmodells einschließlich der Daten-und algorithmi- schen Strukturen sowie deren Validierung. Komplexität ist durch Abstraktion zu bewältigen, wobei sowohl die Einfachheit als auch Überschaubarkeit des Ganzen gewährleistet sein muss (Strukturie- rung im Großen). In späteren Schritten bezieht sich die Struktu- rierung ebenso auf die Auswahl angemessener Programmbausteine bei der algorithmischen Formulierung mit dem Ziel einer Optimie- rung der geforderten Leistungseigenschaften des Systems (Struk- turierung im Kleinen). Das Ziel der Implementierungsphase be- steht in der Übertragung des logischen Datenmodells, der System- architektur und Algorithmen in übersetzbaren Programmcode für die einzelnen Steuergeräte und das Kommunikationsnetzwerk im Kraftfahrzeug.

Zeichnung Die Erfindung ist anhand der in den Figuren 1 bis 14 darge- stellten Ausführungsformen näher erläutert.

Beschreibung von Ausführungsbeispielen Im Folgenden wird die Abbildung der Cartronic-Elemente in UML- Elemente anhand des in Figur 4 dargestellte-Ausschnittes vorge- stellt. Wesentliche Überlegungen sind hierbei, die CARTRONIC- Regeln möglichst komplett zu unterstützen, die Grundgedanken der Objektorientierung zu wahren und dabei für den CARTRONIC- Modellierer verständlich genug und ausreichend transparent zu bleiben, sowie alle notwendigen Informationen für spätere Ar- beitsschritte aufnehmen und darstellen zu können.

Figur 4 zeigt die CARTRONIC-Komponenten Umwelt, Antrieb, Fahr- zeug-Koordinator und Elektrisches Bordnetz. Zwischen diesen Kom- ponenten bestehen folgende Kommunikationsbeziehungen : Der Fahr- zeug-Koordinator befragt den Antrieb nach der aktuellen ? dreh- zahl beziehungsweise beauftragt den Antrieb ein moment-go am Ge- triebeausgang bereitzustellen. Der Antrieb befragt den Informa- tionsgeber Umwelt nach dem aktuellen ? luftdruck und fordert ! el_Leistung von der Komponente Elektrisches Bordnetz an.

Klassen in der objektorientierten Terminologie sind in der Regel die Generalisierungen gleichartiger Objekte (Schablonen), auf höheren Abstraktionsebenen sind Komponenten beziehungsweise Klassen seltener materielle Gegenstände, sondern meistens ab- strakte Gebilde oder Funktionseinheiten. Objekte (im Allgemeinen Gegenstände) sind Exemplare von Klassen mit Eigenschaften und Verhalten. In der objektorientierten Modellierung ist ein häufig genutzter Einstieg bei der Suche nach Klassen die Suche nach Substantiven, da diese in der Sprache im Allgemeinen die Genera- lisierung von Objektgruppen bilden. Adjektive beschreiben Eigen- schaften und werden in der Regel als Attribute modelliert. Ope- rationen wiederum bilden das Verhalten von Objekten ab, entspre- chen also den Verben. Es liegt deshalb nahe, die CARTRONIC- Komponenten als UML-Klassen beziehungsweise UML-Objekte darzu- stellen.

Über die Stereotypen <<huelle,,, cinformationsg2ber>>, c<koor- dinator » und « operator » werden die Komponentenklassen den oben eingeführten Kategorien zugeordnet. Die Komponente Umwelt aus Figur 4 wird beispielsweise als Klasse mit dem Namen Umwelt und dem Stereotyp <<informationsgeber>> dargestellt.

Die drei CARTRONICe-Kommunikationsarten Auftrag, Abfrage und An- forderung fordern andere Komponenten auf,"etwas zu tun"-in objektorientierter Modellierung werden diese deshalb als Nach- richten interpretiert und mit den Stereotypen « auftrag », « ab- frage » und canforderung>> als UML-Operationen modelliert. Aus dem CARTRONIC-AuStrag moment_ga wird die UML-Operation « auf- trag # moment_ga der Klasse Antrieb, aus der CARTRONIC-AbErage ? drehzahl an diese Komponente die UML-Operation « abfrage » drehzahl sowie aus der CARTRONIC-AbErage ? luftaruck an die Kom- ponente Umwelt die UML-Operation « abfrage » luftdruck der Klas- se Umwelt. Bei der Darstellung in Figur 5 symbolisiert die dop- pelte Linie in den Klassen Antrieb, Elektrisches Bordnetz und Umwelt, dass bislang noch keine Attribute vorhanden sind. Bei der Klasse Fahrzeug-Koordinator wird auf die Darstellung eventu- ell vorhandener Attribute oder Operationen ganz verzichtet und nur der Deklarationsbereich der Klasse abgebildet. Dies ergibt ein übersichtlicheres Diagramm. CARTRONIC-Rückmeldungen können als Rücicgabeparameter von UML-Operationen modelliert werden und sind deshalb bei der Abbildungsvorschrift nicht explizit als ei- genständige UML-Operationen modelliert.

Die Kapselung der einzelnen Komponenten mit dem Ziel einer definierten Zugriffsregelung und-Kontrolle wird über expli- zite UML-Schnittstellen für die UML-Operationen modelliert.

Es wird zwischen Schnittstellen für Aufträge sowie Abfragen und Anforderungen unterschieden mit den beiden Stereotypen « interfaceAuftrag » und « interface ». Die für Aufträge geltenden strengerer Zugriffsregeln nach dem #Ein-Chef- Prinzip"werden hierdurch explizit modelliert. Figur 6 zeigt dies am Beispiel der Klasse « operator » Antrieb.

Eine tiefer detaillierte CARTRONIC-Kom ? onente zeigt Figur 7 am Beispiel der Komponente Antrieb, hier im Unterschied zu Figur 2 jedoch nur mit den drei Teilkomponenten Motor, Antriebs- Koordinator und Getriebe. UML-Aggregationen drücken veine, zist Teil von"-Beziehung aus und entsprechen som-t exakt einer CAR- TRONICe-Detaillierung. UML-Kompositionen drücker. als Spezialfäl- le von UML-Aggregationen analog zum CARTRONIC-Verständnis aus, dass Teilkomponenten ohne das Aggregat keinen Bestand haben.

UML-Aggregat und UML-Komposition als logisches Ganzes delegieren (automatisch) Nachrichten, die sie erhalten, aber selber nicht ausführen können, an die entsprechende Teilkomponente (Analogie zur CARTRONIC-Hülleneigenschaft). Figur 8 zeigt die teilweise detaillierte UML-Klasse « huelle » Antrieb als UML-Komposition der UML-Klassen Motor, Antriebs-Koordinator und Getriebe.

Große komplexe CARTRONIC-Komponenten auf hohem abstrakten Ni- veau können analog zur Modellierung aber UML-Klassen auch als UML-Subsysteme abgebildet werden. UM-Subsysteme sind eine Son- derform von UML-Paketen, die Schnittstellen besitzen dürfen und deshalb geeignet sind, eine sinnvolle Kapselung und Strukturab- bildung im Großen zu gewährleisten. Die separaten Schnittstellen für Aufträge beziehungsweise Abfragen und Anforderungen bleiben dabei ebenso erhalten wie analog die im Folgenden vorgestellten Vorgehensschritte. Verbindungen in Form einer Aggregation, oder Komposition zwischen dem Subsystem und darin eni. haltenen Model- lelementen ermöglichen die Weiterleitung von Nachrichten von den Subsystem-Schnittstellen direkt zu den entsprechenden Komponen- ten. Wie in Figur 9 gezeigt, kann eine Schnittstelle, hier « in- <BR> <BR> <BR> <BR> terfaceAuftrag # IA_Antrieb, direkt durch die Schnittstelle ei- nes internen Elements, hier « interfaceAuftrag » IAAn. triebs- Koordinator, bereitgestellt werden.

Die ständige Weiterentwicklung der CARTRONIC#-Modelle erfordert Veränderungs-und Austauschmöglichkeiten von Komponenten. Neben der im vorhergehenden Teilabschnitt beschriebenen Abbildung ein- zelner CARTRONIC-Elemente in die UML müssen die Schritte und Vorgänge im fortlaufenden Entwicklungsprozess unterstützt wer- den. In der Praxis treten hierbei Mischformen der nachfolgend unterschiedenen Vorgehensschritte auf. Diese setzen sich zusam- men aus der Detaillierung, der Abstraktion, dem Ersetzen sowie dem Löschen von Elementen.

Bei der Detaillierung einer CARTRONIC-Komponente entsteht nach dem CARTRONIC-Regelwerk eine Hülle ohne eigene logische Funk- tionen, alle bereits bekannten, existierenden Funktionalitäten werden auf die entstehenden Teilkomponenten verteilt. Die Kapse- lung beziehungsweise die Schnittstellen der zu detaillierenden Komponente müssen vollständig in der Hülle erhalten bleiben, um das Verhalten nach außen nicht zu verändern. Dies sind im Bei- spiel in Figur 6 die Operationen momentga und drehzahl der Klasse Antrieb. Figur 10 zeigt die neue UML-Klasse nach der De- taillierung. Detailliert ist hier in die Klassen Motor, An- triebs-Koordinator und Getriebe sowie zusätzliche Operaticnen #auftrag# moment_ma, #anforderung# rGang und « auftrag » e-nlegenGang. Zu beachten ist die Darstellung der Klasse Antrieb mit dem nunmehr leeren Operationsbereich sowie der Änderung des S_ereotyps in <<huelle>>. Die <<abfrage>> luftdruck der Kompo- nente Motor aus der Komponente Antrieb heraus an den « informa- tionsgeber » Umwelt wird modelliert : über eine Beziehung zwischen diesen beiden Komponenten in Form einer Assoziation-beide müs- sen sich kernen-sowie eine Abhängigkeit von Motor an die ent- sprechend Schnittstelle von Umwelt. Dies gilt analog für alle CARTRONIC-Kommunikationsbeziehungen. Die explizit Modellierung aller Beziehungen der UML-Klassen untereinander führt automa- tisch zu einem vollständigen Überblick über alle Zugriffe auf jede einzelne Schnittstelle.

Abstraktionsvorgänge sind notwendig und sinnvoll für eine kom- pakte und übersichtliche Darstellung strukturierter komplexer Komponentenstrukturen durch ihre Hüllenkomponente und Schnitt- stellen. Bei dem Vorgang der Abstraktion dürfen keine Informa- tionen aus der detaillierten Darstellung verloren gehen und Ab- hängigkeiten zwischen verschiedenen Komponenten müssen möglichst ohne Hinzufügung weiterer Information abgebildet werden. Bei der Abstraktion vom detaillierten UML-Aggregat Antrieb in Abbildung 10 bleibt im Unterschied zu der in Figur 6 dargestellten Kompo- nente Antrieb eine"leere"Klasse (Figur 11). Hierbei ergibt sich aber das Problem der Nicht-Sichtbarkeit der Beziehung zwi- schen einer Teilkomponente von Antrieb und Umwelt. Deshalb er- fordert das UM-Modell zusätzlich zur CARTRONIC"-Funktionsarchi- tektur eine künstlich gesetzte Assoziation und Abhängigkeit zwei- schen den Komponenten Antrieb und Umwelt. Bei Einsatz-eines Mo- dellierungstools kann diese Problematik beispielsweise durch entsprechende Zusatzattribute berücksichtigt werden.

Die einfachste Art des Austauschens von Elementen ist ein Austausch mit gleicher Funktionalität, bei dem Modifikatio- nen nur intern in einer Komponente ohne eine nach außen sichtbare Veränderung von Namen, Schnittstellen oder Bezie- hungen vorgenommen werden (Figur 12).

Ein Austausch mit erweiterter Funktionalität liegt vo-, wenn eine Komponente den Namen, vorhandene Beziehungen und ihre alte Funktionalität behält, jedoch um neue Funktionalität und damit neue Schnittstellenoperationen erweitert wird (Fi- gur 13).

Werden bei einem Austausch innere Elemente einer Komponente so modifiziert, dass neue Beziehungen zu anderen Komponenten erfor- derlich werden, handelt es sich um einen Austausch mit veränder- ten Beziehungen. Dies ist zum Beispiel der Fall bei zusätzlich abgefragter Information. Der Komponentenname und die Schnitt- stellen bleiben hierbei unverändert (Figur 14).

Beim Austauschen mit wegfallender Funktionalität entfallen ein- zelne Funktionen beziehungsweise Operationen in den Schnittstel- len. Vor dem eigentlichen Löschvorgang muss deshalb eine (auto- matisierte) Konsistenzprufung zur Sicherstellung erfolgen, dass keine weitere Komponente des Gesamtmodells die zu löschen-den Elemente noch verwendet.

Das Löschen einer Komponente kann als Sonderform des Austau- schens mit wegfallender Funktionalität betrachtet werden. Hier- bei wird eine vorhandene Klasse in eine #lere" überführt durch iterativen Wegfall ihrer Operationen.

Es wird also ein Verfahren und Vorrichtung zur Nodellierung ei- nes mechatronischen Systems in einem Kraftfahrzeug im Rahmen ei- nes objektbasierten Ordnungskonzept als eine Abbildung in die Unified Modeling Language beschrieben. Diese stellt ein wesent- liches Bindeglied zwischen der Analyse-und Design-beziehungs- weise Entwurfsphase im objektorientierten Sofiwareentwick. lungs- prozess dar. Die Elemente der CARTRONIC"'mit Komponenten und Hül- len als ihren Klassen beziehungsweise Objekten und Auftragen (mit Rückmeldung), Abfragen (mit Hinweis) und S orcerungen als ihrer. Kommurikationsbez ehungen sind an Har--3eispielen zu- sammen mit den wesentlichen Regeln aus dem Gesamtregelwerk vor- gestellt. Für diese Modellierungselemente wird eine Abbildungs- vorschrift in UML-Konstrukte dargestellt. CARTRONIC'-Komponenten einschließlich-Hüllen werden als UML-Klassen beziehungsweise- Objekte mit den Stereotypen « koordinator », « operator », « in- formationsgeber » und « huelle » abgebildet. Die CARTRONIC- Kommunikationsbeziehungen Abfrage und Anforderung werden als UML-Operationen mit den Stereotypen « abfrage » und « anforde- rung » in Schnittstellen mit dem Stereotyp <<interface>> bereit- gestellt, alle Auftragsoperationen werden durch den Stereotypen « auftrag » in Schnittstellen mit Stereotyp <<interfaceAuftrag>> gekennzeichnet. In eine detaillierte Komponente eingehende Nach- richten werden automatisch über Kompositionsbeziehungen an die jeweils zuständigen Teilkomponenten delegiert. Für nicht hierar- chische Kommunikationsbeziehungen zwischen Auftraggeber und Be- auftragtem wird zwischen diesen eine Assoziation und von dem Auftraggeber zu der Schnittstelle des Beauftragten eine Abhän- gigkeitsbeziehung modelliert. Die Kapselung von Komponenten wird somit über die beiden separaten Schnittstellen, die Komposition als imp ; izite Zugehörigkeitsbeziehung und die Darstellung der Abhängigkeiten gewährleistet. Für die im Entwicklungsprozess auftretenden Vorgänge Detaillierung, Abstraktion, Austausch und Löschen von Komponenten werden Vorgehensweisen für den Einsatz eines kommerziell verfügbaren UML-Softwareentwicklungswerkzeuges aufgezeigt.