Automatic Generation of Conﬁguration Files: an Experience ...

Journal of Object Technology | RESEARCH ARTICLE

Automatic Generation of Configuration Files anExperience Report from the Railway Domain

Enxhi Ferkolowast Alessio Bucaionilowast Jan Carlsonlowast and Zulqarnain Haiderdagger

lowastMaumllardalen University SwedendaggerBomdardier Railway Transportation Sweden

ABSTRACT In recent years software product line development has been adopted by a growing number of companies Withinsoftware product line development one way of creating specific products is by using configuration files to control a given setof parameters of the product at run time Often configuration files are created manually and this may lead to a sub-optimalprocess with respect to development effort and error proneness In this experience report we describe our work in enabling theautomatic generation of configuration files in the railway domain We discuss a four-step approach whose generation mechanismuses concepts of generative programming The approach is the outcome of a bottom-up effort leveraging the experiencesand the results from our technology transfer activities with our industrial partner Bombardier Transportation We evaluatethe applicability and the correctness of the proposed approach using the Aventra train family from Bombardier TransportationBesides we evaluate the ability of the proposed approach in mitigating the development effort and error proneness typical oftraditional manual approaches We performed expert interviews to assess the industrial relevance of the proposed approachand collect qualitative feedback on the perceived benefits and drawbacks Eventually for each of the four steps composing theproposed approach we identify factors that might affect the adoption of the approach and use these factors for discussing thelessons we have learned

KEYWORDS Software Product Line Configuration File Automatic generation

1 IntroductionIn recent years many companies have witnessed an increasingdemand for customised software-intensive systems able to ad-dress different market needs regional standards certificationsas well as software and hardware requirements BombardierTransportation (BT) is one such company1 To meet this increas-ing demand for customisation BT has been shifting its productdevelopment towards Software Product Line (SPL) (Klaus Pohl2005) SPL is a software development paradigm where a singlesystem is developed to meet the needs of a product family henceseveral products with commonality and variability (Metzger amp

JOT reference formatEnxhi Ferko Alessio Bucaioni Jan Carlson and Zulqarnain HaiderAutomatic Generation of Configuration Files an Experience Report fromthe Railway Domain Journal of Object Technology Vol 20 No 3 2021Licensed under Attribution 40 International (CC BY 40)httpdxdoiorg105381jot2021203a41 httpswwwbombardiercomentransportationhtml

Pohl 2014) In a nutshell SPL focuses on identifying and mod-elling similarities and differences of a product family and usingthis information for deriving and configuring specific productsof the family SPL differentiates between two processes namelydomain engineering and application engineering (Klaus Pohl2005) Domain engineering focuses on defining the commonal-ity and variability of the product family as well as developingthe common and distinguishing software assets Applicationengineering uses these assets to derive specific products of thefamily by selecting variability options for matching productrequirements and functionalities SPL provides the opportunityof decreasing the overall development cost while providing forhigher quality and shorter development time compared to thedevelopment of multiple independent systems

In BT the adoption of SPL has brought some challenges anddifficulties too (Metzger amp Pohl 2014) One of the main openchallenges that BT is facing is how to derive specific productsfrom a family Once a product has been designed there are

An AITO publication

Figure 1 Mapping proposed steps to the SPL process

several ways in which the design can be turned into a concreteproduct One common option which is used by BT and isthe focus of this work is to realise individual products usingconfiguration files A configuration file is part of the concreterealisation of the system and determines at run time some of itsaspects A typical example of a configuration file would be anXML data file with parameters that enable or disable differentportions of the common source code according to the featuresselected for that particular product In BT configuration filesare currently created manually starting from a set of heteroge-neous documents These documents often provide for a generaland informal description of the products and their features onlyBesides they might not be stored and managed systematicallyStarting from these documents BT engineers manually createconfiguration files for the different products in the family Expe-riences from BT show that manually creating configuration filesstarting from a set of heterogeneous and informal documentsis time-consuming and error-prone The most common errorsreported by engineers are categorised as (i) omitting informa-tion (ii) wrong semantics and (iii) inconsistencies Besidesthis manual process does not allow exploiting product common-alities meaning that common information needs to be specifiedfor each product

In this experience report we describe our experience in au-tomating the generation of SPL configuration files in the rail-way domain within BT We enable the automatic generationof configuration files defining a four-steps approach whosegeneration mechanism leverages concepts of generative pro-gramming (Czarnecki amp Eisenecker 2000) We demonstrate theapplicability and correctness of the proposed approach using anindustrial SPL from BT being the Aventra train SPL Besideswe evaluate the ability of the proposed approach in mitigatingthe development effort and error proneness typical of traditionalmanual approaches The application on the Aventra SPL sug-gest that the proposed approach has helped BT in lowering thedevelopment effort and mitigating the error proneness typical ofthe traditional manual approaches already for SPL containingmore than 3 products Eventually we use experts interviews tothe Aventra Development team for assessing the industrial rele-vance of the proposed approach and for collecting qualitativefeedback on the perceived benefits and drawbacks For eachstep of the proposed approach we identify a number of factors

and alternatives to take into account for adapting the approachto other development process and domain Eventually we usethese factors and alternatives for discussing the lessons we havelearned

The remainder of this paper is structured as follows In Sec-tion 2 we present the proposed approach its steps and thegeneration mechanism In Section 3 we show the applicationof the proposed approach on the Aventra SPL In Section 4and Section 5 we evaluate the proposed approach and discusslessons learnt and generalisability respectively In Section 6we present some related researches documented in literatureIn Section 7 we conclude the paper with final remarks andpossible future work

2 Proposed ApproachIn this section we describe the proposed approach for automati-cally generating configuration files within the BT developmentprocess Figure 1 provides a graphical representation of theapproach in relation to a simplified version of the SPLE frame-work presented by Pohl et al (Klaus Pohl 2005) the two mainphases of a typical SPLE process are Domain Engineering andApplication Engineering which are represented as white rect-angles in Figure 1 Each main phase consists of a number ofsub-phases represented as red rectangles

The proposed approach consists of four steps being FeatureCategorisation Creation of the Variability Model Variant Con-straints Categorisation and Generation of Configuration FilesFigure 1 represents these steps as circled numbers and placesthem in relation to the sub-phase they occur in In the remainderof this section we describe each step of the proposed approach

21 Feature CategorisationFeature Categorisation is the first step of the proposed approachand should be performed during the Domain Analysis sub-phaseDomain Analysis is responsible for defining documenting andvalidating all the shared and individual requirements of the SPLThese requirements are further mapped to features which areused for defining the variability model of the SPL during theDomain Design sub-phase An example of this could be therequirement that a train has two driver cabins which wouldtranslate in the feature direction indicating the orientation of

2 Ferko et al

the train Industrial SPLs often consist of thousands of featureswhich are typically neither organised nor prioritised Managingsuch a huge number of unorganised features is a complex taskwhich negatively affects the product derivation process (Loeschamp Ploedereder 2007) The categorisation of the features identi-fied in the Domain Analysis sub-phase is of crucial importancefor BT

Feature Categorisation focuses on grouping the elicited fea-tures into Primary Features and Secondary Features Primaryfeatures are all those features whose combinations can uniquelyidentify products in the SPL Within BT voltage number ofcars and side of consist are primary features as the combinationof their values can uniquely identify a certain train Secondaryfeatures are all those features which do not explicitly definea product Max speed is an example of a secondary feature inthe case of BT The output of the Feature Categorisation stepis a list of features labelled as primary or secondary Based onthe complexity of the SPL and the result of the categorisationsecondary features can be included or excluded from the featuremodel of the SPL In the first case the secondary features willbe automatically added to the configuration files This strat-egy leads to a complete but potentially unmanageable featuremodel In the second case the secondary features need to beadded manually to the configuration files Such a strategy leadsto an incomplete but light-weight feature model In Section 5we discuss the advantages and drawbacks of each strategy anddiscuss the lessons we have learned in our work with BT

