Keywords: Unmanned Aerial Vehicles, Simulink Models, Software Product Lines, Pure::variants, Hephaestus.

Portuguese Keywords: Linha de Produtos de Software, Veículos Aéreos Nao Tripulados, Simulink ]]>

Received 2012-07-09, Revised 2012-12-13, Accepted 2012-12-13

1 Introduction

The approach of software product line (SPL) is ideal for software domains where the objective is to develop a set of products that have common characteristics and variable parts. Using this approach it is possible to develop systems with much less time and effort compared to traditional development approaches (focusing on a single system). A software domain that has these characteristics is the one related to the control of Unmanned Aerial Vehicles (UAV), which includes an autopilot. 

The Software Product Line (SPL) approach has been successfully used in the development of embedded systems. It looks for commonalities and variabilities within a family of products and maintains a set of core assets to leverage reuse. We have already explored the development of a SPL for UAVs using an approach called ProLiCES (1). In the implementation phase, contrarily to many other proposals in this domain, we have used a model-based approach that uses Simulink models to generate C code. 

Nevertheless, there are just a few works (2, 3) that investigate how to model and manage variabilities in this environment. Thus, in this paper we show a catalog of patterns to model variabilities in Simulink and a simple SPL that has been developed to test our approach. Here we also explain how to manage configurability of SPL assets modeled in Simulink, considering two alternative product derivation tools tailored to manage variability in SPL Simulink models. This paper also shows how these tools have been used to configure variabilities of a Simulink model of a UAV. Furthermore, a comparison of the main features, benefits and drawbacks of each tool is presented. 

This paper is organized as follows: Section 2 introduces some related work, considering SPLs for Unmanned Aerial Vehicles, modeling SPL variability in Simulink models, and tool support for modeling SPL variabilities in Simulink models. Section 3 presents one of the contributions of this paper, which is an extended approach for modeling SPL variabilities in Simulink models. Then, in Section 4 we model the variabilities of Tiriba (a small-sized UAV) using our approach. In order to do that, we first customized two existing tools (Pure::Variants and Hephaestus) for product derivation, accordingly the requirements of our approach. Section 4.1 and Section 4.2 detail the customization of such a tools. In Section 5 we compare the use of Pure::Variants and Hephaestus to manage SPL variability and product derivation and, finally, Section 6 presents our conclusions and some future works directions.

2 Related Work

2.1 Software Product Lines for Unmanned Aerial Vehicles

The Software Product Line (SPL) approach aims to develop a set or family of software products within a specific domain (4). Products of a family have a common part (a reusable architecture) and variable parts that satisfy different requirements. An important SPL concept is the one of a feature, which is a functional characteristic considered relevant for both customers and developers (5, 6). Features might be mandatory, optional or alternative, and its structure and relationships are usually represented as feature diagrams. 

Among the responsibilities of tools that support SPL variability management, it is also included that of generating specific products of the line. Generation of products can be accomplished using either positive or negative variability techniques. The derivation of products with negative variability starts with a template that contains the unification of all features of an SPL and changes them removing or disabling features that are not selected. Differently, in the positive approach, a specific asset relates fragments of artifacts with features of an SPL. During the product derivation, these fragments will be added or not to the product depending on the feature configuration. 
There are many cases of SPL developed with success in the domain of embedded systems. A large number of companies have used the approach to develop its products, such as Siemens, Nokia, Philips and HP (4, 7). Unmanned Aerial Vehicles (UAV) is one of the different types of embedded systems that might be worthwhile to apply the SPL approach. UAV is an expression that refers to aircrafts that can fly without a pilot, or an aircraft structure and an embedded computer system which, combined with sensors, GPS, actuators and CPUs are able to fly without human intervention (8). 

The UAVs have been originally designed for military applications, because they provide safe solutions at a relatively low cost for various types of missions, such as: surveillance, spying and blocking or interfering with radars. In addition to military applications these aircrafts are increasingly being used in civilian, commercial, and scientific applications such as meteorological measurements, topographic data collection, assessment of incidents of catastrophic proportions, agriculture monitoring, fishing, and environment. 

