VehicleFeature represents a special kind of feature intended for use on Vehicle Level. The main difference to features in general is that they provide support for the multi-level concept (via their DeviationAttributeSet) and several additional attributes with meta-information specific to the vehicle level viewpoint.<br/><br/>Constraints:<br/>[1] VehicleFeatures can only be contained in FeatureModels on VehicleLevel.<br/><br/>Semantics:<br/>A VehicleFeature is a functional or non-functional characteristic, constraint or property that can be present or not in a vehicle product line on the level of the complete system, i.e. vehicle.<br/><br/>Extension:<br/>Class<br/>
This attribute states whether the VehicleFeature is customer visible (in contrast to a VehicleFeature that is e.g. technically driven).<br/><br/>VehicleFeatures describe the system's characteristics on the level of the complete system and on a high abstraction level but they can still have a strong technical viewpoint. Therefore, they are usually not suitable for being directly presented to the end-customer. There are two approaches to deal with this situation.<br/><br/>(1) The simple approach uses this attribute to denote those VehicleFeatures that are suitable for immediate end-customer configuration: if this attribute is set to true, then the feature will be directly presented to the end-customer for selection or de-selection; if set to false, then the feature will be hidden from the end-customer and is thus reserved for internal configuration.<br/><br/>(2) The more sophisticated approach is to define a dedicated product feature model to capture the customer viewpoint (available in the variability extension) in addition to the technical feature model on Vehicle Level and to provide a configuration decision model that maps configurations of this end-customer-oriented product feature model to the core technical feature model on Vehicle Level. This approach is much more flexible because the customer-view on the product line's variability can be structured freely and independently from the core technical feature model; furthermore, this approach can cope much better with evolution because the end-customer-oriented feature model can be evolved independently of the core technical feature model (and vice versa). When applying this second approach, this attribute isCustomerVisible will no longer be used, i.e., its value will be ignored.<br/><br/>The simple approach #1 is suitable for simple product line scenarios. Approach #2 should be used for complex scenarios with large core technical feature models and/or longer evolution periods of the overall product line infrastructure.<br/>
A VehicleFeature marked as a design variability rationale captures a variant showing up on a concrete artifact level that needs to be modeled on the Vehicle Level as well, in order to be directly available for immediate configuration on Vehicle Level. It is, from the abstraction layer's point of view, not a true Vehicle Level feature.<br/><br/>If true, then isCustomerVisible is usually false but there may be rare exceptions.<br/>
This attribute describes if the VehicleFeature is removed (but kept in the database for tracking of evolution, which is required by the multi-level concept).<br/>
Name: deviationAttributeSet
Possible deviation attributes included in the VehicleFeature. If the VehicleFeature is part of a reference feature model in the context of multi-level feature models, the attribute can constrain the allowed deviations for the respective referring features.
