EP1268996A2 - Method and device for modelling a mechatronic system in a motor vehicle - Google Patents

Abstract

The invention relates to a method and a device for modelling a mechatronic system in a motor vehicle according to an object-based architecture, whereby said system is represented in the unified modelling language. The elements of the CARTRONIC® which comprise components and sleeves as the classes thereof or objects and orders (with feedback), inquiries (with hints) and requests as the communications relations thereof are provided by means of examples and together with the essential rules of the entire catalogue of rules. A representation rule for said modelling elements is provided in UML constructs.

Description

Verfahren und Vorrichtung zur Modellierung eines mechatroni- schen Systems in einem KraftfahrzeugMethod and device for modeling a mechatronic system in a motor vehicle

Stand der TechnikState of the art

Die Erfindung betrifft ein Verfahren und Vorrichtung zur Modellierung eines mechatronischen Systems in einem Kraftfahrzeug .The invention relates to a method and device for modeling a mechatronic system in a motor vehicle.

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 .The demand for more safety, economy, comfort and better environmental compatibility makes mechatronics in vehicles an increasingly important and competitive factor. Economical vehicle developments and the mastery of complex system structures with ever shorter product cycles force continuous, as far as possible automated, computer-aided development processes. In the analysis phase, on the basis of agreed formal structuring and modulating rules of the cartronic modular concept, which is independent of the automobile manufacturer and supplier, expandable architectures for "function", "safety" and "electronics" can be specified. The demand for more safety, economy, comfort and better environmental compatibility makes mechatronics in vehicles an increasingly important and competitive factor in technology change from mechanics to electronics to information technology. Given the constantly increasing complexity of the systems and, at the same time, ever shorter product cycles, the cost and development effort can only be managed if a continuous, largely automated, computer-aided and largely parallelized work and development process is managed.

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.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.

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.Networking also enables a change from purely function-oriented implementations to configurations in which the application functions are mapped to networked control devices. In addition, in the event of partial system failures, dynamic relocations from functions to other systems can be supported.

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.Based on the logical functional units with their standardized interfaces, it is also possible to network functions with different origins, from different Auromobile manufacturers and suppliers. A function supplier must guarantee that the function division to several networked control units complies with the required specification.

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) .The development of complex, networked systems requires a systematic process with recursive phases and the use of computer-aided tools, both for the automotive manufacturer and the supplier to formulate all the requirements and constraints on the functions to be developed to develop the various functions Analyze interactions with other functions and the environment in all application and error cases and evaluate the function in its effect on the security of the overall network For the development of complex, networked systems, the V-Modell has also established itself in the automotive industry as a process model. The V-Modell provides that all activities and processes for functional development can be classified in eleven phases (Figure 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.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. In contrast, 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.

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/MicmganIn order to be able to meet the demands for economical vehicle development, the mastery of complex system structures and adequate documentation, the Cartronic order concept (see Bertram, T., R. Bitzer, R. .Mayer and A. Volkart, 199S, CARTRONIC - An open architecture for nεt- workmg the control systems of an automobile, Detroit / Micmgan

U.Ξ.A., SAE 9B200, 1-9) entwickεltU.Ξ.A., SAE 9B200, 1-9) developed

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 .In the first phase of the process, the analysis, 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 After a short training period, everyone involved in the development process can understand the logical description of the requirements at a very early stage of development.

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ützenGraphic-based models, as essential documentation elements, support a space between all the people involved in the development and the maintenance and further development after the development has been completed. In addition to the classic software engineering, support must be given as personal groups for me-chatronic system developments in the motor vehicle sector

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üssenFan manufacturers as users / customers as well as interested parties who need information about the functionality of systems, engineers in the fields of mechanical engineering and electrical engineering as well as computer scientists as developers of echatronic components on manufacturers and suppliers as well as those who will modify and modify these after the subsequent development and understanding of the overall system or its parts, managers on developer and customer needs, organizational and economic details for project control, calculation of costs and information for future projects and developments, and last but not least, vehicle drivers as special end users, who are familiar with selected functionalities of the system have to be done

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εmenAn essential step at the end of the analysis and at the beginning of the design phase is the mapping of the specification models developed by Cartronic to an information technology draft for software development. This figure contributes to increasing the information density and expanding the semantic content of the Cartronic model, defines subsystems of an overall system architecture, increases the transparency of the overall system in the direction of implementation and creates the essential basis for the distributed development and testability of mechatronic systems