Tiriba is a small-sized, electrically motorized UAV developed in partnership between the company AGX and the INCT-SEC (National Institute of Science and Technology for Critical Embedded Systems) (9, 10). Its design was created using an approach based on Simulink models from which C code is automatically generated. Simulink is an integrated development environment based on models for system’s analysis, modeling and simulation developed by Mathworks (11). It uses the infrastructure of MATLAB, which enables the modeling of linear dynamic systems, nonlinear, continuous or discrete in time. Using Simulink it is possible to design, simulate, test and generate code for many types of systems, including communication systems, control and signal processing, image and video. 

Developers represent a system using Simulink models by means of blocks and the execution and communication among blocks use a synchronous time model. Simulink contains a library with various types of blocks, each one representing a different dynamic process. Besides modeling in blocks, which is called dataflow, Simulink allows interaction of its models with finite state machines (FSM) and with algorithms coded in MATLAB.

2.2 Modeling SPL Variability in Simulink Models

A few authors have discussed in the literature how to model variabilities in Simulink. Nonetheless, the negative approach seems to be preferred due to the graphical nature of Simulink modeling. Polzer et al. combine model driven techniques with rapid application development to manage variability within a sensor network (3). Using their proposed approach, the configuration process not only selects sensors and actuators based on the specific features of an SPL instance, but also tailors the micro-controller behavior according to the resulting configuration. The micro-controller behavior is specified using Simulink models, while the component variability (or parameterization is this case) is specified using a different asset (a configuration file). Using a well established practice of the SPL approach, domain engineers specify the scope of the product line using feature models (6). Finally, the product derivation is supported by the pure::variants tool and the Simulink connector (we discuss tool support for Simulink product lines in Section 2.3). 

Botterweck et al. also present a product derivation process for SPL Simulink models (12), which follows a negative and transformational style (see Section 2.1). In order to derive valid Simulink models, corresponding to the union of all selected features, it is necessary to use the variability mechanisms of Simulink blocks for each feature. Therefore, optional features might be represented using enabler subsystems— in the cases where the enabler port is 0, the subsystem will be absent. Alternative features might be represented using switch blocks, which have three input gates. The output value of a switch block is either the value of the first or third gate, depending on both the configuration value of its condition and the value of the second gate. Finally, inclusive-or features might be represented using integrator blocks, which could implement different functions such as minimum and maximum. In their work, the instantiation process comprises two phases: product derivation and pruning. During product derivation, all blocks not related to the selected features must be removed from the resulting Simulink model. During the pruning phase, all invalid lines (which are not connected to a source block, target block, or both) must be removed from the resulting Simulink model, as well as the remaining variability mechanisms. All transformations lead to a valid Simulink model including only the blocks related to the selected features and the required lines. 

Moreover, some approaches have been proposed to represent SPL variability in the vehicle domain, for both the automotive industry (13, 14) and UAV systems (15). For instance, Fragal et al. describe an approach for mapping SPL features to UAV Simulink models, using a negative technique for product derivation (15) that basically considers one-to-one or one-to-many mappings between features and blocks. Here we go beyond this simple kind of mapping, allowing relationships between feature expressions using propositional logic and differente components of simulink models (such as blocks and final state machines). Our approach is also guided by a set of variability patterns described in Section 3. 

2.3 Tool Support for Modeling SPL Variability in Simulink Models

There exist several tools for managing variability in SPLs, and Torres et al. present an assessment of some of these tools (Pure::variants, Hephaestus, GenArch, ColorIDE, and XVCL) in the context of SPL evolution (17). We decided to use Pure::variants and Hephaestus to implement the tool support for our approach, since our goal here is to investigate the use of annotative and compositional methods to manage SPL variability of UVA Simulink models. We decided to implement the annotative approach using Pure::variants because a Simulink connector was already available at the time we started this research. Our decision to use Hephaestus is that, differently from the other mentioned tools, it is primarily based on a compositional approach, where no explicit annotation is required in the underlying model. Moreover, the third author of this paper is the lead Hephaestus developer, reducing the risks to implement a Hephaestus Simulink integration. 

Pure::variants is a widely used business tool for managing variabilities in product lines. Among the plugins of the tool, there is the Simulink connector, which uses an approach similar to that proposed by Dziobeck et al.(2). The management of variability with Simulink connector uses the concept of “point of change”, which encapsulates the variability information of a particular functional variant. It uses a unique identifier and also:

• A variability parameter, which describes a configuration parameter in a Simulink model that can be configured to select a functional variant.
• Mechanisms of variability, which describe how functional variants are selected in different parts of Simulink models. They guarantee that after parameters of variability are configured, only the selected variants are executed. These variability mechanisms are implemented by a set of specific blocks of Pure::variants that are exported to Simulink. Examples of blocks used as mechanisms of variability are presented in Section 2.2.

