DE10015114A1 - Verfahren und Vorrichtung zur Modellierung eines mechatronischen Systems in einem Kraftfahrzeug - Google Patents

Abstract

Es werden ein Verfahren und Vorrichtung zur Modellierung eines mechatronischen Systems in einem Kraftfahrzeug im Rahmen eines objektbasierten Ordnungskonzept als eine Abbildung in die Unified Modeling Language beschrieben. Die Elemente der CARTRONIC mit Komponenten und Hüllen als ihren Klassen beziehungsweise Objekten und Aufträgen (mit Rückmeldung), Abfragen (mit Hinweis) und Anforderungen als ihren Kommunikationsbeziehungen sind an Hand von Beispielen zusammen mit den wesentlichen Regeln aus dem Gesamtregelwerk vorgestellt. Für diese Modellierungselemente wird eine Abbildungsvorschrift in UML-Konstrukte dargestellt.

Description

Stand der Technik

Die Erfindung betrifft ein Verfahren und Vorrichtung zur Mo­ dellierung eines mechatronischen Systems in einem Kraftfahr­ zeug.

Die Forderung nach mehr Sicherheit, Wirtschaftlichkeit, Komfort sowie einer besseren Umweltverträglichkeit lässt die Mechatronik im Fahrzeug zu einem immer 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 zuliefererneutralen Ordnungskonzepts "Cartronic modulare", erwei­ 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 über 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 automati­ 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 Kooperation und Mehr­ fachnutzung von Sensorik sowie Aktuatorik 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 Verteilung 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 11 Phasen eingeordnet werden können (Fig. 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 Fahrzeugentwick­ lung, der Beherrschung komplexer Systemstrukturen und einer ad­ äquaten Dokumentation gerecht werden zu können, wurde das Ord­ nungskonzept "Cartronic" (siehe Bertram, T., R. Bitzer, R. Mayer und A. Volkart, 1998, CARTRONIC - An open architecture for networking the control systems of an automobile, Detroit/Michigan, USA, SAE 98200, 1-9) entwickelt.

In der ersten Phase der Prozesskette, der Analyse, ermöglicht das auf objektbasierenden Grundgedanken entwickelte Ordnungskon­ zept 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 für me­ chatronische Systementwicklungen im Kraftfahrzeugbereich als Personengruppen zu unterstützen:

Fahrzeughersteller als Benutzer/Kunden sowie Interessenten, die Informationen zur Funktionalität des Systems benötigen,
Ingenieure der Fachrichtungen Maschinenbau und Elektrotechnik sowie Informatiker als Entwickler der mechatronischen Komponen­ ten auf Hersteller- und Zuliefererseite sowie diejenigen, die 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ünftige 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 Sprachstandard 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 Funktionsarchitektur 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 Systemverbunds garantieren. Schließlich wird für die Elektronik eine Systematik angegeben, wie der Systemverbund mit bedarfsge­ recht optimierten 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:

• - Komponenten mit überwiegend koordinierenden und verteilenden Aufgaben,
• - Komponenten mit hauptsächlich operativen und ausführenden Aufgaben und
• - 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 Nichterfüllung 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 abgefragte 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 Pflicht zur Erfüllung ge­ koppelt, was beispielsweise bei konkurrierenden Anforderungen Berücksichtigung findet. Folgende Tabelle stellt die Struktu­ relemente zusammenfassend dar.

Die Strukturierungsregeln beschreiben erlaubte Kommunikationsbe­ ziehungen innerhalb der Architektur des Gesamtfahrzeugs. Es wer­ den Strukturierungsregeln unterschieden, die die Kommunikations­ beziehungen auf der gleichen Abstraktionsebene und in höhere und tiefere Ebenen unter Berücksichtigung angegebener Randbedingun­ gen regeln. Ferner klären die Strukturierungsregeln die Weiterleitung 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 entwic­ kelte Struktur zeichnet sich durch folgende Merkmale aus:

• - vereinbarte, einheitliche Strukturierungs- und Modellierungs­ regeln auf allen Abstraktionsebenen,
• - hierarchische Auftragsflüsse,
• - hohe Eigenverantwortung der einzelnen Komponenten,
• - Bedienelemente, Sensoren und Schätzer sind gleichwertige In­ formationsgeber und eine
• - Kapselung, die jede Komponente für die übrigen Komponenten so sichtbar wie nötig und so unsichtbar wie möglich dargestellt.

Fig. 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 moment_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 !rGang (Rückwärtsgang) vom Getriebe-Bedienfeld 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 Softwaresystems 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, grafischen 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 entwic­ kelten Object Oriented Software Engineering (OOSE). Die UML stellt dabei keine weitere, neue, universelle Methode dar, sondern ein Metamodell zur Konstruktion von Modellen auf verschie­ dene Sichten (Fig. 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 Konzepte 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 Schnittstellen zwischen diesen spezifiziert. Die Hinzufügung von 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 Fig. 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 Fig. 4 dargestellten 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.

Fig. 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_ga 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», «informationsgeber», «koor­ dinator» und «operator» werden die Komponentenklassen den oben eingeführten Kategorien zugeordnet. Die Komponente Umwelt aus Fig. 4 wird beispielsweise als Klasse mit dem Namen Umwelt und dem Stereotyp «informationsgeber» dargestellt.

Die drei CARTRONIC®-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 «anforderung» als UML-Operationen modelliert. Aus dem CARTRONIC®-Auftrag moment_ga wird die UML-Operation «auf­ trag» moment_ga der Klasse Antrieb, aus der CARTRONIC®-Abfrage ?drehzahl an diese Komponente die UML-Operation «abfrage» drehzahl sowie aus der CARTRONIC®-Abfrage ?luftdruck an die Kom­ ponente Umwelt die UML-Operation «abfrage» luftdruck der Klas­ se Umwelt. Bei der Darstellung in Fig. 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ückgabeparameter 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 strengeren Zugriffsregeln nach dem "Ein-Chef- Prinzip" werden hierdurch explizit modelliert. Fig. 6 zeigt dies am Beispiel der Klasse «operator» Antrieb.

Eine tiefer detaillierte CARTRONIC®-Komponente zeigt Fig. 7 am Beispiel der Komponente Antrieb, hier im Unterschied zu Fig. 2 jedoch nur mit den drei Teilkomponenten Motor, Antriebs- Koordinator und Getriebe. UML-Aggregationen drücken eine "ist Teil von"-Beziehung aus und entsprechen somit exakt einer CAR­ TRONIC®-Detaillierung. UML-Kompositionen drücken 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). Fig. 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 abstraktem Ni­ veau können analog zur Modellierung über UML-Klassen auch als UML-Subsysteme abgebildet werden. UML-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 enthaltenen Model­ lelementen ermöglichen die Weiterleitung von Nachrichten von den Subsystem-Schnittstellen direkt zu den entsprechenden Komponen­ ten. Wie in Fig. 9 gezeigt, kann eine Schnittstelle, hier «in­ terfaceAuftrag» IA_Antrieb, direkt durch die Schnittstelle eines internen Elements, hier «interfaceAuftrag» IA_Antriebs- 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 Fig. 6 die Operationen moment_ga und drehzahl der Klasse Antrieb. Fig. 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 Operationen «auftrag» moment_ma, «anforderung» rGang und «auftrag» einlegenGang. Zu beachten ist die Darstellung der Klasse Antrieb mit dem nunmehr leeren Operationsbereich sowie der Änderung des Stereotyps 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 kennen - sowie eine Abhängigkeit von Motor an die entsprechende Schnittstelle von Umwelt. Dies gilt analog für alle CARTRONIC®-Kommunikationsbeziehungen. Die explizite 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 Abb. 10 bleibt im Unterschied zu der in Fig. 6 dargestellten Kompo­ nente Antrieb eine "leere" Klasse (Fig. 11). Hierbei ergibt sich aber das Problem der Nicht-Sichtbarkeit der Beziehung zwi­ schen einer Teilkomponente von Antrieb und Umwelt. Deshalb er­ fordert das UML-Modell zusätzlich zur CARTRONIC®-Funktionsarchi­ tektur eine künstlich gesetzte Assoziation und Abhängigkeit zwi­ 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 (Fig. 12).

Ein Austausch mit erweiterter Funktionalität liegt vor, 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 ( Fig. 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 (Fig. 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) Konsistenzprüfung zur Sicherstellung erfolgen, dass keine weitere Komponente des Gesamtmodells die zu löschenden 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 "leere" überführt durch iterativen Wegfall ihrer Operationen.

Es wird also ein Verfahren und Vorrichtung zur Modellierung ei­ nes mechatronischen Systems in einem Kraftfahrzeug im Rahmen ei­ nes objektbasierten Ordnungskonzepts 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 Softwareentwicklungs­ prozess dar. Die Elemente der CARTRONIC® mit Komponenten und Hül­ len als ihren Klassen beziehungsweise Objekten und Aufträgen (mit Rückmeldung), Abfragen (mit Hinweis) und Anforderungen als ihren Kommunikationsbeziehungen sind an Hand von Beispielen zusammen 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 implizite 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.

Claims (7)

1. Verfahren zur Modellierung eines mechatronischen Systems in einem Kraftfahrzeug, wobei das mechatronische System aus mehreren Komponenten besteht, zwischen denen vorgegebene Kommunikationsbeziehungen bestehen, dadurch gekennzeichnet, daß die Komponenten und Kommunikationsbeziehungen zwischen den Komponenten im Rahmen einer objektorientierten Modellie­ rungssprache dargestellt werden.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die objektorientierte Modellierungssprache die unified mode­ ling language ist.

3. Verfahren nach einem der vorhergehenden Ansprüche, da­ durch gekennzeichnet, daß auf der Basis der dargestellten Komponenten und Beziehungen das Softwaredesign erstellbar ist.

4. Verfahren zur Modellierung eines mechatronischen Systems in einem Kraftfahrzeug, wobei das mechatronische System in mehrere Komponenten zwischen denen vorgegebene Kommunikati­ onsbeziehungen wie Abfrage, Aufforderung und Auftrag beste­ hen, gegliedert ist, dadurch gekennzeichnet, daß eine Abbildungsvorschrift vorgesehen ist, mit der die Komponenten und Beziehungen des Systems in Konstrukte einer objektorientier­ ten Modellierungssprache, vorzugsweise der UML-Sprache, um­ gesetzt werden.

5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass die Abbildungsvorschrift darin besteht, dass die Komponenten einschließlich -Hüllen als UML-Klassen beziehungsweise -Objekte mit den Stereotypen «koordinator», «operator», «informationsgeber» und «huelle» abgebildet werden, die Kommunikationsbeziehungen Abfrage und Anforderung als UML- Operationen mit den Stereotypen «abfrage» und «anforde­ rung» in Schnittstellen mit dem Stereotyp «interface» be­ reitgestellt werden und alle Auftragsoperationen durch den Stereotypen «auftrag» in Schnittstellen mit Stereotyp «interfaceAuftrag» gekennzeichnet werden.

6. Vorrichtung zur Modellierung eines mechatronischen Systems in einem Kraftfahrzeug, welches aus mehreren Komponenten be­ steht, zwischen denen vorgegebene Kommunikationsbeziehungen bestehen, dadurch gekennzeichnet, dass die Komponenten und Kommunikationsbeziehungen zwischen den Komponenten im Rahmen einer objektorientierten Softwaresprache dargestellt sind.

7. Vorrichtung zur Modellierung eines mechatronischen Sy­ stems in einem Kraftfahrzeug, welches aus mehreren Komponen­ ten besteht, zwischen denen vorgegebene Kommunikationsbezie­ hungen bestehen, gekennzeichnet durch eine Abbildungsvor­ schrift, mit der die Komponenten und Beziehungen des Systems in Konstrukte einer objektorientierten Modellierungssprache, vorzugsweise der UML-Sprache, umgesetzt werden.