The Weather Station — a Pure Application

OSBase

Pure Component

Family OSEK

Component Family

Machine

OsekOS Interfaces Streams

Figure 6.12: The OSEK OS domain feature model

called conformance classes that control basic features of the operating system. Both BCC1 and BCC2, for instance, do not allow event based activation of tasks. The other features allow the developer or the generator to provide additional information about the services the application requires.

This model was integrated into a hierarchical domain model, which is schematically shown in Figure 6.12. TheOsekOSmodel is mapped to theOSBasethat is basically the original Pure feature model minus theMachine,Interfaceand Streamssub-model. Those three models are also exposed to the user and/or the system generator. TheOSEKcomponent family consists almost entirely of the API interface layer. The hiding ofOSBasefeatures with theOsekOS model reduces the amount of features the user may select by 74% (16 versus about 100), the number of possible configurations is reduced even further.

This proves the usefulness of multi domain models, both in terms of reusability and usabil-ity.

6.4 The Weather Station — a Pure Application

While the previous examples were centered on the component or component family level, the final example is a small application family that shows again the usefulness of hierarchi-cal feature models. In a project the goal was to develop a complete weather station based on a small experimental microcontroller board equipped with an ATMEL ATMEGA103.

The board was equipped with several sensors (air pressure, temperature, wind speed) and has an LCD display, a serial controller and a USB controller for output and input purposes.

Although the ATMEGA103 has 128 kByte of code memory, for the project the memory was limited to 8 kBytes (Figure 6.13)

I C²

AVR−Microcontroller

USB RS232

Sensors

UDP/IP or special protocol over USB/RS232

Pressure Wind

Temp

Display

PC−Connection

Figure 6.13: Weather station

Device

LCD Serial USB

Formatted Unformatted Formatted UDP Unformatted Formatted Unformatted Input

Pressure Temperature WindSpeed Output

Format WeatherStation

Figure 6.14: The weather station application feature model

Several input and output options had to be implemented. Each of the sensors was optional, the output options were formatted or unformatted output for the LCD display and for serial output. Another output option was the use of SLIP¹⁰UDP¹¹ packets in a predefined way.

One resulting feature model for this application family is shown in Figure 6.14. The model was completely independent from the implementation platform used (in this case Pure) and could be reused without any changes on top of any other operating system. Only the mapping functionality had to be exchanged.

The implementation of the weather station relied heavily on the combination of simple C++ components, realizing separate functions, and AspectC++ aspects that provided the

“glue” for combining the independent components. Features were used to select functional

10Serial Line Internet Protocol

11User Datagram Protocol

6.4 The Weather Station — a Pure Application

#ifndef __Pressure_ah__

#define __Pressure_ah__

#include "PressureSensor.h"

#include "WeatherData.h"

aspect Pressure {

// measure the pressure, when the weather data should be updated advice args (weather) && execution ("void Sensors::measure(...)") :

after (WeatherData &weather) {

weather.pressure = PressureSensor::measure ();

}

// advise the display to print the wind speed after each update advice args (weather) && execution ("void Display::update(...)") :

before (WeatherData &weather) {

thisJoinPoint->that ()->print ("Pres", "hPa",

850 + (int)weather.pressure);

} };

#endif // __Pressure_ah__

Figure 6.15: Aspect connecting pressure sensor and output components

components like pressure sensor driver, LCD output driver and the connecting aspects (see Figure 6.15).

The combination of functional C++ code and aspects proved to be easy to handle. The aspects were quite small, the functional components remained uncluttered from the different variations, the sensors, for example, did not know whether and how their output was used for displaying or transmitting via USB. Other techniques, like virtual methods/abstract base classes, would have allowed the same effect but require more resources, as shown in Table 5.4 on page 111.

6.4.1 Feature Model Templates

The feature model of the weather station exhibits an interesting problem. Each of the dif-ferent output devices (USB, Serial and LCD) have almost identical sub-features. This is not very surprising, as all devices can be used for the same functionality. The resulting replica-tion is a general problem of feature models. The alternative of representing the formatting features in a separate and independent sub-model is not possible, because then it is not defined which formatting option has to be supported by which output device. All devices would have to support all output options. The output formatting has to be set separately for each output device.

The most intuitive solution would be a matrix ofDeviceT ype×F ormatOption. The fea-ture model shown is in fact a flattened matrix. However, the creation for larger numbers of features involved can be very expensive. A feature model template mechanism where the

model FormatOption

{ alternative(Formatted,Unformatted,UDP) } template WeatherStationTemplate<LCDFO,SFO,USBFO>

{ ...

Device: or(LCD,USB,Serial) LCD: LCDFO

Serial: SFO USB: USBFO }

model WeatherStation<LCD: FormatOption,

Serial: FormatOption, USB: FormatOption>

Figure 6.16: Proposal for feature model templates

parameters are models that can be inserted into specif iced locations would make this quite easy to handle. Based on the feature model notation introduced in [vDK02], a template no-tation is proposed (Figure 6.16). To avoid name conflicts when the same model or template is inserted, an individual prefix can be specified for a template parameter at instantiation time. CONSUL does not yet implement this extension but will do so in the near future.