Automatic optimisation of system architectures using EAST-ADL

(1)

HAL Id: cea-01810011

https://hal-cea.archives-ouvertes.fr/cea-01810011

Submitted on 7 Jun 2018

HAL is a multi-disciplinary open access

archive for the deposit and dissemination of

sci-entific research documents, whether they are

pub-lished or not. The documents may come from

teaching and research institutions in France or

abroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, est

destinée au dépôt et à la diffusion de documents

scientifiques de niveau recherche, publiés ou non,

émanant des établissements d’enseignement et de

recherche français ou étrangers, des laboratoires

publics ou privés.

Automatic optimisation of system architectures using

EAST-ADL

Martin Walker, Mark-Oliver Reiser, Sara Tucci-Piergiovanni, Yiannis

Papadopoulos, Henrik Lönn, Chokri Mraidha, David Parker, Dejiu Chen,

David Servat

To cite this version:

Martin Walker, Mark-Oliver Reiser, Sara Tucci-Piergiovanni, Yiannis Papadopoulos, Henrik Lönn,

et al.. Automatic optimisation of system architectures using EAST-ADL. Journal of Systems and

Software, Elsevier, 2013, 86, pp.2467 - 2487. �10.1016/j.jss.2013.04.001�. �cea-01810011�

(2)

TheJournalofSystemsandSoftware86 (2013) 2467–2487

ContentslistsavailableatScienceDirect

The

Journal

of

Systems

and

Software

j ourna l h o m e p a g e :w w w . e l s e v i e r . c o m / l o c a t e / j s s

Automatic

optimisation

of

system

architectures

using

EAST-ADL

Martin

Walker

a,∗

_,

_Mark-Oliver

_Reiser

b

_,

_Sara

_{Tucci-Piergiovanni}

c

_,

_Yiannis

_Papadopoulos

a

_,

Henrik

Lönn

d

_,

_Chokri

_Mraidha

c

_,

_David

_Parker

a

_,

_DeJiu

_Chen

e

_,

_David

_Servat

c

a_University_of_Hull,_Cottingham_Road,_Hull_HU6_7RX,_UK

b_Technische_Universität_Berlin,_{Ernst-Reuter-Platz}_7,_D-10587_Berlin,_Germany c_CEA_Saclay_Nano-INNOV,_Point_Courrier_No._174,₉₁₁₉₁_Gif_sur_Yvette_cedex,_France d_Volvo_Technology,_Dept_6260,_M2.7,₄₀₅₀₈_Gothenburg,_Sweden

e_KTH_Royal_Institute_of_Technology,_{Brinellvägen}_83,₁₀₀₄₄_Stockholm,_Sweden

a

r

t

i

c

l

e

i

n

f

o

Articlehistory: Received31July2012

Receivedinrevisedform28March2013 Accepted1April2013

Available online 8 April 2013

Keywords:

Multi-objectiveoptimisation Architecturaldescriptionlanguages DependabilityAnalysis

TimingAnalysis

a

b

s

t

r

a

c

t

There are many challenges which face designers of complex system architectures, particularly safety–criticalorreal-timesystems.TheintroductionofArchitectureDescriptionLanguages(ADLs)has helpedtomeetthesechallengesbyconsolidatinginformationaboutasystemandprovidinga plat-formformodellingandanalysiscapabilities.However,managingthiswealthofinformationcanstill beproblematic,andevaluationofpotentialdesigndecisionsisstilloftenperformedmanually. Auto-maticarchitecturaloptimisationcanbeusedtoassistthisdecisionprocess,enablingdesignerstorapidly exploremanydifferentoptionsandevaluatethemaccordingtospeciﬁccriteria.Inthispaper,wepresent amulti-objectiveoptimisationapproachbasedonEAST-ADL,anADLintheautomotivedomain,with thegoalofcombiningtheadvantagesofADLsandarchitecturaloptimisation.Theapproachisdesigned tobeextensibleandleveragesthecapabilitiesofEAST-ADLtoprovidesupportforevaluationaccording todifferentfactors,includingdependability,timing/performance,andcost.Thetechniqueisappliedto anillustrativeexamplesystemfeaturingbothhardwareandsoftwareperspectives,demonstratingthe potentialbeneﬁtsofthisconcepttothedesignofembeddedsystemarchitectures.

1. Introduction

Achievingqualityattributessuchas dependability(e.g. mea-sured in terms of reliability, availability, and safety) and performance(e.g.measuredintermsofthroughputofinformation andresponsetimes)incomplexsystemsisachallengingtask.Itis beneﬁcialtoconsidertheseattributesthroughoutthewholedesign process,factoringthemintoearlydecisionsandtherebyensuring thatqualityattributesarecontrolledfromtheearlystagesrather thanlefttoemerge(ornot)attheend,whenanyrequiredchanges wouldincurlargercostsanddelays.However,balancingthemany demandsonthesystemdesign canbedifﬁcult,andthetaskof

Abbreviations: ADL,ArchitectureDescriptionLanguage;COE,Central Opti-misationEngine;FAA,FunctionalAnalysisArchitecture;FDA,FunctionalDesign Architecture;HDA,HardwareDesignArchitecture;OSDM,OptimisationSpace Def-initionModule;VRM,VariabilityResolutionMechanism.

∗ Correspondingauthor.Tel.:+44(0)1482465994. E-mailaddresses:martin.walker@hull.ac.uk(M.Walker),

mark-oliver.reiser@tu-berlin.de(M.-O.Reiser),sara.tucci@cea.fr

(S.Tucci-Piergiovanni),y.i.papadopoulos@hull.ac.uk(Y.Papadopoulos),

henrik.lonn@volvo.com(H.Lönn),chokri.mraidha@cea.fr(C.Mraidha),

d.j.parker@hull.ac.uk(D.Parker),chen@md.kth.se(D.Chen),david.servat@cea.fr

(D.Servat).

exploringpotentiallyhugedesignspacesforoptimalconﬁgurations thatmaximisequality(i.e.,dependabilityandperformance)and minimisecostposesevenmorechallenges.

Recentworkonmodel-baseddevelopmenthaslookedintohow progressivelyreﬁnedmodelsofrequirementsanddesigncanbe usedtodrivethedevelopmentandveriﬁcationofcomplex sys-tems.ThisworkhasresultedinmethodslikeUMLandSysMLwhich enablesystemmodellingthatencompassesdescriptionof struc-ture,behaviourandallocationoffunctionstohardwareresources. More recently, ADLs such as AADL and the automotive EAST-ADLhaveemergedaspotentialfuturestandardsformodel-based design of embeddedsystems in thetransport andspace indus-tries.

Beyondmodellingofnominalbehaviour,theselanguagesalso incorporateerrormodellingsemanticsthatenabledependability analysis.Early workhasdemonstrated that dependability anal-ysisof EAST-ADL modelsis possibleviaHiP-HOPS (Chen etal., 2008)whiledependabilityanalysisofAADLerrormodelsis possi-bleviaconversiontofaulttrees(Joshietal.,2007)andGeneralised Stochastic Petri Nets (GSPN)(Feiler and Rugina, 2007). MARTE (www.omgmarte.org)isanothersigniﬁcantdevelopment, imple-mented asa UMLproﬁlefor thedesign ofreal-time embedded systems,enablingpredictionofotherqualityattributes,including performanceandschedulability.

(3)

NewADLsarelikelytoinﬂuencethedesignoffuturedependable systems. These languages can achieve transparency and con-sistency in a model-based process but are not yet sufﬁciently developedtoguarantee effectiveassessment andsatisfaction of qualityattributes.Wecanidentifytwochallengesthatneedtobe tackledfromtheearlystagesofdesign:

(a)Ensuring effective prediction of quality attributes such as dependabilityandperformance,viauseofadvanced,scalable, automatedmodel-basedanalysistechniques.

(b)Enablingeffectiveexplorationofpotentiallyhugedesignspaces fordesignsolutionsthatachievebetteroroptimaltrade-offs amongdependability,performanceandcost.Wenotethatthis capabilityisparticularlyrelevantwherelittlepriordesign expe-rienceexiststoguideengineersinthedesignofasystem,e.g.in caseofinnovativedesignsorwhenrelativelyimmature tech-nologiesareemployed.

1.1. Analysisofarchitecturalmodels

Over the last fifteen years, in order to tackle the first of thesechallenges,workonmodel-baseddependabilityanalysishas resultedinnewapproachesthatpartlyautomateandthereby sim-plifythesynthesisofdependabilityevaluationmodels.Inseveral techniques,predictivesystemfailuremodelssuchasfault trees andFMEAs(FailureModesandEffectsAnalysis)areconstructed fromthetopologyof thesystemandcomponentfailuremodels usingaprocessofcomposition.Inthisapproach,automationand reuse of component failure modelsacross applicationsbecome possibletosomeextent.Compositionalityandcareful reuseare expectedtobringbenefitsindependabilityanalysissimilartothose introducedbyreuseoftrustedsoftwarecomponentsinsoftware engineering.Techniques that follow this approach include HiP-HOPS(Papadopoulosetal.,2001),ComponentandState-EventFault Trees(Grunskeetal.,2005)andtheFailurePropagationand Trans-formationCalculus(Wallace,2005).Anotherbodyofresearchwith similarobjectiveshasdevelopedintheareaofformalverification, focusingonautomateddependabilityanalysisofsystems repre-sentedasstateautomata(e.g.seeworkonAltarica(Bieberetal., 2004)andFSAP-NuSMV(BozzanoandVillafiorita,2007)).Inthese approaches,model-checkingis usedtoverify thesatisfaction of dependabilityrequirementsordetectviolationsofrequirements innormalorfaultyconditions.