Most of the variability mechanism blocks need input signals to control their execution, thus serving for the selection of variability. The blocks responsible for these signs are called control blocks and usually control variabilities in the model using values defined by the variability parameter of their variation point. Pure::variants sets the value of the variability parameter used by the control blocks based on three main artifacts: features model, instance model (a valid configuration of features of the feature model) and variant model. The latter maps expressions of features from the feature model to values of the variability parameters, as depicted in Figure 1. 

Hephaestus is a tool to generate artifacts of specific instances of SPLs. In its current version, it supports variability management of different types of assets, such as use case scenarios, source code and business processes (18). Hephaestus contains a graphical interface that allows application engineers to select artifacts and models that are input to the process of product derivation. The tool evaluates the artifacts and models and then generates artifacts for specific instances of an SPL. Figure 2 shows a high level view of Hephaestus. The input artifacts and models are: features model, instance models, product line assets, and configuration knowledge. The instance model represents the configuration of the features of a product and the configuration knowledge maps feature expressions to transformations that to be performed on the SPL assets. 

Figure 2: Highlevel view of Hephaestus behavior

Hephaestus has been recently extended as part of this work to allow for the generation of instances of SPL products in Simulink. The configuration knowledge defined in this extension associates with each feature expression of a set pairs, each comprised by a block identifier and a transformation to be applied to that block. 

Two transformations have been implemented in Hephaesuts: selectSimulink-Block, which should be linked to the block identifiers that will be selected for the instance model and clearVariabilityMechanism which should be associated to blocks that implement variability mechanisms (as we detail in the next section). 

First selectSimulinkBlock transformations are executed by introducing into the instance model all blocks that are related to the selected features, as well as the connections betweem each one of these blocks. After the evaluation of all selectSimulinkBlock transformations, the transformations of the clearVariabilityMechanism are executed. In the current status of Hephaestus this transformation removes the block marked as the variability mechanism associated to it, and reconnects the block connected to its entry in the block connected to its output. An example of how this transformation can be configured and applied is shown in Figure 3: the switch block is associated to the processing clearVariabilityMechanism, and blocks A, Input Kind, and Out1 are associated with the transformations selectSimulinkBlock (having already been performed). In the figure, one can see step by step how Hephaestus applies the transformation clearVariabilityMechanism: the variability blocks are removed and the selected block connected to the input of the block used as variability mechanism is connected to its output block. 

3 An Extendend Approach for Modeling Variability in Simulink Models

In order to design an SPL Simulink model, it is necessary to use a few mechanisms to model variability in different parts of the model. The main reason for that is to avoid an invalid model and to adequately bear the model variability making possible to simulate and generate SPL product specific code. 

As mentioned in section 2.2, Botterweck et al. (12) introduced some mechanisms for that purpose. In their work, these mechanisms model variability of optional features and features with or-inclusive and or-exclusive relationships. In this section we extend the mechanisms proposed by Botterweck et al. showing two patterns to configure features with hierarchical or dependency relations in the dataflow part of Simulink models and two patterns to configure variability in MATLAB/Simulink finite state machines (FSM). 

A variability mechanism for features with dependency or hierarchical relation with its functional variants encapsulated in one or more enabler subsystems is created using an AND comparator block; which is used to determine whether the input on the enabler port of the feature dependent (or child feature) enabler subsystem will be enabled or disabled. The enabler subsystem will be enabled only in the cases where both the activation value of the father and child features are true (thus the output of the AND block will also be true). If one of the activation values is false, the subsystem related to the child feature will be disabled. Figure 4 shows an example of this pattern, considering that the activation values of the features are determined by constant blocks. 

The interaction with FSMs is a common property of many Simulink models. Thereby, besides the variability in the dataflow part of the models (as explained before), an SPL Simulink model must also considers FSM variability. Variability in FSM can be accomplished by modeling a FSM for each variability within the scope of an enabler subsystem. Using this pattern, the application engineer can activate the desired FSM as well as deactivate the non desired ones. All enabler subsystems that comprise FSMs must be further modularized within other subsystems, together with an infrastructure to manage the inputs and outputs of the selected FSM as part of a product (or simulation). An example of such a subsystem is shown in Figure 6 (external interface). In the example, there are two mandatory inputs and two mandatory outputs. In other words, they are always used independently of the chosen FSM; there are also an optional input and an optional output that can be used or not, depending on the selected FSM. 