22 Creation of the Variability ModelCreation of the Variability Model is the second step of theproposed approach and should be performed during both theDomain Design and Domain Realisation sub-phases DomainDesign and Domain Realisation are responsible for definingthe variability model and implement the related domain arte-facts The variability model represents the commonalities anddifferences of the SPL products The variability model con-sists of variation points variants and their relationships andconstraints A variation point is a representation of a loca-tion where a feature can have different values2 For instancevoltage is a variation point with values being Dual Voltage(DV) Direct Current (DC) and Alternating Current (AC) Avariant is a realisation of a variation point Creation of theVariability Model focuses on the creation of a model capturingthis information and the output of this step is a formalisationof the variability model Currently there is no standard wayof representing variability models (Arboleda amp Royer 2012)and different companies may use different notations and toolsOne of the most used notations for representing the variabil-ity model is feature model (Danilo Beuche 2006) Featuremodelling is a well-defined formalism which is currently sup-ported by several open-source and commercial tools such asFeatureIDE (Meinicke et al 2017) Another possibility for rep-resenting variability models is using metamodelling for buildinga domain-specific language (DSL) describing the SPL variationpoints and variants Most of the commercial tools supporting

2 In the remainder of this paper we use the terms feature and variation pointsanalogously

feature modelling are built around ad-hoc DSLs In Section 5we discuss some aspects to consider when choosing one ap-proach over the other that have emerged as pivotal during ourwork with BT

23 Variant Constraints CategorisationVariant Constraints Categorisation is the third step of the pro-posed approach and should be performed during the ProductAnalysis and Product Design sub-phases These sub-phases arefocused on configuring all the products within the SPL Thisinvolves the selection of a valid and complete set of variantstogether with possible constraints on them We have observedthat in BT variant constraints and their management have a di-rect impact on the complexity of the generation of configurationfiles and the complexity of the product realisation To ease themanagement of variant constraints we propose to categorisethem into Technical Constraints and Customer-specific Con-straints Technical constraints are all those constraints whichprevent the engineer to select erroneous or invalid variants Anexample of this could be a constraint preventing the selectionof pantograph and diesel engine variants for trains not havingthe electrical engine variant Customer-specific constraints areall those constraints which bind the choice of variants based oncustomer preferences An example of this can be the orientationof a car (same or different from the leading car) which can dif-fer from a customer to another Technical and customer-specificconstraints can refer indiscriminately to primary and secondaryfeatures While most of the time technical constraints wouldbe specified on primary features there might be cases whentechnical constraints would be specified on a secondary featuretoo so to avoid erroneous configuration of a product Similarlycustomer-specific constraints can be specified on primary fea-tures The output of this step is the categorisation of variantconstraints into technical and customer-specific Based on thetotal number of constraints customer-specific constraints can bespecified or omitted In the case they are omitted the customer-specific constraints need to be added directly during the configu-ration file generation This solution yields towards a lighter andmore malleable SPL with respect to addition modification anddeletion of products variation points and variants Howeversuch a solution might reduce the degree of automation Specify-ing both technical and customer-specific constraints yields toa less malleable solution with respect to the above-mentionedcases but it enables full-fledged automation In Section 5 wediscuss the advantages and drawbacks of both solutions whenapplied in the Aventra SPL

24 Generation of Configuration FilesGeneration of Configuration File is the last step of the proposedapproach and should be performed during the Product Realisa-tion sub-phase In this phase products are configured based onthe identified variants and variant constraints For each derivedproduct technical values of the variants are expressed in theconfiguration files which are part of the concrete realisation ofthe software and determines at run-time the set-up of the actualsoftware Hence this step focuses on the automatic generationof such configuration files

Automatic Generation of Configuration Files an Experience Report from the Railway Domain 3

Collector

Features andconstraints

List of variationspoints and variants

Executor

Translationfile

Configurationfile

Figure 2 Mechanism for the automatic generation of configu-ration files

There might be several alternatives in how to achieve suchan automatic generation One option is by using transformationlanguages and model transformations (Sendall amp Kozaczynski2003) Model transformations are automated processes that takeone or more source models as input and produce one or moretarget models as output according to a set of transformationrules An example of this could be the use of the template-based language Acceleo (Nesrine amp Bennouar 2018) for theautomatic generation of configuration files starting from modelsrepresenting the SPL These models should be conforming tometamodels This solution benefits from the tooling whichusually accompanies such transformation languages One draw-back is that model-based solutions usually entail the knowledgeof concepts as modelling metamodelling and model transfor-mation We have noticed that this knowledge is rarely possessedand mastered by the engineers at BT which are also unfamil-iar with model-based tooling (Liebel et al 2014) Anotherdrawback of this solution is the certification process Being asafety-critical domain the railway domain needs to comply withseveral safety standards eg IEC 61508 (Bell 2006) In par-ticular the European standard EN 50128 specifies the processand technical requirements for the development of software forprogrammable electronic systems for use in railway control andprotection applications (CENELEC 2020) EN 50128 definesthree classes of tools of ascending criticality which are T1 T2and T3 (CENELEC 2020) According to this categorisationmodelling and transformation languages and environments fallin the T3 category as they could introduce errors in the finalexecutable Among other requirements tools in the T3 categoryneed (i) to demonstrate a suitable history of successful tooluse in a similar environment (ii) have diverse redundant codewhich allows the detection and control of failures (iii) complywith the safety integrity levels and (iv) demonstrate a record ofvalidation activities (CENELEC 2020) Such requirements areassessed by external certification bodies in a process which maytake up to several years and add a development cost overheadbetween 25 and 100 (Pop et al 2016)

Another possibility to achieve the automatic generation ofconfiguration files is by using traditional programming lan-guages for realising concepts of generative programming (Czar-

necki amp Eisenecker 2000) In a nutshell generative program-ming refers to programs that are written for creating softwarecomponents in an automated fashion Generative programmingis considered the ancestor of metamodelling and model trans-formation This solution may allow mitigating the certificationcost in the case it can be realised using programming languagesand tools already used within the company hence already cer-tified In Section 5 we discuss the advantages and drawbacksof both alternatives In this research effort we have developedone such mechanism for the automatic generation of configu-ration files using C and leveraging the concepts of generativeprogramming

241 Mechanism for the Automatic Generation of Con-figuration Files Figure 2 shows a simplified representationof the functional architecture of the mechanism for the auto-matic generation of configuration files It consists of two mainmodules namely Collector and Executor (represented as redrectangles in Figure 2) and one Translation File (represented asa red note in Figure 2) The Executor module is implemented inC while the Collector module represents any feature modellingenvironment The mechanism takes the following as input thelist of features and constraints and a translation file In thefirst step the Collector module is used for gathering the listof features and their values Besides it considers the speci-fied technical and customer-specific constraints for establishingrelationships among the selected features These constraintsmight be expressed in formal or informal notation For eachproduct the Collector resolves these constraints and producesan XML data file where each feature is marked as automaticallyselected automatically deselected or manually selected to spec-ify all features selected for one final product In particular afeature can be automatically selected or deselected based onthe resolution of a technical constraint A feature can be manu-ally selected as a result of the resolution of a customer-specificconstraint Listing 1 shows an excerpt of one of such files inwhich the maxSpeed feature is selected automatically and thecaro feature is selected manually If using a feature modellingenvironment these steps correspond to the modelling of theSPL In the second step the Executor translates the informationabout selected features into a configuration file according to therelations specified in the Translation File In a nutshell theserelations link selected features to corresponding objects in theconfiguration files An example of these relations are

ndash Parameter-to-Features each parameter in the configurationfile is associated to the list of features that might contributeto its specification For instance in Listing 2 parameter1is associated to variant1 and variant2 to variant1 or tovariant1 and variant3

ndash Features-to-ParameterValue the value of the parameter isselected considering the list of features actually contribut-ing to that parameter

Listing 2 shows an excerpt of the general structure of the trans-lation file developed for this research effort using the JavaScriptObject Notation (JSON) In Section 3 we show the concreteTranslation File developed for the Aventra SPL

4 Ferko et al

1 ltconfigurationgt

2

3 ltfeature automatic=selected name=maxSpeedgt

4 ltfeature manual=selected name=carogt

5

6 ltconfigurationgt

Listing 1 Example of list of active feature for a product

1 parameterName1

2 Type Type of parameter1

3 Comment Comment for parameter1

4 Values [

5 Features [ variant1 variant2 ]

6 Value technicalValue1

7 Features [ variant1 ]



10 Value technicalValue3]

11

12 parameterName2

13

14 DefaultValue minus1

15

Listing 2 Example of the translation file

