Software variability in service robotics

Robots artificially replicate human capabilities thanks to their software, the main embodiment of intelligence. However, engineering robotics software has become increasingly challenging. Developers need expertise from different disciplines as well as they are faced with heterogeneous hardware and uncertain operating environments. To this end, the software needs to be variable—to customize robots for different customers, hardware, and operating environments. However, variability adds substantial complexity and needs to be managed—yet, ad hoc practices prevail in the robotics domain, challenging effective software reuse, maintenance, and evolution. To improve the situation, we need to enhance our empirical understanding of variability in robotics. We present a multiple-case study on software variability in the vibrant and challenging domain of service robotics. We investigated drivers, practices, methods, and challenges of variability from industrial companies building service robots. We analyzed the state-of-the-practice and the state-of-the-art—the former via an experience report and eleven interviews with two service robotics companies; the latter via a systematic literature review. We triangulated from these sources, reporting observations with actionable recommendations for researchers, tool providers, and practitioners. We formulated hypotheses trying to explain our observations, and also compared the state-of-the-art from the literature with the-state-of-the-practice we observed in our cases. We learned that the level of abstraction in robotics software needs to be raised for simplifying variability management and software integration, while keeping a sufficient level of customization to boost efficiency and effectiveness in their robots’ operation. Planning and realizing variability for specific requirements and implementing robust abstractions permit robotic applications to operate robustly in dynamic environments, which are often only partially known and controllable. With this aim, our companies use a number of mechanisms, some of them based on formalisms used to specify robotic behavior, such as finite-state machines and behavior trees. To foster software reuse, the service robotics domain will greatly benefit from having software components—completely decoupled from hardware—with harmonized and standardized interfaces, and organized in an ecosystem shared among various companies

Uncertainty Modeling for AUV Acquired Bathymetry

Abstract Autonomous Underwater Vehicles (AUVs) are used across a wide range of mission scenarios and from an increasingly diverse set of operators. Use of AUVs for shallow water (less than 200 meters) mapping applications is of increasing interest. However, an update of the total propagated uncertainty TPU model is required to properly attribute bathymetry data acquired from an AUV platform compared with surface platform acquired data. An overview of the parameters that should be considered for data acquired from an AUV platform is discussed. Data acquired in August 2014 using NOAA’s Remote Environmental Measuring UnitS (REMUS) 600 AUV in the vicinity of Portsmouth, NH were processed and analyzed through Leidos’ Survey Analysis and Area Based EditoR (SABER) software. Variability in depth and position of seafloor features observed multiple times from repeat passes of the AUV, and junctioning of the AUV acquired bathymetry with bathymetry acquired from a surface platform are used to evaluate the TPU model and to characterize the AUV acquired data

Dynamic decision-making based on NFR for managing software variability and configuration selection

Due to dynamic variability, identifying the specific conditions under which non-functional requirements (NFRs) are satisfied may be only possible at runtime. Therefore, it is necessary to consider the dynamic treatment of relevant information during the requirements specifications. The associated data can be gathered by monitoring the execution of the application and its underlying environment to support reasoning about how the current application configuration is fulfilling the established requirements. This paper presents a dynamic decision-making infrastructure to support both NFRs representation and monitoring, and to reason about the degree of satisfaction of NFRs during runtime. The infrastructure is composed of: (i) an extended feature model aligned with a domain-specific language for representing NFRs to be monitored at runtime; (ii) a monitoring infrastructure to continuously assess NFRs at runtime; and (iii) a exible decision-making process to select the best available configuration based on the satisfaction degree of the NRFs. The evaluation of the approach has shown that it is able to choose application configurations that well fit user NFRs based on runtime information. The evaluation also revealed that the proposed infrastructure provided consistent indicators regarding the best application configurations that fit user NFRs. Finally, a benefit of our approach is that it allows us to quantify the level of satisfaction with respect to NFRs specification

An Approach to Detect the Origin and Distribution of Software Defects in an Evolving Cyber-Physical System