Toolshavebeendevelopedtosupportthesedependabilityand performanceevaluationtechniquesandcomplexcasestudieshave beenreportedthatdemonstratebenefits.However,relatively lit-tleworkhasbeenappliedinthecontextofmodel-baseddesign (especiallyincombinationwithADLs).IntheATESST2and MAE-NADEUprojects,ithasbeendemonstratedthatscalableautomated dependabilityanalysiscanbeachievedviaharmonisationof EAST-ADLwithHiP-HOPS.Thisworkhasshownbenefitsfromtheability toproducecomplexfaulttreesandmultiplefailureFMEAsfrom designsexpressedinanADL(Chenetal.,2008).However,there isstillscopeforimprovementinthisworkthatcouldextendthe state-of-the-artinmodel-baseddependabilityanalysis.In princi-ple,AADLmodels—effectivelystateautomatashowingtransitions fromnormaltodegradedandfailedstates—canbeconvertedto GSPNsand then analysed for dependability (Feilerand Rugina, 2007).However,inthisapproach,itisnotpossibletoperform qual-itativeanalysis,i.e., establishmentof directcausalrelationships betweencausesandeffectsoffailureasinFMEA,whichis impor-tantwhenprobabilisticdataarenotavailable,e.g.atearlystages ofdesign.Analternativeapproachhasbeendemonstratedin(Joshi etal.,2007)viaconversionofAADLerrormodelstofaulttrees.The maindifficultywehaveidentifiedhereisthatthetemporal seman-ticsoftheAADLerrormodel(aformofstatemachine)arelostinthe

translationtocombinatorialfaulttreesandthispotentiallycauses seriouserrors.Tocorrectthisconceptualﬂawandenabletrue tem-poraldependabilityanalysis,weproposetoenableanalysisofAADL errormodelsviaHiP-HOPS,wherearecentlyintegratedtemporal logiccalledPandoracanbeusedtoachieveautomatedsynthesis andanalysisofdynamicfaulttrees,makingitpossibletocapture theoftensigniﬁcanteffectsofsequencingoffaults.Theproblem hasbeendiscussedin(WalkerandPapadopoulos,2009)anda gen-eralsolutionwasproposed;however,thissolutionstillneedstobe adaptedinthecontextofparticularmodellinglanguages.

Anotherissue,oftenignoredinmoderndependabilityanalysis techniques,isthatofseparationofconcernsindesign.Most model-baseddependabilityanalysistechniquesassumethatthemodel ofthesystem(whetherintheformofablockdiagramorastate machine)isafunctionalmodel,effectivelyajointrepresentation ofhardwareandsoftware.However,thisignorestheseparation ofconcernsthattypicallytakesplaceinpracticalmodelling,where peopletendtodevelopseparatemodelsforhardwareandsoftware and linkthosemodelswithallocation relationships.Such mod-elsarenotdirectlyanalysablebythepresentstate-of-the-art.In HiP-HOPS,aconcepthasbeendevelopedthatenablesintegrated dependabilityanalysisofdesignsthatarerepresentedinmorethan oneperspective(e.g.hardware,software,middleware)via assess-mentofthefaultpropagationthroughallocationrelationships.

Inthecontextoftiminganalysis,manymodel-basedapproaches have been recently developed for the automotive domain. ProjectssuchasATESSTand ATESST2(www.atesst.org),TIMMO (www.timmo.org),andEDONA(www.edona.fr)havebeencarried outtoprovideconcepts,toolsandmethodologiesforthe descrip-tionofautomotivearchitecturesandtimingproperties.