The Executor uses the relations in the Translation File for au-tomatically creating configuration files and it is realised asa console application It takes as inputs the path to the folderwhere the files from FeatureIDE are stored the path to the folderwhere the generated configuration files will be stored and thepath to the translation file First the Executor collects the infor-mation expressed in the JSON file and stores it in a data structurecalled Translation Collection The Translation Collection hasthe information expressed in the JSON file such as the parame-ters to be generated their possible mapping options to featuresand respective technical values Then starting from the list ofvariants and variation points the Executor extracts the featuresmarked as selected (either manually or automatically) and storesthis information in a data structure called Feature CollectionEventually for each parameter in the Translation Collection theExecutor checks which combination of features are selected inthe Feature Collection and assigns the corresponding technicalvalue This is done for all the products For instance using therelations in Listing 2 the Executor will derive parameter1 fromthe features variant1 and variant2 with value technicalValue1 ifthe features variant1 and variant2 are selected Alternatively itderives it from the feature variant1 with value technicalValue2if only feature variant1 is selected Or it can derive it fromthe features variant1 and variant3 with value technicalValue3 ifthe features variant1 and variant3 are selected A default valueis added in case none of the options is triggered Engineerscan filter all configuration files with parameters that have a de-fault value to find any possible inaccuracy when configuringthe products The result of this step is a configuration file foreach product in the SPL In Section 3 we provide an exampleof configuration files

3 Applying the Proposed Approach to theAventra SPL

In this section we demonstrate the industrial applicability ofthe proposed approach using the Aventra SPL from BombardierTransportation The Aventra SPL is a family of passenger trainsdesigned by Bombardier for the British market The trains in theAventra SPL might be of three types the London Overgroundtrain (LOT) the East Anglia train (EAA) and the South West-ern Rail train (SWR) Each train might have a specific number(eg four five ten) and type (eg passengers carrying cabindrivers cabin) of cars power supply (eg Dual Voltage(DV)Alternative Current (AC) Direct Current (DC)) and other char-acteristics In addition to differences at the train level theremight be differences at car level too An example of this couldbe the orientation (same or opposite direction as the leadingcar) or the position of the car All the train functions such ason-board communication passenger information entertainmentare controlled by the Train Control and Management System(TCMS) which is a complex system consisting of different soft-ware and hardware units connected via different communicationlinks such as Internet Protocol (IP) networks Most of the func-tionalities of TCMS units are common for different types oftrains Some of the generic functions in TCMS units are

ndash Doors control function mdash controlling the opening andclosing of train doors

ndash Passenger information function mdash displaying real-timeinformation to the passenger

ndash Pantograph updown function mdash indicating if the panto-graph is in contact with the electric lines

In addition each of these units might have few modules de-veloped differently for each train to accommodate the traindifferences In total the Aventra SPL composes of 12 differenttrains 17 variation points and 63 variants

31 Aventra SPL Feature CategorisationAccording to the proposed methodology the first step to be per-formed is the elicitation and categorisation of the SPL featuresWe have elicited the Aventra SPL features from the SoftwareArchitecture and Design Specification (SAS) of Aventra TCMSApplications using the third degree of data collection techniqueintroduced by Lethbridge et al (Lethbridge et al 2005) Thisactivity has identified 63 variants grouped in 17 variation pointsIn sum 12 final products are configured starting from the 4 pri-mary features and related constraints Table 1 shows the elicitedfeatures together with their values

We have decided to include the secondary features with cor-responding options in the variability model for a number ofreasons including the following In the Aventra SPL we hada small number of secondary features Hence including themin the variability model did not lead to an unmanageable vari-ability model Omitting secondary features from the variabilitymodel would have hampered the automatic generation of config-uration files and required a considerable amount of additionalwork for manually specifying these features in each and everyconfiguration file In addition having secondary features in the


Featurename

Categorisation Description

type Primary Type of train It can be t_LOT t_EAAt_SWR

carNr Primary Number of car per consist It can be 45 or 10

voltage Primary High voltage configuration in the con-sist It can be AC DC DV

maxSpeed Secondary It can be unknown 140kph87mph180kph111mph or 250kph155mph

doorsPerCar Secondary Number of doors per car It can be 1 23 4 or 5

sideOfConsist Primary Side of the consist It can right or left

cartype Secondary Type of car in the consist It can be AB C D E

carOrient Secondary Orientation of the car with respect theleading car It can be unknown same oropposite

Table 1 Features for the Aventra SPL

variability model gave us the possibility of specifying variantsconstraints on such features

32 Aventra SPL Variability ModelIn the second step of the proposed approach the elicited fea-tures and their values are used to create a model of the SPLvariability model We have created the model of the SPL usingthe FeatureIDE tool which is an Eclipse-based framework forfeature-oriented software development FeatureIDE providesfor a user-friendly visualisation of the features and their rela-tionships in the model It supports multi-views configuration ofeach product It provides support for the evolution of the featuremodel simply enabling the addition or deletion of features inthe feature model In addition FeatureIDE provides variantconstraints management and constraints can be added deletedor modified in accordance with user needs Figure 3 to Fig-ure 5 show the FeatureIDE model of the Aventra SPL variabilitymodel For the sake of readability we have split the modelinto three figures Figure 3 shows the primary features togetherwith their possible values while Figure 4 and Figure 5 show thesecondary features and their possible values It is worth notingthat the categorisation of features in primary and secondary inthe feature model is only logical hence has no direct impact onthe variability model or configuration files FeatureIDE allowsto mark features as mandatory optional concrete and abstractMandatory features are those features that hold for all the prod-ucts in the SPL For instance all the trains will have the typefeature but only ten-cars-per-consist trains will have the side-OfConsist feature Optional features are features that might beomitted for given products Concrete features are features thatwill be included in the configuration file We have used concretefeatures for representing variants Abstract features representfeatures that will not be included in the configuration file Wehave used abstract features for representing variation points Inaddition features can be assigned in the so-called alternativegroup Features in an alternate group are mutually exclusiveIn the variability model in Figure 3 to Figure 5 we have used

alternative group features for representing variants of a variationpoint When features are marked within an alternative groupFeatureIDE generates implicit constraints to ensure the correctsemantic

33 Avetra SPL Variant ConstraintsIn FeatureIDE variant constraints (also known as cross-treeconstraints (Seidl et al 2016)) are expressed using Boolean-like formulas via the create constraint functionality Variantconstraints can be updated and new variant constraints can beadded at any point in time In the Aventra SPL we have decidedto add only technical constraints to the variability model Themain reason for such a decision was to ensure the separationof concerns between domain knowledge expressed by techni-cal constraints and customer preferences The Aventra SPLtechnical constraints were

1 tLOT rarr carNr4 or carNr5

2 tLOT and carNr5 rarr vDV

3 tLOT and carNr4 rarr notvDC

4 tEAA rarr vAC

5 tSWR rarr carNr5 or carNr10

6 tSWR rarr notvAC

7 carNr10 rarr sideO f Consist

8 carNr4 or carNr5 rarr notsideO f Consist

9 carNr5 or carNr10 rarr car5type

10 carNr5 or carNr10 rarr car5o

11 carNr4 rarr notcar5type

12 carNr4 rarr notcar5o

Technical constraints impose restrictions on variants of differentvariation points The first constraint specifies that a train of typeLOT can only have four-cars or five-cars consists The secondconstraint specifies that a train of type LOT having five-cars con-sists will have a dual voltage system The third imposes directcurrent systems for trains of type LOT The fourth constraintstates that all trains of type EAA must have an alternating cur-rent system The fifth and sixth constraints specify that trains oftype SWR must have five-cars or ten-cars consists and that cannot have an alternating current system The seventh constraintspecifies that the feature sideOfConsist can be specified onlyfor ten-cars consists In fact a ten-car consist is composed of apermanent linking of two five-car sets hence the two sides of con-sists might have different configurations of cars and functionsThe eighth constraint specifies that the feature sideOfConsistcan not be specified for four-cars or five-cars consists Ninth andtenth constraints specify that features car5type and car5o canbe specified only for trains having five-cars or ten-cars consistswhile constraints number eleven and twelve states that car5typeand car5o features can not be specified for trains having four-cars consists FeatureIDE provides a graphical editor for the

6 Ferko et al

Figure 3 Primary Features of the Aventra SPL variability model

Figure 4 Secondary Features of the Aventra SPL variability model (I)

Figure 5 Secondary Features of the Aventra SPL variability model (II)

visualisation of products and their features For each productfeatures are organised in a tree structure where leaves representpossible values of features as shown in Figure 6 and Figure 7Each feature and feature value are provided with a checkbox

