The simplest approach to managing change is to introduce the notion of a version. This approach is already well known and used for documents, software, parts, and CAD drawings. Basically, a version number is assigned which is incremented for each revision of the information that is versioned. Version numbers can be structured, for example, many PLM systems divide the version identifier into a revision and an iteration such as B.3 (Revision B, 3rd iteration).
This way of versioning becomes a challenge when several objects are related, each of which are versioned. If object A refers to and depends on object B, should the version of A be changed if we only update object B?
In software development, where thousands of files make up an application, the approach to versioning has evolved from a simple local strategy with a version identifier per file, to advanced distributed and graph-based approaches such as Git.
A product model, consisting of a large number of configuration parameters and rules, is fundamentally no different from managing the source code for a software application:
Configit Ace® uses versioning to manage changes to configuration parameters and rules in a way that resembles how modern version control systems manage software.
In Ace®, the single source of modeling data truth is in the master branch. To modify any data in master, the user creates a work item. Within the work item, all changes are done in isolation from date in master and any other work items. This allows modelers to create, change and delete data without worrying about impacting other people’s work or affecting downstream systems that consume data from master. It’s only when the work item is promoted that the changes are brought into master.
This approach to versioning of the modeling data supports concurrent changes to the model in a controlled manner. When looking at the data in master, it changes whenever a work item is promoted, as illustrated below. The rebase operation allows changes to be brought into a work item from master.
Notice how this versioning approach is global: given the version identifier for the data in master, it is possible to identify the work items that led to the given version. In the above example, the master branch contains four versions: the “white”, “green”, “purple” and “red” version. If the configuration was done based on the “green” version, and this configuration later turned out to be invalid, the modeler could use Ace to inspect the product models as they looked right after the “green” work item was promoted to master. You can then debug the models and find the error, even though the rules may have changed several times since the “green” version.
The Ace history provides an overview of the work items that have been promoted to master:
Each work item can be expanded to show all details of the data that was modified in the work item.
For example, if a new color was introduced in a model, it would look like this in the Ace history:
This information is also available for each data object in Ace.
For example, the rule history shows the changes of the rule done in each work item:
Versioning is an essential approach to manage immediate changes: when a work item is promoted, the changes are immediately brought into master. But consider the scenario where a change is to occur later in the future such as on next year’s model. One approach is to wait a year to make the change, or one could have a separate configuration definition of next years model. However, both approaches quickly becomes impractical when there are multiple future changes to track and they occur at different points in time.
Effectivity is used to define when information, such as features on a configuration model or configuration rules, is valid. Some organizations use effectivity as the only way of managing changes, however, effectivity and versioning really go hand-in-hand to manage changes over time.
For example, consider a legal requirement that all cars to have a reverse camera in Germany starting on January 1, 2023. Initially, a rule is added to the configuration model which specifies that if the market is Germany, then the reverse camera must be selected. Effectivity is used to specify that the rule applies from January 1st, 2023 and onwards, illustrated below.
This allows the modeler to analyze the effect of the rule on the overall configuration solutions by setting the date to sometime after January 1st, 2023.
Imagine that the requirement changes: instead of January 1st, 2023, the legal requirement does not take effect until June 1st, 2023. The rule is updated by changing the effectivity of the rule to reflect the new date and this causes a new version of the rule (even though the logic of the rule is unchanged):
In this example, it may be that the legal requirement is also adopted by France. This requires yet another change to the rule, yielding a third version:
To support changes over time, Configit Ace® uses effectivity on all data objects such as configuration parameters and rules to manage when the object takes effect.
It is a complex task to create configuration models with parameters and rules. But the real work starts after the initial model has been completed as the capabilities of products change over time. Configit Ace® has implemented a versioning strategy known from modern software development and combined it with effectivity known from automotive and aerospace engineering to provide unique set of capabilities to manage changes to configuration models over time.
Ace provides advanced tools to analyze and understand how these rules interact over time, providing companies business benefits such as higher quality products, introducing new products faster to the market and a more efficient product development process.
Learn more about Configit Ace®,
including features, benefits, and technical details