EP1268996A2

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

Info

Publication number: EP1268996A2
Application number: EP01915011A
Authority: EP
Inventors: Pio Torre Flores; Juergen Schirmer; Michael Walther; Holger Huelser; Torsten Bertram; Marc Heckes; Joerg Petersen
Original assignee: Robert Bosch GmbH
Current assignee: Robert Bosch GmbH
Priority date: 2000-03-28
Filing date: 2001-02-16
Publication date: 2003-01-02
Also published as: WO2001072552A3; DE10015114A1; US7188016B2; EP1242264A2; US20040030461A1; JP2004504972A; WO2001073279A3; WO2001073279A2; WO2001072552A2; AU4244501A

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

Method and device for modeling a mechatronic system in a motor vehicle

State of the art

The invention relates to a method and device for modeling a mechatronic system in a motor vehicle.

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.

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. In addition, in the event of partial system failures, dynamic relocations from functions to other systems can be supported.

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.

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

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.

In 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) developed

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.

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

Fan 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

An 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

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

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.

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 ^* 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. 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:

□ components with predominantly coordinating and distributing tasks,

O components with mainly operational and executive tasks and

Q Components that only generate and provide information.

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.

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

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.

A structure developed according to the structuring and modeling rules is characterized by the following features:

□ standardized, structuring and modifying rules on all abstraction levels,

□ hierarchical order flows,

Q high individual responsibility of the individual components,

□ Operating elements, sensors and estimators are equivalent information providers and one

□ Encapsulation, which shows the component as visible as necessary and as invisible as possible for the other components.

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

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

- the queries "condition and" air pressure (of the surrounding area) to gearbox and environment

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

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.

Developed UML modules can be clearly interpreted by everyone involved in the development process and offer the following major advantages:

- the use of an international standard,

a tool-supported procedure that is as independent of the manufacturer as possible,

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

independence as far as possible from the programming language used at the logical level,

- maintaining the consistency between analysis, design and implementation, and

- The possibility of a bottom-up reverse engineering ring procedure.

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.

drawing

The invention is explained in more detail with reference to the embodiments shown in FIGS. 1 to 14.

Description of exemplary embodiments

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.

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.

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

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

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.

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.

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.

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.

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.

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.

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.

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

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

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

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.

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.

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ε

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 according to claim 1, characterized gekannzεichnet that the objektoriεntiεrte modeling language is the unified mode l g language.

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