which can be used for selecting or deselecting that feature orvalue (selected features are marked with a green plus in Figure 6and Figure 7) FeatureIDE prevents users from selecting invalidcombinations of features or values meaning combinations thatviolate the specified constraints All the features and the valuesspecified as mandatory in the constraints are automatically se-lected Similarly features and values excluded by the specifiedconstraints are automatically disabled and cannot be selected

For instance Figure 6 shows that the value v_DC is deselectedbecause of a technical constraint and that value v_DV is manu-ally selected instead Similarly Figure 7 shows that the featurecar5type is automatically deselected because of the specifiedconstraint

34 Generating Aventra SPL Configuration FilesThe generation of the Aventra SPL configuration files is en-trusted to the automation mechanism described in Section 2FeatureIDE provides a mechanism for creating XML data filescontaining the list of features along with their values These filesare created starting from the three structures described above


Figure 6 Tree constraint in configuration editor forLOT4carDV

Figure 7 Cross-tree constraint in configuration editor forLOT4carDV

and for each product of the SPL In the context of the mech-anism presented in Section 2 these files are equivalent to thelist of variation points and variants created from the Collectormodule We have used such a feature for creating the files con-taining the list of features that are selected for one product andtheir values of the Aventra SPL Listing 3 describes a fragmentof the file containing the list of variation points and variants forthe LOT4carDV product

1ltconfigurationgt

2

3ltfeature automatic=selected name=typegt

4ltfeature manual=selected name=t_LOTgt

5ltfeature automatic=unselected name=t_EAAgt

6ltfeature automatic=unselected name=t_SWRgt

7ltfeature automatic=selected name=carNrgt

8ltfeature manual=selected name=carNr_4gt

9ltfeature automatic=unselected name=carNr_5gt


11ltfeature automatic=selected name=voltagegt

12ltfeature automatic=unselected name=v_ACgt

13ltfeature automatic=unselected name=v_DCgt

14ltfeature manual=selected name=v_DVgt

15ltfeature automatic=selected name=maxSpeedgt

16ltfeature manual=selected name=sp_140kph87mphgt

17ltfeature automatic=unselected name=sp_180kph111mphgt


19ltfeature automatic=selected name=DoorsPerCargt

20ltfeature automatic=unselected name=D_onegt

21ltfeature manual=selected name=D_twogt

22ltfeature automatic=unselected name=D_threegt

23ltfeature automatic=unselected name=D_fourgt

24ltfeature automatic=unselected name=D_fivegt

25

26ltconfigurationgt

Listing 3 List of variation points and variants for theLOT4carDV product

This product is a LOT train characterised by four cars and a dualvoltage system Its max speed is 140 kilometres per hour andit has two doors per car Accordingly the variation points andvariants corresponding to these values are marked as selectedFor the sake of space we only show a portion of the file contain-ing the list of variation points and variants for the LOT4carDVproduct The interested reader can find the other files here3

It should be noted that the higher the number of constraints inthe SPL model the higher is the number of features that can beautomatically selected or deselected However the complexityof specifying new constraints increases with the total numberof constraints as each of these is specified through Booleanexpression (which needs to take into account already specifiedones) All these files are provided as input to the generationmechanism together with the translation file described in Sec-tion 2 In Listing 4 we report an excerpt of the translation filedeveloped for the Aventra SPL In particular Listing 4 showsthe relations responsible for the translation of S_B_Project andST_B_MaxSpdHmi parameters For the sake of space we onlyreport portions of these files Listing 5 shows the generatedconfiguration file for the LOT4carDV product In particular wecan see that the features have been translated into parametersaccording to the relations specified in the translation file in List-ing 4 For instance the combination of features type and carNrhas been translated into the S_B_Project parameter and theirvalues t_LOT and carNr_4 into the parameter value 1 (lines 1to 9 of Listing 4)

3 httpszenodoorgrecord4737049YJFBwy0Rrxh

8 Ferko et al

1 S_B_Project

2 Type Integer

3 Comment Customer project 1 Lotrain 4 cars 2 Lotrain 5 cars 3 East

Anglia 5 cars 4 East Anglia 10 cars (side A or B of 5 car consist) 5

intentionally empty 6 South West 5 cars 7 South West 10 cars (side A

or B of 5 car consist)

4 Values [

5 Features [ t_LOT carNr_4 ]

6 Value 1


8 Value 2

9 ]

10 ST_B_MaxSpdHmi

11 Type Integer

12 Comment Max speed dial valueValue interpretation 0minusunknown 1minus

140kph87mph 2minus180kph111mph 3minus250kph155mph

13 Values [

14 Features [ sp_140kph87mph ]

15 Value 1


17 Value 2


19 Value 3

20 ]


22

Listing 4 Example of the translation file for the Aventra SPL

1 ltParameterSetgt

2

3 ltParametersgt

4 ltParameter Name=S_B_Project Type=Integer Value=1 gt

5 ltParameter Name=ST_B_MaxSpdHmi Type=Integer Value=1 gt

6 ltParameter Name=HV_config Type=Integer Value=1 gt

7 ltParameter Name=Nr_of_cars_in_consist Type=Integer Value=4 gt

8 ltParameter Name=Nr_of_doors_per_car Type=Integer Value=2gt

9 ltParameter Name=Type_car1 Type=String Value=D gt

10 ltParameter Name=Orientation_car1 Type=Integer Value=2 gt

11

12 ltParametersgt

13 ltParameterSetgt

Listing 5 Generated configuration file for the LOT4carDVproduct

4 EvaluationIn this experience report we describe our experience in au-tomating the generation of SPL configuration files in the railwaydomain with BT

In this section we evaluate the correctness of the pro-posed approach together with its ability in lowering the error-proneness and the developing effort typical of the manual ap-proach We use expert interviews for assessing the industrialrelevance of the proposed approach and collecting qualitativefeedback on its benefits and drawbacks Eventually we dis-cuss the main threats to validity for this research and relatedmitigation strategies

When defining the automation mechanism we have createdboth the Executor and the Translation file so that they wouldgenerate configuration files identical to the handcrafted onesthat were previously used within BT It is important to note thathaving identical configuration files was of crucial importancefor BT In fact differences in the configuration files wouldaffect the software running in the trains which would need tobe updated Assuming that the correct set of variation pointsand variants are selected there is only one factor that couldundermine the generation of identical configuration files whichis the presence of errors in the Translation file In order to showthat the Translation file is free from errors we have comparedthe 12 generated configuration files for the Aventra SPL withthe handcrafted ones using a visual difference tool focusing onfiles directories and version controlled projects comparisonThe results of the comparison have shown that all the generatedconfiguration files were 100 identical to the manually createdones The interested reader can access the comparison here4

Hence the proposed mechanism is correct One may argue thatin general there is still the possibility to introduce errors whenwriting the mappings in the Translation file While this is a validconcern such a risk can not be completely removed althoughwe have identified several mitigation strategies that could beadded to our automation mechanism (we discuss this in thefollowing section) Moreover it should be noted that this risk ismore likely to happen in a traditional manual approach as theengineer would need to rely on the mappings that we formalisein the translation file each time she writes the configuration filefor a product in the SPL (while in the proposed process theTranslation file is written only once per SPL)

One of the main goals of the proposed approach is to miti-gate the error proneness typical of manual approaches Whenworking on the Aventra SPL engineers in BT have identifiedthree main categories of errors that can be made when manuallycreating the configuration files being (i) omitting informationparameters or technical values are omitted from configurationfiles (ii) wrong semantics the parameters and their value areinserted in the document but they are interpreted wrongly (iii)inconsistencies parameters or technical values are inconsistentamong the configuration files Errors in the first and third cate-gories are implicitly avoided using the proposed approach Infact both parameters and values are automatically generatedstarting from the same SPL model and Translation file Thismeans that it is not possible to have two or more configurationfiles having for instance a different set of parameters Besidesall the parameters and their value are generated taking into ac-count the set of identified variation points and variants Henceno information is omitted or lost in the process of generatingconfiguration files The above mentioned comparison amonggenerated and manually created configuration files shows thatthe proposed mechanism is free from inconsistencies and in-formation loss Within the proposed approach errors in thesecond category may arise if an erroneous Translation file iscreated However compared to the traditional manual approachthe proposed mechanism drastically reduces the possibility ofsuch errors In fact the Translation file is only written once per4 httpszenodoorgrecord4737049YJFAXC0Rrxg


SPL as opposite to the manual approach where such errors canhappen each time an engineer writes a configuration file for aproduct in the SPL

