No abstract

Feature models are arguably one of the most intuitive and successful notations for modeling the features of a variant-rich software system. Feature models help developers to keep an overall understanding of the system, and also support scoping, planning, development, variant derivation, configuration, and maintenance activities that sustain the system's long-term success. Unfortunately, feature models are difficult to build and evolve. Features need to be identified, grouped, organized in a hierarchy, and mapped to software assets. Also, dependencies between features need to be declared. While feature models have been the subject of three decades of research, resulting in many feature-modeling notations together with automated analysis and configuration techniques, a generic set of principles for engineering feature models is still missing. It is not even clear whether feature models could be engineered using recurrent principles. Our work shows that such principles in fact exist. We analyzed feature-modeling practices elicited from ten interviews conducted with industrial practitioners and from 31 relevant papers. We synthesized a set of 34 principles covering eight different phases of feature modeling, from planning over model construction, to model maintenance and evolution. Grounded in empirical evidence, these principles provide practical, contextspecific advice on how to perform feature modeling, describe what information sources to consider, and highlight common characteristics of feature models. We believe that our principles can support researchers and practitioners enhancing feature-modeling tooling, synthesis, and analyses techniques, as well as scope future research.

This paper reports the design of a photovoltaic energy harvesting device used as telemetry node in wireless sensor networks. The device draws power from the small solar cell, stores it into the primary energy buffer and backup supercapacitor, collects measured data from various sensors and transmits them over low power radio link at 868 MHz. Its design ensures reliable cold booting under very poor illumination conditions (down to 20 lx). The solar cell also enables indirect illumination level detection for the subcircuit that manages stored energy (day/night detector). The device is allowed to draw power from the backup supercapacitor only when it is not possible to gather enough energy from the solar cell during the sleep period. Short lasting and sudden drops of the illumination do not activate the backup power supply. A wireless sensor node design is adjusted to the proposed photovoltaic harvesting circuitry, so the overall power consumption in the sleep mode is less than 25 µW. Also, due to adaptive power consumption, proposed device topology ensures its autonomy time in the total darkness of 81 h. The device has been produced using commercially available components enabling versatile telemetric functionality by the implementation of different sensors.

Fully automated vehicles will require new functionalities for perception, navigation and decision making -an Autonomous Driving Intelligence (ADI). We consider architectural cases for such functionalities and investigate how they integrate with legacy platforms. The cases range from a robot replacing the driver -with entire reuse of existing vehicle platforms, to a cleanslate design. Focusing on Heavy Commercial Vehicles (HCVs), we assess these cases from the perspectives of business, safety, dependability, verification, and realization.The original contributions of this paper are the classification of the architectural cases themselves and the analysis that follows. The analysis reveals that although full reuse of vehicle platforms is appealing, it will require explicitly dealing with the accidental complexity of the legacy platforms, including adding corresponding diagnostics and error handling to the ADI. The current fail-safe design of the platform will also tend to limit availability. Allowing changes to the platforms, will enable more optimized designs and fault-operational behaviour, but will require initial higher development cost and specific emphasis on partitioning and control to limit the influences of safety requirements. For all cases, the design and verification of the ADI will pose a grand challenge and relate to the evolution of the regulatory framework including safety standards.

Safety cases are used to argue that safety-critical systems satisfy the properties determined to mitigate the potential hazards in the systems deployment environment. Although primarily a manual task, safety cases have been successfully created for single systems. However, when systems with a high number of configurations are considered, typically developed as a Product Line (PL), considering each possible configuration and constructing sound and complete safety-case argumentation is challenging. This paper presents a novel and general approach for the construction of a safety case for an arbitrary PL that is based on Contract-Based Specification (CBS) of the PL. Starting from a general CBS framework, a PL extension of the CBS framework is presented and it is shown that the extension preserves the properties of the original framework. Then, given a CBS specification of a PL, a set of transformation rules for the construction of the safety case argumentation-structure is defined. Finally, the approach is exemplified on a simplified, but real, and currently produced system by Scania CV AB.