Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data

Definitions

• the invention relates to a method for generating and managing data for the application of electronic control devices for a motor vehicle.
• 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.
• 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.
• 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.
• the set of all parameters that belong to a software version is initially free of values.
• 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.).
• 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.
• a parameter variant indicates a specific status for the parameter.
• An example is the distinction between development and series status.
• 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.
• 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.
• a new version of a parameter set is created.
• Each version of a parameter set receives a unique label for the versioning.
• 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 most current valid parameter set for the latest vehicle variant, or historical versions of the parameter set can always be determined for a model.
• FIG. 1 shows the data model of the present invention
• Figure 2 den the schematic structure of the parameter set management.
• Fig. 1 is a so-called class diagram of the data model (which is part of the invention) is shown.
• UML Unified Modeling Language
• the boxes represent “classes” and the connecting lines represent "associations”.
• 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.
• the data model on which the software is based can be described.
• the class diagram is self-explanatory and therefore requires no further words.
• 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.
• the master data 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.
• Parameter set management implements the main functions described in the following sections.
• the database 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.
• 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.
• the documentation must be carried out on the levels parameter set, parameter and parameter value.
• a label is assigned for the parameter set.
• 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.
• saved parameter sets can be checked out of the database.
• a parameter set can be generated for this.
• the documentation is to be carried out on the parameter set level.
• a label is assigned for the parameter set.
• Various information can be retrieved from the local database, e.g. the history of various parameter set files.
• Parameter sets can be compared. It does not matter whether these are available as a parameter set file or stored in the database.
• Each request is typed in relation to the request hierarchy:
• 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.
• a base request is subordinate to exactly one requirement group.
• 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.
• 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.
• 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.
• 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.
• Requests are assigned to the parameter values when importing or checking in parameter sets to the parameter set management database.
• the relevant requirements are determined for each parameter during check-in and offered to the user for selection. Find the relevant requirements for a parameter:
• 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.
• 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.

Landscapes

• Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Data Mining & Analysis (AREA)
• Databases & Information Systems (AREA)
• Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Stored Programmes (AREA)

Priority Applications (1)

Applications Claiming Priority (2)

Publications (1)

Family

ID=35645891

Family Applications (1)

Country Status (1)

Cited By (1)

• 2005
  • 2005-10-06 WO PCT/DE2005/001785 patent/WO2006042501A2/fr active Application Filing

Similar Documents

Legal Events