Another important goal of the proposed approach is to lowerthe development effort of the configuration files In order toevaluate this aspect we have compared the number of artefactsthat need to be manually created with the proposed approachand with the traditional one If n is the number of productsin a SPL then the number N of manually created or modifiedartefacts for the proposed approach is Nproposedapproach = 3Within the proposed approach an engineer needs to manuallycreate the Collector Executor and Translation file If n is thenumber of products in a SPL then the number N of manuallycreated or modified artefacts for the traditional manual approachis Nmanualapproach = n With manual approaches the engineerswould need to manually create a configuration file for each ofthe n products in the SPL By estimating the number of manu-ally created artefacts with both approaches it is evident that theproposed mechanism is able to reduce the development effortfor the configuration files This suggests that the proposed ap-proach discloses the opportunity of lowering development effortalready for SPLs containing three products In this comparisonwe assume that the effort of eliciting and managing featuresis the same with both approaches and that the SPL is newlycreated If that is not the case then the number N of manu-ally created or modified artefacts for the proposed approachis Nproposedapproach = 4 In fact an engineer would need tomanually create the SPL model besides the already mentionedartefacts It is worth mentioning that the complexity of the SPLmodel is directly related to the number n of products in the SPLHowever we can reasonably state that for reasonable n-valuesthe development effort related to manual models in traditionalapproaches is greater than the effort related to the creation ofthe SPL model Collector Executor and Translation file in theproposed approach

In order to discuss the development effort needed in thecase of evolving SPLs we have identified three different sce-narios The first scenario involves adding new functionalityfor any existing product in a SPL as the result of a customerneed In the context of the Aventra SPL this could be the in-stallation of a new air conditioning system for the EAA trainsThis scenario requires updating all the configuration files of allthe products in the SPL so to reflect the new parameter alongwith its technical value If n is the number of products in theSPL manual approaches would require n modifications whilethe proposed approach would require 1 modification In factmanual approaches would require the modification of all theconfiguration files The proposed approach would require mod-ification of the translation file only as the configuration fileswill be updated automatically by a subsequent execution of theautomation mechanism The second scenario involves changinga feature for a subset of existing products in the SPL In thecontext of the Aventra SPL this could be requiring that all theLOT trains would switch from having two doors per car to fourdoors per car This scenario requires the modification of theconfiguration files of the involved products only If k is thenumber of the products in the subset being modified manual

approaches would require the modification of k configurationfiles while the proposed approach would require 1 modificationfor modifying the constraint related to the feature The thirdscenario involves the addition of a new product to the SPL Thisscenario has two sub-scenario In the first sub-scenario theproduct is added with the same set of features as the existingones In the Aventra context this sub-scenario could be tohave a LOT train with 10 cars This scenario would require thecreation of the configuration file for the new product Manualapproaches would require the manual creation of one configu-ration file while the proposed approach would not require anymanual modification as the new product would be captured bythe variability model prior to the generation phase The secondsub-scenario is when the new product is added with additionalfeatures In the Aventra context an example of this scenariocould be a customer requiring a LOT train with 10 cars and anew maximum speed of 300kph186mph This scenario wouldrequire the modification of all the configuration files If n isthe number of products in the SPL manual approaches wouldrequire n modifications while the proposed approach wouldrequire the modification of the translation file only

We have performed expert interviews for assessing the indus-trial relevance of the proposed approach and collecting feedbackon perceived benefits and drawbacks The questionnaire encom-passes thirteen questions being a mix of open-ended and closed-ended questions The questions assessing the industrial rele-vance draw on the model for assessing the industrial relevanceof technology transfers introduced by Ivarsson et al (Ivarssonamp Gorschek 2011) This model focuses on four aspects beingsubjects context scale and research method The survey wasshared with the engineers from the BT Aventra developmentteam and we got six respondents For the sake of space we omitthe list of the questions which can be found here5 To sum up667 of the respondents have found the problem of manuallycreating configuration files to be relevant and 167 extremelyrelevant (on a scale from not relevant at all to extremely rel-evant) One respondent has said that ldquothis is a problem thatwill only be more extensive in the future when trying to pro-vide generic softwarerdquo When asked about the suitability of theproposed approach 834 of the respondents found it to besuitable (on a scale from not suitable at all to extremely suit-able) Some of the perceived benefits are ldquoeasy to maintain andextendrdquo ldquothis approach can improve quality of Aventra softwaredeliveries reducing time for generating the configuration filesmitigating risk for a failure etcrdquo Among the main drawbacksthe respondents have identified that ldquoin the (unlikely) eventof major changes in the parameters the feature model and theautomation pipeline could require huge and time consumingrefactoringrdquo and ldquo challenging to have it reused in other do-mainsprojectsrdquo When evaluating the industrial relevance ofthe proposed approach 837 of the respondents have foundthe subjects the context the method and the scale aspects tobe industrially relevant

5 httpszenodoorgrecord4737049YJFAXC0Rrxg

10 Ferko et al

41 Threats to ValidityHereafter we discuss and classify potential threats to validityand describe our mitigation strategies according to the schemeproposed by Runeson et al (Runeson amp Houmlst 2009) The workpresented in this experience report is an example of appliedresearch According to Wohlin et al the threats to validityfor applied researches can be prioritised as follow (from themost to the least important) internal external construct andconclusion validity (Wohlin et al 2012)

411 Internal Validity Threats to internal validity affectthe ability to draw correct relationships between treatment andoutcome In order to mitigate possible threats to internal validitywe have decided to work on a real-life example coming from ourindustrial partner the Aventra SPL This has ensured the validityof the artefacts and of the use case set up When developing theproposed approach we have made an effort not introducing newtools and limiting the impact of tool performance For instancewe have decided to measure the number of createdmodifiedartefacts rather than the developing or modifying time as thiscould have been affected by the tools and underlying hardwareAlthough we have used only a single group we believe this didnot affect the response of the subjects involved as all of them hadprior and established experience in BT and SPL development

412 External Validity Threats to external validity affectthe ability to generalise the results beyond the experiment set-tings In order to mitigate such threats we have made an effortfor selecting the most representative subjects Within BT wehave only had subjects that had prior experience with SPL de-velopment When it comes to the selection of the use case wehave referred to the real-world use case from BT being the Aven-tra SPL The Aventra SPL was among the latest SPLs beingdeveloped at BT We have designed developed and appliedthe proposed mechanism within the BT premises within thesame context where the production takes place Eventually wehave proposed a discussion for each step composing the pro-posed approach for adapting it in different scenarios as a wayof generalising the finding of this research

413 Construct Validity Threats to construct validity re-late to the extent to which the setting of an experiment reflectsthe theory In order to mitigate such threats we have tried toevaluate different aspects of the proposed approach as oppositein focusing on one single factor Besides we have comple-mented the evaluation with a qualitative survey The designdevelopment and application of the proposed approach havebeen carried out within BT and using a real-world exampleWhen preparing the questionnaire we have made an effort inavoiding any possible hypothesis guess and treatment testing

414 Conclusion Validity Threats to conclusion validityaffect the ability to derive a correct conclusion from the rela-tions between treatment and outcome To minimise threats toconclusion validity we have asked independent practitioners toanalyse the outcome of our experience report Besides we havemade an effort in evaluating the proposed mechanism usingobjective measures as in the case of the number of artefacts We

have found the number of artefacts to be more reliable sinceit does not involve human skills When constructing the quali-tative questionnaire we have tried to use simple wording andhave remained available for possible explanations Eventuallywe have submitted the questionnaire only to the BT engineershaving a proven experience in SPL development

5 Discussion and Lessons Learnt

In Section 2 we have introduced the proposed approach andits steps For each of these steps we have identified a setof alternatives or decisions that could potentially impact thegeneration process In this section we discuss the benefits anddrawbacks of these alternatives with the aim of highlightingimportant aspects contributing to the generalisability of theproposed approach In addition we discuss our choices anddescribe lessons learnt

