The underlying idea of a feature-based design in body electronic development is that such systems can be described by means of standardized modules with design-specific interactions. Thus, the identification of such basic functions and the development of respective feature models are a prerequisite prior to any feature-based design. Such models typically are archived as re-usable components in a Feature Library. Examples of feature models in Body Electronic Systems are:
The Feature Model: Seat Heating figure depicts the structure of a Seat Heating feature model. Feature models are functional models, i.e. they do not reveal implementation details. Their top-level structure corresponds to the hierarchy level 2 structure outlined in Functional System Design Methodology Roadmap respectively in the Typical Rational Statemate Structure of Hierarchy Level 2 with State-based Behavior Embedded in the Control Activity figure. Feature models are generic and have purely logical interfaces.
An ensemble of basic feature models with specific interactions can be grouped within a macro, called a feature interaction model. In such a model, the feature interactions are decoupled from the feature blocks and described in an additional functional block called an arbitrator. Arbitrators might be interpreted as “intelligent switches.” The Feature Interaction Model: Seat Controller figure shows a Seat Controller module as an example of a feature interaction model. It combines the following basic features:
The Seat Feature Arbitrator describes the specific behavior of the Seat Heating in this configuration:
●Refer to the Feature Model: Seat Heating figure. If the Seat Venting was ON and is switched OFF during this time, the Seat Heating will also be switched OFF. The Arbitrator then shall generate a respective RESET event and send it to the Seat Heating module.
Feature/feature interaction models are verified and validated through simulation. Test scenarios are derived from respective requirements.
Note: Not only the Feature Interaction Model itself but also its top-level functions (feature models and the arbitrator) shall be generic, thus enabling an easy partitioning to different ECUs (refer to System Partitioning).