prettify

October 29, 2018

Reusing self-written pvSCL functions


In order to simplify expressions or to share and thus reuse pvSCL functions between constraints, restrictions and calculations, pure::variants lets you store pvSCL functions in a so-called code library. In each model such a libraray can be defined and this is done by entering the code into the pvSCL Code Library properties page of a model as shown in the following picture.


Due to the fact that each feature and also family model can define code libraries and pvSCL functions defined in one model are also available in all other models of the same configuration space, sharing and reusing of pvSCL functions is very easy. However, defining the same function in more than one model, will redefine the function. Hence, which function is used may differ, since there is no explicit model loading order. That means, it is better to stick to the ODR even that this is not enforced by pure::variants.

September 28, 2018

Exporting an optionally filtered overview about multiple variant configurations

We often get the question from customers about a functionality to export multiple variant configurations in an Excel like fashion that may also be optionally filtered according to definable criteria like shown elements or attributes. Our answer is in almost all case just use the matrix, filter the elements and attributes as you like, and export the visualized information by using the build-in export functionality of the matrix view via the context menu. It is just that simple. 


Choosing the "Export Matrix ..." action from the matrix view's context menu opens a wizard where the user can for example configure the preferred output format. After specifying the output file, followed by pressing the Ok-Button the export is carried out and the file in the correct path is filled with the desired content.

August 22, 2018

Tooltips: The good, the bad and the ugly

pure::variants makes intensive use of tooltips. Whenever you hover over a model element, e.g., a feature, attribute, constraint, etc., a yellow tooltip pops up providing you with additional information on the model element.

The good 

I think this is utterly useful. All relevant information on the model element is displayed at once. Most notably the description telling the configuring user how to handle the model element, what to set, and last but not least the trace links to the system requirements or design specification. [Well, if the person who created the feature model was kind enough to write a good description, that is..., but we're all kind, aren't we?]


It is possible to copy text from the tooltip. It is even possible to click on hyperlinks in the description. All in all a fast and easy-to-use way to access the information. Super good.

The bad/ugly

Sometimes these tooltips get in your way. You just wanted to move your mouse and — bam! — there comes the tooltip. It can consume a large fraction of your screen. And in this moment you just wanted to focus on something else. Tooltips are really annoying when you are presenting your screen in a tele-conference and want to use your mouse to point out things on the screen. "As you see, there is a sub-feature below here and — bam! — sorry, you can't ... now this got covered by..." You get the point.

The good strikes back

We wouldn't want to end a blog post so negatively on a Monday morning after all. So,good news, everyone: the solution is right there in your menu bar!

 
This tiny inconspicuous button gives you all you need. Just turn off the tooltips when they get in your way. And it's just consistent that the functionality of this helpful button is described ... in a tooltip!! This one cannot be turned off.

July 26, 2018

Mapping values in pvSCL

Mapping a certain (input) value to another (output) value is a task that is often needed in code generation implementations. An example may be to map an input value to a specific enum constant name in the source code, which cannot be directly calculated from the input.

PVSCL neither has a map data structure, nor a switch/case statement. Not even "elsif". All of which would facilitate this task. This leads to the following ugly antipattern:
if inputValue = A then
    outputA
else
    if inputValue = B then
        outputB
    else
        if inputValue = C then
            outputC
        else
            if inputValue = D then
                outputD
            else
                ...
            endif
        endif
    endif
endif

The task of mapping input values to defined output values can, however, be solved more elegantly using a list of pairs (two-element lists) like this:
{ /* list of pairs */
{ A, outputA },
{ B, outputB },
{ C, outputC },
{ D, outputD },
...
}->pv:Select( pair | pair->pv:Item(0) = inputValue ) /* eliminate all pairs that have not the e.g., {{C, outputC}} */
->pv:Item(0) /* use the first pair from the set of pairs having the correct input value. */
->pv:Item(1) /* return the mapped-to output value, e.g., outputC */

The result of both code snippets is the same. The second one is just a lot clearer and shorter.

June 20, 2018

Finding unselected features


In large variant models (.vdm files) it is easy to overlook some features that you still wanted to deal with. They are currently unselected and the model is error free, but maybe you still planned to select some?

The art of saying no

First of all, there are two ways of having a feature not selected:
  1.  Unselected (empty).
  2.  Excluded.
Excluded features are explicitly marked as "NO!". You must do this with your mouse (right-click, exclude). In this case it is made explicit that you did think about this parameter and decided that you did not want it to be selected. Good, all done.