A second approach to model variability in FSM consists of creating a conditional transition to variables that define variabilities. The MATLAB FSMs can have inputs from the dataflow part of a MATLAB/Simulink model. These inputs can be used as conditional variables to perform a transition to one of two states; they can be used as single boolean variables or in expressions involving logic operators. If there are specific states in the machine that implement behavior related to SPL variability, it is possible to create an alternative transition in the FSM so that it can obtain this states depending on the condition associated to the transition. In the cases where the condition is a variable with the value assigned to an FSM input from the dataflow part, the control of the selection variability will require little effort, and it would be possible to be represented as a constant block (the same kind that is being used to enable or disable enabler subsystems in the mechanisms described here). 

Figure 8 shows an example of a FSM with variabilities modeled following this approach. In this FSM there are two variants, one that considers only states low_peak and high_peak and other that considers only low_peak and high_peak_counter. If the machine is in the initial state and the variable sine_wave_value is greater than 10, it will change its state. The following state will depend on the boolean variable counter: if this variable is true, the state will be high_peak_counter, or high_peak otherwise. 

Finally, Figure 8 shows the finite state machine block for the FSM of Figure 9. It is possible to see the inputs of the FSM from the Sine Wave block, the input port that controls the variability (counter) and the machine’s outputs. 

 
Figure 9: FSM block for the FSM of Figure 8

4 Modeling Variability of UAV Product Lines Using Simulink

• Pressure subsystem: this subsystem monitors the vertical and horizontal velocities of the vehicle and its altitude.
• Inertial subsystem: this subsystem determines the space position of the vehicle considering its longitude, latitude and altitude.
• Navigation subsystem: this subsystem controls the UAV mission and navigation. Based on the planned flight route the UAV current position, this subsystem computes the actions the vehicle must perform in order to achieve the flight mission.
• Control subsystem: based on the commands sent by the navigation subsystem, this subsystem must computer the suitable parameter values of the actuators, positioning the UAV to the right direction.

For instance, consider the Photographic camera and Georef log optional features. The UAV camera subsystem won’t be present if the Photographic camera optional feature is not selected for a specific product— and configurations like this are only valid for missions that do no take pictures during the flight. Similarly, the facility of attaching GPS data to the pictures is only available in the cases where the Georef log feature is selected. The changes needed by the Tiriba Simulink model to introduce support for the mentioned variability are as follows. First, the blocks related to both features were removed from the original, single product Simulink model. Then, the corresponding behavior was modeled as enabler subsystems. Finally, we introduced a three-port switch block as a variability mechanism. Using this switch, there are three possible configurations: the selection of both Photographic camera and Georef log, the selection of only Photographic camera, and the absence of both of these features. Figure 12 illustrates how we evolve the original model into the model supporting the SPL variability introduced by the Photographic camera and Georef log features. 

Regarding the Parachute feature, the corresponding blocks in the original Simulink model were already specified as an independent subsystem. Therefore, to model the parachute variability, we only had to transform this subsystem into an enabler subsystem, as discussed in Section 2.2. Differently, the variability related to the optional features Entry segment simulation, Feather threshold handler, and Failure handler was specified in the finite-state machine (FSM) that models the Tiriba mission controller unsing the mechanism of transitions conditioned to variables that define variability (as introduced in Section 3). When the feature is Entry segment simulation selected, a simulation is performed whenever the UAV starts a new segment of the mission, in order to find out the better approach to transit between two mission segments. The second feature (Feather threshold handler), when selected, fix the UAV route whenever the vehicle deviates more than a certain limit from the planed mission route. Finally, when the Failure handler feature is selected, the UAV is able to return to specific positions where, for any reason, a picture was not captured during the mission. 

Since the behavior of these features is specified in the mission controller FSM, we introduced alternative flows having boolean variables conditions, which allow us to enable or disable certain flows and states according to the selection or not of the aforementioned features (following the pattern introducted in the section 3 as illustrated by Figures 8 and 9). For instance, the boolean value SimEnable is the conditional that enables (or disable) the behavior related to the Entry segment simulation feature. Therefore, there is a boolean variable for each optional feature related to the mission controller, and the role of these variables is to decide which transitions of the FSM will take place. Figure 13 shows the input values that are assigned to these variables highlighted in red. 

