Evolution is a well-known problem in any software product family of non-trivial complexity. Over the lifespan of a product line, new features will be added, old features are deprecated, and separate code branches may be created to deal with spin-off products. As the code and customer base grows, the possible feature combinations used by various product instances soon becomes unwieldy.
In some domains, such as the automotive industry, all the possible variants of a car (make, model, base equipment, extras, etc.) can create a situation with a combinatorial explosion of feature combinations. This poses a challenge when maintaining the supporting software. Not only the new features must be catered for, but also all previous feature combinations for products that are still on the market and under support agreements.
This can easily lead to bad software development practices. One approach is to “clone and own”. This happens when developers copy some code from elsewhere or spin off a repository branch that they don’t dare merge back into the main branch out of fear of breaking something. While this approach can reduce the amount of problems in the short-term, it is not a good long-term solution because errors-may propagate unnoticed and maintenance effort is multiplied.
Another issue is on the deployment side. Returning to the automotive scenario, how does one ensure that a given car gets an update that is customized to its particular feature combination? To add even more complexity, how can we also take, e.g., the driving characteristics of the car owner into account when updating the car software? Using traditional software development techniques, it is easy to end up with a software repository with lots of duplicated and overlapping code and where making any substantial change carries the risk of unforeseen down-the-line implications.
On the development side (see Figure 1), we have created a set of tools that use software product line (SPL) modeling techniques for a structured approach towards handling feature combinations. These tools can either be adopted from scratch for new projects or be applied to existing projects with low adoption efforts. Moreover, our analysis tools can be applied to a project that is already suffering from previous clone-and-own development, so that differences and similarities of cloned products are automatically extracted and modeled. This greatly simplifies the task of cleaning up from years of bad development practices.
Figure 1 - Development Tool Chain
On the deployment side (Figure 2), we introduce a cloud-based tool chain that complements our development tools. The tool chain functions in an Internet of Things context, keeping tabs on a large number of connected devices and their feature configurations. A reconfiguration component detects whenever a software update must be applied, either due to changes on the device (pull action) or changes on the software side (push action). Instead of taking the naïve approach of pushing the same monolithic update to each device, the tool chain will create a customized update for each device and only do the full recompile when it is deemed necessary. This greatly reduces the complexity and bandwidth required to do over-the-air updates for a device fleet. Also, as part of the supporting toolkit, we can do a static analysis of the resources required for running our tool chain on the cloud. For a realistic traffic pattern model, this removes a lot of the guesswork when doing cloud infrastructure cost estimation.
Figure 2 - Deployment Tool Chain
Part 1: Getting started with the tool chain
Consider the (fictional) automotive software company Autosoft.
Autosoft’s main product is software for the eCall system, which automatically sends geo-positioned distress calls when an accident happens. Autosoft is a fairly progressive company: They write software using code generated from statecharts.
So far, Autosoft has only developed software for the European car market. Now they want to branch into the Russian market as well. To do so, they have a couple of technical challenges to solve. Firstly, in Russia the ERA-GLONASS positioning system must be used instead of GPS. Also, all audible and visual prompts must be given in Russian instead of in English.
Autosoft first considers developing a separate software system for the new Russian product. This plan is quickly scrapped when they realize that their development efforts will be doubled and that software maintenance will be significantly more demanding.
To help them plan the best course of action, they hire the HyVarTech consulting company. Quickly recognizing the problem, HyVarTech suggests that Autosoft adopts the HyVar tool chain. This causes some initial resistance: The software developers in Autosoft are uncertain about how to adopt the tool chain and fear they have to change their software development practices or even start completely from scratch. This can be both costly and time consuming but Autosoft needs to move fast to get the new product to market.
Figure 3 - Use of HyVar Toolchain to create a new variant starting from an existing product
HyVarTech assures them this is not the case and that there are several benefits to using the tool chain:
Autosoft decides to test the tool chain for this project (Figure 3). A feature model for the specific Russian configuration is created and a separate build is created. The adoption is considered successful and the product is ready for use on Russian cars. While there is some overhead for getting started with the tools and the methodology, Autosoft feels that it has a stronger foundation for adding new features and spin-offs to their product line.
Learn more: Plug-and-play variability for Eclipse
Part 2: Reducing risk in distributed software development projects
After the success of the new eCall product, Autosoft is approached by a car manufacturer who wants them to develop software for gear advice and start and stop automation, along with a new heads-up display (HUD) to give the driver feedback on her driving style.
Autosoft feels competent on the gear advice functionality but displaying the advice on a HUD is something they have not done before. Since the deadline is tight and they are short on manpower, Autosoft decides to hire Visionmatix, a company specializing in consumer-level user interfaces, as a subcontractor.
This is a new situation for Autosoft. They are not accustomed to using third-party vendors and have concerns over how well the independently developed new functionality will integrate with the existing product, especially within the new highly-configurable software product line. It is vital for Autosoft to avoid a situation where critical integration issues show up close to the final deadline.
Luckily, their use of the HyVar tool chain also has benefits when running distributed development projects (Figure 4):
Figure 4 - Multi Software Product Lines for distributed development
Autosoft instructs Visionmatix on how to work with their tool chain setup. After defining feature model interfaces and using them in the initial planning of the new feature SPL, Visionmatix goes off to develop the new functionality. The changes to the product are tracked as temporal feature models, effectively documenting the evolution of the software system. After a smooth integration, the product is ready ahead of the final deadline.
Part 3: Personalized deployment from the cloud
After using the new gear advice functionality for a while, the car manufacturer finds that, while it works as intended, it is often too generic. For example, it does not take the driving style of the driver or the weather conditions into account. The necessary parameters are already collected on the car and it is just a matter of making use of them. This, however, is easier said than done. The large number of possible combinations of drivers, environments and car configurations means that, in principle, each customer could need a separate product. Moreover, getting the new software on the cars is tricky enough as it is. Currently, the only method for pushing a software update is to have all the cars book an appointment at a service garage and have the software installed manually. If the updates are also personalized, this is clearly not a viable option. While there are existing solutions for doing over-the-air (OTA) upgrades, they will not work with updates that are customized for each user. In addition to the technical challenges, the costs involved with setting up such an OTA upgrade network are not clear. The car manufacturer knows there are peak periods in their data traffic and, therefore, a cloud infrastructure makes sense--but how much will this cost them?
Because of their previous work with Autosoft, HyVarTech is consulted on the manner. Their opinion is that the HyVar tool chain is suitable both for modeling personal preference features and for doing OTA deployments of the customized software updates to the individual cars (Figure 5):
In cooperation with the car manufacturer and Autosoft, HyVarTech runs a simulation where the typical features and configurations are taken into account. This not only shows that it is practically feasible to provide individual updates, but also that the potential resource use is such that the car manufacturer will still make a profit. The car manufacturer feels that it has a good basis for making an informed decision and decides to go ahead with a rollout of the cloud tool chain infrastructure.
Figure 5 - Context-based Reconfiguration and Over The Air software update
Learn more: The reconfiguration engine HyVarRec
Part 4: Reducing code duplication in software product lines with variability mining
After being introduced to the tool chain, Visionmatix finds that this is something they would like to make more use of internally. However, they worry that the effort required for adopting the HyVar tool chain will be too large to capitalize on its benefits as they know that they have a large amount of code that has been copied between projects and cleaning up this mess seems both difficult and time-consuming.
This is not necessarily the case, though. HyVarTech shows them that the HyVar variability mining technology (Figure 6) is a good way of kickstarting their efforts:
Visionmatix let some of their senior developers do a few test runs with the variability mining tool and they are surprised to see that it actually is able to abstract common features from separate projects. They are able to adopt the tool chain with far more ease than they previously thought possible due to the large degree of automation, while still providing manual control over individual steps.
Figure 6 - Abstraction of common features through Variability Mining
We have presented an innovative solution to the software reuse problem, integrating SPL engineering principles with existing tools and commonly used industrial practices. The HyVar approach supports the development and deployment of individualized software adaptations and realizes the concept of Hybrid Variability. The methodology and tool chain has been applied in a scenario from the automotive domain, and seems promising also for other emerging scenarios, such as Internet of Things (IoT) and Cyber-Physical Systems (CPS), characterized by a huge number of remote devices, each of whom has its own hardware configuration, runs a customizable distributed software application and needs to evolve in order to fix or prevent misbehavior, to adapt to environmental changes, accomplish new regulations, satisfy new user requests and meet new market expectations.