Unselected features, on the other hand, are, well, of course not selected, but they are not explicitly out, either. It's more like stating "not so sure". For example, in a second variant model (.vdm file) which inherits from this model, the unselected feature could still be either selected or excluded.

For this reason it is good practice to exclude features if you are sure you don't want them on.

But back to the start: imagine you started are in the middle of working with a large variant model: How can you see which features are still unselected?

 

A filter definition

pure::variants has the ability to filter features based on complex filter criteria, including the selection state of a feature. To access the filter dialog, simply right-click and select "Filter" from the context menu.

The following filter settings will show all features that are unselected:
This filter is composed of three main parts:
  1. The key part is at the bottom. "Selection Type" must be only unselected.
  2. The "Selector" must be empty, since unselected features are, well, unselected, no matter by whom.
  3. Since pure::variants filter mechanism is designed for conditions in the first place, you have to ensure that either no condition is defined at all or a condition that will always evaluates to true. To go the safe way, you define a condition "Class contains ps" that has zero filter effect for all element types.

A filter as shown in the screenshot will show you all unselected features. As soon as you select one of them, it disappears from the view.

If you want, you can save the filter definition if you give it a name. It then becomes accessible in the "Visualization" view to enable easy reusing it also on other models.
Finally, you can clear the filter in the context menu (right-click, clear filter).

May 7, 2018

The power of pvSCL

We get support questions and even customer requests about extending pvSCL's functionality with the mathematical operations for power or modulo. Since pvSCL is a programming language, especially a functional one, it allows to define new functions using the def  keyword and you are able to write not existing functionality by your own.

As an example the definition of the power function may be done in the following way.
def power(x,y)=
        if (y=0) then
                1
        else
                power(x,y-1)*x
        endif;


It can be used very easily by calling power with two parameters with x as the base and y as the exponent. For example, if you call power(2,3) you will get 8 as result. For sure, this power function is not a generic solution and it also doesn't support error handling in case of false usage, but if one respects the specific circumstance that the exponent is allowed to be only a non-negative integer, it will deliver the expected result reliable.

Supporting a modulo operation by self-writing a respective function is also very simple, leaving it up as an exercise for the reader!

April 3, 2018

Introducing the pure::variants Model Test Framework

The complexity and number of embedded systems is continuously increasing. For the development this means a growing number of product variants and configurations must be handled. Beside these general challenges, most of the products from the automotive, avionics, automation, and transportation domain are faced additionally with functional safety aspects, thus valid product configurations are especially important since misconfiguration of products could have fatal consequences.

pure::variants offers the possibility to model the variability and their dependencies and also to express attribute calculations or consistency checks using constraints. Moreover, it allows to running self-written scripts e.g. to transform variant model content to source code in pure::variants. Creating and maintaining variant management models and also such transform scripts is itself an engineering and development activity, and thus needs validation and verification.

To satisfy this demand, with release 4.0.12 of pure::variants it comes with the new feature pure::variants Model Test Framework for variant management models, which greatly simplifies regression testing for variant models. In more detail the Model Test Framework can test variant models on multiple levels:
  • Evaluation Validation tests - Does the evaluation produce the ...
    • expected general evaluation result?
    • expected selections and exclusions?
    • expected attribute values?
    • expected markers?
  • pvSCL code library test - Unit tests for your pvSCL code library functions
  • Transformation tests - Is the transformation result as expected?
Using the framework is easy: The tests itself are written using a specialized editor. Tests are organized in test suites and can be executed directly from the user interface at any time. In addition, to support continuous integration scenarios, the tests can be carried out by an automation task.

To test the new feature, you can download an example project (download password: example), which defines a test suite containing seven test cases from which six will pass and one will fail during the test execution. The following screenshot shows a test case opened in the specialized editor.


Beside giving general information like the test case's name and the used variant model during evaluation, you can specify the test case's Enabled status, add additional Tags and Values useful for grouping, searching, and conditional test case execution, and naturally a documentation of the test case itself. The execution of the test case can be started using the play button in the upper right corner. You can also perceive further tabs next to the General tab, where you can specify the tests case more in detail. As an example see the screenshot at the end of the post. However, explaining all the details of all tabs, the execution of test cases, the result format, and lots more, would be beyond the scope of simple blog post, thus the reader is directed to the manual of pure::variants Model Test Framework.