There are two valid engine configurations: Combustion based engine and Electric engine. The first leads to a better flight autonomy and higher power when compared to the electric engine, even though introducing complexity to the acceleration controller. This occurs because it is necessary a gradual process for both acceleration and deceleration, target to avoid accidents and the lost of the UAV which eventually occurs due to an engine stop. Another characteristic of combustion based engines is that they are constrained by a low speed limit, and the engine could also stop when the UAV flies at a speed bellow this limit. Electric engines are less restricted, and the acceleration and deceleration might be done abruptly. Moreover, the engine do not stop even when the UAV speed is zero. Therefore, although presenting less autonomy, electric engines are safer, make easier to design and integrate the controller into the UAV, and reduce the maintenance costs. Regarding the Tiriba Simulink model, the engine variability is scattered through two distinct areas: the behavior related to the engine configuration, so that it is possible to configure the maximum and minimal speeds of the UAV; and the behavior related to the acceleration and deceleration of the engine, which is only required by combustion based engines.

4.1 Configuring Tiriba variabilities using Pure::variants

As mentioned in the previous section, the engine configuration (combustion based or electric based) changes the behavior of two distinct areas (speed and acceleration controllers). For both of them, we introduced a switch as variability mechanism. Then, we configured the control block of these switches with the same variation point, which might assume two distinct values: 0 indicating the selection of the Electric engine feature; and 1 indicating the selection of the Combustion based engine feature. 

The remaining variation points, which are related to the UAV mission behavior, might only assume values 0 or 1 (since they address the configuration of optional features). The difference here, when compared to the variation point of the Parachute feature, is that these variation points arise in the finite-state machine (FSM) that specifies the UAV mission. Nevertheless, the conditional gates of Simulink FSMs only accept boolean values as input, while the variation points of Pure::variants are integers. To solve this problem, we implemented a simple integer to boolean converter— when the input value is 0, it returns false; otherwise it returns true. 

4.2 Configuring Tiriba variabilities using Hephaestus

Initially, we related all mandatory blocks to the Tiriba feature, which is the (mandatory) root feature of the Tiriba product line. This triggers the selection of all these mandatory blocks in the final product. We also introduced one feature expression Parachute that selects all Simulink blocks related to this feature. 

The restruction of the areas related to the Photographic camera and Georef log features were very similar to the restruction shown in Figure 12. Differently of the Parachute feature, the configuration of this features were specified using three feature expressions, since there are three valid combinations of these features and, for each possibility, the variability is solved in a different way. For instance, when both features were enabled, blocks 12785, 12813, 12831, and 12817 must be selected (this blocks are respectively the photografic camera subsystem, georef log subsystem, signal mux and join block) to the final product, and the variability block of id 12822 (a switch block) must be correctly errased from the model. When the Photographic camera is selected and the Georef log feature is not, only blocks 1278 must be selected in the final product, and we must also clear the variability block 12822. Finally, when none of these features are selected, we just must clear the variability block whose identifier is 12822. 

The Figure 17 shows the configuration knowledge built for the Photographic camera and Georef log features. In the Figure is possible to see the feature expressions and its implications over the transformations. The only common configuration knowledge part over the three feature expressions is the configuration of the transformation clearVariabilityBlock for the to the variability block switch (id 12822). 

For each mission related feature we created two feature expressions— one for the cases where the feature was selected and another for the cases where the feature was not selected. For instance, if the feature Entry segment simulation is selected, the product derivation selects the 1 value constant block that is connected to the corresponding gate of the FSM. Differently, if the feature Entry segment simulation is not selected, the corresponding 0 value constant block will be selected in the final product. Therefore it was necessary to add two feature expressions for each feature related to de mission, one case the feature is selected and one case it is not. It was also necessary to make use of a switch block as variability mechanism block, which was associated to a clearVariabilityBlock in the configuration knowledge for each feature expression related to the mission. Figure 18 shows on its left side variability mechanisms blocks (as switch blocks) to structure blocks used to assign values of different variability selections; on its right side it is shown the configuration knowledge of the feature Entry segment simulation: there are two expressions (for the case it is selected or not) the selection of one constant block (value 1 if it’s selected or 0 if it’s not) and in both cases the switch variability mechanism block is cleared. 