Amongthewiderangeoftiminganalyses,schedulability anal-ysis (Selic, 2000) is considered a good candidate for analysing timingpropertiesatthedesignstage.Amodel-basedframework forschedulabilityanalysishasbeendevelopedalongtheselines in the context of the EDONA project. This framework enables model-basedschedulabilityanalysisattheEAST-ADLdesignlevel. TheEAST-ADLdesignlevelincludesfunctionalarchitecture, hard-warearchitecture,andanallocationmodelstipulatingthemapping offunctionstohardwarenodes.Theschedulabilityframeworkis basedonsupplementingEAST-ADLwithconceptsfromthe mod-ellinglanguageMARTEfollowingtheprocedurepresentedbyAnssi et al. (2010). In this framework, schedulability analysis is per-formedafteramanualtransformationofEAST-ADLmodelstowards areﬁnedarchitecture:theMARTEtaskmodel.Themanual trans-formationestablishesthemappingoffunctionsontasks(including task priorities and periods). Then the framework provides an automatictransformationofMARTEtaskmodelstoanacademic schedulinganalysistoolcalledMAST(http://mast.unican.es).

It should be noted that in the EDONA approach, schedula-bility analysis veriﬁes the task model, and does not directly verifythedesign-levelarchitecture.1_{Schedulability}_results

there-fore have to be manually ‘fed-back’ to the design level by interpretingschedulability propertiesobtainedfromtheMARTE taskmodel.Furthermore,extrapolatingfeedbacktoimprovethe design-levelarchitectureiscumbersome oreven impossiblefor non-schedulabilityexperts.Thereasonforthisliesinthefactthat schedulabilityresultsdependnotonly ondesign-level architec-turepropertiesbutalsoonthechoicesmadeduringthereﬁnement towards the task model (e.g. priority assignment, task periods, schedulingpolicy,etc.).

1_It_is_worth_noting_that_EAST-ADL_lacks_{implementation-like}_concepts,_such_as

thetaskconcept,althoughotherlanguages(e.g.AUTOSAR)canbeusedtoovercome thislaterinthesystemdevelopmentprocess.

(4)

M.Walkeretal./TheJournalofSystemsandSoftware86 (2013) 2467–2487 2469

The ATESST2 and MAENAD projects made improvementsto model-based timing analysis for EAST-ADL models in order to produceautomaticfeedbackontheEAST-ADLarchitecture. Sim-plefeedbackcanbeobtainedbyanalysingarchitectureproperties which do not need refinement towards a task model, such as resource utilisation, which can becomputed only knowingthe allocation of functions/signalsto hardware resources.For more advanced indicators,suchas responsetime analysisoffunction activationchainsthattraverseseveralsharedhardwareresources, full schedulability analysis is still needed, which necessitates refinementtowardsataskmodeltoconfigureschedulability analy-sistools.However,byapplyingcontrolledrefinements,itispossible to produce automatic feedback at design level. In this paper weadoptoneofthesepossiblecontrolledrefinements,whichis detailedinSection2.4.

1.2. Optimisationofarchitecturalmodels

Model-basedanalysisandverificationtechnologiescanenrich a model-driven development process by answering important questionsregardingthequalityofindividualdesignproposals.In complex distributed systems, however, rich functionalities and their distribution across shared hardware and communication channelsallowalargenumberofconfigurationoptionsatdesign timeandalargenumberofreconfigurationoptionsatruntime.This createsdifficultiesindesign because,aspotentialdesign spaces expand,theirexplorationforsuitableoroptimaldesignsbecomes increasingly difficult.When a number of differentarchitectural configurationscanpotentiallydeliverthefunctionsofa system, designersarefacedwithadifficultoptimisationproblem.Assuming thatitistechnicallyandeconomicallypossibletofulfilallquality requirements,theymustfindanarchitecturethatentailsminimal developmentandotherlifecyclecosts.Ontheotherhand,if fulfill-ingoroptimisingallqualityrequirementsisinfeasible,thenthey mustfindthearchitectureorarchitecturesthatachievethebest possibletradeoffsamongqualityattributesandcost.Theproblemis compoundedbythefactthatqualityattributesareoftenconflicting, e.g.improvingsafetyoftenmeansnotonlyincreasingcostsbutalso reducingavailability.Thevariousformulationsoftheabove repre-senthard,multi-objectiveoptimisationproblemsthatcanonlybe approachedsystematicallywiththeaidofoptimisationalgorithms thatcanefficientlysearchlargepotentialdesignspaces.

Whilstmanydesignproblemscanonlybetackledeffectively bythehumanintellect,itisclearthat,aspotentialdesignspaces expand,theirexplorationforsuitableoroptimaldesigns(e.g.in termsofqualityandcost)becomesincreasinglydifficult,andsome automationisneeded.Modelling languagesand emergingADLs couldthereforebenefitfromconceptsandtechnologicalsupport thatenablethistypeofoptimisation,whilestillbenefitingfrom thesupportformultipleanalysisandevaluationfunctionsthatan ADLoffers.

Someworkhasrecentlybeendoneinthisﬁeldfromthe direc-tionofsafetyand reliabilityanalysis,thoughnotinthecontext ofADLs.ClassicaldependabilitymodelslikeReliabilityBlock Dia-grams(RBDs)(Konaketal.,2006)and,morerecently,advanced compositionaldependabilityanalysistechniquessuchasHiP-HOPS havebeencombinedwithmeta-heuristics(Pareto-basedGenetic Algorithms)toassistintheautomaticevolutionofdesignmodels thatcanmeetdependabilityandcostrequirements.HiP-HOPShas contributedtothisareabyenablingtheoptimisationofsystems thathaveanetworkedarchitecture(i.e.theyarenotnecessarilyin parallel/seriesconﬁgurationsasinRBDs)andbyovercomingthe traditionalassumptionmadeinRBDsthatacomponentorsystem eitherworksorfailsinasinglefailuremode(Papadopoulosand Grante,2005;Papadopoulosetal.,2011;Adachietal.,2011).

Recentworkthathasfocusedonenablingmulti-objective opti-misation of software architectures has ledto the development ofnewtoolsthatalsoofferablendofanalysisandoptimisation capabilities.Onesuchtool isPerOpteryx,whichisbasedonthe Palladiomodellingenvironment(Martensetal.,2010;Koziolekand Reussner,2011).PerOpteryxallowsfortheautomaticoptimisation ofsoftwarearchitecturemodels,developedwithPalladiousingthe PalladioComponentModel(PCM),onthebasisoffourmain qual-itydimensions:cost,reliability,maintainability,andperformance. OneparticularadvantageofPerOpteryxisitsabilitytotake advan-tageofdomainspeciﬁcknowledge,suchasperformancetactics,to enhancetheoptimisation(Kozioleketal.,2011).

AnothertoolisAQOSA(AutomatedQuality-drivenOptimisation ofSoftwareArchitecture),whichusesmodeltransformation tech-nologytoconvertinputmodels(e.g.fromAADLorageneralUML2 model)intoanintermediateformat(AQOSA-IR)thatcanbeused asthebasisoftheoptimisationprocess(EtemaadiandChaudron, 2012).Differentcandidatesareprovidedbyarepositoryof possi-blecomponents,andasetofexternalobjectivefunctionplugins providestheevaluationthatdrivestheprocess.AQOSAisdesigned tobeindependentofanygivendomainspeciﬁclanguage(DSL)or ADL,butthereforereliesonacorrectmodeltransformationtoits ownintermediatemodeltoperformtheoptimisation.

Finally,otherworkbyGrunskeetal.hasshownthepotentialof usingvariousmeta-heuristicsfordependabilityversuscost optimi-sationofarchitecturaldesigns.ThisworkhasbeenappliedtoAADL modelsandalsolooksatotheroptimisationapproachesbeyond geneticalgorithms,e.g.anttrailalgorithms(Aletietal.,2009a,b; Meedeniyaetal.,2010,2011;MeedeniyaandGrunske,2010).An introduction tothemodel-based optimisationﬁeld canalso be foundinGrunskeetal.(2007),andawidersurveyofliteratureon architecturaloptimisationtechniquescanbefoundinAletietal. (2012).

Alloftheapproachesmentionedaboveexploitmeta-heuristics tosearchadesignspaceforoptimalsolutions.However,they oper-ateondifferentmodels(EAST-ADL,PCM,AQOSA-IRetc.)anduse differentmeansofdefiningthedesignspace(e.g.variability mech-anisms).Theyalsoaddressdifferentobjectives,whichtheydefine indifferentways,andusedifferenttechniquestoevaluatethose objectives.Theaimofthispaperistocontributetothestateof theartbydevelopinganapproachwhichbringsaunique combi-nationofobjectiveevaluationtechniques(e.g.HiP-HOPS,MAST) derivedfrominformationobtainedfromthevariability capabili-tiesandqualityattributesprovidedbyEAST-ADL.Therefore,while there are both commonalities and differences across the opti-misationapproachesmentionedabove,webelieveourapproach offersauniqueconfigurationthatcombinesthebenefitsof exter-nalanalysistoolsandtheall-in-onemodellingcapabilitiesoffered byEAST-ADL.

1.3. Contributionsofthepaper

Inthispaper,weshowhowearlierworkondesignoptimisation, e.g.workdevelopedinthecontextofHiP-HOPS,canbetransferred tomodel-baseddesign—speciﬁcallyinthecontextoftheEAST-ADL language.Thenovelcontributionsofthepaperare:

• Thedevelopmentofageneralmethodforautomatic optimisa-tionof EAST-ADL modelsvia geneticalgorithms.The method sofarenablesevaluationofunavailability,simplecostmetrics, andschedulability ofcandidatedesignstodrivethe optimisa-tion,butcouldbeextendedinthefuturetootherfunctionaland non-functionalattributesaswell.

• The use(inthe contextof optimisation)of advanced mecha-nisms which allowadequateparameterisation of modelsand

(5)

Fig.1. TheEAST-ADLabstractionlevels(http://www.east-adl.info/).

expressionofdesignvariabilityinthelanguagewherethemodel isexpressed(i.e.,EAST-ADL).

• Applicabilityoftheapproachonarchitecturalmodelswhichare represented in multiple perspectives, i.e., separate hardware andsoftwaredesigndiagramswhicharelinkedwithallocations ofsoftware tohardware. Thisis a non-trivialmatter asmost approachestodependabilityandoptimisationassumeasingle functionalmodelofthesystemasbasisforanyanalysis. • Theuseofannotationsofacorestructuralmodeltoformalise

timing,cost,energyconsumption,etc.forthepurposeof architec-tureevaluationasapartofoptimisation.Themodularapproach makesitpossibletoprovideannotationsconsistentwith vari-ants,andcorrespondingtotheinputneedsforﬁtnessfunctions oftheintendedoptimisation.Whilstnotalloftheseannotations arecurrentlyexploited,theoptimisationarchitecturedescribed inthepaperisextensibleandcouldtapfurtherintothewealth ofdesigninformationcapturedwithinanEAST-ADLmodel.

Inthenextsection,weshalldescribeEAST-ADL,itsmajor fea-tures,anditscapabilitiesforlinkingwithexternalanalysistoolsto performsafetyandtiminganalyses(amongstothers).InSection3, wedescribethemulti-objectiveoptimisationconceptandthetool architecturebeingdevelopedtofulﬁlthisconcept,andinSection4 weapplytheapproachtoasimpleexamplesystemtoillustrate manyof theadvancesmentioned above(multiple perspectives, variabilityrepresentation,timinganddependabilityinformation etc.).FinallywepresentourconclusionsinSection5.

2. RepresentingsystemarchitectureswithEAST-ADL

2.1. IntroductiontoEAST-ADL

EAST-ADL is an Architecture Description Language (ADL) initiallydeﬁnedintheEuropeanITEAEAST-EEAprojectand subse-quentlyreﬁnedandalignedwiththemorerecentAUTOSAR auto-motivestandard(www.autosar.org).Currently,itismaintainedand evolvedbytheEAST-ADLAssociation(www.east-adl.info).

EAST-ADLisanapproachfordeﬁningautomotiveelectronic sys-temsbywayofacomprehensiveinformationmodelthatcaptures engineeringinformationinastandardisedform.Aspectscovered includevehiclefeatures,functions,requirements,variability, soft-warecomponents,hardwarecomponentsandcommunication.

Asaguidingprinciple,EAST-ADLdeﬁnesmultipleabstraction levelsanddistributesalldevelopmentinformationacrossthese lev-els(seeFig.1).Thus,software-andelectronics-basedfunctionality ofthevehicleisdescribedatdifferentlevelsofabstraction dur-ingthedevelopmentfromearlyanalysistoimplementation.The proposedabstractionlevelsaretailoredtoprovideaseparationof

concernsandanimplicitstyleforusingthemodellingelements. Theembeddedsystemiscompleteoneachabstractionlevel,and partsofthemodelarelinkedwithvarioustraceabilityrelations. Thismakesitpossibletotraceanentityfromfeatureleveldownto componentsinhardwareandsoftware.

The features in themain technical feature model atvehicle levelrepresentthemajorfunctionalitiesandcharacteristicsofthe completesystem,i.e.,theentirevehiclefromatop-level perspec-tive, without exposing any realisation details. It is possible to managethecontentofeach individualvehicleandentire prod-uctlinesinasystematicmanner.Inadditiontothismainfeature modelwithitstechnicalperspective,otherfeaturemodelsmay bedeﬁnedthatprovideviewsonthemainfeaturemodel,e.g.a customer/marketing-orientedviewdeﬁningmodelsandpackages ofoptionalequipment.

Acompleterepresentationoftheelectronicfunctionalityinan abstractformismodelledintheFunctionalAnalysisArchitecture (FAA).Thepurposeistodeﬁneandstructurethesystem’s function-alityfromaproblemdomainperspective,similartoatraditional functional analysis.Entities ofthe FAA,so-called analysis func-tions,capturetheprincipalinterfacesandbehaviourofthevehicle’s subsystems.

Thesolutiondomainaspectsareintroducedwhiledefiningthe design level, which comprises the Functional Design Architec-ture(FDA)andtheHardwareDesignArchitecture(HDA).TheFDA definesafunctionarchitecturethattakesintoaccounthardware allocation,efficiency,legacyandreuse,commercial-off-the-shelf (COTS)availability,andotherarchitecturalqualities.Thefunction structureissuchthatoneormorefunctionscanbesubsequently realisedbyoneorseveralAUTOSARsoftwarecomponents (SW-C).Theexternalinterfacesofsuchcomponentscorrespondtothe interfacesoftherealisedfunctions.Ontheotherhand,theHDA definestheexecutionenvironmentinwhichthesoftwarewillbe deployed.Itsmainentitiesaresensors,actuators,unitsof execu-tion,theirinterfaces,andcommunicationlinksbetweenallthese. Finally,theallocationjoinstheFDAandHDAbydefiningforeach softwareentityintheFDAonwhichunitofexecution,asdefined intheHDA,itwillreside.

On the lowest, most concrete abstraction level, the imple-mentationlevel, EAST-ADLdoesnot provideits ownmodelling entities;instead,thislevelisentirelydeﬁnedbymodelsfromthe AUTOSARstandard.In thisrespect,EAST-ADLcanbethoughtof asanextensiontoAUTOSARprovidingsupportformodellingon higherabstractionlevelsduringearlierdevelopmentphases. How-ever,traceabilityissupportedfromimplementationlevelelements (AUTOSAR)toFDA/HDAelementsand,fromthere,furtherupto vehiclelevelelements.

Verifyingandvalidatingafeatureacrossallabstractionlevels, byusing simulation or formaltechniques,requires an environ-mentmodelfromtheearlystagesofthedesignprocess.This“plant model”capturesthebehaviourofthevehicledynamics,driver,etc. Thecorepartoftheenvironmentmodelcanbethesameforall abstractionlevels,whichmeansthat,forthepurposeof simula-tion,bothFAAandFDA/HDAareattachedtothesameenvironment model.

2.2. VariabilitymodellinginEAST-ADL

EAST-ADLprovidesextensivesupportfor managing variabil-ity,whichisakeyelementoftheEAST-ADL-basedoptimisation approachpresented inthis article.First,variability modellingis used to deﬁne the optimisation space (also referred to as the “architecturaldegreesoffreedom”inAletietal.(2012))andthen conﬁgurationandvariabilityresolutionareappliedtoproducethe individualoptimisationcandidatestobeevaluatedwithrespect totheoptimisationobjectives.Beforegoingintomoredetail on

(6)

Fig.2.FeaturemodelsondifferentEAST-ADLlevelsandtheconﬁgurationlinksconnectingthem.

theoptimisationapproachinSection3,wethereforedescribethe EAST-ADLvariabilitymanagementconceptshere.

ModellingofvariabilityinEAST-ADLstartsonthevehiclelevel, wheremodelrangefeaturesandvariabilityarerepresented.Atthis point,thepurposeofvariabilitymanagementistoprovideahighly abstractoverviewofthevariabilityinthecompletesystemtogether withdependenciesbetweenthese“variabilities”.A variabilityin thissenseisacertainaspectofthecompletesystemthatchanges fromonevariantofthecompletesystemtoanother.Inthisabstract overview,theideaisnottospecifyhowthesystemvarieswith respecttoanindividualvariabilitybutonlythatthesystemshows suchvariability.Forexample,thefrontwipermayormaynothave anautomaticmode.Atvehiclelevel,theimpactofthisvariabilityon thedesignisnotdefined;onlythefactthatsuchvariabilityexistsis definedbyintroducinganoptionalfeaturenamed “RainControlled-Wiping”.Thisissubsequentlyvalidatedandrefinedduringanalysis anddesign.

Oneormorefeaturemodelsmaybedefinedonthevehiclelevel: thecoreTechnicalFeatureModel—themainfeaturemodelinan EAST-ADLsystemmodel—isusedtodefinethecompletesystem’s variabilityonagloballevelfromatechnicalperspective,andoneor moreoptionalProductFeatureModelscanbeusedtodefineviews onthistechnicalvariabilitywhichcanbetailoredtoaparticular view-pointorpurpose,e.g.themarketing-orientedendcustomer perspective.AnexampleofthisisshownatthetopofFig.2.

Whilethedetailsofhowvariabilityisactuallyrealisedinthe sys-temarelargelysuppressedatthevehiclelevel,theyarethefocusof attentionwhenmanagingvariabilityintheFAA,FDAandHDA.In fact,aspecificvariabilitymayleadtomodificationsinany develop-mentartefact,suchasrequirementsspecificationsandfunctional models.Here,describingthataspecificvariabilityoccursisnot suf-ficient;itisnecessarytodescribehoweachvariationaffectsand modifiesthecorrespondingartefact.

Thepurposeoffeaturemodellingistodeﬁnethe commonali-tiesandvariabilitiesoftheproductvariantswithinthescopeofa productline.Featuremodelsarenormallyusedonahighlevelof abstraction,asdescribedaboveforvehiclelevelvariability. How-ever,inEAST-ADL,theyarealsousedonanalysisanddesignlevels andacquireamuch moreconcrete meaningthere:theycanbe

attachedtoanalysisand design functionsandare thenused to exposethevariabilitywithinthisfunctiononly.Fig.2illustrates thisfortheFAA:thetop-levelanalysisfunction“Car”containsa subfunction“WiperSystem”whichinturnconsistsofthe subfunc-tion“RainSensor”and“WiperController”;alltheanalysisfunctions “Car”,“WiperSystem”and“WiperController”haveafeaturemodel attached.

Inadditiontotheirfeaturemodel,analysisanddesignfunctions maycontainvariationpointsdefining howthefunction’s struc-turevariesfromonesystemconfigurationtoanother.InEAST-ADL, suchstructuralvariationcanberepresentedbymarkingstructural entities—e.g.subfunctions,ports,connectors—asoptional,whichis denotedgraphicallybyadashedline.Fig.2presentsanexample: the“WiperSystem”hasanoptionalsubfunction“rs”oftype “Rain-Sensor”.Allactualsystemvariationonanalysisanddesignlevelis definedusingthisstraightforwardconceptofoptionalstructural entities.

Conﬁguration decision modelling is another key variability management concept in EAST-ADL: the conﬁguration of a tar-get featuremodel FMT—i.e. theselection and deselection ofits

features—isdefinedintermsoftheconfigurationofanotherfeature modelFMS,calledsourcefeaturemodel.Aconfigurationdecision

modelcanthusbeseenasadirectedrelationfromFMS toFMT

thatallowsustoderiveaconﬁgurationofFMTfromanygiven

con-ﬁgurationofFMS.InEAST-ADL,thismechanismisusedtodeﬁne

howacertainconfigurationonahigherlevelaffectsthebinding ofvariabilityonlowerabstractionlevelsandinlower-level com-ponents.Again,Fig.2providesanexample:configurationlinksare depictedasdashedarrowsandaredefinedbetweenallthefeature models;theonefromthe“TechnicalFeatureModel”tothe fea-turemodelattachedto“Car”,forinstance,defineshowtoconfigure the“Car”analysisfunctiondependingonagivenconfigurationof thecoretechnicalfeaturemodelonvehiclelevel;notehowthis configurationlinkcrossesabstractionlayerswhilethelinksfrom the“Car”tothe“WiperSystem”featuremodelcrossescontainment hierarchieswithintheanalysisarchitecture(thesameappliesto theFDAandHDA,butthiswasomittedfromthefigure).Similarly, configurationlinksareusedtodefinehowthestructural variabil-itywithinanalysisanddesignfunctionsisresolveddependingon

(7)

agivenconfigurationofthefunction’sfeaturemodel.For exam-ple,theconfigurationlinkinthe“WiperSystem”functionofFig.2 stateshowtheoptionalsubfunction“rs”willbeselectedor dese-lecteddependingontheconfigurationofthewipersystem’sfeature model.

Variabilitymanagementonanalysisanddesignlevelisdriven bythevariabilityidentifiedonthevehiclelevel.Thismeansthatthe maindriverforvariabilitydefinitionandalsovariability instantia-tionisthevehicle-levelfeaturemodel.Variabilityspecificationin FAAandFDA/HDAessentiallyconsistsofthedefinitionof varia-tionpointswithintheanalysisanddesignfunctions(intheformof optionalsubfunctions,connectorsandports).Asmentionedabove, featuremodelscanbeattachedtofunctionsin ordertoexpose thevariabilitywithinthesefunctionsandhidetheactual structur-ing,representationandbindingofthisfunction-internalvariability. Thisway, thebenefits of information hiding canbe appliedto thevariability representationand variabilitybindingwithinthe containmenthierarchyoffunctionsin theFAAand FDA/HDAof EAST-ADL.

Insummary,EAST-ADLprovidesthemeanstodefine variant-richsystemsandtoorganisethisinformationsuchthatanentire, fullyresolvedsystemconfigurationcanbederivedautomatically fromtheconfigurationofasinglefeaturemodelonvehiclelevel. Forthepurposeofthisarticle,thismeansthatwecandefinethe optimisationspace,i.e.thesetofsystemstobeevaluated,byway ofEAST-ADL’s variabilitymodelling conceptsand then produce individualcandidateswithinthisoptimisationspacebyapplying EAST-ADL’sconfigurationandvariabilityresolutionmechanisms. 2.3. DependabilityanalysisofEAST-ADLmodelswithHiP-HOPS

EAST-ADLofferspowerfulfaultmodellingcapabilitiescentred onitsErrorModelconcepts.TheErrorModelinEAST-ADLisa sepa-ratemodellingview,paralleltothenominalsystemmodelsoneach level,andallowssystemdesignerstospecifyhowthesystem ele-mentscangeneratefailuresandhowthosefailurescanpropagate tootherpartsofthesystem.

AswithotherpartsofEAST-ADL,theErrorModelonlystores information;analysiscapabilitieshavetobeprovidedbyan exter-naltool.AspartoftheATESST2andMAENADprojects,signiﬁcant effort has gone into enabling the HiP-HOPS (Hierarchically-PerformedHazardOriginandPropagationstudies)safetyanalysis tool toanalyse EAST-ADL modelsby meansof model transfor-mationtechnology.Thishasentailedsomeharmonisationofthe errormodellingconceptsinbothEAST-ADLandHiP-HOPSandthe resultisapowerfuldependabilityanalysiscapabilityforEAST-ADL models.

AHiP-HOPSanalysishasthreemainstages: • Faultmodellingandfailureannotation

• Synthesis of fault trees to model the propagation of failure throughthesystem

• FaultTreeAnalysis(FTA) andsynthesis of Failure Modes and EffectsAnalysis(FMEA)tables

Theﬁrstphaseismanuallyperformedandconsistsof annotat-ingtheelementsofthesystemmodel(orinthiscase,theEAST-ADL errormodel)withlogicalexpressionsthatdescribetheirlocal fail-urebehaviour,i.e.,whatoutputfailurestheypropagate(knownas outputdeviations)andhowthoseoutputfailuresarecausedbya mixtureofinputfaultsandinternalfailuremodes.Intheirbasic form,theseexpressionstaketheformofafailureclass(e.g. commis-sion,omission)andthenameoftheportandcomponentwherethe deviationoccursandcombinesthemwithlogicaloperatorssuchas ANDandOR.Forexample:

Omission-Actuator.out = Omission-Actuator.in OR ActuatorStuck

indicatesthatanomissionofthe‘out’portofanactuator compo-nentiscausedbyeitherasimilaromissionreceivedatthe‘in’port oftheActuatororaninternalfailuremodecalled“ActuatorStuck”, which mayalsohaveprobabilistic failuredata(e.g.failure rate, repairrate,MTTFetc.)deﬁned.Such expressionscantakemore complexformstoexpressgeneralisedpatternsofcomponent fail-urebehaviour.

Thesecondandthirdphasesareconductedautomaticallyby HiP-HOPS.First,anetworkofinterconnectedfaulttreesis synthe-sisedbycombiningthelogicalexpressions,therebyshowingthe relationshipbetweensystemhazardsandcombinationsof individ-ualcomponentorfunctionfailures.Inthethirdphase,thefaulttrees areanalysedusingFTAreductionalgorithmstoobtaintheminimal causesofsystemfailurestogetherwithestimatesforthe probabil-itiesofthosefailures.ThisinformationisusedtoconstructFMEA tableswhichshownotonlytheeffectsofeachindividualfailure mode,butalsotheeffectsofmultiplefailuremodesoccurringin conjunction.

2.3.1. Multi-perspectiveanalysisinHiP-HOPS

One of the biggest differences between theHiP-HOPS error modelandtheEAST-ADLapproachisthatEAST-ADLdoesnotlimit thesystemmodellertoasinglearchitecture,asHiP-HOPSdoes.Not onlyaretheErrorModelandnominalmodelseparate,but EAST-ADLprovidesmultiplelayersorlevelsofpotentialmodellingas wellasdifferentviewsorperspectivesofamodel.HiP-HOPScanbe appliedtoEAST-ADLmodelsatboththeanalysisanddesignlevels, eachofwhichmaycontainanumberofdifferentperspectives.For example,attheanalysislevel,theprimarymodellingperspective istheFunctionalAnalysisArchitecture(FAA),whichprovidesan abstractviewofthefunctionsofthesystemandwhichwillhavea similarlyabstractErrorModelattached.Later,atthedesignlevel, themodelmaybeseparatedintotheFunctionalDesign Architec-ture(FDA),whichrepresentstheconcretefunctionalperspective, and theHardware Design Architecture (HDA), representingthe hardwareperspective,andeachofthesemayhaveaseparate—but interrelated—ErrorModel.

In HiP-HOPS, software and hardware are usually modelled togetheraspartofthesamearchitecture,withsoftwarefunctions beingdeﬁnedassubcomponentsofhardwareelements.Thiscan beemulatedinEAST-ADLbycombiningeverythingintoasingle perspective,buttheadvantages ofhavingmultipleperspectives arethenlost.Instead,inordertomakeitcompatiblewith EAST-ADLandtoallowforthepropagationoffailuresfromsoftwareto hardwareorviceversa,HiP-HOPShasbeenextendedwithnative multi-perspectivecapabilities,asshowninFig.3.

InEAST-ADL,hardwareandsoftwareentitiescanbein sepa-ratearchitectures(e.g.HDAandFDA)andtherelationfromone perspectivetotheotheris accomplishedbymeansofallocation relationships,inwhichsoftwarefunctionsareallocatedtothe hard-warecomponents that execute them. Failuresof the hardware componentswillpropagatetothesoftwarefunctionsallocatedto them.HiP-HOPSnowprovidesthesamecapabilities,andin addi-tiontoanoutputdeviationbeingcausedbyaninputdeviationor aninternalfailuremode,itmaynowalsobecausedbyafailure propagatedfromthecomponentthecurrentfunctionisallocated to.Forexample:

Omission-Function.out = Omission-Function.in OR FromAllocation

(8)

Fig.3. Multi-perspectivemodellinginHiP-HOPS.

Thisspeciﬁesthattheomissionofoutputfromasoftware func-tioniscausedeitherbyalackofinputoraparticularfailure(power failureinthiscase)beingpropagatedfromthehardware compo-nentthatthefunctionisallocatedto.

Furthermore,inbothEAST-ADLandnowinHiP-HOPS,itis possi-bletodeﬁnemorethanonepossibleallocation,e.g.usingvariability constructsinEAST-ADL.Thisallowsscopeforpotential optimisa-tionofthemodelonthebasisofchangingtheallocationofsoftware functionstodifferenthardwarecomponents.

The introduction of multiple perspectives to HiP-HOPS has necessitatedachangetothesemanticsofcommoncausefailures, which HiP-HOPS previously treated asglobal failures. Whereas before common cause failures (CCFs) were globally accessible throughoutthemodel,andcouldcauseafailureofany compo-nent,nowCCFsaredefinedpermodellingperspective,andthusa CCFdefinedforthehardwareperspective(e.g.flooding,fire)would notbeaccessiblefromafunctioninthesoftwareperspective,for instance.

Foranyrarecaseswherearbitrarycross-perspective propaga-tionisrequired,HiP-HOPSprovidesa‘Goto’declaration.Thisallows failurestopropagatefromonecomponentinoneperspectiveto anothercomponentinadifferentperspective(or,forthatmatter, inthesameperspective),evenifthosecomponentsdonotsharean allocationrelationship.

Becausethesenewconnections(allocationsandgotos)connect toexisting HiP-HOPSconstructs(namely,outputdeviationsand thenormallocalfailurelogic),theyﬁtrelativelyseamlesslyinto theHiP-HOPSfaulttreesynthesisprocess.Oncethefaulttreesare generated,theycanbeanalysed asnormal withoutanyfurther distinctionbetweenoneperspectiveandanother.

ThisharmonisationofEAST-ADLandHiP-HOPSerrormodelling conceptsprovidesapowerfuldependabilityanalysiscapabilityfor EAST-ADLmodels,allowingfaultpropagationtobetracedacross severaldifferentmodellingviews.Thisalsoenablesoptimisation ofEAST-ADLmodelsusingdependabilitycharacteristics(e.g.safety, unavailability)asobjectives,asshowninSection4.

2.4. TiminganalysisofEAST-ADLmodels

EAST-ADL, and speciﬁcally its Timing Extension, provides a rich setofconceptsto supporttiminganalysis.The term “tim-ing analysis”, however, encompassesa wide range of analyses applicable to different models (and levels of abstraction) pro-ducedduringthedevelopmentprocess.High-levelanalyses,such

asusingmodel-checkingfortheverificationofthetiming prop-ertiesofthefunctionalmodel,canusuallybeemployedfromthe verybeginningofthedevelopmentprocess,assoonasfunctional behavioursaredefined.Conversely,low-levelanalyses,suchastask levelschedulabilityanalysis,computetimingpropertiesof func-tionswhenconceptuallyexecutedondetailedsoftware/hardware resourcemodels.Theseresourcemodelsincludeinformationabout processor/busschedulersandtask/messageconfigurationsandare ingeneralproducedatlaterstagesofthedevelopmentprocess.

Inthispaperweareprimarilyinterestedinthedesignlevelof EAST-ADL,wheretheallocationoffunctionsonhardwarenodes isdeﬁnedandtiminganalysiscanbeappliedinconjunctionwith dependabilityanalysis.Speciﬁcally,thedesign-levelconceptsused bytheanalysisare:

(1)activationchainsoffunctions,therateoftheiractivation,worst caseexecutiontimesoffunctionsandend-to-enddeadlines; (2)thetopologyofthehardwarenetworkintermsofprocessors

andthebusesthatconnectprocessors; (3)theallocationoffunctionsonprocessors.

These concepts come from EAST-ADL’s FunctionModelling, HardwareModellingandTimingaspects,andarespeciﬁedinthe FDA,theHDA,andtheassociatedTimingViewrespectively.

Timinganalysisatthisstageaimstoevaluatetheimpactthat hardware resources may have on the execution of functions, althoughitmakesuseofmoreabstractresourcesthanthoseused byschedulabilityanalysis(notasks,schedulers,etc.).Togivea sim-pleexampleontheimportanceofevaluatingtheresourceimpact onfunctionexecution,letusconsiderthearchitecturein Fig.3. Inthisexample,FunctionsF1AandF1Bdonothaveprecedence dependencies,sotheycanbelogicallyexecutedinparallel.Asa comparison,assumethatthetwo functionsareallocatedonthe sameCPU,meaningthatF1AandF1Bareexecutedsequentially. NowletusconsiderthatFunctionF2mustproduceavalueforeach cycleofdurationT(deadline).IneachcycleF2mustconsumeat leastonevalueproducedbyF1AandoneproducedbyF1Binthe samecycle.Itisclearthatifthetwofunctionscouldbeexecuted inparallelandstartatthebeginningofthecycle,inputvaluesfor F2willbeavailableaftermax(C1,C2),whereC1andC2are esti-matedworstcaseexecutiontimes.Ontheotherhand,incaseof sequentialexecution,theinputvaluesforF2willbeavailableonly aftersum(C1,C2).Thesesituationsmustbecarefullyanalysedas

(9)

Fig.4. MARTEtaskmodel.

theeffectofaccessinghardwareresourcesmayleadtoresponse timesviolatingdeadlines.

Tothisend weproposeanapproachthatprovidesa connec-tiontotheMAST analysistooland givesautomaticfeedbackto theEAST-ADLmodel.AsstatedinSection1.1,weneedtosolve themismatchbetweentheschedulabilityanalysislevel(wherethe MASTtoolworks)andtheEAST-ADLdesignlevel.Tothisend,we devisedacontrolledreﬁnementtowardsataskmodelthatensures theMASTresultsprovidevaluableinsightintotheEAST-ADLlevel. Itshouldbenotedthatthisreﬁnementmaybeembeddedinamodel transformationthatistransparenttotheuser.

Thecontrolledrefinementperformsa1:1mappingofEAST-ADL functionstoMARTEtasks.Ataskmustbeconfiguredintermsof periodsandpriorities;thecontrolledrefinementassignstoatask theperiodofthefunctionitismappedto,and allprioritiesare fixedtothesamevalue.Theeffectofassigningthesamelevelof prioritiesforallthetasks(functions)allowsforthecomputingofthe upperboundonworstcaseresponsetimes,i.e.,anyotherpriority assignmentwillimproveresponsetimes.Thiseffectisexplained bythewayinwhichresponsetimesarecomputedbyMASTwhen prioritiesareatthesamelevel.

Toclarifythispoint,considertheexampleinFig.3again. Apply-ingourcontrolledreﬁnement tothis modelmeansobtaining a MARTEmodelasshowninFig.4.Eachfunctionishererepresented byataskexecutingthefunctionitselfattherateof20ms,expressed byanexternaltrigger.PrioritiesandallocationstoCPUsarealso shown.Thedeadlineof20msfortheentirecycleisalsospeciﬁed.

OncetheEAST-ADLmodelistransformedintoaMARTEmodel, MASTcanbeappliedtocomputetheresponsetime.Theresponse timeisobtainedbyconsideringworstcase executiontimesand theadditionaldelaycausedbysequencingF1AandF1BonCPU1 (forsakeofsimplicitywedonotconsidercommunicationdelaysin theexample).Inﬁxed-priorityschemes,theadditionaldelaydueto sequencingexecutionsiscalledpre-emptiontime.Rememberthat underordinarycircumstances,thehighestprioritytaskwillaccess theCPUﬁrstandlowerprioritytaskswillaccessafterhigher prior-itytasksterminatetheirexecution.Thetimespentbyataskwaiting forhigherprioritytaskstoexecuteisthepre-emptiontime.The globalpre-emptiontimeisthesumofallpre-emptiontimesforall tasks.Obviously,toimproveresponsetime,theglobalpre-emption timeshouldbeminimised.2_But_what_happens_if_priorities_are_set

tothesamelevel,asinourcase?MASTinthiscaseconsidersthat eachtaskispre-emptedbyallothertasks.IncaseofFig.4theglobal pre-emptiontimeonCPU1willbesum(C1,C2).Anyother assign-mentconsideringdifferentlevelsofprioritywillgivealowervalue fortheglobalpre-emptiontimeonCPU1(C1orC2).

2 _It_should_be_noted_that_the_worst_case,_in_which_all_the_tasks_are_activated_at

thesametime,isassumedbytheanalysis,sothatthepre-emptiontimeisalways includedintheresponsetime.

Theglobalpre-emptiontimecouldbedecreasedbyreducing thenumberoftasks.Intheexample,analternativemappingwith thetwofunctionsonasingletaskwouldmeanreducingthe pre-emptiontimeonCPU1to0,asonlyonetaskrunsinCPU1.Indeed, the1:1mappingisanothersourceofpessimismthatgivesusthe worstresponsetime,independentofimprovementsthatcanbe achievedlaterbyapplyingsmarterreﬁnementstowardsalternative taskmodels.

Onceithasbeenestablishedthattheresponsetimecanonly beimprovedbysubsequentreﬁnements,itcanbecorrectly inter-pretedinEAST-ADLasasufﬁcientcondition.Aresponsetimethat meetsdeadlinesatthetasklevelimpliesthattheEAST-ADL archi-tecturecanbeconsideredvalid.Ontheotherhand,anegativeresult doesnotnecessarilyimplyadesignerrorforschedulability. Expe-riencesuggeststhatthisdoesnotpresentaproblemifthedesigner isawareofthischaracteristic.Furthermore,acomplementaryand lessconservativeanalysiscouldbemadewhereaperfectpriority assignmentisassumed.Thiswouldservetoassessfeasibilityofthe architecture.

TheresponsetimecomputedwithMASTundertheproposed controlledreﬁnementallowsustocomparedifferentarchitectures fromatimingpointofview,enablingarchitectureoptimisationas describedinSection4.

3. OptimisationofEAST-ADLarchitectures

Model-basedsystemsanalysistechniquesallowagreatdealof informationtobeobtainedaboutasystem,includingits depend-abilityandtimingcharacteristics,amongstothers.Thisisespecially truewhentheseanalysistechniquesarecombinedwithADLslike EAST-ADL,whichservetocentralisealltheknowledgeabouta par-ticularsystem,sinceitisnolongernecessarytoproduceaspeciﬁc errormodeltailoredforaparticulardependabilityanalysistool,or aseparatetimingmodelsolelyfortiminganalysisetc.

However,asmentionedearlier,thiswealthofinformationcan alsobedifﬁculttomanage.Achievingabalancebetweenthe dif-ferentattributerequirementsduringthedevelopmentofcomplex systemsbecomesproblematic,bothbecausethereisavast num-berofpossibledesignalterationsthatcouldbemadeandbecause theinterrelationshipsbetweentheattributes—andthereforethe effectsofanyalterations—arenotnecessarilyclear.Thisis particu-larlytruewhentradeoffsbetweenmultipleconﬂictingattributes (like safety versus cost, or energy consumption versus perfor-mance)areinvolved, as improvingoneattribute maylead toa worseningofanother.

The increasing automation of analysis techniques helps overcomethistoanextent,assumingtheautomatedtoolsare com-patiblewiththemodelinquestion.Suchtoolsallowmodelstobe rapidlyevaluatedaccordingtodifferentcriteria,enablingdesigners toquicklyseetheeffectsofanychangestothedesign architec-tureandinformingdesigndecisionsaspartofaniterativeprocess.

(10)

Evenwiththisautomation,evolvingthedesignmanuallyisstilla complexandtime-consumingprocess,relyingonmanual experi-mentationwithdifferentdesignoptions,andmaystillbedifficult tofulfilthecompetingrequirementsonthesystem—particularly asthetimeandeffortinvolvedmeansthattypicallyonlyasmall numberofpotentialdesignoptionscanbeinvestigatedinthisway. In suchsituations, automatic architectural optimisation can potentiallybeapplied.Automaticoptimisationallowsamuchmore efficientsearchofthedesignspace(thetotalsetofpossibledesign variations),coveringamuchgreaternumberofalternativesthan couldbeconsideredmanually.However,tobeeffective,the opti-misationmustbeguidedinsomeway,whichrequiressomeformof heuristicevaluation.ItisherethattheuseofADLssuchasEAST-ADL forrepresentingthedesignmodelpaysdividends,becausesucha modelcontainsalloftheinformationnecessaryforanalysistotake placewithrespecttoeachsystemattributebeingconsidered.For example,iftheobjectivesoftheoptimisationweretomaximise safetyandperformancewhileminimisingcostandunavailability, ithastobepossibletoevaluateeachofthecandidatedesignsbeing exploredaccordingtothosefourcharacteristicsbymeansofsome formofanalysis.Bymakingchangestothedesignmodel automat-icallyaspartoftheoptimisationprocessandallowingtheanalysis toolstoaccessthesamecommonmodel,itthenbecomespossible toevaluatethenewvariantdirectlyandseamlessly,facilitatinga rapid,efficientsearchofthedesignspace.

3.1. Multi-objectiveoptimisation

Taken together,the problemof optimising a largepotential designspace toobtainoneor moregoodsolutions thatfeature a desirable balance of attributes is known as a multi-objective optimisationproblem.Thereareavarietyofdifferentautomated algorithmsthatcanbeemployedtosolvesuchproblems,butin generalthey all aimto quickly ﬁndviable solutions (i.e.,valid design variants inthis case) that offeroptimalor near-optimal attributeswithoutneedingtoinvestigateallpossibledesigns.It shouldbenotedthatinamulti-objectiveoptimisationproblem, thereisnottypicallyasingleoptimumsolution,becausethe dif-ferentobjectivesmaybemutuallyexclusive;instead,thegoalis oftentoproduceasetof‘optimal’solutionsthatfeaturearangeof attributesthatbalancethedifferentobjectivesindifferentways—in otherwords,eachprovidingadifferenttradeoffbetweenthe objec-tiveswhilststillmeetinganyconstraints.

TheseareknownastheParetosolutionsandarebasedonthe conceptofdominance.Adominantsolutionisonethatis better inatleastoneobjectivethaneveryothersolutionyetfound,and noworseintheotherobjectives.Thesetofdominantsolutionsis knownastheParetoset.Whenplottedonthegraph,theytendto formacurveknownastheParetofrontier,whichshowsthe cur-rentprogressoftheoptimisation;newsolutionsbeyondthePareto frontierarenewoptimalsolutionsandwilldominateolder solu-tions, whereassolutions withinthefrontier aredominated and non-optimal.Thisis shown inFig. 5,where theParetofrontier consistsofthesolutionsmarkedasblackdots,whilstdominated solutionsarewhitedots.

InFig.5,solutionsareshownasdotsplottedagainsttwoaxes, eachrepresentingdifferentobjectiveattributes(e.g. unavailabil-ityandcost).Inthiscase,thegoalistominimiseeachattribute, solower values are better.Thus A dominates Bbecause it has lowervaluesforeachattribute;itisbetterinbothrespects.Aalso dominatesC,becausealthoughtheyhavethesamevalueforone objective(e.g.unavailability),Ahasalowervaluefortheother(e.g. itischeaper).ConverselyDisanon-dominatedsolutionbecauseit isbetterthanAinoneobjectivebutworseinanother;forexample, Dmaybecheapbutnotveryreliable,whereasAismorereliable butalsomoreexpensive—bothareequallyvalidsolutions.

Fig.5.Paretofrontier.

Althoughthere are manydifferentmulti-objective optimisa-tionalgorithms,e.g.tabusearch(Kulturel-Konaketal.,2003),ant colonies(LiangandSmith,2004), andsimulatedannealing(Kim etal.,2004),oneofthemostprominentapproachesistheuseof geneticalgorithms.Thegeneralprincipleswillbebrieﬂydiscussed next.

3.1.1. Geneticalgorithms(GAs)

Geneticalgorithmsareoptimisationalgorithmsinspiredbythe evolutionaryprocessesfoundinnature.Theyhavebeenidentiﬁed asaparticularlyeffectivemethodforsolvingcombinatorial optimi-sationproblems(suchasthosediscussedhere)andtheyarecapable ofnavigatinglarge,complexsearchspaces(CoitandSmith,1996a).

Thegeneralprocessisasfollows:

• Apopulation(set)ofindividualcandidatesolutionsisrandomly generated.Eachindividualisrepresentedbyadifferentencoding, analogoustohumangenes,whichencapsulatesthewaytheycan varyfromeachother.Theencodingcanbethoughtofasthe‘DNA’ ofeachindividual.

• Geneticoperators—crossoverandmutation—areappliedtothe populationtoobtainanewgenerationofchildsolutions,which are added tothe population(or, in somegeneticalgorithms, becomethesolenewpopulation).Crossoverinvolvesmixingthe genesoftworandomparentcandidatestoproduceachild; muta-tion involvesrandomlychanging thegenes of a candidate to produceanewsolution(oralteranexistingcandidate).

• This process of reproduction continues until the population growstoolarge,atwhichpointthosewiththeleastsuccessful genomesarediscarded.Thisisestablishedbyevaluatingthe solu-tionsinthepopulationaccordingtotheobjectivecriteria(the evaluationfunctionsareknownasﬁtnessfunctions)and retain-ingthosewiththebestresults—inotherwords,survivalofthe ﬁttest.

• Afterasetnumberofgenerations,theoptimisationceases,and thecurrentpopulationshouldcontainthebest(i.e.,optimal) solu-tionsdiscoveredsofar.

Thenatureoftheproblemdomainandcontexthasalarge inﬂu-enceonthenatureofthegeneticalgorithm,andconsequentlythere are manyversions ofgeneticalgorithms, each ofwhich can be customisedfurtherbymeansofdifferentparameters.Generally, however,theyallsharethesamemajorfeatures:apopulationof individualsrepresentedbysomeformofencoding,crossoverand mutationoperatorstoproducenewindividuals,andsomekindof ﬁtnessfunctiontoevaluatetheindividuals.

(11)

Encodings,whichidentifythecharacteristicsoftheindividual solutions,cantakemanydifferentforms.Oneofthesimplestisto useastringofintegers:eachpositionofthestringrepresentsa differentcharacteristic,andthevalueatthatpositiondetermines thenatureofthecharacteristicforthatindividual.Forexample, asimplesystemofthreecomponentsconnectedinseriescould be represented by a string of three integers, and the value of eachintegerindicatestheversionormanufacturerofeachofthe threecomponents.Whilesimple,thistypeofencodingisalsoquite limited,sootherformsofencodingarepossible,suchashierarchical (i.e.,tree-based)encodingswhichmimicthehierarchicalstructure ofthesystemarchitecture.

GAsalsodifferinhowtheyhandlemultipleobjectives(assuming theydoatall).Onecommonapproach istocombinethe differ-entevaluations into a single value byapplying a weightingto eachobjective—ineffect,convertingamultiple-objectiveproblem intoasingle-objectiveproblem.Soforexample,iftheobjectives weresafety, performance, and cost, each would benormalised andweighted—e.g.0.4×safety,0.3×performance,0.3×(inverse ofcost)—andtheresultoftheformulausedasthefitnessforthat individual.However,thisisnotalwaysdesirable(sinceitcanhide usefultradeoffs)andthefitnessweightingscanbeverydifficultto derive.

Anotherapproach isthe penalty-basedGA approach. In this approach,oneobjectiveistreatedasthemainobjectiveand mini-mised(ormaximised)—e.g.cost—andotherobjectivesaretreated asscaled,weightedconstraintsand appliedasa penaltytothe mainobjective.Forexample,amaximumunavailabilitylimitmight beset,andthemorethedesigncandidateexceedsthelimit,the moreharshlytheﬁtnessispenalised.Thuseveniftwosolutions both achieve the same cost, theone that doesnot violate any constraints—orwhichviolatesthembythesmallestdegree—is pre-ferredbythealgorithm.However,becausesuccessfulexploration ofthedesignspaceoftenrequiresinfeasiblesolutions(i.e.,those thatbreaktheconstraints)tobeexploredtoo,adynamicpenalty functioncanbeemployedthatvariesthepenaltyaccordingtothe lengthoftheoptimisationrunsofar(e.g.applyinglightpenalties earlyintheprocess,toencouragemoreexploration,and gradu-allymakingthemheavierastimegoeson).Thisformofdynamic penalty-basedGAhasbeenfoundtohavesuperiorperformance comparedtoeitherstaticversionsorversionsthatonlyallow fea-siblesolutionstobepartofthepopulation(CoitandSmith,1996b). Thereare alsotruemulti-objectiveapproaches thatevaluate againstmultipleobjectivesatonceand maintainaParetofront ofoptimal,non-dominatedsolutions.Thisallowsabroadersetof solutionsandgenerallyresultsinabettercoverageofthesearch space (Salazar et al., 2006), albeit at the cost of higher com-plexity.Thesetypesofalgorithmsaregenerallybettersuitedto multi-objectiveproblemsbecausetheyallowthevarioustradeoffs betweentheobjectivestobebetterrepresented,ratherthanbeing biasedtowardsoneobjectiveandusingtheothersasconstraintsor weightedpenaltiesetc.Therearemanydifferentmulti-objective GAs,including:

• PESA-II(Pareto Envelope-basedSelection Algorithm 2)(Corne etal.,2001),whichseekstomaximiseevenlydistributedspread intheParetosetbyincludingcrowdingintheselectioncriteria; solutionsthatarefoundinlesscrowdedregionsofthesearch spacearepreferredforselectiontoencouragethealgorithmto lookatunder-exploredareasofthesearchspace.

• SPEA-II(StrengthParetoEvolutionaryAlgorithm2)(Zitzleretal., 2001).UnlikePESA-II,whichadoptsa“pureelitist”strategythat allowsnodominatedsolutionstoberetained,SPEA-IIdoeskeep somedominatedsolutions.Theselectioncriteriaarealteredto includeadominancestrength(howmanysolutionsitdominates) andadensityvalue(howcloseanindividualistoothersolutions).

Thusalthoughdominated,crowdedsolutionsarepossible, non-dominated,non-crowdedsolutionsarepreferred.

• NSGA-II (Non-Dominated Sorting Genetic Algorithm 2) (Deb etal., 2002).InNSGA-II, both non-dominated and dominated solutionsarekeptinthesamepopulation,rankedaccordingto dominance(basedonhowmanyothersolutionstheydominate). Moredominatingsolutionsarepreferredduringselection,and crowdingis usedasa tie-breakeriftwo solutionshave equal dominance.

3.1.2. Chosenalgorithm

Aftercomparingthethreealgorithmsabove,thealgorithm cho-senforuseintheATESST2andMAENADprojectsfortheautomatic optimisationofEAST-ADLmodelsisavariantoftheNSGA-IIgenetic algorithm, which wasdeemedto havea good balanceof char-acteristics.NSGA-II is alsoused as thebasis of thePerOpteryx optimisation engine(Koziolek et al., 2011) and is also used in AQOSA(EtemaadiandChaudron,2012).NSGA-IIoffersreasonably goodperformance,widecoverageofthedesignspace,and(most importantly) excellent support for multiple objectives (Parker, 2010).ThealgorithmisnotguaranteedtoﬁndallParetooptimal solutions(thoughnorareanyoftheotheralgorithms,geneticor otherwise),butitshouldstillproduceasetofsuperiorsolutions muchfasterandmoreefﬁcientlythancouldbeperformed manu-ally.

Theencodingusedisaformofhierarchical,tree-basedencoding, whereeachtreenoderepresentsadifferentvariabilitypointforone ormorefunctionsorcomponentsinthesystemarchitecture.Ifan optionalfunctionispresentandalsohasachoiceofsubfunctions (orsubcomponents),thenthenodewillhavecorrespondingchild nodesbeneathitwhichcanalsobevaried.

The different values of the encoding represent all possible variations of the system architecture—in effect, the encoding encapsulatestheentiredesignspace.ItisdefinedinEAST-ADLby meansofthevariabilitymanagementmechanism,allowingmore complexconfigurationsof featurestoberepresented,including dependenciesbetweenfeatures(possiblyhierarchical)and dupli-cationof features.Variabilityis thereforeusedtorepresentthe possibleoptionsforarchitecturalvariationofthedesignbydefining thevariationpointsofthedesignspace;thisnotionofoptimisation spacecorrespondsexactlytowhatiscalledaconfigurationspace infeaturemodellingterminology.Thusforexampleacritical com-ponentcanbedefinedwithseveralimplementationsorperhapsan alternativereplicatedsubsystemspecified(whichprovides addi-tionalredundancy,butincreasescost);theoptimisationalgorithm canthenchooseoneoftheseoptionsandevaluatetheeffectsof thatoptionontheoverallattributesofthesystem.

Optimisationvariantscanbedeﬁnedinoneofthreemainways: 1.Substitution: A component/function(or subsystem) is substi-tutedfor another that hasdifferent objective attributes(e.g. safety, cost, performance).A substitute must befunctionally equivalent,i.e.,itmustperformthesametaskandhavea compat-ibleinterface,butneednotachievethetaskinthesamewayor makeuseofallconnections(e.g.anelectronicbrakingsubsystem maybereplacedbyahydraulicversion).Differentsubstitutes areoftentermedasdifferentimplementationsofafunctionor component.

2.Replication:Toimprovereliability,acriticalcomponentormodel elementmaybeduplicatedtoachieveredundancy.Replicants are usually connected in parallel to ensure that a failure of one elementdoesnot leadto afailure of thewhole subsys-tem.Note that thereplicants have tobedeﬁned in advance asoptionalelements;theoptimisationdoesnotgeneratethem itself.

(12)

Fig.6.Differentvariationstrategies.

3.Allocation: In systemswithboth hardware and software ele-ments,theremaybeachoiceofallocationstrategy,e.g.interms ofwhichsoftwarefunctionisallocatedtobeexecutedonwhich hardwareplatform.Thisallowstimingperformanceaswellas reliabilitytobebalancedovertheavailableprocessingresources ofthesystem.

ThesedifferentvariationsareillustratedinFig.6.Furthermore, morecomplexoptimisationispossibleviaacombinationoftwoor moreoftheabove,e.g.replicationthatusesmorethanone imple-mentation.

Duringtheoptimisationprocess,differentvariantscanthenbe chosen fromamongst the predeﬁned choices, and the variabil-itymechanismsensurethattheconnectionsbetweenthechosen componentsarekeptconsistent.Thisenablesrelativelyseamless connectionsbetweendifferentchoicesoffunctions/componentsin themodelandensuresthate.g.failuresarepropagatedcorrectly throughthesystemmodel.

Thisvariability-basedapproachisveryﬂexibleandallows com-plexcompositionalvariantstobemodelled;forexample,asingle componentmaybesubstitutedforanothercomponentfroma dif-ferentmanufacturer,orreplacedbyareplicatedsubsystemwith heterogeneous subcomponents. This allows more sophisticated designpatterns(suchasvotersandmonitorsetc.)tobeevaluated aspartoftheoptimisation;furthermore,suchconﬁgurationscan oftenbestoredinalibraryandreusedinothermodels.

3.2. EAST-ADLoptimisationtoolarchitecture

ThissectiondescribestheEAST-ADLoptimisationtool architec-tureascurrentlybeingdevelopedintheMAENADproject.Thetool architectureisdesignedtomeldallofthevariousanalysisand opti-misationtoolsrequired,usingtheEAST-ADLsystemmodelasthe glue.Aprototypeoptimisationenvironmenthasbeendeveloped basedontheEPMtool(basedontheEclipseframework),which currentlyimplementsacoresubsetofEAST-ADL(Abeleetal.,2012). Therearethreemaingoalstobefulfilledbythetoolarchitecture: • Designspacedefinition:Inorderforoptimisationtotakeplace,it mustbepossibletodefinethedesignspacebymeansofspecifying variabilitypointsinthemodelthattheoptimisationcanlater chooseandevaluate.Thisisprimarilyachievedthroughtheuse ofEAST-ADL’svariabilitymanagementmechanism,whichallows alternativeimplementationsandallocationstobespecified.In thetoolarchitecture,thisroleisfulfilledbytheEPMtool. • Rapidobjectiveevaluation:Foroptimisationtobeguidedrather

than random, it must be possible to evaluate new solutions todeterminewhethertheyarebetterorworsethan previous solutions. In a multi-objective problem, this means analysing thesolutions(intheformofdesigncandidates)foreachofthe

objectivesbeingevaluated.Inthiscase,HiP-HOPSistheprimary tooltoevaluatesafetyandreliabilitycharacteristics,cost (cur-rentlyonlyasimplisticsummation)ishandledbyadedicated plugin, and timing analysis capabilities are provided by the MASTtool. Otherpluginscanbeaddedasneededtoevaluate otherobjectives.

• Efﬁcientdesignspaceexploration:Finally,optimisationrequires that thedesign spacebeexploredby meansof analgorithm. Inthiscase,avariantontheNSGA-IIgeneticalgorithmisused, based onprototypeoptimisationtechnologyin HiP-HOPSbut implemented as anEPM plugininstead. In combination with thedesign spacedeﬁnitionandanalysiscapabilities, itallows automaticoptimisationofanEAST-ADLarchitecture.

Anadditionalcrucialstepisvariabilityresolution.Inorderfora designvarianttobeanalysedandevaluated,thevariabilityﬁrsthas tobe‘resolved’,i.e.,toproduceamodelinwhichallofthe variabil-itypointshavebeenselectedordeselectedtoproduceaparticular systemconﬁgurationwithaconcretesetofobjectiveattributes.

Therearestillcertainissuesandconstraintstobedealtwith. For example,EAST-ADLdoesnotrequireaone-to-one mapping betweenitsnominaland errormodelarchitectures, i.e.,it does notordinarilyrequirethateachfunctionhasacorrespondingerror model type;however,for theerrormodel tobeevaluated cor-rectlywhenthenominalarchitecturechanges, theoptimisation requiresaone-to-onemappingtobeapplied.Thisisresolvedby explicitlydeﬁningtheErrorModelforeachnominalmodelvariant. Furthermore,itisveryimportantthattheoptimisation variabil-ityensuressubstitutability,i.e.,thatiftheoptimisationalgorithm selectsadifferentoption,theresultingsystemdesignremainsvalid andsensible.Thisimposestworequirementsonthevariants:that theyshareacompatibleinterface(i.e.,theyshareatleastacommon subsetofportsandconnections)andthattheyperformequivalent functions.Otherwise,theoptimisationalgorithmmayselecta dif-ferentoptionthatleadstoaninvalidornonsensicalsystemdesign. Thisisnotnecessarilyasimpleproblem,especiallyinanADLsuch asEAST-ADL,wheretheerrormodel,software,andhardwaremay allberepresentedinseparatemodelviewsandachangeinonemay needtobereﬂectedintheothers.Atthesametime,thisisacriterion forvalidityofthemodelregardlessofcontext:itisnotonly optimi-sationwhichrequiresthatavalidtimingmodel(orerrormodelor anyothermodel)mustemergetogetherwiththecorearchitecture asaresultofchangestothevariability;thisisageneralissueinany variabilityresolutionprocess.

ThetoolarchitectureitselfisshowninFig.7.Thisdiagramshows theflowofoperationsintheoptimisationprocess.Theinitial EAST-ADLmodel(withvariability)ispassedtotheOptimisationSpace DefinitionModule(orOSDM),whichgeneratesaMasterEncoding Hierarchy.ThisdefinesthesearchspacefortheCentral Optimisa-tionEngine,whichgeneratesdifferentmodelencodingsthatare

(13)

Main Optimisation Loop

Product Line Loop

Analysis Wrapper 1

(interface to external tool)

...

EXTERNAL ANALYSIS TOOLS Analysis Wrapper 2 (self-contained) Analysis Wrapper N (interface to external tool) Variability Resolution Mechanism Central Optimization Engine Optimization Space Definition Module EAST-ADL Model with Variability Master Encoding Hierarchy Model Encoding Resolved Model (or set of resolved product line models)

Analysis Results

Pareto set of optimized

models

Analysis performed for each of the product line models (if present) For product lines,

results cover the whole line, e.g. a sum, product, minmum or maximum.

Fig.7.EAST-ADLoptimisationtoolarchitecture.

passedto theVariability Resolution Mechanism to beresolved intoanalysablemodels.Theanalysiswrappersthenevaluatethese modelsaccordingtodifferentobjectivesand returntheresults. EventuallytheoptimisationsettlesonasetofParetooptimal solu-tions,whichconstitutetheﬁnalresultsoftheprocess.Thereisalso afurtherplannedprocessinvolvingproductlineoptimisation(see Section3.2.5),althoughthisisnotincludedinthecurrent proto-type.

Themajorelementsofthearchitecturewillbedescribednext. 3.2.1. OptimisationSpaceDeﬁnitionModule(OSDM)

TheOSDMprovidestheinputfortheoveralloptimisation pro-cessbytakingtheoriginal“variant-rich”EAST-ADLmodel,which containsvariabilityelementstodeﬁnethevariationpointsofthe design,andderivesfromthisinputthesetofpossibleencodings oftheoptimisationsearchspace—theMasterEncodingHierarchy. Thisisastructurethatcanbemanipulatedtoobtainthesetofall validdesigncandidates.TheMasterEncodingHierarchyallowsthe CentralOptimisationEnginetoexplorethedesignspace automat-icallybyusinganabstractstructurewithouttheneedforsemantic knowledgeoftheEAST-ADLdesignmodelitself.Thisis“abstract” inthesensethatitdoesnotincludeanyinformationonthe struc-ture,behaviourorotherpropertiesoftheindividualcandidates;it justprovidesameanstounambiguouslyidentifyeachcandidate. Ittakestheformofatree-basedhierarchicalstructure(basedon anormal variabilityfeaturemodel)in whicheach nodedeﬁnes anindividualvariabilityandthenatureofthenodedescribesthe typeofvariability.InEAST-ADL,thecoretechnicalfeaturemodel

onvehiclelevelprovidessuchanabstractviewofthecomplete system’svariability,asdetailedinSection2.2,andcanthereforebe usedasisforthispurpose.

TheOSDMisthereforenecessarytoensurethattheoptimisation engineitselfdoesnotneedtoknowanythingaboutthesemantics ofthemodelsitdealswithotherthanwhatvariabilityispresent intheoriginalmodelandhowit canbeencoded. Itisthenthe joboftheVRMtoconvertaparticularencoding—i.e.,aparticular conﬁgurationofthevariabilityinthemodel—intoanewmodelin whichallthevariabilityisresolved.Thiscanthenbeanalysedby theexternaltools,andtheoptimisationenginethendetermines whethertokeepordiscardthatparticulardesigncandidateonthe basisofthoseanalysisresults.

Unliketheotherelements,whichareusedineachoptimisation iteration,theOSDMisonlyrequiredonce,atthebeginningofthe optimisation,notiterativelyineachoptimisationcycleaswiththe otherelements.

3.2.2. CentralOptimisationEngine(COE)

TheCentralOptimisationEngineisthedriveroftheoptimisation process,responsibleforexploringthedesignspace(bychoosing whichencodingstoevaluate)andforcollectingthebestsolutionsso far.TheCOEwillusegeneticalgorithmsbasedonestablished HiP-HOPStechnology(Papadopoulosetal.,2011),butisimplemented asaseparateplugintofacilitateeasiercommunicationwiththe otherelementsofthetoolarchitecture.

Whenoptimisationisinitiated,theoptimisationenginereceives threethings:asetofoptimisationparameters(suchasthenumber