WO2006042501A2

WO2006042501A2 - Method for the variant-based management of parameter sets used for the application of electronic control devices

Info

Publication number: WO2006042501A2
Application number: PCT/DE2005/001785
Authority: WO
Inventors: Filipe Remelhe; Thomas Jüttner
Original assignee: Aft Atlas Fahrzeugtechnik Gmbh
Priority date: 2004-10-22
Filing date: 2005-10-06
Publication date: 2006-04-27

Description

Method for variant-based management of parameter sets for the application of electronic control units

The invention relates to a method for generating and managing data for the application of electronic control devices for a motor vehicle.

Application systems are known from the prior art that only manage complete parameter sets as an overall configuration. The administration of partial parameter sets is not provided here and the documentation takes place at the level of the parameter set.

After the development of a new control unit, a series of application steps is carried out during the test phase. The aim of the application phase is to make the optimum settings for all operating situations under the various boundary conditions by taking advantage of the degrees of freedom (up to several hundred parameters).

One application step is to reprogram the controller with a complete set of parameters. This set of parameters is generated by an application system (for example MARC, CANape (= proper name of software packages) and stored as a parameter replacement file / overall configuration.

During the test phase, a large number of such parameter sets arise, all of which can differ in a number of parameters. Over the entire development process, an extensive collection of data with different levels of parameter sets is created.

A disadvantage of the known application systems is that the history in relation to the versioning (= provided with a version identification) of the parameter set files can not be maintained due to the high complexity. Thus, extensive overview tests quickly lose the overview, which in extreme cases can lead to errors in the creation of parameter sets.

Reasons for errors can still be: • numerous vehicle variants

• different software versions

• high number of parameters

• many application steps

• distributed documentation

• several applicators

It is therefore an object of the invention to improve the generation and management of parameter sets - including partial parameter sets - in the application of control units for motor vehicles.

According to the invention the object is achieved in that an assignment of the requirements to the vehicle variants takes place. Furthermore, a hierarchical structuring of the parameters of (partial) parameter sets takes place in conjunction with a data model. Labeling (indexing, versioning) the (sub) parameter sets makes unambiguous assignment possible.

As a result, it is possible to centralize the entire application documentation at the levels of the (sub) parameter set, the parameters and the parameter value. In addition, the administration and versioning of (partial) parameter sets becomes possible. Furthermore, the inventive method allows effective generation of (partial) parameter sets for new vehicle variants including consistency check, Voll¬ durability test and quality assurance.

As part of the development of the method according to the invention, the management of (sub) parameter sets has been developed according to the following aspects:

• Management of different software versions

• Storage of vehicle variants

• Description of the vehicle variants by requirements

• Structuring the individual requirements

• Grouping of all parameters in a hierarchical structure

• Creating relationships between parameters and requirements

• Documentation: o Parameter set description o Parameter description o Application notes o Input history

• Creation of parameter sets from given requirements

• Maintaining the history of changes to parameter values

• Import / Export

The implementation of the implemented software, which implements the new method, leads to the following improvements in the method of application:

• Bug fix by automated creation of new parameter sets

• Synthesis of parameter sets based on given requirements

• Consistency and completeness check

• Direct connection to an application system

• Ensure documentation during import

• Documentation of the history

• Centralization of documentation (history, application notes, etc.)

Here are some definitions of terms to be made:

Software Version:

Base size as a starting point for the creation of a parameter set is the software version. The software version alone determines the number, identifiers, types and value ranges for all parameters. Two software versions differ in that at least one parameter is omitted or at least one other is added. Parameters represented in several software versions may vary with respect to data type and / or value range.

Parameter:

The set of all parameters that belong to a software version is initially free of values. With parameters, the physical control unit variables are characteristic maps, map axes, characteristic curves (eg speed-torque characteristics of a motor type) and constants. Various parameters can be grouped under a generic term.

Parameters can be present in the control unit in different variants, for example to differentiate various levels (development, series, test stand, etc.). Thus, the functionality of the control unit can be modified by simple coding without a completely new parameter set having to be flashed (= writing data into, for example, an E ² PROM).

Parameter Type:

There are different data types for the parameters (parameter type). A parameter can belong to different data types in different software versions. The data types are distinguished by physical (the actual numerical value) and logical (e.g., linguistic indication in enumerated types) data types.

Parameter Type Value:

Corresponds to the valid values (value range) of the logical data types in Aufzählungsty¬ pen. The value ranges of enumeration types can vary over the software versions.

Parameter variant:

A parameter variant indicates a specific status for the parameter. An example is the distinction between development and series status.

Parameter Definition:

A complete, unambiguous definition for a control device-relevant parameter results from its identifier (summarized with commentary and application note under the term parameter), its parameter type and the associated software version.

Parameter value: Parameters are assigned values according to their data type and software version. Each value is versioned.

Parameter Value Matrix:

An auxiliary size to simplify the management of characteristic curves, maps and map axes.

Parameter set:

A parameter set is described by the software version with the exception of the applied values. Assigning the values to the parameters (applying) results in a complete parameter set.

label:

If at least one value of a parameter is changed, a new version of a parameter set is created. Each version of a parameter set receives a unique label for the versioning.

Requirement:

A requirement combines several (at least one) parameters, including their values, under a separate term. If parameter values depend on several requests, this combination itself becomes a new request (combination request). Different requirements can be summarized under a generic term. The grouping of the mutually exclusive requirements determines the parameter set of a vehicle.

The rules for designing the requirement hierarchy, as well as the permitted operations are discussed in a separate section.

Vehicle: By grouping mutually exclusive requirements, a particular vehicle can be clearly described.

Vehicle type:

Several vehicle stands can be summarized by the corresponding model under a generic term. The vehicle statuses assigned under a model again reflect the vehicle history.

With the aid of the requirements, the most current valid parameter set for the latest vehicle variant, or historical versions of the parameter set can always be determined for a model.

The invention will be explained in more detail with reference to FIGS. Show it:

FIG. 1 shows the data model of the present invention;

Figure 2den the schematic structure of the parameter set management.

In Fig. 1 is a so-called class diagram of the data model (which is part of the invention) is shown. This representation is borrowed from the UML (= Unified Modeling Language). According to the UML, the boxes represent "classes" and the connecting lines represent "associations". According to the UML syntax, not only the numbers and symbols at the connecting lines are important, but also the position (which end of the connecting line) Numbers and symbols. On the basis of the already formulated dependencies between the defined terms, the data model on which the software is based can be described. On the basis of the knowledge of the UML syntax, the class diagram is self-explanatory and therefore requires no further words.

The basic idea underlying the parameter set management software is summarized in the following figure (Fig. 2). The parameter set management is to be understood as an add-on to an application system. It should not replace the functions of an application system, in particular the editing of the parameter values for optimization purposes and the actual application function.

The tool is designed as a multi-user application. The data is stored on a database. If the database is centrally accessible, various users can simultaneously work on the database data via the front-end (user interface). Eben¬ so a single-user version for mobile use can be installed.

Before using the basic functions of parameter set management, the master data must be entered in the system. Based on the various vehicle models, the vehicle variants in use must be specified. There is at least one vehicle variant per model. Next, the requirements are defined by which the vehicle is uniquely described (e.g., type of tire, engine type, etc.). Each of the requirements is directly related to at least one parameter of the parameter set. The requirements must be selected so that the sum of all requirements clearly describes a vehicle variant. At the same time, it must be ensured that each parameter of the parameter set is exactly covered by a requirement.

Functionalities for data maintenance of parameter set management:

• Classification of all parameters in groups and their combinations (engine, transmission, func tional, other)

Storage of vehicle variants with specific groupings (model) and assignment of requirements

Input and documentation (printing) of history, comment, validity, optional application notes

Reading, creation and comparison of parameter sets

New creation of parameters for a new software version (insert) as a function separate from simple data import (update) Management of already created parameter sets

Export a specific group of parameters as a subparameters record Data transfer from an old to a new software version in terms of parameters and requirements Documentation, Reporting to MS-Word, MS-Excel, XML Search for changes in parameter values

Parameter set management implements the main functions described in the following sections.

Import

When importing a software version, the database is filled based on the contents of the parameter record. This includes information about parameters, parameter type and parameter value. Only the parameter variants defined in the database are taken into account so that only the relevant parameters are filtered out at the same time during the import.

In addition, the assignment of the parameter values to the requirements is carried out. The assignment of a request to a parameter value has to be carried out manually only once, in all subsequent cases, the assignment takes place on import on the basis of a given vehicle variant.

The import is only necessary once for a complete parameter set per software version. To simplify the import process when changing over from an existing software version to a new software version, the transfer of the assignments of the request to parameter values is automated. Only for newly added parameters must the assignment be maintained manually.

The documentation must be carried out on the levels parameter set, parameter and parameter value. During import, a label is assigned for the parameter set.

check in

When a parameter set is checked in, the parameter values of a parameter set are stored in the database according to the software version and the associated vehicle variant. Based on the vehicle variant, the requirements are automatically assigned to the corresponding parameter values. The documentation must be carried out on the levels parameter set, parameter (special application note) and parameter value. At check-in, a label is assigned for the parameter set.

check-Out

Based on the information about vehicle variant and software version (as an alternative to a label), saved parameter sets can be checked out of the database.

If a new vehicle variant is formulated on the basis of existing requirements, a parameter set can be generated for this.

The documentation is to be carried out on the parameter set level. At check-out, a label is assigned for the parameter set.

Copy

Has the same functionality as Check Out, but no documentation is required and no label is created.

Search

Various information can be retrieved from the local database, e.g. the history of various parameter set files.

to compare

Parameter sets can be compared. It does not matter whether these are available as a parameter set file or stored in the database.

Requirement-based parameter set management As stated above, this is the core of the new parameter set management method, the requirement-based management of the parameter values.

requirements tree

Requirements are structured hierarchically.

Each request is typed in relation to the request hierarchy:

Type = 0, request group type = 1, base request type = 2, combination request

Requirements in the request hierarchy are differentiated by status:

Status = '', Active (e.g., space) Status = 'H', historical

request group

A requirement subordinated to further requirements is a requirement group. This is clearly marked with type = 0 in the request hierarchy.

Operations for requirement groups:

To change:

Allowed: Change the name of the request.

Clear:

If no requests are subordinate, then actually delete them.

New:

A requirement group can always be created in the top level of the requirement hierarchy. In a lower level, a requirement group can only be created if the superordinate requirement itself is a requirement group to which no requirements of type 1 or 2 are still subordinate. basic requirement

A base request is a request that is subordinate to a request group but is not itself a request group. This is marked uniquely in the request hierarchy with type = 1.

A base request is subordinate to exactly one requirement group.

Basic requirements operations:

To change:

Allowed: Change the name of the request.

Not allowed: The assignment of the base requests to another request group is not permitted, unless the basic request is neither contained in combinations nor assigned to parameter values or vehicles.

Clear:

If parameter values or vehicles are assigned or the base request is assigned to a historical combination, then set status to historical. If no parameter values and no vehicles are assigned, and not part of combinations then actually delete.

New:

A base request can only be created as a subquery of a request group if it is not yet subordinate to sub-requests or if the already subordinate requests themselves are basic requirements.

combined request

If existing basic requirements are combined below a separate requirement group, a combination request is created (combination). These are clearly identified with type = 2 in the request hierarchy. Consequence:

The basic requirements are contained in the request hierarchy exactly once with Type = 1 and possibly at least once with Type = 2.

Operations for combinations:

To change:

Allowed: Change name / request name.

Not allowed: Assign the base requirements of this combination and assign the combination to another requirement group.

Clear:

If parameter values or vehicles are assigned, then set status to historical.

If no parameter values and no vehicles are assigned, then actually delete them.

New:

A combination request can only be created as a sub-request of a request group. It is created by subordinating at least two already existing basic requirements that belong to different requirement groups. All combinations that are subordinate to a requirement group are composed of basic requirements whose requirement groups are identical.

Relationship parameter value / requirement

The values of a parameter are always assigned only basic requirements or combinations.

Relationship parameter value / requirement group

The values of a parameter are always assigned only requirements of the same group of requirements. Consequence 1:

If the composition of the basic requirements of requirement groups or combinations changed, then the assignment to the parameter value would also change.

Konsequenz2:

The (historical) structure with respect to the combinations must be preserved because a combination can be assigned to a parameter value.

Konsequenz3:

The (historical) structure with respect to the base requirements subordinate to a requirement group must be preserved because a base requirement can be assigned to a parameter value.

Assignment parameter value / request

Requests are assigned to the parameter values when importing or checking in parameter sets to the parameter set management database.

Import:

If no information is yet stored in the database, then everything must be specified manually during import (basic requirements and / or combinations).

Check in:

If information is already available in the database, the relevant requirements (base or combination) are determined for each parameter during check-in and offered to the user for selection. Find the relevant requirements for a parameter:

Define the last saved parameter value for the parameter. These are assigned one or, in the case of a combination request, multiple base requests. With reference to the higher-level requirement group (s), all requirements that are permissible for an assignment result.

Only the appropriate basic requirements are displayed in the selection for the assignment of the requirements to the parameter values to be checked.

Assignment of a request to the parameter value:

The parameter value is assigned the default base requirement if the relevant requirements for this parameter are also basic requirements. Otherwise, the matching combination request is searched for based on the selected base requests if a combination was previously set for this parameter.

In conclusion, it can be stated that the variant-based management of parameter sets can also be referred to as requirement-based parameter management, since, starting from the requirements, the variants of the parameter sets result.

Claims

claims

1. A method for generating and managing data for the application of electronic control devices for a motor vehicle, comprising: a data model which describes the dependencies of the variables that are relevant for control devices,

Rules for data management, which define the interactions between parameters / parameter values and requirements.

2. The method according to claim 1, characterized in that the parameter sets are provided with ei¬ ner versioning.

3. The method according to claim 2, characterized in that partial parameter sets are provided with a versioning.