Vorliegend wird eine Abbildung von m CARTRONIC⁶ 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.In the present case, an illustration of m CARTRONIC ⁶ first specification models is described m a standardized object-oriented representation against the background of the widest possible support by commercially available software development tools. A suitable notation is provided by the internationally standardized object management group (OMG) , object-oriented language standard of the Unified Modelmg Language (UML).

Im folgenden wird eine zusammenfassendε Bεscnrεibung αεr Struk- turelεmente und formalen Stru tuπerungs- sovvie Modellier/ungsre- geln nach CARTRONIC¹ 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.In the following, a summary description of structural elements and formal structuring and modeling rules according to CARTRONIC ¹ for functional architectures is given. Furthermore, a high-level level of functionality is described presented the entire vehicle with a detail for the drive component. Based on this, the theoretical foundations of the modeling are presented first, before the elements used in the object-oriented notation with UML are discussed in the further course of this section. The procedure for the existing CARTRONIC ^* model is shown using an example.

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.An example of an existing system for vehicles today is traction control. This is only possible through the communication of the control device for traction control with the control device for engine management to regulate the drive torque.

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 .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.

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: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. Finally, 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. Within the framework of the structuring, one speaks of a system as a combination of components to form a whole, which interact with one another via communication relationships. The term component does not necessarily mean a physical unit in the sense of a component, but is understood as a function response. There are three different types of components in the order concept:

□ Komponεntεn mit übεrwiεgend koordinierenden und vertεilεnden Aufgaben,□ components with predominantly coordinating and distributing tasks,

O Komponenten mit hauptsächlich operativen und ausführenden Aufgaben undO components with mainly operational and executive tasks and

Q Komponεnten, die ausschließlich Informationen generieren und bereitstellen.Q Components that only generate and provide information.

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. In the communication relationship, a distinction is made between an order (with confirmation), a query (with a note) and a request. The order indicates the obligation to execute; in the event of non-fulfillment, the contractor must send a feedback to the client describing the reason for the non-execution. The query is used to obtain information for an order execution. In the event that a component cannot provide the queried information, it gives an indication to the component in question. A requirement describes a "wish" that a function is carried out by another component. However, the requirement is not linked to the fulfillment of this requirement, which is taken into account, for example, in the case of conflicting requirements. The following notes summarize the structural releems.

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 hineinThe 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. The structuring rules of the Management of communication relationships from one system to another detailing it

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.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.

Eine nach den Strukturierungs- und Modellierungsrεgeln entwik- kεlte Struktur zeichnet sich durch folgendε Mεrkmalε aus:A structure developed according to the structuring and modeling rules is characterized by the following features:

□ vεrεinbartε, εinhεitliche Struktuπεrungs- und Modεlliεrungs- rεgεln auf allen Abstraktionsεbenen,□ standardized, structuring and modifying rules on all abstraction levels,

□ hiεrarchische Auftragsflüsse,□ hierarchical order flows,

Q hohe Eigenverantwortung der einzelnen Komponenten,Q high individual responsibility of the individual components,

□ Bedienεlementε, Sεnsoren und Schätzer sind gleichwertigε In- formationsgebεr und eine□ Operating elements, sensors and estimators are equivalent information providers and one

□ Kapsεlung, diε edε Komponεntε für diε übrigen Komponenten so sichtbar wie nötig und so unsichtbar wie möglich dargestellt.□ Encapsulation, which shows the component as visible as necessary and as invisible as possible for the other components.

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.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.

