Variants
With variance management features, the VEC supports two dimensions of variance. VariantConfigurations and ApplicationConstraints. VariantConfigurations define the validity of an element based on characteristics of the product itself, such as features, functions, options or technical characteristics. ApplicationConstraints define the validity of an element based on conditions "around" the product like manufacturing schedules and change management, association with a specific product derivative or factory dependencies. VariantConfigurations are expressed by a LogisticalControlString or LogisticalControlExpression, typically some kind of Boolean logic in a company specific syntax. ApplicationConstraints are expressed by a concise semantic with attributes and relations or by using EffectivityControlKeys, which are unique references in the logisitics/change/scheduling control systems of an organization.
All elements in the VEC that could be subject to product variance are ConfigurableElements (classes that are derived from ConfigurableElement). Since most variant management conditions do not exclusively affect only one element, ApplicationConstraints and VariantConfigurations are embedded in their own container Specifications, the ApplicationConstraintSpecification and the VariantConfigurationSpecification.
Till VEC 2.0 a ConfigurableElement could only reference a single VariantConfiguration.This is true, if you consider only one specific context, however, there can be different variant management contexts for a single element. Different contexts might be defined by ApplicationConstraints, such as differing variant conditions for different product derivatives or the change of VariantConfigurations over the time. Another reason for different contexts might be, that VariantConfigurations are based on a defined set of variant codes (a universe of variance). Multiple universes can coexist in an organisation and there are a variety of reasons that justify their existence, for example productlines might define their own variant codes and semantics, the variant codes (e.g. feature model) might different for a set of building blocks compared to an actual vehicle, or the variant codes of a generic E/E-component might different from the ones in a specific usage.
Such a context is defined by a combination of ApplicationConstraints and a specific VariantConfiguration.ConfigurationType and is represented by a ConfigurationConstraint. With the ConfigurationConstraint, a ConfigurableElement can have multiple VariantConfigurations. However, an element shall only have one VariantConfiguration for a specific context (combination of ApplicationConstraints & VariantConfiguration.ConfigurationType). If an element has multiple variant conditions within a context, those shall be expressed by the boolean logic within the VariantConfiguration.LogisticControlExpression.
Note: With VEC 2.0.2 the direction of the assocation between ConfigurableElement and ConfigurationConstraint has been inverted and the ConfigurationConstraintSpecification has been introduced as container for the ConfigurationConstraints. The former approach, with the ConfigurationConstraint contained in the ConfigurableElement, had the effect, that a change of the configuration information resulted in a change of the ConfigurableElement itself. This in turn means a change or addition of configuration information results always in change of the original document. However, when reusing engineering artefacts it is a common approach to configure the elements not until they are used. Configuration information is added in the context of usage and not in the context of definition. By extracting the ConfigurationConstraint into an independent specification it is now possible to add configuration information in a later stage of the process.
Note: The direct associations between ConfigurableElement and ApplicationConstraints and VariantConfigurations have been deprecated with VEC 2.0 and have been kept only for backwards compatibility. They will be removed in a future version. It is not valid to use these associations in combination with ConfigurationConstraints.
Note: Please refer to the detailed class description for information about which elements inherit from ConfigurableElement.
Note: VariantConfiguration.logisticControlExpression has been introduced as an alternative attribute for VariantConfiguration.logisticControlString. For the logisticControlExpression the prostep ivip project group "VES-WF" wants to introduce a defined syntax in the future.