EP1268996A2 - Verfahren und vorrichtung zur modellierung eines mechatronischen systems in einem kraftfarhzeug - Google Patents

Verfahren und vorrichtung zur modellierung eines mechatronischen systems in einem kraftfarhzeug

Info

Publication number
EP1268996A2
EP1268996A2 EP01915011A EP01915011A EP1268996A2 EP 1268996 A2 EP1268996 A2 EP 1268996A2 EP 01915011 A EP01915011 A EP 01915011A EP 01915011 A EP01915011 A EP 01915011A EP 1268996 A2 EP1268996 A2 EP 1268996A2
Authority
EP
European Patent Office
Prior art keywords
components
uml
modeling
language
relationships
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.)
Ceased
Application number
EP01915011A
Other languages
English (en)
French (fr)
Inventor
Pio Torre Flores
Juergen Schirmer
Michael Walther
Holger Huelser
Torsten Bertram
Marc Heckes
Joerg Petersen
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Robert Bosch GmbH
Original Assignee
Robert Bosch GmbH
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Robert Bosch GmbH filed Critical Robert Bosch GmbH
Publication of EP1268996A2 publication Critical patent/EP1268996A2/de
Ceased legal-status Critical Current

Links

Classifications

    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
    • B60R16/02—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
    • B60R16/023—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements for transmission of signals between vehicle parts or subsystems
    • B60R16/0231—Circuits relating to the driving or the functioning of the vehicle
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B62—LAND VEHICLES FOR TRAVELLING OTHERWISE THAN ON RAILS
    • B62D—MOTOR VEHICLES; TRAILERS
    • B62D65/00—Designing, manufacturing, e.g. assembling, facilitating disassembly, or structurally modifying motor vehicles or trailers, not otherwise provided for