- 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,- the order momεnt_ga (provide torque at the transmission output), which is passed on from the drive casing to the input component drive coordinator, which is also the coordinator,

- 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,- the orders moment_ma (provide torque at the engine output), place the frictional engagement and shift gear (engage a gear) from the drive coordinator to the engine converter and gearbox, - The requirement IrGang (reverse gear) from the transmission control panel to the drive coordinator,

- die Abfragen ?zustand und ?luftdruck (der Umgenung) an Getriebe und Umwelt- the queries "condition and" air pressure (of the surrounding area) to gearbox and environment

- 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.- as well as the queries "gear (reverse gear or not) and" speed on the casing of the drive, which forwards them to the responsible components motor and gear.

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.In the classic software life cycle, the strictly sequenced phases of problem analysis, system specification, design, implementation with component, overall test and introduction as well as operation and maintenance of a software system are differentiated. In practice, such a strictly sequential development process is an idealization that cannot be met. Theoretically clearly delimitable points overlap or are possibly differently advanced, at the same time the know-how is advancing with the system development on the part of all those involved in the development process. A method which is ectoπentiεrtε enables a phase-spanning procedure with from the beginning high reusability already developed or existing parts and concepts. This is essentially seen through the use of a computer-supported, graphic notation. 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. 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.

Entwickelte UML-Modεllε sind von allen am Entwicklungsprozess betεiligtεn Personen eindeutig interpretierbar und bieten als wesεntliche Vorteile:Developed UML modules can be clearly interpreted by everyone involved in the development process and offer the following major advantages:

- die Vεrwεndung eines internationalεn Standards,- the use of an international standard,

- eine möglichst herstellerunabhängigε, toolunterstütze Vorgehensweise,a tool-supported procedure that is as independent of the manufacturer as possible,

- 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,- a softening of the rigid adherence to the classic succession of analysis and design phase in the software development without tasks of the software life cycle model as the basis of an engineering top-down procedure,

- möglichst weitgehεndε Unabhängigkeit von dεr lεtztεndlich verwendeten Programmiersprache auf der logischen Ebene,independence as far as possible from the programming language used at the logical level,

- die Erhaltung dεr Konsistenz zwischen Analysε, Dεsignentwurf und Implementierung, sowie- maintaining the consistency between analysis, design and implementation, and

- die Möglichkeit εinεr glεichzεitigεn bottom-up Reverse- Engineεring-Vorgehensweise .- The possibility of a bottom-up reverse engineering ring procedure.

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.In the analysis phase 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. Through a suitable mapping into a far more powerful UML model, 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. Complexity can be mastered through abstraction, whereby both the simplicity and the manageability of the whole must be guaranteed (structuring on a large scale). In later steps, 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.

Zeichnungdrawing

Die Erfindung ist anhand der m den Figuren 1 bis 14 dargε- stellten Ausführungsformen näher erläutert.The invention is explained in more detail with reference to the embodiments shown in FIGS. 1 to 14.

Beschreibung von AusführungsbeispielenDescription of exemplary embodiments

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 CARTRONIC¹- 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.In the following, the mapping of the Cartron c elements UML element is presented on the basis of the detail shown in FIG. 4. The main considerations here are to support the CARTRONIC ^* rules as completely as possible, to maintain the basic idea of whether they are oriented to the sector and to be understandable enough and sufficiently transparent for the CARTRONIC ¹ modeler remain, as well as being able to record and display all the necessary information for later work steps.

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.FIG. 4 shows the CARTRONIC ^* components environment, drive, vehicle coordinator and electrical on-board electrical system. The following communication relationships exist between these components: 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.

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.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) are copies of classes with properties and behavior. In 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ε.