The first step of the proposed approach is the categorisa-tion of features in primary and secondary features Here thedecision is whether or not to include the secondary features inthe variability model to build in the second step Including thesecondary features in the variability model leads to a more de-tailed model of the SPL and enables the automatic generation ofconfiguration files However including the secondary featurescan contribute to a very complex and potentially unmanage-able variability model especially when secondary features arethe majority in the architecture Omitting secondary featuresfrom the variability model would reduce the complexity and thesize of the architecture leading to a more manageable modelHowever it would dramatically increase the number of manualmodifications as the secondary features and their values wouldneed to be added later as variation points and variations of eachproduct In addition omitting secondary features would alsohamper the specification of constraints on these features hencethe automatic generation of valid configuration files Here thetrade-off is between completeness and manageability The rele-vance of such a trade-off has been stressed by an expert in thesurvey ldquoin the (unlikely) event of a major change in the parame-ters the feature model could require a huge and time consumingrefactoringrdquo In the case of the Aventra SPL we have decidedto include the secondary features and mark them as mandatoryfeatures in the feature model developed using FeatureIDE Inthis way they were automatically selected for every product andwe could easily configure them and add put constraints Ourdecision was mainly affected by two factors being the level ofautomation we wanted to achieve and the limited number ofsecondary features for the Aventra SPL

The second step of the proposed approach is creating thevariability model The main decision to take is on the notationto be used for representing the variability model hence variationpoints and variants We have identified two alternatives beingto use feature modelling or to use metamodelling Feature mod-elling is a well-established formalism which has been widelyused for SPLs The second alternative is using metamodellingfor creating an ad-hoc language It is worth mentioning thatfeature modelling is often achieved using metamodelling tech-niques In our experience the crucial factors affecting this step


are the set of competencies and skills in the company and theavailable resources in terms of time and costs In the surveyone respondent has highlighted that ldquoItrsquos not easy to find prac-titioners with modelling skillsrdquo Here the trade-off is betweendevelopment effort flexibility and prior knowledge In thecase of the Aventra SPL we have decided to use feature mod-elling and the FeatureIDE tool as it was already known withinBombardier Transportation and did not require further trainingOther reasons behind our choice were ease of use graphicalinterface and support for SPL evolution

The third step of the proposed approach is the categorisa-tion of variant constraints in technical and customer-specificThe main decision in this step is whether or not to specifycustomer-specific constraints on the variability model Spec-ifying customer-specific and technical constraints leads to aprecise definition of products whose configuration files can bederived using automation mechanisms However this wouldrequire more development effort for engineers to write all theconstraints and deep knowledge of the products In additionthis could have an impact even when a product is added ormodified as a higher number of constraints might potentiallyneed to be updated Defining only technical constraints hasresulted to be a more flexible solution and supports the evolu-tion of SPL with less effort than in the first option Moreoverwith this approach tasks can be easily divided through differ-ent teams Engineers with domain knowledge are involved increating technical constraints and other engineers would dealwith the customer requirements in later stages and at the productlevel In this step the trade-off is between development effortand completeness In the case of Aventra SPL we have decidedto specify only technical constraints to ease possible future ex-tensions and to be able to separate tasks into teams with differentlevels of domain knowledge and customer-specific requirementsknowledge

The last step of the proposed approach is the generation ofconfiguration files The main discussion here is how to realisethe automation mechanism The first alternative is to use ad-hoc transformation languages The second alternative is to usetraditional programming languages leveraging concepts of gen-erative programming The first alternative can rely on a wideset of transformation languages and supporting tools may en-able a round-trip process (Eramo amp Bucaioni 2013) and wouldseem the natural choice in the case metamodelling is used in thesecond step However this solution comes with several prac-tical drawbacks including the following Metamodeling andtransformation languages require specific skills to be masteredUsually these skills are rarely found in the industry In additiontools supporting transformation languages are usually not inthe technological stack of companies hence they would requireprior training to be effectively used Finally transformationlanguages and supporting tools would need to undergo the certi-fication processes and this is a major drawback for a companyoperating in safety-critical domains such as the railway domainas discusses in Section 2 Metamodelling and domain-specificlanguages (DSLs) could have been used for creating the transla-tion file with a concise syntax and semantics A simple toolinginfrastructure could have build on this language so to achieve

eg code completion type checking etc As mentioned abovewe have decided not to use metamodelling techniques for thelack of competencies in the company which would have made itdifficult to maintain and evolve the automation mechanism Be-sides the use of a DSL would have not improved the mappingsbetween parameter and features value that can not be changed infavour of more meaningful ones as the feature technical valuescome from the actual software (which in many cases is inheritedfrom previous related projects) Eventually we have providedthe translation file with a default value that is added in case noneof the correct mappings is triggered With such a mechanismengineers can filter all configuration files with parameters thathave a default value to find any possible inaccuracy or mistakeswhen configuring the products It should be noted that despitewe do not use external (modelling) tools the proposed mecha-nism still needs to undergo verification and validation activitiesin accordance with the safety standards

6 Related Work

In this section we survey the principal strands of research thatrelate to the work we present in this paper

In the last decades researchers and practitioners have pro-posed several notations and approaches for representing thevariability model of SPLs along with its variability In thisrespect one of the most used techniques is feature mod-elling (Danilo Beuche 2006) Other commonly used techniquesare modelling and metamodelling In their work Fang et alhave presented an approach for automating software derivationwhere feature modelling is integrated with domain-specific mod-elling languages for variability expression (Fang et al 2016)Bergen et al in their study present a comparison of Kconfigand Component Description Language (CDL) two variabilitymodelling languages that adopt the concepts of feature mod-elling Both languages are used in practice to describe thevariability of the Linux kernel and eCos operating system forembedded devices respectively (Berger et al 2010) Compareto our approach the work by Fang et al and Bergen et al havea narrower scope as they mostly focus on variability expressionand not on product derivation

The work by Czarnecki et al proposes to split the configu-ration process into different stages Each stage yields a featuremodel where a subset of the system described on the initialfeature model can be specified An example of this could beto address the requirements from individual manufacturers inthe first stage while configuring product components in a laterstage The process by Czarnecki et al has some similaritieswith Variant Constraint Categorisation in our proposed processBoth approaches propose to split the configuration process intostages While correspondences between staged-configurationsand primary and secondary features can be drawn in the generalcase they are not equivalent To the best of our understandingour categorisation of features is more restrictive while in theprocess by Czarnecki et al an engineer can decide to split therequirements in any way she wants and assign each category toa given stage (Czarnecki et al 2004)

12 Ferko et al

In the domain of train signaling Svendsen et al (Svend-sen et al 2010) have proposed an approach for representingSPLs and generating their products which uses the interplay oftwo domain-specific modelling languages being the Train Con-trol Language and the Common Variability Language (CVL)Vasilevskiy et al have investigated the use of domain-specificmodellling languages for representing variability and derivingnew products (Vasilevskiy et al 2015) In particular they haveintroduced the Base Variability Resolution language as an ex-tension of CVL and have provided the BVR tool bundle asa set of Eclipse plugins The BVR tool bundle supports theresolution realisation and derivation of products The sameauthors have introduced an approach to build robust realisationstoo (Vasilevskiy et al 2016) In the scope of their work realisa-tions define mappings between abstract features in a feature treeand their implementation artefacts The goal of their approachwas to ensure that small changes in the SPL model would resultin small changes in the realisations Although targeting productrealisation the approaches of Svendsen et al and Vasilevskiyet al use different techniques as compared to our approachThe approach in this paper achieves product realisation usingconfiguration files Besides being a possible technique this wasa strong requirement inherited from our business partner In theproposed approach we use the concepts of generative program-ming while in their approaches Svendsen et al and Vasilevskiyet al leveraged the interplay of modelling languages and codegeneration

Several works have been investigating the use of Aspect-Oriented Programming (AOP) for product derivation Lee etal (Lee et al 2009) leverage the interplay of AOP and fea-ture modelling for introducing automation in the product re-alisation Voelter and Groherin propose to use model-drivenand aspect-oriented development to support the product deriva-tion process (Voelter amp Groher 2007) Feature models anddomain-specific models are used to represent the problem andthe solution domain while model transformations and AOPtechniques are used for the automatic manipulation of thesemodels leading to product realisation Another research focus-ing on model transformations has been presented by Tawhidand Petrin (Tawhid amp Petriu 2011) Their approach tacklesthe problem of automatically generating a model for a specificproduct while focusing on performance aspects To this endit relies on two model-to-model transformations The first oneuses the Atlas Transformation Language (ATL) and takes asinput a feature model of the SPL and produces a UML modelwith performance annotations realised as MARTE annotationsStarting from this model the second transformation generates aLayered Queueing Network (LQN) model that will be used toanalyse the performance of the SPL