Definitions

  • the invention relates to a method and device for modeling a mechatronic system in a motor vehicle.
  • One approach to solving the partially diverging requirements is to link the individual systems, which are largely independent of one another, to form a vehicle-wide network system and to logically combine system components into functional units with standardized interfaces.
  • the system association offers the possibility of a cooperation and multiple use of sensors and actuators and thus a utilization of emergent functions.
  • Networking also enables a change from purely function-oriented implementations to configurations in which the application functions are mapped to networked control devices.
  • dynamic relocations from functions to other systems can be supported.
  • the V-Mod ⁇ ll describes a procedure in which the specification and design process are characterized by detail and refinement, and which can be illustrated as a top-down procedure.
  • the verification and validation phases are botto-up procedures.
  • the essential requirement and prerequisite for quality certifications are detailed documentation requirements for each individual phase.
  • the order concept developed on the basis of object-based principles enables the logical combination of system components into functional units with standardized logical interfaces.
  • the description of the networking of the previously largely independently working individual systems of a motor vehicle to form a vehicle-wide network system thus represents a (meta) model for a modularly expandable functional, safety and electronic architecture
  • CARTRONIC * is an organization concept for all control and regulation systems of a vehicle.
  • the concept contains modular, expandable architectures for "function”, “security” and “electronics” on the basis of agreed formal structuring and modeling rules.
  • An architecture is to be understood here both as the structuring system (rules) and its implementation in a concrete structure.
  • the functional architecture encompasses all control and regulation tasks occurring in the vehicle.
  • the tasks of the system association are assigned to logical components, the interfaces of the components and their interaction are defined.
  • the security architecture extends the functional architecture by elements which guarantee secure operation of the system association.
  • a system is specified for the electronics, such as how to implement the system network with hardware topologies optimized as required.
  • the elements of the architectures are components and communication relationships on the one hand and structuring and modeling rules on the other.
  • the term component does not necessarily mean a physical unit in the sense of a component, but is understood as a function response.
  • the structuring rules describe permitted communication relationships within the architecture of the overall vehicle. There are structuring rules that regulate the communication relationships on the same level of abstraction and m higher and lower levels taking into account the specified boundary conditions.
  • These model rules contain patterns that combine components and communication relationships for the solution of special, multiple tasks. These patterns, for example energy management, can then be reused at various points within the structure of the vehicle.
  • FIG. 2 shows an example of the architecture features and the permitted communication relationships. These are in detail - for simplicity, only the order, query and request are discussed, but what is meant is the relationship that is possible in each case.
  • the various software methods used for the object-specific software development contain a graphic notation developed specifically for the respective method ect Mod ⁇ lmg T ⁇ chnique (OMT) and the Ob ⁇ ct Oriented Software Engineering (OOS ⁇ 'developed under Ivar acobson.
  • OOS ⁇ Ob ⁇ ct Oriented Software Engineering
  • D e UML does not represent another, new, universal method, but but a measurement or construction for the construction of models on different views (FIG. 3). It represents a graphic and supplementary tabular and textual notation with uniform syntax and clearly defined semantics.
  • CARTRONIC * -Mod ⁇ ll ⁇ emerges as a preformally structured specification of what the mechatronic system should achieve.
  • These models represent an object-based abstraction of the functional, logical concepts from the vehicle system structures.
  • the change from the analysis to the design and design phase takes place at the same time.
  • Basics for the overall architecture of the software system are laid, partial systems for reduction or manageability of the comolexity, and clean interfaces between see this specified.
  • the addition of more and more details leads in the progressing design process towards implementation.
  • the aim of the design or draft phase is to determine the system components, their structure and interfaces with the definition of the underlying logical data model, including the data and algorithmic structures, and their validation.
  • the structuring also relates to the selection of appropriate program modules for the algorithmic formulation with the aim of optimizing the required performance characteristics of the system (structure in the gills).
  • the aim of the implementation phase is to transmit the logical data model, the system architecture and algorithms translatable program code for the individual control units and the communication network in the motor vehicle.
  • FIG. 4 shows the CARTRONIC * components environment, drive, vehicle coordinator and electrical on-board electrical system.
  • the vehicle coordinator asks the drive for the current speed or commanded the drive to provide a moment to the transmission output
  • Drive asks the information provider for the environment for the current? Air pressure and requests! El_Le ⁇ stung from the component electrical system.
  • Classes with object-oriented terminology are usually the generalization of similar objects (templates), on higher levels of abstraction components are> or classes of rarely material objects, but mostly abstract structures or functional units.
  • Objects generally objects
  • Objects are copies of classes with properties and behavior.
  • object-oriented modeling a frequently used entry point in the search for classes is the search for nouns, since in the language in general this forms the generalization of object groups.
  • Adjectives describe properties and are usually modeled as attributes. Operations, in turn, represent the behavior of oojjects, so they correspond to the verbs. It therefore makes sense to represent the CARTRONIC £ components as UML classes and as UML-Ot> je ⁇ t ⁇ .
  • FIG. 7 shows a more detailed CARTRONIC * component at the example of the component drive, but in contrast to FIG. 2 only with the three sub-components motor, drive coordinator and transmission.
  • UML aggregates express a "is part of" relationship and thus correspond exactly to a CARTRONIC e detail.
  • UML compositions express as a special case of UML aggregations in analogy to from that parts without the aggregate have no stock.
  • the UML aggregate and UML composition as a logical whole (automatically) delegate messages that they receive but cannot carry out themselves to the corresponding subcomponent (analogy to the CARTRONIC ⁇ shell property).
  • FIG. 8 shows the partially detailed UML class ⁇ cover >> drive as a UM composition of the UML classes motor, drive coordinator and transmission.
  • UML subsystems are a special form of UML packages that may have interfaces and are therefore suitable for ensuring meaningful encapsulation and structural mapping on a large scale.
  • the separate interfaces for orders or queries and requests remain as similar as the procedure steps presented below.
  • Connections in the form of an aggregation or composition between the subsystem and the model elements contained therein enable messages to be forwarded directly from the subsystem interfaces to the corresponding components. As shown in FIG.
  • an interface here ⁇ m- t ⁇ rfac ⁇ order >> IA_Antneb, can directly through the interface n ⁇ s internal element, here ⁇ mterfac ⁇ Avem >> IA_Antr ⁇ ebs- coordinator, o ⁇ r ⁇ itn.
  • deletion of a component can be regarded as a special form of exchange with falling functionality.
  • one of the previous classes becomes an "empty" one due to the iterative elimination of its operations.
  • CARTRONIC 'components including envelopes, are mapped as UML classes or relationships - whether files with the star types ⁇ coordinator>>, ⁇ operator >>, ⁇ m-format onsender >> and ⁇ hull >>.
  • This CARTRONIC * - communication relationship Query and request are provided as UML options with the stereotypes ⁇ query >> and ⁇ request >> m interfaces with the stereotype ⁇ mterface>>, all job operations are provided by the stereotype ⁇ order>> interfaces with the stereotype «interface order >> Messages arriving in a detailed component are automatically delegated to the component components responsible for the composition components.

Landscapes

  • Engineering & Computer Science (AREA)
  • Mechanical Engineering (AREA)
  • Automation & Control Theory (AREA)
  • Manufacturing & Machinery (AREA)
  • Chemical & Material Sciences (AREA)
  • Combustion & Propulsion (AREA)
  • Transportation (AREA)
  • Stored Programmes (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Control Of Electric Motors In General (AREA)
  • Automobile Manufacture Line, Endless Track Vehicle, Trailer (AREA)
  • Train Traffic Observation, Control, And Security (AREA)

Abstract

Es werden ein Verfahren und eine Vorrichtung zur Modellierung eines mechatronischen Systems in einem Kraftfahrzeug im Rahmen eines objektbasierten Ordnungskonzepts 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

Verfahren und Vorrichtung zur Modellierung eines mechatroni- schen Systems in einem Kraftfahrzeug
Stand der Technik
Die Erfindung betrifft ein Verfahren und Vorrichtung zur Modellierung eines mechatronischen Systems in einem Kraftfahrzeug .
Die Forderung nach mehr Sicherheit, Wirtschaftlichkeit, Komfort sowie einer besseren ümweltverträglichkeit lässt die Mechatronik im Fahrzeug zu einem immer bedeutenderen und wettbεwerbsbεstim- menderen Faktor werden. Wirtschaftliche FahrZeugentwicklungen und die Beherrschung komplexer Syste strukturen bei immer kürzer werdenden Produktzyklεn erzwingen durchgängige, möglichst weit automatisierte, rechnerunterstützte Entwicklungsprozesse. In der Analysephase können auf der Basis vereinbarter formaler Struktu- rierungs- und Modεilierungsrεgeln des automobilherstεller- und zuliefererneutralen Crdnungskonzepts Cartronic modularε, erwei- tεrbarε Architekturen für „Funktion", „Sicherheit" und „Elektronik" spezifiziert werden. Die Forderung nach mehr Sicherheit, Wirtschaftlichkeit, Komfort und einer besseren Ümweltverträglichkeit lässt die Mechatronik im Fahrzeug zu einem immer bedeutεndsren und wettbewerbsbestim- mεnderen Faktor im Technologiewandεl von der Mechanik über die Elektronik zur Informationstechnik werden. Bei ständig scεigen- der Komplexität der Systeme und gleichzeitig immer kürzer werdenden Produktzyklen bleibt der Kosten- und Ξntwicklungsaufwand nur bei Einsatz eines durchgängigen, möglichst weit automatisierten, rechneruntεrstützten sowie weitgehend parallelisiεrten Arbeits- und Entwicklungsprozesses beherrschbar .
Ein Ansatz zur Lösung der teilweise divergiere iεn Anforderungen ist die Vernetzung der bishεr weitgehend unabhängig voneinander arbeitεndεn Einzεlsysteme zu einem fahrzeugweiten Verbundsystem und die logische Zusammenfassung von Systemkomponentεn zu funk- tionalεn Einheiten mit standardisierten Schnittstellen. Der Sy- stemvεrbund bietet die Möglichkeit einer Kooperation und Mehrfachnutzung von Sensorik sowiε Aktuacorik und somit εiner Nutzbarmachung emergεntεr Funktionen.
Die Vernetzung ermöglicht darüber hinaus einen Wandel von rein funktionsorientierten Rεalisiεrungεn zu Konfigurationen, bei denen die Anwεndungsfunktionen auf vernetztε Stεuεrgeräte abgεbil- dεt werden. Außerdem können bei partiellen Systemausf llen dynamische Vεrlagεrungεn von Funktionεn auf andere Systemε unterstützt werden.
Ausgehεnd von dεn logischεn Funktionseinheiten mir ihren standardisierten Schnittstellen wird es ebenfalls möglich, Funktionεn unterschiεdlichεn Ursprungs, verschiedener Auromobilherstel- lεr und Zuliefεrεr, miteinander zu vernetzen. Ein Funkrionslie- ferant muss hierbei garantieren, dass die Funktion auch bei Ver- tεilung auf mehrere vernεtzte Steuergeräte diε geforderte Spezifikation einhält.
Diε Entwicklung komplexer, vernεtztεr Systeme setzt einen systε- matischεn Prozεss mit rεkursivεn Phasεn und den Einsatz rechner- gestütztεr Wεrkzeuge voraus, bεi dεm sowohl der Automobilhεr- stεllεr als auch der Zuliεferer alle Anforderungen und Randbe- dingungεn an die zu entwickelnde Funktion formulieren, die vielfältigen Interaktionen mit anderεn Funktionεn und der Umgebung in allen Anwendungs- und Fehlerfällen analysieren und die Funktion in ihrer Auswirkung auf die Sicherheit des GesamtVerbunds bewerten kann. Für diε Entwicklung von kompiεxεn, vεrnetztεn Systemen hat sich das V-Modell als Vorgεhensmodell auch in dεr Au- tomobilbranchε εtabliert. Das V-Modell sieht vor, dass sämtliche Aktivitäten und Abläufe zur Funktionsentwicklung in elf Phasen eingeordnet werdεn können (Figur 1) .
Das V-Modεll beschreibt ein Vorgehen, bei dεm der Spezifika- tions- und Entwurfsprozess durch diε Detaillierung und Verfeinε- rung charaktεrisiεrt sind und das sich als top-down- Vorgehensweisε vεranschaulichen lässt. Dagegen sind die Verifi- kations- und Validierungsphasen botto -up-Vorgεhεnsweisen. We- sεntlichε Anfordεrung und Voraussetzung für QualitätsZertifizierungen sind hierbei detaillierte Dokumentationsuntεrlagεn für jεdε εinzεlnε Phase.
Um den Forderungen nach einer wirtschaftlichen Fahrzeugentwicklung, dεr Beherrschung komplexεr Systemstrukturen und einer adäquaten Dokumentation gerεcht wεrdεn zu könnεn, wurdε das Ord- nungskonzεpt Cartronic (siεhe Bertram, T. , R. Bitzer, R. .Mayer und A. Volkart, 199S, CARTRONIC - An open architεcture for nεt- workmg the control Systems of an automobile, Detroit/Micmgan
U.Ξ.A., SAE 9B200, 1-9) entwickεlt
In der ersten Phase der Prozesskεttε, dεr Analyse, ermoglicnt das auf obj ektbasierεnden Grundgedanken entwickelte Ordnungskon- zεpt die logische Zusammenfassung von Systemkomponentεn zu funk- tionalεn Einhεiten mit standardisierten logischen Schnittstellen. Die Bεscnreibung der Vernetzung der bisher weitgεhend unabhängig voneinander arbeitendεn Einzelsysteme eines Kraftfahrzeugs zu einem fahrzeugwεitεn Vεrbundsystem stellt somit ein (Meta-) Modell für eine modular erwεitεrbare Funktions-, Sicher- hεits- und Elεktronikarchitektur dar Ein wesentlicher Vorteil dieser automobilhersteller- und zuliefεrneutralen Spezifikati- onsmoglichkeit ist die nach kurzer Einarbeitungszeit allen am Entwicklungsprozess Beteiligten verständlichε, logischε Beschreibung der Anforderungen schon zu einem sehr frühen Entwicklungszeitpunkt .
Grafikbasierte Modelle unterstützen als wεsεntlichε Dokurnεntati- onsεlemεntε wahrend aller Entwicklungsonasen eine Komraumκatιon zwischen allen an dεr Entwicklung beteiligten Pεrsonεn sowiε nach Abschluss dεr Entwicklung die Pflege und Weiterentwicklung. Ergänzend zum klassischen Softwareengmeεπng sind dabei für me- chatronischε Systementwicklungen im Kraftfanrzeugbereich als Pεrsonεngruppεn zu unterstützen
Fanrzeughεrstellεr als Benutzer/Kunden sowie Interessenten, die Informationen zur Funktionalität αεs Systems benötigen, Ingenieure der Fachrichtungen Maschinenbau und Elektrotechnik sowie Informatiker als Entwickler αer echatronischεn Komponenten auf Hersteller- und Zulieferεrsεi e sowie diejεnigεn, die diese nach angeschlossener Entwicklung mod fizierεn bεzienungs- wεise erweitern werden und dazj Verständnis des Gesamtsystems oder seiner Teile benotigen, Manager auf Entwickler- und Kunden- sεitε, diε organisatorischε und wirtschaftlichε Einzelheiten zur Projεktkontrollε, Berechnung von Kosten und Informationen für zukunftige Projekte und Entwicklungen benot gen sowie nicht zuletzt die Fahrzeugfuhrer als spezielle Endbenutzεr, diε mit ausgewählten Funktionalitäten des Systems vertraut gemacht werden müssen
Ein wesεntlicner Schritt am Ende dεr Analysε- und zu Beginn der Designphase ist die Abbildung dεr m Cartronic εntwickεlten Spe- zifikationsmodelle einen informationstechnischen Entwurf für die Sof wareεntwicklung . Diese Abbildung tragt zur Erhonung der Informationsdichte und der Erweiterung des semantischen Gehalts aufgestelltεr Cartronic-Modellε bei, definiert Teilsysteme einer Gesamtsystemarchitektur, erhöht die Transparenz des Gesamtsystems in Zielrichtung dεssεn Implementierung und schafft wesentliche Grundlagen für eine verteilte Entwicklung und Test- barkeit von mechatronischen Systεmen
Vorliegend wird eine Abbildung von m CARTRONIC6 erstεllten Spε- zifikationsmodellen m eine standardisierte objektorientierte Darstellung vor dem Hintergrund einer möglichst wεitgehεndεn Unterstützung durch kommerziell verfügbare Softwarε-Entwicklungs- Werizeuge beschrieben Eine dafür erforderlicne geeignete Notation stellt der von der Object Management Group (OMG) international standardisierte, objektorientierte Spracnstandard der Unified Modelmg Language (UML) dar.
Im folgenden wird eine zusammenfassendε Bεscnrεibung αεr Struk- turelεmente und formalen Stru tuπerungs- sovvie Modellier/ungsre- geln nach CARTRONIC1 für Funktionsarchitεkturεn gegeben Ferner wird, auf einer hohen Abstraktionsebεne eine Funktιonsarcnιte tur dεs Gesam fahrzeugs mit einer Detaillierung für die Komponente Antrieb vorgestellt. Davon ausgehend erfolgt zunächst die Darstellung theoretischer Grundlagen der Modellierung, bevor auf die verwendeten Elemεntε der objektoriεntiertεn Notation mit UML im wεiteren Vεrlauf diεses Abschnitts eingegangen wird. Die Vorgehensweise für das vorhandenε Modell nach CARTRONIC* wird an einem Beispiel aufgezeigt.
Ein bereits in heutigen Fahrzeugen existierendes Beispiεl für εinεn Systεmvεrbund ist die Antriebsschlupfrεgelung. Diese wird erst durch diε Kommunikation des Steuεrgεräts für die Antriebsschlupfrεgelung mit dem Stεuεrgerät für das Motormanagement zur Regεlung dεs Antriεbsmoments möglich.
CARTRONIC* ist ein Ordnungskonzεpt für alle Steuεrungs- und Regelungssysteme eines Fahrzeugs. Das Konzept enthält modulare erweiterbare Architekturεn für „Funktion", „Sicherhεit" und „Elektronik" auf dεr Basis vereinbarter formaler Struktuπerungs- und Modεllierungsregeln .
Unter einer Architektur ist hier sowohl die Strukturierungssy- stematik (Regeln) zu verstehen als auch deren Umsetzung m einε konkrete Struktur. Die Funktionsarchitektur umfasst sämtliche im Fahrzeug vorkommenden Steuεrungs- und Regεlungsaufgaben. Die Aufgaben des Systemvεrbunds werden logischen Komponenten zugeordnet, die Schnittstellen der Komponenten und ihr Zusammenwirken werden festgelegt. Die Sicherheitsarchitεktur erweitεrt die Funktionsarchitektur um Elemente, die einen sichεrεn Betrieb des Systemvεrbunds garantieren. Schließlich wird für die Elektronik eine Systematik angegeben, wie dεr Systemverbund mit bedarfsgerecht optimierten Hardwarεtopologien zu realisiεrεn ist. Die Elemεnte der Architekturen sind Komponenten und Kommunikatl- onsbeziεhungen auf der einen und Strukturierungs- und Modellie- rungsrεgεln auf der anderen Seite. Im Rahmen der Strukturierung wird von einem System als einer Zusammenstellung von Komponenten zu einem Ganzen gesprochen, die über Kommunikationsbeziεhungen miteinander Wechsεlwirkungεn stεhen. Der Begriff Komponente meint nicht zwangsläufig eine physikalische Einheit im Sinne eines Bauteils, sondern wird als Funktlonse hεit verstanden. Bei dem Ordnungskonzept werden drei verschiεdene Typen von Komponenten unterschiedεn:
□ Komponεntεn mit übεrwiεgend koordinierenden und vertεilεnden Aufgaben,
O Komponenten mit hauptsächlich operativen und ausführenden Aufgaben und
Q Komponεnten, die ausschließlich Informationen generieren und bereitstellen.
Bei den Kommunikationsbeziehungεn wird zwischεn einem Auftrag (mit Rückmeldung) , einer Abfrage (mit Hinweis) und einer Anforderung untεrschiεdεn. Dεn Auftrag kennzeichnet die Pflicht zur Ausführung; für dεn Fall dεr Nichtεrfüllung muss der Auftragnεh- mer eine Rückmeldung an den Auftraggeber absetzen, die den Grund für die Nich ausführung beschreibt. Die Abfrage dient der Beschaffung von Informationen für eine Auftragsausführung. Für den Fall, dass eine Komponentε diε abgεfragtε Information nicht bε- reitstellεn kann, gibt sie einen Hinweis an die fragende Komponente. Eine Anforderung beschreibt einen „Wunsch", dass eine Funktion von einer anderεn Komponεntε ausgeführt wird. An diε Anfordεrung ist allerdings nicht die Pflicht zur Erfüllung gekoppelt, was beispiεlsweise bei konkurπεrεndεn Anforderungen Ber cksichtigung findet. Folgende Tanεliε stellt die Ξtruktu- relεmεntε zusammenfassend dar.
Die Strukturierungsregeln beschreiben εrlaubtε Kommunikat onsbeziεhungen innerhalb der Architektur des Gesamtfahrzeugs . Es werden Strukturiεrungsrεgεln untεrschiεdεn, die die Kommunikat10ns- bεziehungεn auf dεr gleichen Abstraktionsebεnε und m höhere und tieferε Ebenen unter Berücksichtigung angegεbener Randbedingungen regeln. Fεrnεr klären die Strukturierungsregeln d e Weitεr- leitung von Kommunikationsbeziehungen von einem System m ein andεrεs dessen Detaillierung hinein
Diε Modεlliεrungsregεln beinhalten Muster, die Komponenten und Kommumkationsbeziεhungen für die Losung speziεllεr, mεhrfach vorkommender Aufgaben zusammenf ssen Diese Muster, zum Beispiεl ein Energiemanagement, können dann an verschiεdenen Stellen innerhalb der Struktur des Fahrzeugs wiederverwendεt wεrden.
Eine nach den Strukturierungs- und Modellierungsrεgeln entwik- kεlte Struktur zeichnet sich durch folgendε Mεrkmalε aus:
□ vεrεinbartε, εinhεitliche Struktuπεrungs- und Modεlliεrungs- rεgεln auf allen Abstraktionsεbenen,
□ hiεrarchische Auftragsflüsse,
Q hohe Eigenverantwortung der einzelnen Komponenten,
□ Bedienεlementε, Sεnsoren und Schätzer sind gleichwertigε In- formationsgebεr und eine
□ Kapsεlung, diε edε Komponεntε für diε übrigen Komponenten so sichtbar wie nötig und so unsichtbar wie möglich dargestellt.
Figur 2 stellt beispiεlhaft diε Architεkturmεrkmalε und diε erlaubten Kommunikationsbeziεhungen dar. Dies sind im Einzelnen - der Einfachheit halbεr wird nur von Auftrag, Abfragε und Anforderung gεsprochεn, gemeint ist aber die Beziehung, die diesε jeweils ermoglichεn.
- dεr Auftrag momεnt_ga (Moment am Getriebeausgang bereitstel- lεn) , dεr von dεr Hülle Antrieo an die Eingangskomponente Antriebs-Koordinator wεitergεlεitεt wird, die gleichzeitig auch Koordinator ist,
- die Aufträge moment_ma (Moment am Motorausgang bereitstellen) , stelleKraftschluss und emlegenGang (einlegen eines Ganges) vom Antriebs-Koordinator an Motor Wandler und Gεtriεoe, - diε Anfordεrung IrGang (Rückwärtsgang) vom Getriebe-Bedienfeld an den Antriebs-Koordinator,
- die Abfragen ?zustand und ?luftdruck (der Umgenung) an Getriebe und Umwelt
- sowie die Abfragen ?gang (Rückwärtsgang oder nicht) und ?dreh- zahl an diε Hülle Antrieb, die diese an die zustandigen Kompo- nεntεn Motor und Gεtriebε weiterleitet.
Im klassischen Software-Lebenszyklus wεrdεn die strεng sequεnti- εll zu durchlaufenden Phasen Problemanalyse, Systemspεziflkati- on, Entwurf, Implementiεrung mit Komponenten-, Gesamttest und Einführung sowie Bεtriεb und Pflege eines Softwaresystεms unterschieden. In der Praxis ist ein solcher, streng sequentieller Entwicklungsprozess eine nicht einzuhaltende Idealisierung. Theoretisch klar abgrenzbare Punkte überlappεn sich oder sind unter Umständen unterschiedlich weit vorangeschπtten, glεich- zeitig schrεitet das Know-how auf Seiten aller am Entwicklungsprozess Beteiligten mit der Systementwicklung weitεr voran. Eine ob ektoπentiεrtε Vorgehensweise ermöglicht ein phasenübergrei- fεndεs Vorgεhen mit von Anfang an hoher Wieαervεrwεndbarkeit bereits entwickelter neziehungsweise vorhandener Anteile und Kon- zεptε. Diεs wird durch die Verwendung einer rechneruntεrstütz- tεn, grafischεn Notation wεsεntlich εrlεichtεrt. Diε der ob- jεktoπεntiεrtεn Softwarεεntwicklung eingesetzten verschiedεnεn mεthodischεn Vorgεnεnswεisεn beinhalten eine speziεll für die jewεiligε Mεthodε entwickelte grafische Notation Die UML ist hervorgegangen aus den drei m der industriellen Softwareentwicklung meist vεrwεndεten Methoden, der Booch-Metnodε benannt nach Grady Booch, dεr unter James Rumoaugh entwickelten Ob ect Modεlmg Tεchnique (OMT) sowie dem unter Ivar acobson εntwik- kelten Ob εct Oriented Software Engineering (OOSΞ' . D e UML stellt dabei Keine weitere, neue, universellε Methode dar, son- dern ein Mεta odεll zur Konstruktion von Modellen auf verschiedene Sichten (Figur 3) . Sie stellt einε grafische und ergänzend tabellarische und tεxtuelle Notation mit einheitlicher Syntax und eindeutig definiεrter Semantik dar.
Entwickelte UML-Modεllε sind von allen am Entwicklungsprozess betεiligtεn Personen eindeutig interpretierbar und bieten als wesεntliche Vorteile:
- die Vεrwεndung eines internationalεn Standards,
- eine möglichst herstellerunabhängigε, toolunterstütze Vorgehensweise,
- eine Aufweichung der starren Einhaltung der klassischen Hin- tereinandεrabfolgε von Analyse- und Designphase bεi der Softwa- reεntwicklung ohnε Aufgabε des Software-Lebenszyklus -Modells als Grundlage einer ingεniεurmäßigεn top-down-Vorgεhεnswεise,
- möglichst weitgehεndε Unabhängigkeit von dεr lεtztεndlich verwendeten Programmiersprache auf der logischen Ebene,
- die Erhaltung dεr Konsistenz zwischen Analysε, Dεsignentwurf und Implementierung, sowie
- die Möglichkeit εinεr glεichzεitigεn bottom-up Reverse- Engineεring-Vorgehensweise .
In der Analysephasε εntstehεn CARTRONIC*-Modεllε als eine präformal strukturiertε Spezifikation, was das mεchatronischε System leisten soll. Diese Modelle stellen einε objektbas iεrte Abstraktion der funktional logischen Konzepte aus den Fahrzeug- systemstrukturen dar. Durch eine geeignete Abbildung in ein weitaus mächtigerεs UML-Modεll findεt gleichzeitig der Wechsel von der Analyse- in die Design- und Entwur sphase statt. Dabei werden Grundlagen für die Gesamtarchitektur des Sof warεsystεms gelegt, Tεilsystεmε zur Reduktion beziehungsweise Behεrrschbar- kεit der Komolexität dεfiniεrt und saubere Schnittstellen zwi- sehen diesen spezifiziert. Die H zufugung von mehr und mehr Details führt im fortschreitenden Entwurfsprozεss m Richtung Implementierung. Das Ziel der Design- beziehungsweise Entwurfspha- se bestεht der Festlegung der Systemkomponεntεn, derεn Aufbau und Schnittstellen mit der Definition des zugrundeliegendεn logischen Datεn odells einschließlich der Daten- und algorithmi- schen Strukturεn sowie deren Validierung. Komplexität ist durch Abstraktion zu bewältigεn, wobεi sowohl die Einfachheit als auch Überschaubarkeit des Ganzen gewährleistet sein muss (Strukturierung im Großen) . In späterεn Schritten bezieht sich die Strukturierung eoεnso auf diε Auswahl angemεssεnεr Programmbausteine bei dεr algorithmischεn Formulierung mit dem Ziel einer Optimierung der gεfordertεn Leistungsεigεnschaften dεs Systems (Struk- tuπεrung im Kiemen) . Das Ziel der Implemεntierungsphase besteht m der Übεrtragung das logischen Datenmodells, der System- architεktur und Algorithmεn übersetzbaren Programmcode für die einzεlnen Stεuergerätε und das Kommunikationsnetzwerk im Kraftfahrzeug.
Zeichnung
Die Erfindung ist anhand der m den Figuren 1 bis 14 dargε- stellten Ausführungsformen näher erläutert.
Beschreibung von Ausführungsbeispielen
Im Folgεndεn wird die Abbildung dεr Cartron c-Elemente UML- Eiεmεntε anhand dεs m Figur 4 dargestellten Ausschnittes vorgestellt. Wesentliche Überlegungen sind hierbei, die CARTRONIC*- Rεgεln möglichst komplεtt zu unterstützen, d e Grundgedanken dεr Ob εktorientierung zu wahren und daoei für den CARTRONIC1- Modelliεrer verständlich genug und ausreichεnd transparεnt zu bleiben, sowie alle notwendigen Informationen für spatere Ar- bεitsschrittε aufnehmen und darstellen zu können.
Figur 4 zeigt die CARTRONIC*-Komponenten Umwelt, Antrieb, Fahrzeug-Koordinator und Elektrisches Bordnetz Zwischen diesεn Komponenten bestehen folgendε Kommunikationsbεz εhungen: Dεr Fahrzeug-Koordinator befragt den Antrieb nach dεr aktuellεn ?αreh- zahl beziεhungsweise beauftragt dεn Antrieb ein moment_ga am Getriebeausgang berεitzustellεn Der Antrieb befragt den Informa- tionsgeber Umwelt nach dem aktuellen ?luftdrucκ und fordert !el_Leιstung von dεr Komponεnte Elektrisches Bordnetz an.
Klassen m dεr objektorientiertεn Terminologie sind in der Regel die Gεnεralisierungεn glεichartigεr Objekte (Schablonen) , auf höhεrεn Abstraktionsebenen sind Komponenten £>eziehungsweise Klassen seltεnεr materielle Gegenstände, sondern meistens abstrakte Gebildε oder Funktionseinheiten. Objekte (im Allgemeinen Gegenstandε) sind Exemplare von Klassen mit Eigenschaften und Verhalten. In der objektorientierten Modelliεrung ist em häufig genutzter Einstieg bei der Suche nach Klassen die Suche nach Substantiven, da diesε m dεr Sprache im Allgεmεinεn diε Genera- lisiεrung von Ob ektgruppen bilden. Adjektive Beschreiben Eigenschaften und werdεn m der Regel als Attribute modelliεrt Ope- rationεn wiεdεrum bildεn das Verhaltεn von Oojekten ab, entsprechen also den Verbεn Es liegt deshalb nahe, die CARTRONIC£- Komponenten als UML-Klassεn Deziehungsweise UML-Ot>jeκtε darzu- stεllεn.
Über die Sterεotypεn <<huεlle>>, <<mformatιonsgebεr>>, «<κoor- dmator» und <<opεrator>> wεrdεn die Komponentenklassen αen onen eingeführten Kategorien zugeordnεt D ε Komponεntε Jmwelt aus Figur 4 w rd beispiεlswεisε als Klassε mit dεm Namen Umwelt und dem Ξterεotyp <<mformatιonsgεbεr>> dargestellt.
Die drei CARTRONIC^-Kommunikationsarten Auftrag, Abfrage und Anforderung fordern anderε Komponenten auf, „etwas zu tun" - in objεktoπεntiεrter Modεlliεrung wεrdεn diεsε deshalb als Nachrichten interprεtiεrt und mit dεn Stεreotypen <<auftrag>>, <<ab- fragε>> und <<anforderung>> als UML-Operationen modelliεrt . Aus dεm CARTRONIC*-Auftrag moment_ga wird d e UML-Opεration <<auf- trag>> moment_ga dεr Klassε Antrieb, aus dεr CARTRONICβ-Abfragε ?drεhzahl an diesε Komponεntε diε UML-Opεration <<abfragε>> drehzahl sowie aus dεr CARTRONIC"-Abfragε ?luftdruck an die Komponente Umwεlt diε UML-Opεration <<abfrage>> luftdruck der Klasse Umwelt. Bei der Darstellung m Figur 5 symbolisiert die doppelte Linie in den Klassen Antriεb, Elektrischεs Bordnetz und Umwelt, dass bislang noch keine Attribute vorhanden sind. Bei dεr Klasse Fahrzeug-Koordinator wird auf die Darstεllung eventuell vorhandenεr Attπbutε odεr Operationen ganz verzichtet und nur der Deklarationsbereich der Klasse abgebildet. Dies ergibt ein übersichtlicheres Diagramm. CARTRONIC*-Rückmeldungen können als Rückgabεparamεtεr von UML-Operationen odεliiεrt wεrden und sind deshalb bεi dεr Abbildungsvorschrift nicht explizit als eigenständige UML-Operationen modelliεrt.
Diε Kapsεlung dεr einzelnen Komponenten mit dεm Ziel einer definierten Zugriffsregelung und -Kontrolle wird über εxpli- zite UML-Schnittstellen für die UML-Operationen modelliert. Es wird zwischen Schnittstellen für Aufträge sowie Abfragen und Anforderungen unterschieden mit den bεidεn Stεreotypen <<intεrfaceAuf rag>> und <<mter ace». Die für Aufträge geltεndεn strengeren Zugriffsregeln nach dem „E -Chef- Prinzip" werden hierdurch explizit modelliert. Figur 6 zeigt dies am Bεispiεl der Klasse <<operator>> Antrieb.
Eine tiefεr detaillierte CARTRONIC*-Komponente zeigt Figur 7 am Beispiεl dεr Komponεnte Antrieb, hiεr im Unterschied zu Figur 2 jedoch nur mit dεn drei Teilkomponenten Motor, Antriebs- Koordinator und Getriebe. UML-Aggregatlonen drücken einε „ist Teil von"-Beziεhung aus und entsprechen somit exakt einer CAR- TRONICe-Detaillιerung. UML-Kompositionεn drücken als Spezialfalle von UML-Aggregationen analog zum aus, dass Tεilkomponεnten ohne das Aggregat kεinεn Bεstand haben. UML-Aggregat und UML-Komposition als logisches Ganzes delεgieren (automatisch) Nachrichten, die sie erhalten, aber selber nicht ausführεn könnεn, an die entsprεchendε Teilkomponεnte (Analogie zur CARTRONICΦ-Hülleneigenschaft) . Figur 8 zeigt die teil εise detaillierte UML-Klasse <<huεlle>> Antrieb als UM -Komposition der UML-Klassen Motor, Antriεbs-Koordinator und Gεtriebe.
Große komplexε CARTRONIC*-Komponenten auf hohem abstrakten Niveau können analog zur Modellierung über UML-Klassen auch als UML-Subsysteme abgεbildet werden. UML-Subsystemε sind eine Sonderform von UML-Paketen, die Schnittstellen bes tzεn dürfen und deshalb geeignet sind, eine sinnvolle Kapselung und Strukturabbildung im Großen zu gewährlεisten. Die separaten Schnittstellεn für Aufträgε beziehungsweise Abfragen und Anforderungen bleiben dabei εbεnso εrhaltεn wie analog diε im Folgenden vorgestεllten Vorgehensschritte. Verbindungen in Form einer Aggregation oder Komposition zwischen dem Subsystem und darin enthaltenen Model - lelemεntεn ermöglichen die Weitεrlεitung von Nachrichten von den Subsystem-Schnittstellen direkt zu den entsprechenden Komponenten. Wie Figur 9 gezεigt, kann eine Schnittstelle, hier <<m- tεrfacεAuftrag>> IA_Antneb, direkt durch die Schnittstelle ei- nεs internen Elements, hier <<mterfacεAuf rag>> IA_Antrιebs- Koordmator, oεrεitgestellt werdεn.
Diε ständige Weiterentwicklung der CARTRONIC*-Modellε erfordert Vεrändεrungs - und Austauschmöglichkeiten von Komponenten. Neben der im vorhergehenden Teilabschnitt beschriebεnεn Abbildung einzelner CARTRONIC*-Elεmεnte in die UML müssen die Schritte und Vorgänge im fortlaufendεn Entwicklungsprozess unterstützt werden. In dεr Praxis traten hierbei Mischformen der nachfolgend unterschiedenen Vorgεhensschrittε auf. Diεse setzεn sich zusammen aus der Dεtailliεrung, dεr Abstraktion, dem Ersetzen sowie dεm Löschεn von Elementεn.
Bei der Detaillierung einer CARTRONIC*-Komponεntε entsteht nach dem CARTRONIC*-Regelwεrk einε Hülle ohne eigene logische Funktionen, alle bεreits bεkanntεn, εxistierendεn Funktionalitäten werden auf die εntstehenden Teilkomponenten verteilt. Die Kapselung beziεhungsweise die Ξchnittstεllen der zu detailliεrεnden Komponentε müssen vollständig in der Hülle erhalten bleibεn, um das Verhalten nach außen nicht zu verändern. Dies sind im Beispiel m Figur 6 die Operationen momεnt_ga und drεhzahl der Klasse Antrieb. Figur 10 zeigt die neue UML-Klasse nach dεr Dε- taillierung. Detailliert ist hier in die Klassen Motor, Antriebs-Koordinator und Getriεbε sowiε zusätzlichε Opεraticnεn <<auftrag>> moment_ma, <<anfordεrung>> rGang und <<auftrag>> εmlεgenGang. Zu beachtεn ist die Darstellung der Klasse Antrieb mit dem nunmehr lεεrεn Opεrationsberεich sowie der Änderung dεs Stereotyps <<huεllε>>. Diε <<abfrage>> luftdruck dεr Komponente Motor aus der Komponente Antrieb heraus an den << forma- tιonsgεbεr>> Umwεlt wird modelliert über eine Beziεhung zwischen diesen beiden Komponεnten m Form einer Assoziation - bε dε müs- sεn sich kennen - sowie eine Abhängigkeit von Motor an die εnt- sprεchende Schnittstelle von Umwelt. Dies gilt analog für alle CARTRONIC*-Kommunιkatιonsbεzιehungen. Die explizite Modelliεrung aller Beziehungen αer UML-Klassεn untereinander führt automatisch zu einem vollständigen Überblick über alle Zugriffe auf jede einzelne Schnittstelle.
Anstraktionsvorgange sind notwendig und sinnvoll für eine kompakte und übersichtliche Darstellung struktuπertεr komplεxεr Komponentenstrukturεn durch ihrε Hüllεnkomponεntε und Schnittstellen Bei dem Vorgang der Abstraktion dürfen keine Informationen aus der detaillierten Darstellung verlorεn gεhεn und Ab- hangigkεitεn zwischen verschiedenen Komponenten müssen möglichst ohnε Hmzufugung weitεrεr Information abgebildet werden. Be dεr Abstraktion vom detaillierten UML-Aggregat Antrieb Abbildung 10 bleibt im Unterschiεd zu dεr Figur 6 dargεstellten Komponente Antrieb eine „leere" Klasse (Figur 11) . Hiεrbei ergibt sich aber das Problem der Nicht-Sichtbarkeit der Beziehung zwischen einer Teilkomponεnte von Antrieb und Umwelt. Deshalb erfordert das UML-Modell zusatzlich zur CARTRONIC*-Funktιonsarchι- tektur eme kunstlich gεsεtztε Assoziation und Abhangigkεit zwischen dεn Komponenten Antπeo und Umwelt Bei Einsatz eines Mo- dεlliεrungstools kann diese Problematik beispielsweise durch entsprεchende Zusatzattribute oerücksichtigt wεrdεn.
Die einfachste Art des Austauschens von Elemεntεn ist e Austausch mit gleicher Funktionalitat, bei dem Modifikationen nur intern einer Komponente ohne eme nach außen sichtbare Veränderung von Namen, Schnittstellen oder Beziehungen vorgεnommεn werden (Figur 12)
Ein Austausch mit εrwεitertεr Funktionalität liegt vor, wenn eine Komponente αen Namen, vorhandene Beziεnungεn und ihre altε Funktionalltat behält, jedoch um neue Funktionalität und damit nεuε Schnittstellenoperationen erweitert wird (Figur 13 ) .
Werden bei einem Austausch innere Eiemεnte einer Komponente so modifiziert, dass nεue Beziεhungen zu anderεn Komponentεn erforderlich werden, handelt es sich um einen Austausch mit veränderten Beziehungen. Dies ist zum Beispiel der Fall bei zusätzlich abgefragter Information. Der Komponentεnnamε und diε Schnittstellen bleibεn hiεrbεi unverändert (Figur 14) .
Beim Austauschen mit wegfallender Funktionalität entfallen einzelne Funktionen beziεhungswεise Operationen den Schnittstellen. Vor dem eigentlichen Löschvorgang muss deshalb eine (automatisierte) Konsistenzprüfung zur Sicherstεllung εrfolgen, dass keine weiterε Komponente des Gesamtmodεlls diε zu löschenden Elemente noch verwεndεt .
Das Löschεn einer Komponεntε kann als Sondεrform dεs Austau- schεns mit wεgfallεndεr Funktionalität betrachtet werdεn Hierbei wird eme vornandenε Klassε m eine „leere" unεrführt durch iterativen Wegfall ihrer Operationen.
Es wird also em Vεrfahren und Vorrichtung zur Modellierung eines mechatronischen Systems m einem Kraftfahrzeug im Ranmen eines objektbasiεrtεn Ordnungskonzεpt als eine Anoildung m die Unified Modeimg Language beschrieben. Diese stellt e wesentliches Bindeglied zwischen dεr Analyse- und Design- oεzienungs- wεisε Entwurfsphasε im ob εktonεntiεrten Softwareentwic lungs- prozess dar. Diε Elemente der CARTRONIC" mit Komponenten und Hüllen als ihren Klassen beziεnungswεisε Obj exten und Auftragen (mit Rückmeldung) , Abfragen (mit Hinweis) 'und Anforderungen als ihren Kommuni ationsbeziεhungεn sind an Hano von Beispielen z_- sammεn mit den wesentlichen Regεln aus dem Gesamtrεgεlwεrk vorgestellt. Für diese Modelliεrungselemεntε wird eine Abbildungsvorschrift m UML-Konstrukte dargεstellt. CARTRONIC'-Komponεnten einschließlich -Hüllen werdεn als UML-Klassen bεziehungsweisε - Ob εkte mit dεn Stεrεotypen <<koordinator>>, <<opεrator>> , <<m- format onsgeber>> und <<huεlle>> abgebildet. Diε CARTRONIC*- Kommunikationsbeziehungen Abfragε und Anforderung werden als UML-Opεrationεn mit den Sterεotypεn <<abfragε>> und <<anforde- rung>> m Schnittstellεn mit dem Stereotyp <<mterface>> bεreit- gεstellt, alle Auftragsoperationen werdεn durch den Stereotypen <<auftrag>> Schnittstellεn mit Stereotyp «interfaceAuftrag>> gεkεnnzeichnet . In eine detaillierte Komponente eingehende Nachrichten werden automatisch über Kompositionsbεziεhungen an diε εwεils zuständigεn Tεilkomponenten delegiert. Für nicht hierarchische Kommunikatlonsbeziehungεn zwischεn Auftraggεbεr und Beauftragtem wird zwischen diesen eine Assoziation und von dem Auftraggeber zu der Schnittstelle des Beauftragten eine Abhän- gigkeitsbeziεhung modεlliert. Die Kapselung von Komponenten wird somit über die beiden separatεn Schnittstellen, die Komposition als implizite Zugehörigkeitsbeziehung und die Darstellung der Abhängigkeiten gewährlεistε . Für diε im Entwicklungsprozεss auftretenden Vorgänge Detailliεrung, Abstraktion, Austausch und Löschεn von Komponentεn wεrdεn Vorgεhεnswεisen für den Einsatz eines kommerziell vεrfügbarεn UML-Softwarεεntwicklungswεrkzεugεs aufgezeigt .

Claims

Ansprüchε
1. Vεrfahrεn zur Modellierung eines mεchatronischen Systems in einem Kraftfahrzeug, wobei das mεchatromschε Ξystεm aus mεhrεrεn Komponεnten besteht, zwischen denen vorgegebεnε Kommunikationsbεziehungεn bestehen, dadurch gekennzeichnεt , daß diε Komponenten und KommunikationsbεZiehungen zwischen den Komponentεn im Rahmen εinεr objektorientierten Modellierungssprache dargestellt werden.
2. Vεrfahrεn nach Anspruch 1, dadurch gekannzεichnet , dass die objektoriεntiεrte Modellierungssprachε die unified mode- l g language ist.
3. Vεrfahrεn nach einem der vorhergehenden Ansprüche, dadurch gekεnnzεichnεt, daß auf dεr Basis dεr dargestelltεn Komponεntεn und Beziehungen das Softwaredεsign erstεllbar ist.
4. Verfahren zur Modelliεrung eines mεchatronischεn Systems in einem Kraftfahrzeug, wobei das mechatronische System in mehrere Komponenten zwischen denεn vorgegebεne Kommunikati- onsbεziehungen wie Abfrage, Aufforderung und Auftrag bestehen, gegliedert ist, dadurch gekennzeichnet, daß eine Abb l- dungsvorschrift vorgesεhen ist, mit dεr die Komponenten und Beziehungεn dεs Systems in Konstrukte einer ob ektorientier- tεn Modεlliεrungssprache, vorzugsweise der UML-Sprache, umgesetzt werden.
5. Verfahren nach Anspruch 4, dadurch gekennzεichnεt , dass die Abbildungsvorschrift darin besteht, dass die Komponenten einschließlich -Hüllen als UML-Klassen beziehungsweise - Objekte mit den Stereotypen «koordmator», <<operator>>, <<mformatιonsgeber>> und <<huelle>> abgebildet werden, diε Kommunikationsbεziεhungen Abfragε und Anfordεrung als UML- Operationen mit den Stereotypen <<abfrage>> und <<anforde- rung>> in Schnittstellen mit dem Stereotyp «Interface» bereitgestellt werden und alle Auftragsoperationεn durch den Stereotypen <<auftrag>> in Schnittstellen mit Stereotyp <<interfaceAuftrag>> gekennzeichnet werden.
6. Vorrichtung zur Modellierung eines mechatronischen Systems einem Kraftfahrzeug, welchεs aus mehreren Komponen- ten besteht, zwischen denen vorgegebenε Kommunikationsbεzie- hungen bestehen, dadurch gekennzεichnet , dass die Komponenten und Kommunikationsbeziehungen zwischen den Komponenten im Rahmen einer objektorientierten Softwaresprachε dargestellt sind.
7. Vorrichtung zur Modelliεrung eines mechatronischen Systems in einem Kraftfahrzeug, welchεs aus mehreren Komponenten besteht, zwischen denen vorgegebenε Kommunikatlonsbεzie- hungεn bestehεn, gekennzeichnet durch eme Abbildungsvor- schrift, mit der die Komponentεn und Beziehungεn dεs Systεms m Konstrukte einer objektorientiεrten Modellierungssprache, vorzugswεisε dεr UML-Sprache, umgesetzt werden.
EP01915011A 2000-03-28 2001-02-16 Verfahren und vorrichtung zur modellierung eines mechatronischen systems in einem kraftfarhzeug Ceased EP1268996A2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
DE10015114 2000-03-28
DE10015114A DE10015114A1 (de) 2000-03-28 2000-03-28 Verfahren und Vorrichtung zur Modellierung eines mechatronischen Systems in einem Kraftfahrzeug
PCT/DE2001/000587 WO2001073279A2 (de) 2000-03-28 2001-02-16 Verfahren und vorrichtung zur modellierung eines mechatronischen systems in einem kraftfarhzeug

Publications (1)

Publication Number Publication Date
EP1268996A2 true EP1268996A2 (de) 2003-01-02

Family

ID=7636523

Family Applications (2)

Application Number Title Priority Date Filing Date
EP01915011A Ceased EP1268996A2 (de) 2000-03-28 2001-02-16 Verfahren und vorrichtung zur modellierung eines mechatronischen systems in einem kraftfarhzeug
EP01915314A Withdrawn EP1242264A2 (de) 2000-03-28 2001-03-02 Verfahren und vorrichtung zum entwerfen eines gebietsmodells für steuerungssysteme in fahrzeugen in bezug auf die funktionalen anforderungen

Family Applications After (1)

Application Number Title Priority Date Filing Date
EP01915314A Withdrawn EP1242264A2 (de) 2000-03-28 2001-03-02 Verfahren und vorrichtung zum entwerfen eines gebietsmodells für steuerungssysteme in fahrzeugen in bezug auf die funktionalen anforderungen

Country Status (6)

Country Link
US (1) US7188016B2 (de)
EP (2) EP1268996A2 (de)
JP (1) JP2004504972A (de)
AU (1) AU4244501A (de)
DE (1) DE10015114A1 (de)
WO (2) WO2001073279A2 (de)

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10208866A1 (de) * 2002-03-01 2003-09-04 Bosch Gmbh Robert Einrichtung und Verfahren zur Beurteilung und Erzielung von Sicherheit bei Systemen sowie entsprechendes Computerprogramm
EP1550573B8 (de) * 2002-06-24 2015-02-25 Denso Corporation Struktur zur übertragung von fahrzeugsteuerungsinformationen, die übertragungsstruktur verwendende fahrzeugsteuerungsvorrichtung und die übertragungsstruktur verwendender fahrzeugsteuersimulator
DE10233435A1 (de) * 2002-07-23 2004-02-12 Siemens Ag Verfahren zum Verarbeiten von Daten einer Anlage
US7861218B2 (en) * 2004-10-28 2010-12-28 International Business Machines Corporation Computer method and system for enforcing derived union constraints
US20060101381A1 (en) * 2004-10-29 2006-05-11 International Business Machines Corporation Computer method and apparatus for implementing subsets constraints in programming models
US7478362B2 (en) * 2004-12-01 2009-01-13 International Business Machines Corporation Computer method and apparatus for improving programming modeling with lightweight stereotypes
JP2008540223A (ja) * 2005-05-11 2008-11-20 バイエリッシェ モートーレン ウエルケ アクチエンゲゼルシャフト 複数の機能システムを備えた動力車両を作動させる方法
CN100580586C (zh) * 2006-08-28 2010-01-13 中国科学院电工研究所 一种车载分布式网络控制系统的开发方法
US8155989B2 (en) 2007-10-17 2012-04-10 The United States Of America As Represented By The Secretary Of The Army Engineered management system particularly suited for maintenance and repair (M and R) management of structure such as pavement
US8255197B2 (en) * 2008-09-30 2012-08-28 Rockwell Automation Technologies, Inc. Simulation of tuning effects for a servo driven mechatronic system
US20110153056A1 (en) * 2009-08-31 2011-06-23 Siemens Ag Functional Mechatronic Objects
WO2011023239A1 (en) * 2009-08-31 2011-03-03 Siemens Aktiengesellschaft Workflow centered mechatronic objects
CN104536434A (zh) * 2014-12-15 2015-04-22 华晨汽车集团控股有限公司 车辆网络总线仿真与测试方法
CN105205287B (zh) * 2015-10-29 2019-02-12 浙江吉利汽车研究院有限公司 一种车辆参数自动导入车辆动力学模型的方法
DE102019125463A1 (de) * 2019-09-23 2021-03-25 Bayerische Motoren Werke Aktiengesellschaft Verfahren, Struktur, Vorrichtung, Computerprogramm und computerlesbares Speichermedium zur Analyse eines mechatronischen Systems
JP7627816B2 (ja) * 2020-11-20 2025-02-07 深▲ジェン▼引望智能技術有限公司 Ｉ／ｏデバイス・アクセス方法及び装置
KR102624947B1 (ko) * 2023-11-28 2024-01-15 주식회사 티알씨일렉트릭 전동기 역설계 장치 및 방법

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3716091B2 (ja) * 1998-02-20 2005-11-16 株式会社日立製作所 要求仕様モデル・他形式モデル変換装置及び方法
JP3663950B2 (ja) * 1999-01-20 2005-06-22 株式会社デンソー 自動車用電子制御装置
US6259984B1 (en) * 1999-05-11 2001-07-10 Denso Corporation Automatic transmission control with object-oriented program
JP4427860B2 (ja) * 2000-03-24 2010-03-10 株式会社デンソー 車両用制御装置及び記録媒体

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO0173279A2 *

Also Published As

Publication number Publication date
WO2001072552A3 (en) 2002-03-21
JP2004504972A (ja) 2004-02-19
AU4244501A (en) 2001-10-08
WO2001073279A2 (de) 2001-10-04
DE10015114A1 (de) 2001-10-04
US7188016B2 (en) 2007-03-06
WO2001073279A3 (de) 2002-04-18
EP1242264A2 (de) 2002-09-25
US20040030461A1 (en) 2004-02-12
WO2001072552A2 (en) 2001-10-04

Similar Documents

Publication Publication Date Title
EP1268996A2 (de) Verfahren und vorrichtung zur modellierung eines mechatronischen systems in einem kraftfarhzeug
EP1176482B1 (de) Verfahren und Computerprogramm zum Herstellen einer Regelung oder Steuerung
DE102014210854A1 (de) Computerimplementiertes Verfahren und Signalfolge für ein Programm zur Wiederverwendung von ausführbaren Softwarekonfigurationen für Softwaresysteme sowie Rechneranlage und ein Computerprogramm mit Programmcode zur Durchführung des Verfahrens
DE102016119320A1 (de) Verfahren zum Konfigurieren eines realen oder virtuellen elektronischen Steuergerätes
DE10333087A1 (de) Verfahren zum automatischen Zerlegen von dynamischen Systemmodellen in Teilmodelle
EP1674954A1 (de) System und Verfahren zur Wiederverwendung von Projektierungsdaten
EP1917611A2 (de) System für den maschinengestützten entwurf technischer vorrichtungen
DE102011011951A1 (de) Anforderungsgetriebener Merkmalsentwicklungsprozess
DE102020123506A1 (de) Verfahren zur Erzeugung von Quellcode mit servicebasierter Kommunikation
DE102011012068A1 (de) Begriffsverwaltungssystem (tms)
DE202014006343U1 (de) Rechneranlage, Datenträger sowie Signalfolge für ein Programm zur Wiederverwendung von ausführbaren Softwarekonfigurationen für Softwaresysteme
DE112009001818T5 (de) Steuervorrichtung, Steuerverfahren und Computerprogramm
WO2021047970A1 (de) Software-komponenten für eine software-architektur
DE102021202133A1 (de) Verfahren, Vorrichtung und Konfigurationsumgebung zum Erzeugen von Konfigurationsdaten für ein Steuergerät
DE19831651C1 (de) Verfahren zum Erzeugen eines regel- und anpassbaren Netzwerkes von Modellen von Verhaltensmustern einschließlich Software-Systemen
DE10235610A1 (de) Verfahren zum Überprüfen einer Steuergerätefunktion
DE102009054137A1 (de) Verfahren zum Testen einer Applikation hinsichtlich ihrer Performanz
DE102011011950A1 (de) Anforderungserhebungswerkzeug, genannt Anforderungseditor
WO2022069109A1 (de) Verfahren zum erzeugen einer softwarekomponente für eine elektronische recheneinrichtung eines kraftfahrzeugs, computerprogrammprodukt, computerlesbares speichermedium sowie kraftfahrzeugexternes aktualisierungssystem
EP2040160A1 (de) Verfahren zur Integration einer integrierten Schaltung in eine standardisierte Softwarearchitektur für Embedded Systeme
DE102024206331A1 (de) Verfahren zum dynamischen Definieren von Parametern einer Steuergeräte-Software eines Fahrzeuges
EP4390700A1 (de) Computer-implementiertes verfahren zum bestimmen algorithmusversions-kompatibler test- und/oder simulationsdaten und entsprechendes system
DE102024104968A1 (de) Verfahren zur Bereitstellung einer Interprozesskommunikation, IPC, zwischen mehreren Anwendungsprozessen in einer Prozessorschaltung eines Steuergerätes eines Kraftfahrzeuges, elektronisches Steuergerät und Kraftfahrzeug
DE102023116367A1 (de) Verfahren und System zum Konfigurieren einer Applikation zum Ausführen eines virtuellen Tests
DE102021211620A1 (de) Verfahren und System zur automatischen Erzeugung eines eingebetteten Quellcodes für die elektronische Steuereinheit eines AD/ADAS-Strassenfahrzeugs

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20021028

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

17Q First examination report despatched

Effective date: 20030429

RBV Designated contracting states (corrected)

Designated state(s): DE FR IT SE

APBN Date of receipt of notice of appeal recorded

Free format text: ORIGINAL CODE: EPIDOSNNOA2E

APBR Date of receipt of statement of grounds of appeal recorded

Free format text: ORIGINAL CODE: EPIDOSNNOA3E

APAF Appeal reference modified

Free format text: ORIGINAL CODE: EPIDOSCREFNE

APAF Appeal reference modified

Free format text: ORIGINAL CODE: EPIDOSCREFNE

APAF Appeal reference modified

Free format text: ORIGINAL CODE: EPIDOSCREFNE

APBT Appeal procedure closed

Free format text: ORIGINAL CODE: EPIDOSNNOA9E

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

RIC1 Information provided on ipc code assigned before grant

Ipc: G06F 9/44 20060101AFI20101125BHEP

18R Application refused

Effective date: 20101103