Patent Application
20140214783
This nonprovisional application claims priority to European Patent Application No. 13152999.2, which was filed in Europe on Jan. 29, 2013, and to U.S. Provisional Application No. 61/757,971, which was filed on Jan. 29, 2013, and which are both herein incorporated by reference.
1. Field of the Invention
The present invention relates to a computer-implemented method for data management of product variants in control unit development.
2. Description of the Background Art
Methods for data management of product variants are known from widely disparate areas of technical development, and are used primarily in technical products whose development requires the product to be adapted to different requirements, for example. The complex task of data management in the development of product variants is discussed below for the field of control unit development.
Control units today are typically understood to be robust small computers for industrial use that usually have integrated I/O interfaces. Frequently equipped with real-time operating systems, control units execute programs that connect in the broadest sense through the I/O interface to a technical process which is to be controlled and that act on this process in a desired manner. Control units of the type described are used intensively in automaking, for example. The development of control units has in the meantime become an important element in the development of production motor vehicles.
The development of a control unit can be subdivided by topic into different fields, which hereinafter are referred to as domains; these domains can have different components. In control unit development, a domain can be the domain of requirements specifications with the different requirements specifications as components, for example. Additional possible domains are the domain of test cases for testing the various requirements, the domain of test system descriptions—for example, in the form of a hardware description of a hardware-in-the-loop test system, the domain of mathematical models for simulating the control unit environment, and the domain of parameter sets for parameterization of the models; this listing is by way of example and may be expanded as desired.
Typically, different product variants arise in the development of complex products. These product variants differ from one another in certain product features. The sum of all product features taken together makes up the variant model. The product features critical for making a distinction can be broken down into categories that are referred to below as feature categories. Such a categorization of the product features facilitates the overview of product features, but is not essential for the teaching claimed herein. Possible examples of different feature categories in control unit development are the country where the control unit is to be used, with the product features Europe, North America, and Asia; the type of power plant (self-ignited engine, spark-ignited engine), with sub-product features of 4, 6, 8, and 12 cylinder engines; or vehicle body with the sub-product features of sedan, station wagon, and convertible. The product features are possible characteristics that different variants of the product can differ by; accordingly, product variants result from the selection of product features that characterize a specific product variant. In order to take the aforementioned examples further, one product variant could be the control units for four-cylinder self-ignited engines intended for the European market, for example. Another product variant could be the control units for self-ignited engines intended for the American market, where the necessity for distinguishing between these different product variants can arise, for instance, from different manufacturer requirements in the different markets or from different legal requirements in the said regions, for example.
It is evident in view of the background presented that various components in the domains only apply to certain product variants. If it is necessary to distinguish between, for example, the product variants of the control units for four-cylinder self-ignited engines for Europe and the USA, then there may possibly be requirements that differ, at least in part, in the domain of the requirements specifications, test cases that differ, at least in part, in the domain of test cases, controls that differ, at least in part, in the domain of control algorithms, or parameters and/or parameter sets that differ in the domain of parameters or parameter sets.
On the whole, it represents a significant problem to reliably track the dependencies of product variants and components during a development process, particularly when feature categories change within the variant model. Another problem can include simply in reliably identifying the valid components from certain domains corresponding to a certain product variant, particularly when the information on the components of the various domains is only stored in a distributed manner. Finally, it is thoroughly problematic to maintain consistency in the indicated variety of information that composes and accompanies the development project. For instance, a change in the variant model raises the question of the degree of change in the relationship of an altered product variant to the components.
It is therefore an object of the present invention to provide a computer-implemented technical solution with which it is possible to resolve the problems discussed in connection with the data management of product variants in control unit development.
The object derived and presented above is attained in a computer-implemented method for data management of product variants, in particular in control unit development, by the means that initially product features in a variant model are specified, that components in at least one domain are specified, and that feature/component dependencies are defined by associating components with product features. It is immaterial whether the product features or the components are specified first; all that is important is that the user of the method is given the opportunity to systematically specify product features and systematically specify components in domains, with it being possible to subdivide the product features into feature categories. The specification of product features and components can take place in a database, for example. The feature/component dependencies are information that indicates what component is linked to what product feature or product features, or in other words, what product feature a certain component is relevant for. One component can of course also be relevant for different product features.
By means of the storage of the defined feature/component dependencies, which can be stored in a memory of a computer, the method according to the invention makes it possible to subsequently specify at least one product variant of interest by selecting product features, and to specify at least one domain of interest, whereupon the components from the domains of interest associated with the product variants of interest can automatically be identified through automated evaluation of the previously defined feature/component dependencies. The automated output of the identified components then takes place. Accordingly, the product variant characterized by the selection of product features functions more or less as a filter that is used on the totality of the domain data in order to obtain therefrom the components of interest for the product variant.
The automated evaluation of the feature/component dependencies can include, for example, in that all feature/component dependencies are searched, and the particular dependencies are extracted that include a connection to at least one product feature of the specified product variant of interest while simultaneously being connected with a component located in the specified domain of interest. The automatic output of the identified components can have an informative character, for example through display of the components previously identified automatically, but the identified components can also be output as data units, and thus be made available for further processing. It is possible, for instance, that, using the computer-implemented method described, all the test cases are identified that are—also—connected with at least one product feature of the specified product variant of interest, and are delivered directly to a test system in which a corresponding test is carried out.
In an embodiment of the method, provision is made for the variant model, the domains, and the feature/component dependencies to be collected in a common database. In this exemplary embodiment, the entire development process is represented in a uniform, common database, for which reason the computer-implemented method has complete information on all dependencies at all times. In particular, the common database here includes not only organizational information on the components of the domains, but also the actual information processed in the various domains. Accordingly, the common database doesn't only have the information that certain test cases and test sequences exist for the control unit, that certain mathematical models exist for simulating the control unit environment, and that certain parameters are present, but instead it contains and manages the test case descriptions, the code for the test sequences, the description of the mathematical models in terms of data and content, and the parameters with the values associated with them, in and of themselves.
For example, when one of the mathematical models is processed by the software tool that was used to produce the mathematical model, then this software tool ideally accesses the common database. On the whole, then, the procedure according to the method implements a work environment in the manner of a client-server system in which all the various clients working with different domain data work with a consistent state of the uniform database. Preferably, in this case the computer-implemented method is implemented by a single, integrated application that has access to the entire database. In the case of a method implemented in this way and a database configured in this way, it is no longer necessary to acquire corresponding information from the different domains if these domains are equipped with different development tools and separate data administration. While this may indeed still be the case in an integrated solution for data management of product variants, the data of interest from the various domains will in any case also be kept available along with the information on the variant model in the uniform, common database.
In a further development of the method, the defined feature/component dependencies are existence dependencies and/or value dependencies. In the case of an existence dependency, the only information of interest is that a dependence exists between at least one product feature and a component of a domain. In the case of a value dependency, the actual data concealed behind the associated component of the domain is additionally of interest. Thus provision is also made that at least one data item is specified for the component involved. These data can be the values with which parameters are populated, for example. For instance, a parameter P1 in the control of an anti-lock braking system can have different values for a control unit intended for the European market and a control unit intended for the US market. In the case of a value dependency of this nature, provision is made in particular that at least one data item can be stored for each feature combination during specification of multiple dependencies between a component of a domain and one or more product features.
In an embodiment of the computer-implemented method, provision is made that the components within a domain are stored in separate data units, e.g., in separate files. In the case of the domain of requirements specifications, this means that the specifications are stored separately and are available as separate data units, which is to say that they are not mixed with other specifications in a common data unit. This is especially advantageous when the automated evaluation of the feature/component dependencies includes an existence test for the dependency, which is to say all that is being tested is whether a dependency exists between the specified product variant of interest and a component in at least one specified domain of interest. In this case, the option exists to output the data units associated with the identified components without the intermediate step of a special extraction; in particular the data units can be output in unchanged form.
In an embodiment of the method, the components within a domain are stored in a common data unit so that the components are not present separately, in other words. This can make sense for the storage of parameters and parameter sets, for example. For instance, certain parameters and parameter sets for parameterization of a mathematical model or of a control algorithm may differ only through different values for certain parameters, wherein the parameters are themselves the same, or at least some of them appear in multiple parameter sets. Through skilled organization of multiple parameter sets in a common data unit, it is possible to obtain and communicate a good overview of similarities and differences between the various parameter sets in a very simple manner. When the components within a domain are stored in a common data unit, then provision is made for the automated evaluation of the feature/component dependencies to initially include existence test for the dependency, wherein the entries associated with the identified components are extracted from the common data unit and are output. Once again, the output can have merely an informative character, but it can also serve to make the extracted data available for other automated processes, in particular wherein the identified entries from the common data unit are output in a separate file.
In an embodiment of the method, the product features are defined in a hierarchically structured manner. Here, hierarchically structured means that product features are subdivided into product subfeatures, wherein the hierarchical structure can also propagate to the product subfeatures on lower levels of the hierarchy. One possible example for such a hierarchical structuring of product features is the regional association. For instance, the feature category “countries” could have the product features “Europe”, “Asia”, and “North America.” The product feature “Europe” could be hierarchically structured, e.g., into the product subfeatures “Germany”, “France”, “Great Britain”, and “elsewhere”. In a further development of the method claimed, the hierarchically structured definition of the feature categories makes it possible for a feature/component dependency defined for a product feature on a higher level of the hierarchy to also be transferred to variants that have the product feature on a lower level of the hierarchy. When explained using the above example, this means that a component dependency defined for the variant of European self-ignited engines, for instance, also extends to sub-variants that rank lower on the hierarchy, and hence that the defined component dependency also applies to the self-ignited variants that have been defined as dedicated for “Germany”, “France”, “Great Britain”, or “elsewhere”. Hierarchical behavior of this nature is especially advantageous for the case of data administration in which the components have been stored within a domain in a common data unit. Thus, in a tabular listing of all parameter sets for the relevant variants, for example, it is very easy to display and determine whether or not certain parameters also apply to hierarchically subordinate variants. It is then immediately evident whether a parameter exists at all for a particular variant, which is to say that an existence dependency is present. In the case of the existence of a parameter for a certain variant, the value can then also easily be transferred to lower-ranking variants on the hierarchy; the subordinate variants then depend on the higher-ranking variants in terms of value, or in other words a value dependency is present. In addition, provision can be made for value transfers into lower-ranking variants on the hierarchy to only take place when no dedicated value specifications exist here.
An embodiment of the method provides for one value dependency to be defined in each case between one component and multiple product features in multiple feature categories. If VK1, VK2, . . . , VKn are the feature categories in question and vk1, vk2, . . . , vkn are the applicable quantities of the feature/component dependencies in the form of value dependencies, then according to the invention vk1*vk2* . . . *vkn value specifications are made for the component for the various combinations of the product features.
Within the scope of the computer-implemented method under discussion, the defined feature/component dependencies can also be used in a further-reaching way to ensure consistent data management. Thus, provision is made in one embodiment of the method according to the invention that when the deletion of a previously defined product feature is stipulated, a determination is made as to whether the product feature to be deleted is associated with components, something which is possible at any time through evaluation of the existing feature/component dependencies. In the event that the feature to be deleted is indeed associated with components, a conflict exists. Attention is initially drawn to the conflict in that the existing feature/component dependencies are pointed out, and the deletion of the product feature to be deleted is suspended.
In an embodiment of the method, however, not only is attention drawn to a case of conflict that would result in a loss of some data, but in addition a resolution to the conflict is actively and automatically offered. This is accomplished by the means that, when an existing feature/component dependency is present, a new version of the database being managed is generated in the form of a copy of the database being managed—if applicable after approval by the user—wherein the product feature to be deleted is removed in the newly generated version of the database being managed, or the conflict is otherwise resolved. For example, a feature/component dependency could reference a higher-ranking product feature if a lower-ranking product feature has been deleted. This measure ensures that the product feature to be deleted cannot disappear from the data management of the product features. As a result of the versioning, product variants to be deleted are preserved in an old version, where they continue to be accessible. The further development of the variant model, as well as the aggregate having variant model, domains, and feature/component dependencies, can thus move forward in new versions of the database. In an advantageous further development of the method, the feature/component dependencies associated with the deleted product feature are deleted as well, since one of the two partners in the connection is no longer present. The creation of a copy of the database being managed includes, in particular, copies of the variant model, the domains, the definition of product features, and the definition of feature/component dependencies.
In another measure to promote consistent data management, the components that have feature/component dependencies solely with the deleted product feature are automatically deleted from the database being managed. This measure can also be made subject to the approval of the user of the method so that no unintended or imprudent deletions take place in the database.
The deletion of a product feature is not the only condition under which creation of a new version can seem sensible or necessary; instead, the desire to create a new version of the database can also arise for other reasons, for instance in order to document a stage of development. Surprisingly, it has become apparent that handling different versions can easily be supported by the proposed method for data management of product variants. Thus, in a further development of the method, a new version of the variant model is generated through a modifiable copy of an old version and/or a new version of the domain model having all domains and all feature/component dependencies is generated through a modifiable copy of an old version of the domain model. Using the further developed method, it is therefore possible to generate new versions of the variant model and/or of the domain model. Thus it is possible, for example, to continue developing the variant model in a new version while the old variant model is still being processed together with the old domain model and the feature/component dependencies between these two models.
When a new version of the variant model has been created, the desire will arise to again establish an association between the variant model in the new version and components in the applicable domains, while a new version of the domains does not yet exist. Provision is thus made according to the invention that, during a change from an old version of a domain model to a new version of the variant model, first a new version of the domain model is created by copying the old version of the domain model, and the feature/component dependencies associated with the old version of the variant model are automatically transferred to the new version of the variant model, with the automatic transfer taking place through the identification of correspondences. In particular, provision is made for the automatic identification of correspondences to take place directly through evaluation of explicitly stored references—and thus also independently of names—through comparison of names and/or feature combinations of the feature categories in the old version of the variant model with names and/or with feature combinations of the feature categories in the new version of the variant model.
Further scope of applicability of the present invention will become apparent from the detailed description given hereinafter. However, it should be understood that the detailed description and specific examples, while indicating preferred embodiments of the invention, are given by way of illustration only, since various changes and modifications within the spirit and scope of the invention will become apparent to those skilled in the art from this detailed description.
The present invention will become more fully understood from the detailed description given hereinbelow and the accompanying drawings which are given by way of illustration only, and thus, are not limitive of the present invention, and wherein:
a, 9b show the versioning of the database in the case of conflict when a defined product feature is being deleted;
a, 10b show the automated resolution of inconsistencies in the database through versioning and deletion of incomplete feature/component dependencies; and
Shown in
Accordingly, the “country” feature category 2 breaks down into the product features 1, namely Europe, Asia, and North America, with the Europe product feature being subdivided into the further product features DE, GB, FR and elsewhere. The product features can thus be structured hierarchically. Similar applies to the “engine” feature category 2, which deals with the power plant of the vehicle for which a certain control unit is to be developed in the present example. Accordingly, the “engine” feature category 2 breaks down into the product features 1 of self-ignited and spark-ignited. The aforementioned product features 1 are then further subdivided into different engine sizes, here shown as a function of the number of cylinders.
In the exemplary embodiment shown, the variant model 1, the domains 5, and the feature/component dependencies 6 are collected in a common database, which is to say that the data are managed in an integrated software solution and there is no need to gather the data from other applications through different software interfaces. Of course, the information collected in a common database may optionally be used and processed by different applications that are not part of the integrated software solution; in the present case, the data to be processed and the data that also have been processed by different project groups are organized centrally, with the overall result thus being a client-server structure.
Shown at the very bottom in
No parameter values have been specified for the product variant V2 of the control units to be used for Great Britain for spark-ignited, mid size engines. In this case, the feature/component dependency defined for a product feature on a higher level of the hierarchy is also transferred to the variants that have the product feature on a lower hierarchy level. In the present case, therefore, the specifications located on a higher level of the hierarchy for the product variant V1 for Europe are transferred to the same type of motor for Great Britain as well, which is to say to the product variant V2. However, if some parameters have been populated with values for the product variant V2, at least in part, then the locally specified values take precedence over the values that could be transferred through a hierarchical value dependence. The same principle is also used for the product variant V3, which applies to control units of all other European countries as regards spark-ignited engines with eight cylinders. Here, too, the parameters a, b, c, d specified for the product variant V1 can be transferred to the product variant V3 because of the hierarchical relationships. What is important is that the choice of motor type in the product variants V1 and V2 is immaterial insofar as the dependency of the parameter relates solely to the Country feature category.
Shown in
An even further developed variant of the method is shown in
A further development of the claimed method is illustrated in
Version Ver. 2 of the variant model is subsequently changed; for example, the product feature M4 is deleted, and in addition the new product features M2′ and M6 are added. Once the variant model in version Ver. 2 has been changed relative to version Ver. 1, the desire arises to transfer the domain model to version Ver. 2 of the variant model, as well. To this end, provision is made that, during a change from an old version Ver. 1 of the variant model to a new version Ver. 2 of the variant model, first a new version Ver. 2 of the domain model is created by copying the old version Ver. 1 of the domain model, and the feature/component dependencies 6 associated with the old version Ver. 1 of the variant model are automatically transferred to the new version Ver. 2 of the variant model through the evaluation of references or through the evaluation of correspondences. The copying of the domain model from the old version Ver. 1 to the new version Ver. 2 is indicated in
The invention being thus described, it will be obvious that the same may be varied in many ways. Such variations are not to be regarded as a departure from the spirit and scope of the invention, and all such modifications as would be obvious to one skilled in the art are to be included within the scope of the following claims.
| Number | Date | Country | Kind |
|---|---|---|---|
| EP 13152999.2 | Jan 2013 | EP | regional |
| Number | Date | Country | |
|---|---|---|---|
| 61757971 | Jan 2013 | US |