Finally, we specified one feature expression for each valid configuration of the Engine feature. The Tiriba Simulink model parts related to the engine features were restructured to Hephaestus in a very similar way as it was in Pure::variants (see Figure 14). Considering the configuration knowledge, basically it was added three blocks to the be selected (for two different Simulink areas) and two variability blocks to be cleared for the Combustion feature expression. Similarly, in the Electric feature case, one Simulink block is added when Electric feature expression is evaluated as true, and the same two variability blocks must be cleared from the model. Since they are alternative features, Hephaestus guarantees that a valid configuration could not be specified using both features or none of them— and the configuration knowledge do not have to deal with these cases.

5 Evaluation

In this section we present a comparison between the implementation of Tiriba variability using Pure::variants and Hephaestus. According to the product derivation process, we realized at leas one significant difference among the compared tools: using Pure::variants the complete set of valid product instances will comprise all blocks (including the blocks introduced to support variability) of the Tiriba product line, regardless of the fact that some features might not be selected. In this case, the product derivation occurs by means of changing the values assigned to the MATLAB workspace parametres of the control blocks. As explained in Section 4, we use contro blocks to enable (or disable) blocks that are related to optional or alternative features, depending on the selection or not of the corresponding feature. 

In Hephaestus, the product derivation is built uppon a positive approach, in which the initial Simulink model for the product is empty. Than, after evaluating the proper transformations for a specific instance, new blocks are introduced and modified stepwise. After that, the product derivation connects the selected blocks according to the existing paths (or connections between blocks) of the Simulink product line model. Finally, the product derivation removes all variability mechanisms of the product, in such a way that the resulting model will comprise only the functional variant blocks that are related to the selected features of the SPL instance. 

It is important to notice that product derivation using Pure::variants leads to Simulink models that are unnecessarily complex, which in turns produces less efficient generated code— once the Simulink models serve as input for source code generation. Using Hephaestus, the derived instances comprise only the Simulink blocks that are related to the selected features. In this way, there is no dead code motivated by variability management, since the generated code considers only the blocks that are necessary for a specific product. Differently, using Pure::variants the generated code is almost the same for all derived instances, mainly because the Simulink models of the SPL instances allways comprise all blocks. The values assigned to the parameters control the instance’s variabilities, enabling only the execution paths that are valid. Those values are generated from the SPL Simulink control blocks, whose values are specified by Pure::variants. 

It is reasonably easy to define and evolve the configuration knowledge using both Pure::variants and Hephaestus. Nevertheless, specifying an Hephaestus configuration knowledge requires the extra, time consuming task of finding the identifier of each Simulink block and refering to these identifiers as arguments to the Hephaestus transformations. Moreover, evolving the configuration knowledge in Pure::variants is more intuitive, since all variability is represented in the SPL Simulink model. 

Product derivation in both Pure::variants and Hephaestus is effortless. In Pure::variants, after an instance model had been created, a product engineering just have to propagate the configuration using a single command. Similarly, using Hephaestus the product engineering only have to select the product derivation command to derive a product using the selected SPL Simulink model, instance model, and configuration knowledge. 

Table 1 summarizes our comparison, presenting the benefits and drawbacks of both tools.

---

Table 1: Evaluation summary

---

This paper discussed and presented two main results related to the development of software product lines based on Simulink modeling in the domain on UAV. The first and more important was the presentation of a catalog of mechanisms to represent several types of variabilities in Simulink. Then, we used these mechanisms to create, as a proof of concept, a small SPL for part of a real UAV called Tiriba in which we used these mechanisms. 

We also studied two tools to support variability and configuration management of SPL modeled using Simulink following a compositional approach and a instrumentation approach supported by, respectively, two tools: Hephaestus and Pure::variants. We discussed the characteristics and the advantages and disadvantages of these two tools. The model of the UAV Tiriba used as the basis for this work is a simplified version, but the proposal can be perfectly applied to the actual software, which could be done by the company that developed Tiriba. 

As future work, we intend to apply the knowledge acquired in this work on a real SPL for the family of UAV to which Tiriba belongs. The design of Tiriba is already being modified to develop a product line by Braga et al. (19); In this work, a model of 108 features was created, but it is still not enough for a LPS. This feature model is being extended to later be integrated into a feature model of an LPS based on Tiriba and at least two other UAVs. We are also investigating how an UAV can be certified using a SPL approach (1). 

References