In this article, we will take a look at the feature variant handling which is the ability to deal with feature differences within a product line directly in the design model. This is an outstanding feature if you have software-driven variations in your product and it’s the first time that feature variation modeling has been seamlessly integrated into a general modeling tool.
To define what we mean with variants, consider a product that you need to provide in two or several distinct versions in terms of the functionality the product have. You might have a concept of a top-of-the-line version and a basic version and maybe some additional feature variants. The traditional way to deal with this in C/C++ is either to use conditional compilation to create a set of different builds of the software, or to use code that somehow can differentiate in runtime what product variant it is running on. But if you’re using a modelling tool you are traditionally left with checking in runtime, which for complex and large models can be quite expensive in terms of runtime performance, or you can essentially create a set of copies of the design model and enhance them with the desired features.
The variant handling introduced in IAR Visual State 8.1 adds a third choice - the ability to design in feature variations directly in the design model and then at code generation time decide which variant to code generate for. And not only at code generation; you can for example at any time choose to show only the features that are part of a specific variant directly in the design tool. The same of course goes for exercising the selected design variant in the IAR Visual State test and simulation tools.
Design variations pop up in many different fields, but for the automotive industry this is a big challenge and even more so as the amount of software in modern cars continues to increase. Taking into account things like different regulations, different customer preferences and different acceptance of pricing levels in different regions will inevitably lead to a large number of variations and we haven’t even started talking about the tangible stuff like different engines, different gearboxes, head-up displays, multimedia functions etc. All this variability will in the end create complexity in the software, but the level of software complexity is probably different by magnitudes if we are dealing with the compartment lighting or the instrument cluster and multimedia head unit.
The instrument cluster and the multimedia head unit can be seen as focal points for a lot of this variation to come together - to be able to display relevant information in a modern car, the instrument cluster and head unit must be exposed to the variations in for example transmission (automatic/manual), navigation (Is navigation present and should the cluster in that case display simplified driving directions side by side with speed?), head-up display (present, or not) and a myriad of other features.
One of the interesting things with a lot of automotive software is that it is inherently state and event driven and this is especially true for the graphics heavy cluster and infotainment systems in modern cars. Advanced state machine tools like IAR Visual State are necessary to combat the complexity of the state machines used to keep track of the actual logic in the GUI design. IAR Visual State users in automotive routinely deal with state machines with well over 10,000 states and some are planning for state machines with 50,000 states and above!
With such a complex software environment it’s critical to be able to handle feature variation in a streamlined manner and this is where the newly introduced variant handling in IAR Visual State comes in.
Let’s look at a simplified example. Look at the picture below.
It’s a high-level representation of the possible audio sources. Below each region in the picture, there’s a hierarchical and possibly parallel state machine dealing with the logic for each input source. The semantics of hierarchical and parallel state machines is such that each region operates independently, but can interact with the logic in other regions and parts of the state machine. For this example we assume that a vehicle will always have a CD player, but both USB media and AUX inputs are optional. We can describe this by creating three features, CD, USB and AUX and associate them with each corresponding region. We can then create a set of variants that includes the relevant features. In the second picture below we at the same time show the definition of a variant and how it looks on the diagram when we tell the design tool to highlight the selected variant. These constraints are of course applied to every level in the hierarchy below any excluded item.
Variants and feature constraints can be applied at any level in the state machine hierarchy and on any type of design element, so also transitions, individual states and action functions can be included and excluded as dictated by the variant needs in the product domain.
A full-featured state machine tool like IAR Visual State is a perfect match for complex state machine design and both the design method in itself and the automation and test features of the tool make it an excellent choice for high-integrity systems governed by standards like ISO 26262, IEC 61508 and similar.
The variant handling ability is in itself a very powerful feature that can make dealing with complex state machines and variation hierarchies far easier and more predictable. But if we combine this functionality with the existing IAR Visual State functionality in the so called state machine API for off-line manipulation of design models we have an extremely powerful tool. This API can be used to create freestanding tools that can programmatically create and manipulate state machine designs in exactly the same way as a user of the tool, including creating design variations and features. An example of how this can be used is that the design models from a GUI authoring tool can be read and the corresponding state machine scaffolding can be created without any manual state machine design at all, including required design variations. Then the remaining logic can be created by hand. In this way it’s perfectly feasible to deal with state machines with 10,000 states and up.
To summarize: The variant handling ability of IAR Visual State in combination with other IAR Visual State features enables designs with less complexity that are at the same time easier to test and maintain.