Ü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.About the Sterεotypεn << huεlle >>, <<>> mformatιonsgebεr, "<κoor- dmator» and _<<opεrator >> wεrdεn the component classes αen ones established categories zugeordnεt D ε Komponεntε Jmwelt from FIG. 4 is illustrated as a class with the name environment and the otypterεotype << mformatιonsgεbεr >>.

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.The three CARTRONIC ^{^} communication types, order, query and request, ask other components to "do something" - in object-oriented modification, this would therefore be interpreted as messages and with the stereotypes <<order>>, << query >> and <<requirement>> modeled as UML operations. The CARTRONIC ^* order moment_ga becomes the UML operation << order >> moment_ga the class drive, from the CARTRONIC ^β query the number of times this component is the UML operation <query >> speed as well as from the CARTRONIC "query? air pressure to the component Umwεlt this UML-Opεration <<query>> air pressure of the environment class. In the representation in FIG. 5, the double line in the classes of drive, electrical system and environment symbolizes that no attributes are present yet. With the vehicle coordinator class, the presentation of any possible attachments or operations is completely dispensed with and only the declaration area of the class is mapped. This results in a clearer diagram. CARTRONIC ^* responses can be identified as return parameters of UML operations and are therefore not explicitly modeled as independent UML operations in the mapping rule.

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.The encapsulation of the individual components with the aim of a defined access regulation and control is modeled via εexplicit UML interfaces for the UML operations. A distinction is made between interfaces for orders as well as queries and requirements with the two stereotypes << intεrfaceAuf rag >> and << mter ace ». The stricter access rules for orders according to the “E-boss- Principle "are hereby explicitly modeled. FIG. 6 shows this using the example of the class <<operator>> drive.

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- TRONIC^e-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.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.

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.Large complex CARTRONIC ^* components at a high abstract level can be mapped as UML subsystems analogous to the modeling via UML classes. 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. 9, an interface, here << m- tεrfacεorder >> IA_Antneb, can directly through the interface nεs internal element, here << mterfacεAuf Rag >> IA_Antrιebs- coordinator, oεrεitn.

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.The constant further development of the CARTRONIC ^* models requires components to be changed and exchanged. In addition to the mapping of individual CARTRONIC ^* elements into the UML described in the previous section, the steps and processes in the continuous development process must be supported. In practice, mixed forms of the following different procedural steps occurred. These consist of the detail, the abstraction, the replacement and the deletion of elements.

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.When detailing a CARTRONIC ^* component, a shell without its own logical functions is created according to the CARTRONIC ^* rules, all already known, existing functionalities are distributed to the resulting subcomponents. The encapsulation or the interfaces of the components to be detailed must be kept completely in the shell in order not to change the behavior to the outside. In the example in FIG. 6, these are the operations momεnt_ga and drεhzahl of the class drive. Figure 10 shows the new UML class after detailed detailing. It is detailed here in the classes motor, drive coordinator and gearbox, as well as additional optional <<order>> moment_ma, << requirement >> gear and <<order>> gear. Note the representation of the class drive with the now operational area and the change in the stereotype << huεllε >>. The air pressure of the engine component from the drive component to the << format information >> is modeled by means of a relationship between these two components in the form of an association - both of which must be known - and a dependency from engine to εnt- speaking interface of environment. This applies analogously to all CARTRONIC ^* communication missions. The explicit modeling of all relationships of the UML classes with one another automatically leads to a complete overview of all accesses to each individual interface.

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.Antraction processes are necessary and useful for a compact and clear representation of structured, complex component structures through their shell components and interfaces. In the process of abstraction, no information from the detailed representation may be lost and dependencies between different components must be mapped as far as possible without additional information. In contrast to the detailed UML drive unit, Figure 10, in contrast to the drive component shown in Figure 6, remains an "empty" class (Figure 11). However, this results in the problem of the invisibility of the relationship between a partial component of the drive and the environment Therefore, in addition to the CARTRONIC ^* functional architecture, the UML model requires an artificially based association and dependency between the components antπeo and environment. When using a modernization tool, this problem can be taken into account, for example, by corresponding additional attributes.

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)The simplest way of exchanging elements is an exchange with the same functionality, in which modifications are only carried out internally in a component without any externally visible change in names, interfaces or relationships (FIG. 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 ) .An exchange with functionalities exists if a component has a name, existing references and their retains the old functional act, but is expanded to include new functionality and thus new interface operations (FIG. 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) .If an internal unit of a component is modified during an exchange in such a way that new relationships to other components are required, the exchange is based on changed relationships. This is the case, for example, if additional information is requested. The component name and the interfaces remain unchanged (FIG. 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 .When exchanging with the loss of functionality, individual functions or operations are eliminated from the interfaces. Before the actual deletion process, an (automated) consistency check must therefore be carried out to ensure that no further component of the overall model is still using the elements to be deleted.

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.The deletion of a component can be regarded as a special form of exchange with falling functionality. Here, one of the previous classes becomes an "empty" one due to the iterative elimination of its operations.

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 . Thus, a method and device for modeling a mechatronic system in a motor vehicle in the framework of an object-based order concept is described as an implementation in the Unified Mode Language. This represents an essential link between the analysis and design process in the design phase of the software development process. The elements of CARTRONIC "with components and covers as their classes relating to objects and application (with feedback), queries (with Note) 'and requirements as their communication relations are to Hano of examples z_- presented together with the essential rules from the overall framework. For these modeling elements, a mapping rule in UML constructs is shown. 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. For non-hierarchical communication relationships between the client and the agent, an association is modeled between them and a dependency relationship between the client and the agent's interface. The encapsulation of components is thus guaranteed via the two separate interfaces, the composition as an implicit membership relationship and the representation of the dependencies. For the processes occurring in the development process, detailing, abstraction, exchange and deletion of components, procedures for the use of a commercially available UML software development tool are shown.

Claims

Ansprüchε 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.1. Methods for modeling a mechatronic system in a motor vehicle, the matrichromic system consisting of several components between which predetermined communication relationships exist, characterized in that the components and communication relationships between the component language are represented in the context of the intended modeling.

2. Vεrfahrεn nach Anspruch 1, dadurch gekannzεichnet , dass die objektoriεntiεrte Modellierungssprachε die unified mode- l g language ist.2. Vεrfahrεn according to claim 1, characterized gekannzεichnet that the objektoriεntiεrte modeling language is the unified mode l g language.

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.3. A method according to one of the preceding claims, characterized in that the software design can be created on the basis of the components and relationships shown.

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.4. A method for modeling a mechatronic system in a motor vehicle, the mechatronic system being divided into a number of components between the predetermined communication relationships such as query, request and order, characterized in that an image is provided by means of which the components and relationships of the system are converted into constructs of an object-oriented modeling language, preferably the UML language.

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.5. The method of claim 4, gekennzεichnεt fact that the mapping rule is that the components including envelopes as UML classes or - objects with the stereotypes "koordmator"<< operator >>, _{<<mformatιonsgeber} >> and << huelle >> are mapped, diε Kommunikationsbεziεhungen Abfragε and Anfordεrung as UML operations with the stereotype << query >> and <<_>> requirements tion provided in interfaces with the stereotype «interface» and all Auftragsoperationεn contract by the stereotypes _<< >> featured in interfaces with stereotype << interface _order>>.

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 ob_jektorientierten Softwaresprachε dargestellt sind.6. A device for modeling a mechatronic system a motor vehicle, welchεs consists of several components, between which vorgegebenε Kommunikationsbεzie- relationships exist gekennzεichnet characterized in that the components and communication links between components in a are shown whether _j ektorientierten Softwaresprachε.

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. 7. Device for modeling a mechatronic system in a motor vehicle, which consists of several components, between which predetermined communication relationships exist, characterized by a mapping rule with which the components and relationships of the system m constructs an object-oriented modeling language, preferably UML -Language to be implemented.