Several frameworks and commercial tools support productconfiguration in the context of SPL One such tool is Arch-Studio an Eclipse-based development platform based on Arch-Feature (Gharibi amp Zheng 2016) ArchFeature provides foran architectural model integrating feature specification prod-uct line architecture and their relationships This is achievedby extending an existing XML-based architecture descriptionlanguage namely xADL xADL is mostly used for modelling

system architectures consisting of components and connectionsIt includes a graphical modelling environment that visualiserelationships of feature in a SPL and supports the automaticderivation of the products An assessment for other frameworksand commercial tools supporting product configuration in aSPL such as GEARS purevariants Captor CIDE MSVCMXVCL GenArch is done in (Torres et al 2010)

7 Conclusion and Future Work

In this experience report we have presented our work for au-tomating the generation of configuration files in the context ofsoftware product lines The proposed approach revolves arounda mechanism leveraging concepts of generative programmingand is composed of four main steps spanning through the wholesoftware product line development process We have validatedthe applicability of the proposed approach using an industrialuse case from the railway domain the Bombardier Transporta-tion Aventra train family Besides we have evaluated the abilityof the proposed approach of lowering the development effortand mitigating the error proneness typical of manual approachesThe application of the proposed approach on the Aventra trainfamily has shown that the development effort and the errorproneness are mitigated already for software product lines con-taining a limited number of products and features We havecomplemented the evaluation with a questionnaire on the Bom-bardier engineers We have discussed lessons learnt and foreach of the steps of the proposed approach we have identified alist of factors and alternatives that could affect its adoption inother contexts

Future work might encompass several research directionsOne direction is to extend the translation file with a proper JSONschema for improving drawbacks related to type-checking andconsistency Another possible extension improving the specifica-tion of the mappings could be to develop a domain-specific lan-guage Eventually a further extension is to investigate the pos-sibility of realising the proposed approach within FeatureIDEAnother research direction encompasses the development of thegeneration mechanism using model-transformation languagesIn particular we are already investigating the use of the Acceleotransformation language Finally we are investigating how toautomatically collect or elicit features from requirements forenabling the automatic derivation and categorisation of featuresand constraints This could be achieved with the interplay be-tween formal notations for the specification of requirements anda feature mining approach

Acknowledgments

The work in this paper is supported by the Swedish Knowledge Foun-dation (KKS) through the projects A-CPS and MINEStrA and by theSwedish Governmental Agency for Innovation Systems (VINNOVA)through the project PANORAMA

References

Arboleda H amp Royer J-C (2012) Model-driven and softwareproduct line engineering John Wiley amp Sons Incorporated


Bell R (2006) Introduction to iec 61508 In Acm internationalconference proceeding series (Vol 162 pp 3ndash12) AustralianComputer Society Inc

Berger T She S Lotufo R Wasowski A amp CzarneckiK (2010) Variability modeling in the real A perspectivefrom the operating systems domain In Ase rsquo10 (p 73ndash82)Association for Computing Machinery

CENELEC (2020) Railway applications - communication sig-nalling and processing systems - software for railway controland protection systems (httpsstandardsglobalspeccomstd14317747EN2050128)

Czarnecki K amp Eisenecker U W (2000) Generative program-ming Methods tools and applications Addison-Wesley

Czarnecki K Helsen S amp Eisenecker U W (2004) Stagedconfiguration using feature models In Software productlines splc 2004 lecture notes in computer science vol 3154Springer Berlin Heidelberg

Danilo Beuche M D (2006) Software product line engineer-ing with feature models Software Development Magazine -Project Management Programming Software Testing

Eramo R amp Bucaioni A (2013) Understanding bidirectionaltransformations with tggs and jtl Electronic Communicationsof the EASST 57

Fang M Leyh G Doerr J amp Elsner C (2016) Multi-variability modeling and realization for software derivationin industrial automation management In Proceedings ofthe acmieee 19th international conference on model drivenengineering languages and systems (p 2ndash12) New York NYUSA Association for Computing Machinery

Gharibi G amp Zheng Y (2016) Archfeature Integrating fea-tures into product line architecture In Proceedings of the 31stannual acm symposium on applied computing (p 1302ndash1308)New York NY USA Association for Computing Machinery

Ivarsson M amp Gorschek T (2011 06) A method for evaluat-ing rigor and industrial relevance of technology evaluationsEmpirical Software Engineering 16 365-395

Klaus Pohl F v d L Guumlnter Boumlckle (2005) Software productline engineering Springer Berlin Heidelberg

Lee K Botterweck G amp Thiel S (2009 May) Feature-modeling and aspect-oriented programming Integration andautomation In 2009 10th acis international conference onsoftware engineering artificial intelligences networking andparalleldistributed computing (p 186-191)

Lethbridge T C Sim S E amp Singer J (2005) Studyingsoftware engineers Data collection techniques for softwarefield studies Empirical Software Engineering 10 311ndash341

Liebel G Marko N Tichy M Leitner A amp Hansson J(2014) Assessing the state-of-practice of model-based engi-neering in the embedded systems domain In Internationalconference on model driven engineering languages and sys-tems (pp 166ndash182)

Loesch F amp Ploedereder E (2007) Optimization of variabilityin software product lines In 11th international softwareproduct line conference (splc 2007) (p 151-162)

Meinicke J Thuumlm T Schrter R Benduhn F Leich Tamp Saake G (2017) Mastering software variability with

featureide (1st ed) Springer Publishing Company Incorpo-rated

Metzger A amp Pohl K (2014) Software product line en-gineering and variability management achievements andchallenges In Future of software engineering proceedings(pp 70ndash84) Association for Computing Machinery

Nesrine L amp Bennouar D (2018) On the use of model trans-formation for the automation of product derivation process inSPL Acta Universitatis Sapientiae Informatica 10 43-57

Pop P Scholle D Hansson H Widforss G amp RosqvistM (2016) The safecop ecsel project Safe cooperatingcyber-physical systems using wireless communication In2016 euromicro conference on digital system design (dsd)(pp 532ndash538)

Runeson P amp Houmlst M (2009) Guidelines for conductingand reporting case study research in software engineeringEmpirical software engineering 14(2) 131

Seidl C Winkelmann T amp Schaefer I (2016) A softwareproduct line of feature modeling notations and cross-treeconstraint languages In A Oberweis amp R Reussner (Eds)Modellierung 2016 (p 157-172) Bonn Gesellschaft fuumlrInformatik eV

Sendall S amp Kozaczynski W (2003) Model transformationThe heart and soul of model-driven software developmentIEEE software 20(5) 42ndash45

Svendsen A Zhang X Lind-Tviberg R Fleurey F HaugenOslash Moslashller-Pedersen B amp Olsen G K (2010) Developinga software product line for train control A case study of cvlIn J Bosch amp J Lee (Eds) Software product lines Goingbeyond (pp 106ndash120) Berlin Heidelberg Springer BerlinHeidelberg

Tawhid R amp Petriu D C (2011) Automatic derivation ofa product performance model from a software product linemodel In 2011 15th international software product lineconference (p 80-89)

Torres M Kulesza U Sousa M Batista T Teixeira LBorba P Masiero P (2010) Assessment of productderivation tools in the evolution of software product lines Anempirical study In Proceedings of the 2nd international work-shop on feature-oriented software development (p 10ndash17)New York NY USA Association for Computing Machinery

Vasilevskiy A Chauvel F amp Haugen u (2016) Toward ro-bust product realisation in software product lines In Proceed-ings of the 20th international systems and software productline conference (p 184ndash193) New York NY USA Associa-tion for Computing Machinery

Vasilevskiy A Haugen u Chauvel F Johansen M F ampShimbara D (2015) The bvr tool bundle to support productline engineering In Proceedings of the 19th internationalconference on software product line (p 380ndash384) New YorkNY USA Association for Computing Machinery

Voelter M amp Groher I (2007) Product line implementationusing aspect-oriented and model-driven software develop-ment In Proceedings of the 11th international softwareproduct line conference (p 233ndash242) USA IEEE ComputerSociety

14 Ferko et al

Wohlin C Runeson P Houmlst M Ohlsson M C RegnellB amp Wessleacuten A (2012) Experimentation in softwareengineering Springer Science amp Business Media

About the authorsEnxhi Ferko is a PhD student at Maumllardalen University (Sweden)You can contact him at enxhiferkomdhseher

Alessio Bucaioni is an assistant professor at Maumllardalen University(Sweden) You can contact him at alessiobucaionimdhsehim

Jan Carlson is a professor at Maumllardalen University (Sweden) Youcan contact him at jancarlsonmdhsehim