Cyber-Physical Systems (CPS) are usually developed by an incremental approach. A changing environment like demanding user requirements or legislation amendments lead often to multiple development paths in an evolving CPS. Hence, software variability plays an increasingly important role adapting the characteristics of such CPS to different contexts. This paper focuses on software variability realized through a Software Product Line (SPL) more specifically. Thereby, variability and evolution are usually managed in different tools. However with respect to software defects, a holistic handling of variability and evolution is necessary to ensure a reliable software defect removal. Particularly, detecting software defects in different evolution stages and derived variants is ordinary, but complex and error-prone. To close the gap between variability and evolution, this paper presents a systematic approach to combine both disciplines. In particular, we apply existing variant management techniques in combination with software configuration management methods to determine a software defect's origin and distribution in an evolving SPL. We apply our approach to a CPS from the automotive domain to show its industrial relevance and usefulness

Reproducible Science and Deep Software Variability

International audienceBiology, medicine, physics, astrophysics, chemistry: all these scientific domains need to process large amount of data with more and more complex software systems. For achieving reproducible science, there are several challenges ahead involving multidisciplinary collaboration and socio-technical innovation with software at the center of the problem. Despite the availability of data and code, several studies report that the same data analyzed with different software can lead to different results. I am seeing this problem as a manifestation of deep software variability: many factors (operating system, third-party libraries, versions, workloads, compile-time options and flags, etc.) themselves subject to variability can alter the results, up to the point it can dramatically change the conclusions of some scientific studies. In this keynote, I argue that deep software variability is a threat and also an opportunity for reproducible science. I first outline some works about (deep) software variability, reporting on preliminary evidence of complex interactions between variability layers. I then link the ongoing works on variability modelling and deep software variability in the quest for reproducible science

Modelling, Reverse Engineering, and Learning Software Variability

The society expects software to deliver the right functionality, in a short amount of time and with fewer resources, in every possible circumstance whatever are the hardware, the operating systems, the compilers, or the data fed as input. For fitting such a diversity of needs, it is common that software comes in many variants and is highly configurable through configuration options, runtime parameters, conditional compilation directives, menu preferences, configuration files, plugins, etc. As there is no one-size-fits-all solution, software variability ("the ability of a software system or artifact to be efficiently extended, changed, customized or configured for use in a particular context") has been studied the last two decades and is a discipline of its own. Though highly desirable, software variability also introduces an enormous complexity due to the combinatorial explosion of possible variants. For example, the Linux kernel has 15000+ options and most of them can have 3 values: "yes", "no", or "module". Variability is challenging for maintaining, verifying, and configuring software systems (Web applications, Web browsers, video tools, etc.). It is also a source of opportunities to better understand a domain, create reusable artefacts, deploy performance-wise optimal systems, or find specialized solutions to many kinds of problems. In many scenarios, a model of variability is either beneficial or mandatory to explore, observe, and reason about the space of possible variants. For instance, without a variability model, it is impossible to establish a sampling strategy that would satisfy the constraints among options and meet coverage or testing criteria. I address a central question in this HDR manuscript: How to model software variability? I detail several contributions related to modelling, reverse engineering, and learning software variability. I first contribute to support the persons in charge of manually specifying feature models, the de facto standard for modeling variability. I develop an algebra together with a language for supporting the composition, decomposition, diff, refactoring, and reasoning of feature models. I further establish the syntactic and semantic relationships between feature models and product comparison matrices, a large class of tabular data. I then empirically investigate how these feature models can be used to test in the large configurable systems with different sampling strategies. Along this effort, I report on the attempts and lessons learned when defining the "right" variability language. From a reverse engineering perspective, I contribute to synthesize variability information into models and from various kinds of artefacts. I develop foundations and methods for reverse engineering feature models from satisfiability formulae, product comparison matrices, dependencies files and architectural information, and from Web configurators. I also report on the degree of automation and show that the involvement of developers and domain experts is beneficial to obtain high-quality models. Thirdly, I contribute to learning constraints and non-functional properties (performance) of a variability-intensive system. I describe a systematic process "sampling, measuring, learning" that aims to enforce or augment a variability model, capturing variability knowledge that domain experts can hardly express. I show that supervised, statistical machine learning can be used to synthesize rules or build prediction models in an accurate and interpretable way. This process can even be applied to huge configuration space, such as the Linux kernel one. Despite a wide applicability and observed benefits, I show that each individual line of contributions has limitations. I defend the following answer: a supervised, iterative process (1) based on the combination of reverse engineering, modelling, and learning techniques; (2) capable of integrating multiple variability information (eg expert knowledge, legacy artefacts, dynamic observations). Finally, this work opens different perspectives related to so-called deep software variability, security, smart build of configurations, and (threats to) science