Zulqarnain Haider is a software engineer at Bombardier RailwayTransportation


Figure 1 Mapping proposed steps to the SPL process

several ways in which the design can be turned into a concreteproduct One common option which is used by BT and isthe focus of this work is to realise individual products usingconfiguration files A configuration file is part of the concreterealisation of the system and determines at run time some of itsaspects A typical example of a configuration file would be anXML data file with parameters that enable or disable differentportions of the common source code according to the featuresselected for that particular product In BT configuration filesare currently created manually starting from a set of heteroge-neous documents These documents often provide for a generaland informal description of the products and their features onlyBesides they might not be stored and managed systematicallyStarting from these documents BT engineers manually createconfiguration files for the different products in the family Expe-riences from BT show that manually creating configuration filesstarting from a set of heterogeneous and informal documentsis time-consuming and error-prone The most common errorsreported by engineers are categorised as (i) omitting informa-tion (ii) wrong semantics and (iii) inconsistencies Besidesthis manual process does not allow exploiting product common-alities meaning that common information needs to be specifiedfor each product

In this experience report we describe our experience in au-tomating the generation of SPL configuration files in the rail-way domain within BT We enable the automatic generationof configuration files defining a four-steps approach whosegeneration mechanism leverages concepts of generative pro-gramming (Czarnecki amp Eisenecker 2000) We demonstrate theapplicability and correctness of the proposed approach using anindustrial SPL from BT being the Aventra train SPL Besideswe evaluate the ability of the proposed approach in mitigatingthe development effort and error proneness typical of traditionalmanual approaches The application on the Aventra SPL sug-gest that the proposed approach has helped BT in lowering thedevelopment effort and mitigating the error proneness typical ofthe traditional manual approaches already for SPL containingmore than 3 products Eventually we use experts interviews tothe Aventra Development team for assessing the industrial rele-vance of the proposed approach and for collecting qualitativefeedback on the perceived benefits and drawbacks For eachstep of the proposed approach we identify a number of factors

and alternatives to take into account for adapting the approachto other development process and domain Eventually we usethese factors and alternatives for discussing the lessons we havelearned

The remainder of this paper is structured as follows In Sec-tion 2 we present the proposed approach its steps and thegeneration mechanism In Section 3 we show the applicationof the proposed approach on the Aventra SPL In Section 4and Section 5 we evaluate the proposed approach and discusslessons learnt and generalisability respectively In Section 6we present some related researches documented in literatureIn Section 7 we conclude the paper with final remarks andpossible future work

2 Proposed ApproachIn this section we describe the proposed approach for automati-cally generating configuration files within the BT developmentprocess Figure 1 provides a graphical representation of theapproach in relation to a simplified version of the SPLE frame-work presented by Pohl et al (Klaus Pohl 2005) the two mainphases of a typical SPLE process are Domain Engineering andApplication Engineering which are represented as white rect-angles in Figure 1 Each main phase consists of a number ofsub-phases represented as red rectangles

The proposed approach consists of four steps being FeatureCategorisation Creation of the Variability Model Variant Con-straints Categorisation and Generation of Configuration FilesFigure 1 represents these steps as circled numbers and placesthem in relation to the sub-phase they occur in In the remainderof this section we describe each step of the proposed approach

21 Feature CategorisationFeature Categorisation is the first step of the proposed approachand should be performed during the Domain Analysis sub-phaseDomain Analysis is responsible for defining documenting andvalidating all the shared and individual requirements of the SPLThese requirements are further mapped to features which areused for defining the variability model of the SPL during theDomain Design sub-phase An example of this could be therequirement that a train has two driver cabins which wouldtranslate in the feature direction indicating the orientation of

2 Ferko et al









Collector



Executor

Translationfile

Configurationfile









4 Ferko et al

1 ltconfigurationgt

2



5

6 ltconfigurationgt


1 parameterName1



4 Values [







11

12 parameterName2

13


15












Featurename


















4 tEAA rarr vAC


6 tSWR rarr notvAC








6 Ferko et al












1ltconfigurationgt

2























25

26ltconfigurationgt





8 Ferko et al

1 S_B_Project

2 Type Integer





4 Values [


6 Value 1


8 Value 2

9 ]

10 ST_B_MaxSpdHmi

11 Type Integer



13 Values [


15 Value 1


17 Value 2


19 Value 3

20 ]


22


1 ltParameterSetgt

2

3 ltParametersgt








11

12 ltParametersgt

13 ltParameterSetgt














10 Ferko et al
















6 Related Work




12 Ferko et al








Acknowledgments


References
































14 Ferko et al















Collector



Executor

Translationfile

Configurationfile









4 Ferko et al

1 ltconfigurationgt

2



5

6 ltconfigurationgt


1 parameterName1



4 Values [







11

12 parameterName2

13


15












Featurename


















4 tEAA rarr vAC


6 tSWR rarr notvAC








6 Ferko et al












1ltconfigurationgt

2























25

26ltconfigurationgt





8 Ferko et al

1 S_B_Project

2 Type Integer





4 Values [


6 Value 1


8 Value 2

9 ]

10 ST_B_MaxSpdHmi

11 Type Integer



13 Values [


15 Value 1


17 Value 2


19 Value 3

20 ]


22


1 ltParameterSetgt

2

3 ltParametersgt








11

12 ltParametersgt

13 ltParameterSetgt














10 Ferko et al
















6 Related Work




12 Ferko et al








Acknowledgments


References
































14 Ferko et al







1 ltconfigurationgt

2



5

6 ltconfigurationgt


1 parameterName1



4 Values [







11

12 parameterName2

13


15












Featurename


















4 tEAA rarr vAC


6 tSWR rarr notvAC








6 Ferko et al












1ltconfigurationgt

2























25

26ltconfigurationgt





8 Ferko et al

1 S_B_Project

2 Type Integer





4 Values [


6 Value 1


8 Value 2

9 ]

10 ST_B_MaxSpdHmi

11 Type Integer



13 Values [


15 Value 1


17 Value 2


19 Value 3

20 ]


22


1 ltParameterSetgt

2

3 ltParametersgt








11

12 ltParametersgt

13 ltParameterSetgt














10 Ferko et al
















6 Related Work




12 Ferko et al








Acknowledgments


References
































14 Ferko et al







Featurename


















4 tEAA rarr vAC


6 tSWR rarr notvAC








6 Ferko et al












1ltconfigurationgt

2























25

26ltconfigurationgt





8 Ferko et al

1 S_B_Project

2 Type Integer





4 Values [


6 Value 1


8 Value 2

9 ]

10 ST_B_MaxSpdHmi

11 Type Integer



13 Values [


15 Value 1


17 Value 2


19 Value 3

20 ]


22


1 ltParameterSetgt

2

3 ltParametersgt








11

12 ltParametersgt

13 ltParameterSetgt














10 Ferko et al
















6 Related Work




12 Ferko et al








Acknowledgments


References
































14 Ferko et al


















1ltconfigurationgt

2























25

26ltconfigurationgt





8 Ferko et al

1 S_B_Project

2 Type Integer





4 Values [


6 Value 1


8 Value 2

9 ]

10 ST_B_MaxSpdHmi

11 Type Integer



13 Values [


15 Value 1


17 Value 2


19 Value 3

20 ]


22


1 ltParameterSetgt

2

3 ltParametersgt








11

12 ltParametersgt

13 ltParameterSetgt














10 Ferko et al
















6 Related Work




12 Ferko et al








Acknowledgments


References
































14 Ferko et al







1 S_B_Project

2 Type Integer





4 Values [


6 Value 1


8 Value 2

9 ]

10 ST_B_MaxSpdHmi

11 Type Integer



13 Values [


15 Value 1


17 Value 2


19 Value 3

20 ]


22


1 ltParameterSetgt

2

3 ltParametersgt








11

12 ltParametersgt

13 ltParameterSetgt














10 Ferko et al
















6 Related Work




12 Ferko et al








Acknowledgments


References
































14 Ferko et al













10 Ferko et al
















6 Related Work




12 Ferko et al








Acknowledgments


References
































14 Ferko et al






















6 Related Work




12 Ferko et al








Acknowledgments


References
































14 Ferko et al














Acknowledgments


References
































14 Ferko et al




































14 Ferko et al







Automatic Generation of Conﬁguration Files: an Experience ...

Documents

Transcript of Automatic Generation of Conﬁguration Files: an Experience ...