A Conceptual Modelling Approach to Software Variability

Variability is the ability of a system to be efficiently extended, changed, customised or configured for use in a particular context. Increasing amounts of variability are required of software systems. The number of possible variants of a software system may become very large, essentially infinite. Efficient methods for modelling and reasoning about software variability are needed and numerous such languages have been developed. Most of these languages either lack a solid conceptual foundation or a rigorous formal semantics, or both. In this dissertation, three novel software variability modelling languages, KOALISH, FORFAMEL and KUMBANG, which synthesises KOALISH and FORFAMEL, are developed. The languages are based on concepts found relevant to modelling software variability in scientific literature and practice, namely features and software architecture. They synthesise and clarify the concepts defined in a number of previous languages. Ideas first developed in product configuration research for modelling variability in non-software products are elaborated and integrated into the languages. A formal semantics is given for the languages by translation to weight constraint rule language (WCRL). One of the goals of this dissertation is to enable the representation of software variability knowledge at different levels of abstraction in a uniform manner, preferably using an existing conceptual modelling language with a formal semantics. Unfortunately, it turns out that no existing language meets these requirements. Consequently, a novel conceptual modelling language, NIVEL, with the necessary capabilities is developed in this dissertation. The modelling concepts of NIVEL are not based on software variability. Consequently, NIVEL can be applied in domains other than software variability and is hence generic and contributes to the theory of conceptual modelling. A formal semantics enabling automated, decidable reasoning is given for NIVEL by translation to WCRL. NIVEL is used to give an alternative definition of KUMBANG. The alternative definition is more compact and easily understandable than the original one. Major parts of the semantics of KUMBANG are captured by the semantics of NIVEL. The definition of KUMBANG in terms of a generic modelling language also brings software variability modelling closer to other forms of modelling, thus making software variability modelling less of an isolated discipline

Using Domain Features to Handle Feature Interactions

International audienceSoftware Product Lines in general and feature diagrams in particular support the modeling of software variability. Unfortunately, features may interact with each other, leading to feature interaction issues. Even if detected at the implementation level, interaction resolution choices are part of the business variability. In this paper, we propose to use a stepwise process to deal with feature interactions at the domain level: the way an interaction is resolved is considered as a variation point in the configuration process. This method and the associated implementation are applied onto a concrete case study (the jSeduite information system)

Persistent Contextual Values as Inter-Process Layers

Mobile applications today often fail to be context aware when they also need to be customizable and efficient at run-time. Context-oriented programming allows programmers to develop applications that are more context aware. Its central construct, the so-called layer, however, is not customizable. We propose to use novel persistent contextual values for mobile development. Persistent contextual values automatically adapt their value to the context. Furthermore they provide access without overhead. Key-value configuration files contain the specification of contextual values and the persisted contextual values themselves. By modifying the configuration files, the contextual values can easily be customized for every context. From the specification, we generate code to simplify development. Our implementation, called Elektra, permits development in several languages including C++ and Java. In a benchmark we compare layer activations between threads and between applications. In a case study involving a web-server on a mobile embedded device the performance overhead is minimal, even with many context switches.Comment: 8 pages Mobile! 16, October 31, 2016, Amsterdam, Netherland

Context for goal-level product line derivation

Product line engineering aims at developing a family of products and facilitating the derivation of product variants from it. Context can be a main factor in determining what products to derive. Yet, there is gap in incorporating context with variability models. We advocate that, in the first place, variability originates from human intentions and choices even before software systems are constructed, and context influences variability at this intentional level before the functional one. Thus, we propose to analyze variability at an early phase of analysis adopting the intentional ontology of goal models, and studying how context can influence such variability. Below we present a classification of variation points on goal models, analyze their relation with context, and show the process of constructing and maintaining the models. Our approach is illustrated with an example of a smarthome for people with dementia problems. 1