MOO: An architectural framework for runtime optimization of multiple system objectives in embedded control software

(1)

ContentslistsavailableatScienceDirect

The

Journal

of

Systems

and

Software

jo u rn al h om epa 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

MOO:

An

architectural

framework

for

runtime

optimization

of

multiple

system

objectives

in

embedded

control

software

Arjan

de

Roo

a

_,

_Hasan

_Sözer

b,∗

_,

_Lodewijk

_Bergmans

a

_,

_Mehmet

_Aks¸

_it

a a_University_of_Twente,_Enschede,_The_Netherlands

b_Özye˘gin_{University, ˙Istanbul,}_Turkey

a

r

t

i

c

l

e

i

n

f

o

Articlehistory: Received29June2012

Receivedinrevisedform28March2013 Accepted1April2013

Available online 15 April 2013 Keywords: Architecturalframework Multi-objectiveoptimization Runtimeadaptation Embeddedsystems Controlsoftware

a

b

s

t

r

a

c

t

Today’scomplexembeddedsystemsfunctioninvaryingoperationalconditions.Thecontrolsoftware

adaptsseveralcontrolvariablestokeeptheoperationalstateoptimalwithrespecttomultiple

objec-tives.Thereexistwell-knowntechniquesforsolvingsuchoptimizationproblems.However,current

practiceshowsthattheappliedtechniques,controlvariables,constraintsandrelateddesigndecisions

arenotdocumentedasapartofthearchitecturedescription.Theirimplementationisimplicit,tailored

forspeciﬁccharacteristicsoftheembeddedsystem,tightlyintegratedintoandcoupledwiththecontrol

software,whichhindersitsreusability,analyzabilityandmaintainability.Thispaperpresentsan

archi-tecturalframeworktodesign,documentandrealizemulti-objectiveoptimizationinembeddedcontrol

software.Theframeworkcomprisesanarchitecturalstyletogetherwithitsvisualeditorand

domain-speciﬁcanalysistools,andacodegenerator.Thecodegeneratorgeneratesanoptimizermodulespeciﬁc

forthegivenarchitectureanditemploysaspect-orientedsoftwaredevelopmenttechniquesto

seam-lesslyintegratethismoduleintothecontrolsoftware.Theeffectivenessoftheframeworkisvalidatedin

thecontextofanindustrialcasestudyfromtheprintingsystemsdomain.

1. Introduction

A current trend in embedded systems is toward adaptivity undervaryingcircumstances(e.g.,environmentalconditions,user needs and input). For example, current high-end printing sys-temsperformadaptiveoptimizationofmultiplesystemobjectives, suchasmaximizingproductivityandminimizingenergy consump-tion.Theyapplytrade-offdecisionsconcerningseveraluserneeds, conﬂictingqualityattributesandobjectives.Adaptiveoptimization resultsinmorecompetitivesystemsthatleveragebettercustomer satisfactionandcosteffectiveness.

Adaptiveandoptimizedbehaviorisachievedbyadjusting cer-taindecisionvariablesinthesystem.Examplesofdecisionvariables arethespeedofthesystemandthetemperaturesetpointofa heat-ingdevice.Thevaluesofthedecisionvariablesareoftensubject toconstraints.Forexample,thespeedofthesystemislimitedto amaximumspeedandtheamountofconsumedpowerislimited totheamountofpoweravailable.Theproblemofbalancing mul-tiplesystemobjectivesbyinﬂuencingasetofdecisionvariables

∗ Correspondingauthorat:SchoolofEngineering,Özye˘ginUniversity,Nis¸antepe Mah.OrmanSk.No.13,Alemda˘g–C¸ekmeköy34794, ˙Istanbul,Turkey.Tel.:+90216 5649383;fax:+902165649057.

E-mailaddress:hasan.sozer@ozyegin.edu.tr(H.Sözer).

thataresubjecttoconstraintsisknownasmulti-objective opti-mization(MOO)(KeeneyandRaiffa,1976).Inmodernembedded systems,thesetofstrategiesandtechniquestofacilitateMOOare implementedinsoftware,aspartofthecontrollogic.

Embedded systems can comprise many differentcontrollers implementedinseveralsoftwaremodules,eachcontrollingapart of thesystem.Asaresult, MOO havetoberealizedby manip-ulatingandcoordinatingmanycontrollers,scatteredthroughout theembeddedcontrolsoftware.Forexample,powerconsumption andproductivityofthesystemcannotbecontrolledbyaspeciﬁc controller;theyareinﬂuencedbythebehaviorofthesystemas awhole.Thismanipulationandcoordinationofmanycontrollers introducesadditionalstructuralcomplexitywithintheembedded controlsoftware.

Thereisalackofsystematicmethodsandtechniquestodesign andimplementMOOinembeddedcontrolsoftwareandto man-age theresulting complexity. Usually theimplemented control behaviorissufﬁcient,butnotoptimal,asbetteroptimizing solu-tionswould betoocomplextoimplement.Whenimplemented, the applied optimization techniques, controlled variables, con-straints and related design decisions are not documented as a partofthearchitecturedescription.Theyusuallyremainimplicit, makingithardtocommunicate,analyze,maintainandreusethe embeddedcontrol software.Moreover,the lackof explicit rep-resentationofthedecisionvariablesandtheirinterrelationships 0164-1212/$–seefrontmatter © 2013 Elsevier Inc. All rights reserved.

(2)

leadstoimplicitdependenciesamongthesoftwaremodules.Asa result,anymodiﬁcationofthecontrolledsystemand/orthecontrol softwarebecomeserror-prone.

Previously,wehaveproposedanarchitecturalstyle(deetal., 2009),whichintroducesagraphicalnotationtodocumentthe soft-warearchitecturefromtheMOOpointofview.Thisstyleenables thedocumentationofdecision variables, constraintsand trade-offsat thearchitectural level. In this work, we have extended the style with domain-speciﬁc models. In particular, we use SIDOPS+(Broenink,1997)for documenting physical characteris-tics/modelsregardingthecontrolledsystem.Severalsuchphysical modelsareimplementedinembeddedcontrolsoftware.Indigital printingsystemsforinstance,physicalmodelsareusedfor esti-matingtheheatexchangeamongcomponentslikethetonerbelt andthepaperpath.Inpractice,however,thesemodelsare imple-mentedinageneral-purposeprogramminglanguageandtangled withthecontrolsoftware,justliketheimplementationofMOO. Thenewstyle,whichwecallastheMOOarchitecturalstyle,isnot basedonjustonelanguageornotation.Itmakesuseofmultiple domain-speciﬁcmodelinglanguages(DSMLs)together.

In this paper, we also introduce a complete framework for documenting,analyzingandrealizingMOOinembeddedcontrol software.Wehavedevelopedatoolchainconsistingofvisual edit-ors,analysistools,codegeneratorsandweavers.Theframework generatesoptimizers basedontheMOO architectural model.It alsocomposesthegeneratedcodewithboththephysicalmodels andtherestofthecontrolsoftwarebymeansofaspect-oriented software developmenttechniques. The coreapplication is kept modularandindependentfromtheoptimizationdetails.Assuch, ourapproachsupportsthereusabilityandmaintainabilityofthe MOOsolutionsandphysicalmodels,whicharemodularizedand specified with separate DSMLs. Separate specification of MOO aspects,relatedphysicalmodelsandthecontrollogicalsoenables ustoperformdomain-specificanalysisandverification.

Wehaveillustratedtheeffectivenessofourframeworkinthe context of an industrial case study from the printing systems domain.WehavemodularizedthespecificationoftheMOO solu-tionandtheimplementationofthephysicalmodelsforapartofthe controlsoftwarethatisresponsibleforheatcontrolonthepaper path.Thesespecificationsareverifiedbythetoolchainofthe frame-work.Partofthecontrolsoftwareisautomaticallygeneratedbased ontheverifiedMOOarchitecturalmodeland therelated physi-calmodels.Thegeneratedcodeisautomaticallycomposedwith therestofthecontrolsoftware.Wehavecompared the perfor-manceoftheautomaticallygeneratedcontrolsoftwarewiththree otheralternativesthatusestate-of-the-practiceengineering solu-tionsforoptimization.Wehaveseenthatourapproachcanleadto anincreaseinproductivityby20%,anditcandecreasetheenergy consumptionby10%.Wehavealsoseenthatourapproachreduces thedeviationinprintquality.Inaddition,thecontrolsoftwareturns outtobemoremodularized,reusableandmaintainable.

Theremainderofthispaperisorganizedasfollows.Thenext sectionprovidesbackgroundinformationonmulti-objective opti-mization.Section3introducestheindustrialcasestudyandputs theproblem in context. Section4 presents an overview of our approach.WeexplaintheMOOarchitecturalstyleandthetoolchain oftheMOOframeworkinSections5and6,respectively.In Sec-tion7,weexplaintheexperimentalsetupandpresenttheresults. Finally Section8 provides the conclusions and discusses some futureworkdirections.

2. Background:multi-objectiveoptimization(MOO)

MOOisamathematicalprobleminwhichthegoalistooptimize multipleobjectives.Theobjectivescanbeinﬂuencedbyasetof

decisionvariables.Thevaluesofthesedecisionvariablesaresubject toconstraints.AMOOproblemisdeﬁnedasfollows(Colletteand Siarry,2003):

Deﬁnition1(MOOproblem). AMOOproblemcanberepresented byatupleo(x),g(x),h(x),where

• x∈Rn_represents_the_value_of_the_n_decision_variables.

• o(x)∈Rn_→_Rk_is_a_vector_of_k_objective_functions_in_the_decision variablesxthatprovideavaluationforthekobjectives.

• g(x)∈Rn_→_Rl_is_a_vector_of_l_functions_that_describe_inequality constraints.Aninequalityconstraintmeansthatxshouldbe cho-seninsuchawaythattheoutcomeofeachofthelfunctionsing issmallerthan0.

• h(x)∈Rn_→_Rm_is_a_vector_of_m_functions_that_describe_equality constraints.Anequalityconstraintmeansthatxshouldbechosen suchthattheoutcomeofeachofthelfunctionsingisequalto0. Thesolutiontothisproblemarethex∈Rn_that_minimize_o(x) undertheconstraints

∀

i∈[1...l]gi(x)≤0and

∀

j∈[1,...,m]hj(x)=0. Theconstraintslimitthepossiblevaluesforthedecision vari-ablestoasubsetofRn_._This_subset_is_called_the_feasible_decision space.Thesolutiontotheoptimizationproblemisselectedfrom thefeasibledecisionspace.Eachvaluexinthefeasibledecision spacecanbeinputtotheobjectivefunctionso(x).Thesetofall objectivevaluesthatresultfromapplyingallvaluesinthefeasible decisionspacetotheobjectivefunctionsiscalledobjectivespaceor criterionspace.

Optimizing a singleobjective is straightforward, as there is a one-dimensional objective spacein which there is one point thathasasmallerobjectivevaluethanalltheotherpointsinthe objectivespace.Butwhentherearemultipleobjectives,thereis usuallynotasinglepointintheobjectivespacethathasthe min-imal/optimalvalueforallobjectives.Inthiscase,onepointinthe objectivespaceissaidtodominateanotherpointifitimprovesupon atleastoneoftheobjectives,withoutcompromisingontheother objectives.InaMOOproblem,theremightnotbeasinglepointthat dominatesallotherpoints.Instead,therecanbemultiplepointsin theobjectivespacethatarenotdominatedbyanyotherpointin theobjectivespace.ThesepointsarecalledParetooptimalpoints (Paretoetal.,1896).Forpracticalapplications,suchasinthecontrol ofembeddedsystems,asingleresult/solutionoftheMOOproblem isnecessary.Basedontherelativeimportanceoftheobjectives(e.g., basedoncustomerneeds),asingleoptimalvaluecanbeselected. Apreferencerelationshipontheobjectivesisusuallyspeciﬁedin theformofatrade-offfunction,providingascalarvalueforeach pointintheobjectivespace,andassuchprovidingatotalordering relationshipamongtheParetooptimalpoints.

We have employed existing theoryon multi-objective opti-mization(EhrgottandGandibleux,2002;MarlerandArora,2004; YoonandHwang,1995;Eckenrode,1965;HwangandYoon,1981; Geilenetal.,2007)toformamathematicalbasisforourapproach. Hence,wedonotcontribute,butratherutilizeexistingmethods andtechniquesinthisdomain.Several(open-source) implemen-tationsofmulti-objectiveoptimizationalgorithmsexist,suchasin Gnulinearprogrammingkit(2012)andlpsolve(2012).Matlab pro-videsafunction,calledfmincon,toperformoptimizationofasingle objective(Findminimumofconstrainednonlinearmultivariable function,2013),whichcanalsobeutilizedtogetherwitha trade-offfunctionregardingmultipleobjectives.Wehaveemployedthis functionwithinthecodethatisgeneratedbytheMOOframework. 3. Industrialcasestudyandproblemstatement

Wehavedevelopedandevaluatedourapproachwithinthe con-textoftheOctopusproject(Octopusproject,2012).Inthissection,

(3)

Toner Belt Paper Path PaperHeater Radiator Contact Point Belt Temperature Sensor Pph Tph Prad Tbelt Tcontact v

Fig.1.SchematicviewoftheWarmProcess.

weﬁrstdescribetheprojectcontext.Then,weintroducean indus-trialcasestudy,takenfromthedigitaldocumentprintingsystems domain.Finally,weprovidetheproblemstatement.

3.1. Thecontext

In traditional embedded systems development, trade-offs between(conflicting)systemqualities(e.g.,productivity,energy consumption)aremadeatdesigntime.Thisresultsinembedded systemsinwhichthetrade-offbetweenthesequalitiesisfixed.For example,theembeddedsystemiseitherahigh-productivesystem withhighenergyconsumption,oranenergy-savingsystemwith lowproductivity.Nowadays,marketforcesdemandmoreflexible andadaptablemachines,inwhichthetrade-offsbetweensystem qualitiescanbemadeatruntime.For example,acustomerofa printingsystemmightsometimesneedahigh-productivemachine (e.g.,fortime-criticalprintjobs),whileingeneralanenergy-saving systemispreferred.Theembeddedsystemhastodynamically opti-mizethesystemqualitiesunderchangingcircumstances,suchas changesinenvironmentalconditionsandchangesinuserinput.In thefollowingsubsection,weintroduceanexamplecasestudyin thiscontext.

3.2. Casestudy:WarmProcess

Apartoftheprintingprocessindigitaldocumentprinting sys-temsis calledtheWarmProcess.Thisprocessis responsiblefor transferringatonerimagetopaper.

Fig.1depictsaschematicoverviewofthepartsintheprinting systemresponsiblefortheWarmProcessbehavior.TheWarm Pro-cesshastwomainparts;apaperpathtotransportsheetsofpaper andatonerbelttotransporttonerimages.Thecontactpointisthe locationwherethepaperpathmeetsthetonerbelt.Atthis loca-tionthetonerimageistransferredfromthetonerbelttothesheet ofpaper.For correctprinting, boththesheets ofpaperandthe tonerbeltshouldhaveacertaintemperatureatthecontactpoint. Therefore,theWarmProcesscontainstwoheatingsystems;apaper heatertoheatthesheetsofpaperandaradiatortoheatthetoner belt.Thereisnosensortomeasurethetemperatureofthetonerbelt atthecontactpoint(Tcontact).Instead,thephysicalsystemprovides thefollowingsensorsandactuators:

• Tph:Sensorthatmeasuresthepaperheatertemperature. • Tbelt:Sensorthatmeasuresthetemperatureatthesensorlocation

onthetonerbelt.

•

v:

Actuatortosettheprintingspeed.1

1_Note_that_this_only_gives_a_simpliﬁed_and_abstract_view_of_a_printing_system._In reality,thereisnosingleactuatorinthephysicalsystemtosettheprintingspeed.

• Pph:Actuatortosettheamountofpowersuppliedtothepaper heater.

• Prad:Actuatortosettheamountofpowersuppliedtotheradiator. Theprintingspeedcanbeadapteddependingontheneedsand objectives.Forexample,itcanbeloweredtoreduceenergy con-sumptionor raisedwhenprinting onlighterpaper(to increase productivity).Ifthespeedofthesystemchanges,thetemperatures ofthepaperheaterandbeltalsoneedtochange,tomaintain cor-rectprintquality.Engineersidentiﬁedarelationshipbetweenthe threevariables:speed(v),paperheatertemperature(Tph)andthe temperatureofthebeltatthecontactpoint(Tcontact).Correctprint qualityisensuredifthisrelationship,asfollows,holds(c1,c2and c3areconstants):

Tcontactdesired= c1·

v

−c2·Tph+c3 (1)

Thepaperheaterreacts slowlytochangingtemperature set-points,whiletheradiatorcanquicklyinﬂuenceTcontact.Therefore, engineersdecidedtomainlyusetheradiatortoadjustthe tem-peratureswhenthespeedchanges.ThismeansthatEq.(1)isused todeterminetherequiredTcontact(i.e.,thesetpoint).Asthereisno sensortodirectlymeasureTcontact,engineershadtoidentifythe followingrelationshipbetweenTcontactandTbelt(c4isaconstant): Tcontact=c4·

P_√rad

v

+Tbelt (2)

In the following subsection, we analyze important aspects, designdecisionsandissuesregardingtheimplementationofMOO inthecontextoftheWarmProcesscasestudy.

3.2.1. AnalysisofoptimizationintheWarmProcesscasestudy IntheWarmProcesscasestudy,engineersaimtointroducethe possibilityfortheusertomaketrade-offsatruntimebetweenthe twoconflictingobjectivespowerconsumptionandproductivityof theprintingsystem.Theyidentifiedthedecisionvariablesthatcan beusedtoinfluencetheobjectives,thedifferentconstraintsinthe systemandtheobjectivefunctions:

• Decisionvariables:Speedofthesystem(v),temperaturesetpoint ofthepaperheater(T_phsp).

• Constraints:

–60≤

v

(minimalspeedis60). –

v

≤120(maximalspeedis120).

–40≤T_phsp(minimalsetpointforthepaperheateris40). –T_phsp≤90(maximalsetpointforthepaperheateris90). –Pph≤1200(maximalpowertothepaperheateris1200W). –Prad≤800(maximalpowertotheradiatoris800W).

–Ptotal≤Pavail(totalpowerconsumptionshouldnotexceedthe amountofpowerthatisavailabletothesystem).

• Objectivefunctions:

–Totalpowerconsumption:Ptotal=Pph+Prad.

–Productivity:Prod=1/v(productivityisdeﬁnedasaninverse ofspeed,asinMOOthegoalistominimizetheobjective func-tions).

Fig.2shows thearchitectureof thecontrolsoftwarefor the WarmProcesscasestudy.Thesoftwarearchitecturecontainssix

Instead,thepaperpathconsistsofmultiplemotorsandpinches,eachofwhichcan becontrolledindependently.Ifthiscontrolisdoneinacoordinatedway,thisleads tocorrectpapertransportationatacertainspeed.Nevertheless,avirtualspeed actuatorcanbeimplemented,whichtakescareofcontrollingthedifferentmotors inthepaperpathtoobtaintherequestedspeed.

(4)

System I/O Paper Path v PrintQuality Tcontact Tph v Belt Temperature Prad Tcontact Tbelt v Paper Heater Controller Tph Tspph Pph Radiator Controller Tcontact Tsp contact Prad

Pph Pph Tph Tbelt Prad Prad v v

KEY

: Component Connector In-port Out-port

Fig.2. WarmProcesssoftwarearchitecture.

differentcomponents.Componentshaveinterfaces,whichare rep-resentedasin-ports/out-portstoprovide/retrieveavalueto/from thecomponent.

TheSystem I/Ocomponentprovidesaninterfacetothe sen-sorsandactuatorsinthesystem.Thecomponenthasanout-port foreachsensor(TphandTbelt).Thecomponenthasbothanin-port andanout-portforeachactuator(Pph,Pradand

v).

Theout-portfor anactuatorprovidesthecurrentleveloftheactuator(i.e.,thelast valuethathasbeenprovidedtothein-port).

PaperHeaterControllerandRadiatorControllerare com-ponentsthatcontainthecontrollogicforrespectivelythepaper heater and the radiator. The components PrintQuality and BeltTemperature implement respectively the equation that determinesprintquality(Eq.(1))andtheequationthatdetermines belttemperature(Eq.(2)).PaperPathisthecomponentthat con-trolsthebehaviorofthepaperpath.Itdeterminesthespeedofthe systemandprovidesthistotheWarmProcesscontrolcomponents. IfwerelatetheMOO-relevantvariables todifferentportsin thesoftwarearchitecture,wecanconcludethatthesevariables arerelatedtodifferentarchitecturalelements(e.g.,ports),which arespreadthroughthesoftwarearchitecture.Thisillustratesthe factthatoptimizationcanaffectseveralcomponentsatdifferent partsofthesystem.Dependingonthescaleofthesystemandthe functionalitybeingoptimized,thescatteringcanbeworse,which complicatestheimplementationand increasesthemaintenance effort.

3.3. Problemstatement

Thereis a lack of systematic methods todesign and imple-mentMOOinembeddedcontrolsoftware.Thisusuallyresultsin adhocsolutionsthataretailoredtothespeciﬁcsystemand there-foreinﬂexiblewhenthesystemchangesorevolves.Moreover,the implementationofMOOgetstightlycoupledandintegratedwith, andspreadoutovermultiplecontrolsoftwarecomponents.2_The

overallimpactisareductioninsoftwarequality:adhocandtightly coupledsolutionsaremoredifficulttocomprehend,theirinflexible naturehinderstheirevolvabilityandreusability.Thelackofa com-monmethodologyandcorrespondingterminologymakesitharder todocumentandcommunicatethedesigndecisions.Theresultis higherdevelopmentandmaintenancecosts(Bankeretal.,1993). Alternatively,aswehavewitnessedinpractice,theseproblemscan leadtothedecisiontoremovetheruntimeoptimization require-ment,asthebenefitsofamoreoptimalsystemdonotoutweigh thereducedsoftwarequalityandincreasedcosts.Therefore, sys-tematicmethods,techniquesandtoolsarerequiredtosupportthe realizationofMOOandthemanagementofsoftwarecomplexity introducedbyitsrealization.

2_The_issue_of_crosscutting_and_a_large_number_of_dependencies_was_conﬁrmed_as amajorissuebyourindustrialpartnersintheproject.

(5)

Fig.3.Theoverviewoftheapproach.

3.3.1. Relatedwork

Optimizationofsoftwaredesign hasreceivedmoreattention in recentyears (Aletiet al., 2013).Usually there existmultiple (conﬂicting)quality attributes toconsider in a software design (Sozeretal.,2011;Meedeniyaetal.,2010).Therefore,MOO tech-niqueshavebeenappliedtobalancethefeasibledesignalternatives withrespecttodifferentqualityfactorssuchasenergy consump-tionvs.reliability(Aletietal.,2009),resourceutilizationvs.data ﬂowlatency(Lietal.,2011),andperformancevs.reliability(Sozer etal.,2011).Inthispaperwedonotfocusontheoptimizationof thedesignitselfbuttheimplementedcontrolbehaviorinstead.We aimatsupportingthedesignandrealizationofasoftwaresystem thatemploysMOOforcontrollingembeddedsystems.

Anarchitecturalframework(Calinescuetal.,2011)hasbeen introducedforthedevelopmentandadaptationofservice-oriented systems.TheframeworkemploysMOOforselectingoptimal com-position of available services based on QoS requirements. In general,service-orientedsystemsarebuiltthroughthedynamic compositionoflooselycoupledservices.Inthiswork,wefocuson adifferentapplicationdomainthatimposedifferentchallenges.In ourproblemdomain,softwarestructureismainlyﬁxedanditis embeddedinaphysicalenvironment.Themainchallengeisto facil-itatetheoptimalcontrolofasetofdevicesthatinteractwiththis physicalenvironment.

Theimplementationofmulti-objectiveoptimizationincontrol systemshasbeenpreviouslydiscussedbyLuietal.(2002).Weaim atintroducingtwo newperspectivestothesediscussions.First, previousimplementationsmainlyconsiderlocalizedcontrol prob-lems,i.e.,optimizedbehaviorofaspeciﬁccontroller.Ourgoalisto optimizesystemqualities(e.g.,energyconsumptionandthe perfor-manceoftheoverallsystem),whichhasanimpactonthesystem asawhole.Hence,manydifferentcontrollershavetocooperate and an architectural focus is required to manage the incorpo-rationof theMOO functionalityaspartofthecontrolsoftware. Second,previousdiscussionsmainlyfocusonthemathematical designofanoptimizationalgorithm.Ourgoalistoenablemodular speciﬁcation, analysisand automated composition of optimiza-tiontechniques.Hence,inthefollowing,weintroducetheMOO frameworktofacilitatebettermanagementofsoftware complex-ityincontrolsoftwarewithoutcompromisingtheeffectivenessof optimization.

4. OverviewoftheMOOframework

Weintroduce theMOO frameworktodesignandimplement controlsoftwarethatemploysMOO.TheMOOframeworkemploys anapproachasdepictedinFig.3basedontheMOOarchitectural styleandtheMOOtoolchain.

TheMOOarchitecturalstyleprovidestheabilitytospecifya spe-cializedComponent-and-Connectormodel(Clementsetal.,2002) forthearchitectureofthecontrolsoftware.Themodel includes elementsoftheMOOsolution(decisionvariables,constraintsand objectivefunctions)inastructuredway,aspartofthe architec-turedescription.Werefertoanarchitecturalmodelthatiscreated accordingtotheMOOarchitecturalstyleasMOOarchitecturalmodel orMOOmodel.

Inadditiontothedecisionvariables,constraintsandobjective functions,thereexistcomputationallogicandphysical character-istics/modelsregardingthecontrolledsystemthatinﬂuencethe controlbehavior.TobeabletoanalyzeaMOOmodeland gener-ateanoptimizermodule,theseelementsshouldalsobespeciﬁed. Therefore, theMOO methodprovidesthepossibility torefer to modelsthat specify thecomputational logic(e.g., controllogic, implementedphysicalcharacteristics)ofcomponentsinthe archi-tecture.Inthiswork,weadopttheSIDOPS+languageofthe20-Sim toolset(Broenink,1997;Kleijn,2009),becauseofthesuitabilityof thislanguagetomodelcontrollogicandphysicalcharacteristics. ThemodelscreatedwiththeSIDOPS+languagearecalled20-Sim models.

AMOOmodeltogetherwiththe20-Simspeciﬁcationsare pro-vided asinput totheMOO toolchain.The toolchaincontains a graphicaleditor,whichisanextensionoftheArchStudio4toolset (Dashofyetal.,2007),tocreateandeditMOOmodels.TheMOO ConsistencyValidatorcheckstheconsistencyoftheMOOmodel.If theMOOmodelisconsistent,itcanbeprovidedtotheMOOcode generator,togenerateanoptimizermodulespeciﬁcforthegiven architectureandgivenMOOsolution.Thesoftwaremodulesthat implementthebasiccontrolarchitectureareprovidedtotheMOO codeweaver.Thecodeweavercomposesthesesoftwaremodules andthegeneratedoptimizermodulebyweavinginstrumentation inthesoftwaremodules.Theresultisembeddedcontrolsoftware thatincludesMOOfunctionality.ThenextsectionsexplaintheMOO architecturalstyleandtheMOOtoolchaininmoredetail.

(6)

5. MOOarchitecturalstyle

Inthissection,weintroducetheMOOarchitecturalstyle3 _for

documentingembeddedcontrol software architecturefromthe multi-objectiveoptimizationpointofview.Specificstylesfor con-trolsoftwarehavebeendevelopedbefore(Hofmeisteretal.,2000), liketheProcessControlstylesdescribedinShawandGarlan(1996). However,thesestylestakeamoregeneralviewoncontrol;they describethesystemintermsofacontrolledsystem,sensors, con-trollers and actuators. The MOO style is applicable to a more specifictypeoffunctionalityincontrolsoftware,multi-objective optimization,andthereforecanexpressspecificpropertiesofthis functionality.Inthefollowing,wefirstprovideabriefdescription oftheMOOstyle,usingthesamedescriptionstructureasusedin Clementsetal.(2002)todescribearchitecturalstyles.Then,the differentcharacteristicsofthestylearedescribed.

5.1. Styledescription • Elements:Component; • Interfaces:In-port,out-port; • Relations:Connector;

• Propertiesofelements:Componentimplementsthecontrollogic, consistingof,amongothers,controlalgorithmsandmodelsof physicalcharacteristics.Componentshavethefollowing proper-ties:

–20SimReference:Anoptionalreferencetoa 20-Simmodel. This20-Simmodeldescribesthecomputationallogicbetween thein-portsandout-portsofthecomponent.Ifthis computa-tionallogicisnecessarytoanalyzethespeciﬁedMOOsolution, areferencetoa20-Simmodelshouldbeprovided.Otherwise, itcanbeomitted.

–constraints:Alistofconstraintsonthevariables correspond-ingtotheportsofthecomponent.

–isOblivious:Aﬂagthatindicateswhetherthecomponent isoblivious.Thismeansthatthereisnosoftwaremodulethat implementsthecomponent:thecomponentisonlyusedfor specifyingtheMOOsolutiontobeprovidedtothetooling.4_If

theisObliviousﬂagisset,thecomponentshouldalwayshave areferencetoa20-Simmodel.

–subModelReference:AnoptionalreferencetoanotherMOO model. This represents encapsulation of MOO models, to providehierarchicalapplicationoftheMOOstyle.

• Propertiesofinterfaces:Aportcommunicatesthevalueofaspeciﬁc (physical)variable.Anin-portisusedbyacomponenttoreceive thevalueofavariablefromothercomponents.Anout-port is usedbyacomponenttocommunicate thevalueof avariable toothercomponents.In-portsandout-portshavethefollowing properties:

–variableName:Stringcontainingthenameofthe correspond-ing(physical)variable.

–constraints:Alistofconstraintsonthevalueofthisport. –isDecisionVariable:Aﬂagthatindicateswhetherthe

vari-ablecorrespondingtothisportisadecisionvariable(i.e.,the optimizationalgorithmmaydeterminethevalueoftheport). –isObjective: Aﬂag that indicatesthatthe variable

corre-spondingtothisport representstheoutcomeofone ofthe objectivefunctionsintheMOOproblem.

• Propertiesofrelations:SameastheC&Cviewtype(Clementsetal., 2002).

3 _In_the_parlance_of_IEEE₁₄₇₁_(Maier_et_al.,_2001),_the_MOO_{architectural}_style_can beregardedasaviewpoint.

4 _Hence_the_term_oblivious_component,_to_indicate_that_the_actual_{implementation} ofthesoftwareisnotawareofthiscomponent.

Table1

NotationoftheMOOstyle. Notation Description

Componentwithastereotypeandaname.Three stereotypesareavailable:Analyzable,Oblivious and SubModel.Ifacomponenthasareferencetoa20-Sim model,thenithasthestereotypeAnalyzable.Ifa componenthastheﬂagisOblivious set,thenithasthe stereotypeOblivious.Obliviouscomponentshaveby deﬁnitionareferencetoa20-Simmodel,sothestereotype Analyzable isomitted.Ifthecomponentreferences anotherMOOmodel(i.e.,hierarchicalcomposition),the stereotypeisSubModel.

◦ In-port

• Out-port

In-port/out-portwiththeisDecisionVariable ﬂagset. In-port/out-portwiththeisObjective ﬂagset.

Usageofaport:Theportsthatbelongtoacomponentare attachedtotheedgeofthecomponent.Theportmaybe labeledwithitsvariableName.

→ Connector

Informallabelindicatingthatthecomponentorporthas constraints.

• Topology:Connectorsconnectports.Thestart-pointofaconnector isalwaysanout-port.Theend-pointofaconnectorisalwaysan in-port.Thesemanticsof aconnectoristhat thevalueonthe end-pointoftheconnector(in-port)issettothevalueofthe start-pointoftheconnector(out-port).Anout-portcanbethe start-pointofmultipleconnectors.Anin-portcannotbethe end-pointofmorethanoneconnector.Eachconnectorfacilitates one-to-oneconnection.Onecanmakeuseofmultipleconnectorsto createmultipleconnections.

TheMOOstylehasalsoanotationtocreategraphical represen-tationsofMOOmodels.Thesegraphicalrepresentationsarecalled MOOviews.Table1showsthedifferentelementsofthenotation andFig.4showstheMOOviewofthearchitecturefortheWarm Processcasestudy.Thelabels1–5indicatethatconstraintshave beenaddedtothecorrespondingport/component.Thisexample MOOviewwillbeusedinthenextsubsectionstoillustratethe differentcharacteristicsofthestyle.

5.2. SpecifyingaMOOsolution

ThissubsectionexplainsthecharacteristicsoftheMOOstyle thatcanbeusedforspecifyingMOOconcernswithinasoftware architecture.

5.2.1. Portsprovidingdecisionvariablesandobjectivefunctions PortshavetheflagsisDecisionVariableandisObjective. BysettingtheisDecisionVariableflag,adesignerindicatesthat theportrepresentsadecisionvariable.Thismeansthatthe opti-mizationalgorithmmaychoosethevalueontheport.Iftheport alsogetsavaluefromaconnector(incaseofanin-port)ora compo-nent(incaseofanout-port),thevalueprovidedbytheoptimization algorithmoverridesthevalueprovidedbytheconnectororthe component.Fig.4showstwoportswiththeisDecisionVariable flagset:Thein-portT_phspofthePaper Heater Controller compo-nentandtheout-port

v

ofthePaper Pathcomponent.Thismakes thespeedandthesetpointofthepaperheaterthetwodecision variablesintheMOOmodel.

BysettingtheisObjectiveﬂag,adesignerindicatesthatthe valueontheportrepresentstheoutcomeofanobjectivefunction. Fig.4showstwoportswiththeisObjectiveﬂagset:The out-portPtotal ofthePowercomponentandtheout-portproductivity

(7)

System I/O

Paper Path v 1 «Analyzable» PrintQuality Tcontact Tph v «Analyzable» Belt Temperature Prad Tcontact Tbelt v «Analyzable» Paper Heater Controller Tph Tspph Pph «Analyzable» Radiator Controller Tcontact Tsp contact Prad 2 «Oblivious» Productivity v «Oblivious» Power Prad Pph 4

Pph Pph Tph Tbelt Prad Prad v v Pavail

Pavail

3

Ptotal productivity

5

Fig.4. MOOmodeloftheWarmProcesscasestudy.

oftheProductivitycomponent.Thismeansthattherearetwo objectivesinthesystem:totalpowerconsumptionand productiv-ity.NotethatthisMOOmodeldoesnotspecifyatrade-offfunction betweenthetwoobjectives.

5.2.2. Constraints

Componentsandportshavethepropertyconstraints,which contains a list of constraints. Component constraints provide a constraint among the values on the component’s ports (e.g., Ptotal≤Pavail).Portconstraintsonlyconstrainthevalueonthat spe-ciﬁcport.Assuch,everyconstraintisassociatedwiththerelated architecturalelementdirectly.

IntheMOOviewshowninFig.4,therearefourports(labeled 1,2,3and5)thathaveconstraintsandonecomponent(labeled4) thathasconstraints.Theseﬁveconstraintsare:

1Port:

v

(a)value≥60 (b)value≤120 2Port:Prad (a)value≥0 (b)value≤800 3Port:Pph (a)value≥0 (b)value≤1200 4Component:Power (a)Ptotal≥0 (b)Ptotal≤Pavail 5Port:T_phsp (a)value≥50 (b)value≤90

Thetwoconstraintsontheout-portthatislabeled1provide boundaries on the speed. The two constraintson the out-port labeled2 provideboundaries onthepowergiven tothe radia-tor.Notethattheoptimizerisabletoinﬂuencethevalueonthis out-port byadjustingthespeed;thecontrollogicimplemented withincomponentsPrint QualityandRadiator Controller relatespeedtothevalueontheout-portlabeled2,i.e.,thepower giventotheradiator(Prad).Thetwoconstraintsontheout-port labeled3constrainthepowergiventothepaperheater.Itcanbe inﬂuencedbythedecisionvariableT_phsp.Thetwoconstraintsonthe Powercomponentlimitthepowerconsumptionofthesystemto theamountofpoweravailable.Thetwoconstraintsonthedecision variableT_phspgiveboundariesforthisdecisionvariable.

5.2.3. 20-Simreference/analyzablecomponent

In a MOOmodel, constraintsand objectivefunctionscan be specifiedusingvariables(i.e.,ports)otherthanthedecision vari-ables.However,thereshouldbecomputationallogicimplemented in the components that provides mathematical relationships betweenthedecisionvariablesandtheothervariablesusedaspart ofconstraintsandobjectivefunctions.Otherwise,theconstraints andobjectivefunctionscannotbeinfluencedbythedecision vari-ables.TobeabletoanalyzetheMOOmodel,itshouldincludethese mathematicalrelationships.Therefore,thecomponentsofaMOO modelhaveaproperty20SimReference.Thispropertycanbeused tomakeareferencetoa20-Simmodelthatspecifiesthe computa-tionallogic(e.g.,amodelofphysicalcharacteristicsorcontinuous controllogic)ofthecomponent.Itisnotnecessarytoincludea 20-Simmodelforeachcomponent.Suchamodelshouldbeincluded onlyforcomponentsthatrelateconstraintsandobjectivefunctions tothedecisionvariables.

(8)

Fig.5. Overviewofthetoolchain.

Fig.4 shows fourcomponents withstereotypeAnalyzable. Theirreferenced20-Simmodelscontainthephysicalrelationships explainedinSection3.2.

Fig.4alsoshowstwoobliviouscomponents:Powerand Pro-ductivity. The purpose of thesecomponents is to model the objectivefunctionsandtomodeltheconstraintthatthepower con-sumptionofthesystemislimitedtotheamountofpoweravailable. ThePowercomponentreferencesa20-Simmodelcontainingthe equation:Ptotal=Pph+Prad. TheProductivity component refer-encesa20-Simmodelcontainingtheequation:productivity=1/v.5

Inthefollowingsection,weintroducetheMOOtoolchainthat cananalyzeaMOOmodelandgeneratecodeforrealizationof opti-mizedcontrolinembeddedsoftware.

6. MOOtoolchain

Fig.5showsanoverviewoftheMOOtoolchain.Thefigureshows severalartifactsandanumberof(automated)processesthat con-sume/generatecertain(intermediate)artifacts.Oneoftheartifacts istheMOOmodelthatistheinputtothetoolchain.TheMOOmodel canbeeditedbytheMOOModelEditor.Thiseditorisanextensionof Archstudio(Dashofyetal.,2007).Itprovidesagraphicalmodeling environmenttocreateandedit MOOmodels.MOOModelEditor parsesthestored MOOmodelsand SIDOPS+specifications (con-taining20-Simmodels)togenerateamathematicalrepresentation oftheMOOmodel,includingthesemanticsfromthereferenced 20-Simspecifications.Thismathematicalrepresentationisusedby theConsistencyValidatortochecktheconsistencyoftheMOO solu-tion.IftheMOOsolutionisconsistent,theCodeGeneratorgenerates anoptimizationsoftware module,basedonapredefined/selected

5 _Strictly_following_the_mathematical_deﬁnition,_the_goal_of_MOO_is_to_minimize theobjectivefunctions.Therefore,productivityisexpressedastheinverseofspeed: higherspeedleadstoaloweroutcomeoftheproductivityobjectivefunction.

optimizationalgorithm6_and_the_speciﬁc_MOO_problem_provided_by

themathematicalrepresentation.Thisoptimizationmoduleneeds tointeractwiththesoftwaremodulesthatimplementthebasic controllogic,toobtainvaluesofcertain(physical)variablesandto inﬂuencethedecisionvariables.TheCodeWeaverweavesthis inter-actionintothecontrolsoftwaremodules.Thisresultsinembedded controlsoftware that includesMOO functionality. Thedifferent tools/processes/artifactsin theMOO toolchain are discussed in detailinthefollowingsubsections.

6.1. MOOModelEditor

TheArchstudiotoolsuite(Dashofyetal.,2007)offersa graph-icaleditor forComponent-and-Connector models.We extended thistoolsuitetoobtainagraphicaleditorforMOOmodels.Fig.6 presentsascreenshotoftheextendedArchstudiotooling,showing astructuraldiagramthatrepresentstheMOOmodelinFig.4.

Archstudiostoresthearchitecturalmodelsinanarchitecture descriptionlanguagecalledxADL(Dashofyetal.,2001).xADLisan XML-basedarchitecturedescriptionlanguagethatisdeﬁnedusing anXMLschema.ThexADLschemacanbeextendedtobeableto expressnewelementsandpropertiesinanarchitecture descrip-tion.WeextendedxADLtobeabletoaddthedifferentelements oftherealizedMOO(decisionvariables,constraintsandobjective functions)tothecomponentsandportsinthestructuraldiagrams ofxADL.TheextensionisspeciﬁedintheformofaXMLschema(de Roo,2012)conformingtotheMOOarchitecturalstyle.

6.2. Derivingamathematicalrepresentation

Thissubsectiondescribesthemathematicalrepresentationofa MOOmodel(togetherwiththe20-simmodelsreferredbyits com-ponents),andexplainshowthisrepresentationiscreated.Thebasic

6_The _current _toolset _uses _Matlab _libraries _(Find _minimum _of _constrained nonlinearmultivariablefunction,2013)foroptimization.Inprinciple,any optimiza-tionalgorithm/approachcanbeused.

(9)

Fig.6.ScreenshotoftheMOOModelEditor.

modeloftherepresentationiscalledaderivationgraph.A deriva-tiongraphofaphysicalmodelisadirectedgraphthatreﬂectshow thevaluesofthephysicalvariablesarederivedfromoneanother. AformaldeﬁnitioncanbefoundindeRoo(2012).Thederivation graphiscreatedintwosteps:

1AderivationgraphofeachcomponentintheMOOmodelis cre-ated.

2Thederivationgraphsofthecomponentsarecombinedaccording totheconnectionsbetweenthecomponentsintheMOOmodel. Thesetwostepsareexplainedinthefollowing.Forbothsteps, weapplystandarddata-ﬂowanalysistechniques.

Step1.Creatingacomponent’sderivationgraph.Thederivation graphofacomponentiscreatedusingthefollowingprocedure:

Step1a.Createthe dependencygraph.Adependencygraphisa directedgraphthatrelatesvariablesandequationsinaphysical modeltoeachother.AformaldefinitioncanbefoundindeRoo (2012).IfthecomponentreferencesaSIDOPS+specification,this specificationisparsedandthecorrespondingdependencygraphis created(deRoo,2012).

Fig.7showsanexamplecomponent,twoequationsfromthe component’sreferredSIDOPS+speciﬁcationandaconstraintofthe component.Fig.8showsthedependencygraphthatiscreatedfor thisexample.

Step1b.MatchportstovariablenodesEachportofacomponent correspondstoavariable.Thevariablenodesinadependencygraph

Fig.7. Examplecomponent,SIDOPS+speciﬁcationandcomponentconstraint.

d e eq1 b c a eq2 f KEY: Equation Node Variable Node Relationship

Fig.8. Dependencygraphcorrespondingtotheexamplecomponentand speciﬁca-tioninFig.7.

alsocorrespondtovariables.Usingnamematchingofthe corre-spondingvariables,portsofthecomponentarematchedtovariable nodesinthedependencygraph.Foreachportthathasno match-ingvariablenodeinthedependencygraph,anewvariablenodeis addedtothedependencygraph.7

The result of this step is the relationship portMatch-ing:ports→vNodes.Thisrelationshipisusedbyotherprocessesin theMOOtoolchain.Fig.9showsthematchingofthecomponent’s portstothevariablenodesinthedependencygraph.Theout-port forvariablegdidnothaveacorrespondingvariablenode.Therefore, anewvariablenodeisaddedtothedependencygraph.

Step 1c. Handling component’s constraints. A component can haveconstraintsattached.8_These_constraints_should_be_reﬂected

inthecomponent’sdependencygraph.Toincludeacomponent’s

7_This_means_that_the_variable_{corresponding}_to_the_port_is_not_used_in_the SIDOPS+speciﬁcation.Notethatthisdoesnotmeanthatthecomponent’s imple-mentationdoesnotuse(incaseofin-ports)orcompute(incaseofout-ports)the valuesofthatport.TheSIDOPS+modelofacomponentonlyneedstoincludethe partofthesemanticsthatrelatesconstraintsandobjectivefunctionstothedecision variables.Therefore,themodelmayleaveoutunimportantrelationships,inthisway excludingcertainvariables.

8_Constraints_can_also_be_attached_to_ports._Constraints_on_ports_only_constrain thevariablecorrespondingtothatport,noothervariables.

(10)

g d e eq1 b c a eq2 f

KEY

:

Port

Variable

Node

mapping

«Analyzable Component»

C

a b c e

f g

Fig.9. Matchingofportstovariablenodes.

constraintCCiinthecomponent’sdependencygraph,thefollowing approachisadopted:

1TheconstraintCCiisrewritteninoneofthefollowingforms: (a)expressionCCi<0,for‘greaterthan’and‘lessthan’constraints.

Forexample,g<a*bbecomesg−a*b<0.

(b)expressionCCi<=0, for ‘greater than or equal to’ and ‘less thanandequalto’constraints.Forexample,c≥a+bbecomes a+b−c≤0.

(c)expressionCCi=0, for equality constraints. For example, b+c=dbecomesb+c−d=0.

2A structure reﬂecting the mathematical equation

cci=expressionCCi is added to the dependency graph. In this equation,cciisa newvariable.expressionCCi istheexpression formedinthepreviousstep.Thestructurethatisaddedtothe dependencygraphconsistsofanequationnode,whichreﬂects expressionCCiandavariablenode,whichreﬂectscci.

3Dependingonthetypeoftherewrittenconstraintintheﬁrst stepofthisapproach,theccivariablenodeisannotatedwiththe constraintvalue<0,value<=0orvalue=0.Themappingfromthe constrainttothevariablenodeisaddedtotherelationship con-straintMatching:constraints→vNarch.Thisrelationshipisusedby otherprocessesintheMOOtoolchain.

Fig.10 shows the component’sdependencygraph extended withanequationnodeCC1 andavariablenodecc1 forthe con-straint. The constraint g≤a*b is rewritten as g−a*b≤0. The equationnodeCC1reﬂectstheequationcc1=g−a*b.Thecci vari-ablenodegetsannotatedwiththeconstraintvalue≤0.

Step1d.Transformthedependencygraphtothederivationgraph. Thedependencygraphonlyspeciﬁesthedependenciesbetween variablesasspeciﬁedbythe20-Simmodel.Itdoesnotrepresent howthevaluesofcertainvariablesarederivedfromthevaluesof othervariables.Forthispurpose,aderivationgraphiscreated(de Roo,2012).Thevariablenodesthatprovidetheinputforthe deriva-tionarethose variablenodesthatmatch withthecomponent’s in-ports.Fig.11showsthecomponent’sderivationgraph,which iscreatedfromthedependencygraphinFig.10.Thegraphshows thatthein-portslabeleda,b,candeareindependentvariablesfor equationseq1andeq2.Furthermore,thedependentvariabledof

eq1isanindependentvariableforeq2.Thedependentvariableof eq2isf,whichisanout-portofthecomponent.

Step2.ConstructingthederivationgraphfortheentireMOOmodel. SupposeGisthesetofderivationgraphsofthecomponentsina MOOmodel.Thederivationgraphgarch=(vNarch,eNarch,Earch)for theentireMOOmodelisthencreatedbycombiningthederivation graphsinG,asfollows:

1ThesetofvariablenodesinthederivationgraphoftheMOO modelistheunionofthesetsofvariablenodesinthederivation graphofeachcomponent:vNarch=

gi=(vNi,eNi,Ei)∈GvNi. 2ThesetofequationnodesinthederivationgraphoftheMOO

modelistheunionofthesetsofequationnodesinthederivation graphofeachcomponent:eNarch=

gi=(vNi,eNi,Ei)∈GeNi. 3Thesetofedgesisconstructedintwosteps:

(a)First,createtheunionofthesetsofedgesinthederivation graphofeachcomponent:Earch=

gi=(vNi,eNi,Ei)∈GEi. (b)Foreach connectorinthearchitecture:supposethe

corre-sponding out-port has matchingvariable noden1∈vNarch andthecorrespondingin-porthasmatchingvariablenode n2∈vNarch,thenadd(n1,n2)toEarch.9

4TheportMatchingmappingfortheMOOmodeliscreatedby tak-ingtheunionoftheportMatchingmappingsforeachcomponent: portMatchingarch=

iportMatchingi.The portMatchingmapping isstillneededtobeabletorelatenodesinthegraphbackto portsintheMOOmodel.

5TheconstraintMatchingmappingfortheMOOmodeliscreated bytakingtheunionoftheconstraintMatchingmappingsforeach component:constraintMatchingarch=

iconstraintMatchingi.

Fig.12showsthederivationgraphcreatedfortheexampleMOO modelfortheWarmProcesscasestudy.Thederivationgraphs cre-atedforthedifferentcomponentsareindicatedbydashedboxes.

9_Note_that_the_in-port_and_out-port_attached_to_a_connector_always_have_a corre-spondingvariablenode.

(11)

g d e eq1 b c a eq2 f

KEY

:

Equation

Node

Variable

Node

Relationship

CC1 cc1 {value ≤ 0}

{...}

Annotation

Fig.10.Dependencygraphextendedwiththecomponent’sconstraint.

KEY

:

Equation

Node

Variable

Node

Derivation

g d e eq1 b c a eq2 f CC1 cc1

Fig.11.Thecomponent’sderivationgraph.

6.3. MOOConsistencyValidator

The MOO Consistency Validator analyzes a MOO model to ensuretwoproperties:(i)whetheralltheconstraintsandobjective functionsareassociatedwithamathematicalrelationshipinterms ofthedecisionvariables.(ii)ifthereexistcomponentsthatneed tohaveareferencetoaSIDOPS+speciﬁcation(i.e.,20-Simmodel). Thecorrespondinganalysisstepsareexplainedinthefollowing. 6.3.1. Overallconsistencyanalysis

Ifeachconstraintand objectivefunctionhasamathematical relationshipwiththedecisionvariables,thenanoptimizerisable toinﬂuenceallconstraintsandobjectivefunctionsbychangingthe valuesofthesevariables.Inthisway,theoptimizercan guaran-teethesatisfactionoftheconstraintsandtheoptimizationofthe objectivefunctions.10_The_MOO_Consistency_Validator_ensures_this

intwosteps.

First,theMOOConsistency Validatorperformsadependency analysisonthederivationgraphtodetectdependentvariablenodes.

10_Under_the_assumption_that_the_constraints_themselves_are_consistent,_i.e., feasi-bledesignspaceisnotempty.

Thesenodesareassociatedwithvariablesthatareinﬂuencedby oneormoredecisionvariables.Theanalysisisperformedby check-ingforeachvariablenodewhetherthereisapathtoitfromanother variablenodethatcorrespondstoadecisionvariable.Thealgorithm isstraightforwardandexplainedindetailindeRoo(2012).Fig.13 showsthesetofdependentnodesamongthevariablenodesofthe examplederivationgraphpreviouslyshowninFig.12.Theseare thenodesthatarereachablefromthedecisionvariablenodes(v andT_phsp)inthegraph.

Inthesecondstep,theMOOConsistencyValidatorchecksfor eachnodethathasconstraintsorthatistheoutcomeofan objec-tivefunction,whetheritisadependentnodeornot.Ifnot,this meansthatthereisnomathematicalrelationshipwiththe deci-sionvariables,soaninconsistencyhasbeendetected.Fig.13shows thatallvariablenodesthathaveconstraints(thevariablenodes labeled1–5)aredependentvariablenodes.Furthermore,the vari-ablenodesthatrepresenttheoutcomeofobjectivefunctions(Ptotal andProd)aredependentvariablenodes.Therefore,thespeciﬁed MOOmodelisconsistent.

6.3.2. DetectingwhichcomponentsneedaSIDOPS+speciﬁcation ToconstructaconsistentMOOmodel,someofthecomponents that takepartin the architectureshouldhave a reference toa

(12)

h f e Prad (curr) v (curr) Tbelt Tph Prad v Tbelt BeltT PQ Tph v v Tcontact Tcontact Rad contr Tcontact Tcontact SP Prad Pph Power Prad Ptotal Prod. Prod. v PH contr Tph Tph SP Pph a b c d g

a : Paper Heater Controller b : Radiator Controller c: Print Quality d : Belt Temperature e: Paper Path f : System I/O g: Power h : Productivity

KEY

:

Equation

Node

Variable

Node

Derivation

Pavail Pavail CC1 cc1 Pph (act) Prad (act) v (act) Pph (curr)

Fig.12.Derivationgraphfortheexamplearchitecture.

SIDOPS+speciﬁcation(i.e.,20-Simmodel).TheMOO Consistency Validatorchecksthispropertyasfollows.

First,astructuregraphoftheMOOmodeliscreated.Astructure graphshowsthepotentialrelationshipsbetweenportsasspeciﬁed bythecomponentsandconnectors.Thealgorithmforderivingthe structuregraphisstraightforwardandexplainedindetailindeRoo (2012).

Then,thefollowingstepsareperformedtoidentifytheneedfor areferencetoa20-Simmodelforeachportthathasconstraintsor thatistheoutcomeofanobjectivefunction,andforeach compo-nentthathasconstraints:

• Findall pathsin the structure graph fromany decision vari-ablenodetotheport/componentnode.Paths withcyclescan beexcluded,astheyarenotrelevantfortheresult.Supposethe resultisthesetpaths.

• Thereshouldbeatleastonepath_∈paths,forwhichallthe compo-nentsthatcorrespondtothecomponentnodesonthispathrefer toa20-Simmodel.Onlyinthiscaseamathematicalrelationship mightbepresentthatrelatestheconstraintsorobjectivefunction tothedecisionvariables.

6.4. MOOcodegenerator

MOOcode generatoris responsiblefor generatinga software modulethatcontainstheoptimizationfunctionalityspeciﬁcforthe givenembeddedcontrolsoftware.Thefollowingartifacts consti-tuteasinputtothetool:

• TheMOOmodel:mooModel.

• ThederivationgraphoftheMOOmodel.

• TheportMatchingrelationship,whichmatchesportsintheMOO modeltovariablenodesinthederivationgraph.

• TheconstraintMatchingrelationship,whichmatchescomponent constraintsintheMOOmodeltovariablenodesinthederivation graph.

• Thesetofdependentvariablenodes.

Theseartifactsareﬁrstanalyzedtoextractthesetofdecision variables,asetofconstraintsonthesedecisionvariablesandaset ofobjectivefunctionsregardingthesedecisionvariables.Detailed analysisproceduresareprovidedindeRoo(2012).Next,codeis generatedbasedontheextractedinformation.Thegeneratedcode performsthefollowingtasks:

1InformationforcertainpartsoftheMOOproblemstructureare collectedfrombasiccontrolcomponentsatruntime.This infor-mationcanbethevalueatacertainport(valueOf(aPort)),a valueinthestateofacomponent(valueInState(aVariable, aComponent)),oraresultofanexpressionina20-Simmodel. TheMOOcodeweaverinstrumentsbasiccontrolcomponentsto facilitateaccesstotheinformation.

2ProvidetheMOO problemstructure toan optimization algo-rithm(function).Theoptimizationalgorithm thendetermines aParetospaceorasingleoptimaloutcome(incasethereisa trade-offfunction).Thecurrentimplementationonlysupports the Matlab function fmincon (Find minimum of constrained

(13)

h f e Prad (curr) v (curr) Tbelt Tph Prad v Tbelt BeltT PQ Tph v v Tcontact Tcontact Rad contr Tcontact Tcontact SP Prad Pph Power Prad Ptotal Prod. Prod. v PH contr Tph Tph SP Pph a b c d g

a: Paper Heater Controller b : Radiator Controller c: Print Quality d : Belt Temperature e: Paper Path f : System I/O g : Power h : Productivity 1-5: Nodes with constraints

KEY

:

Equation

Node

Variable

Node

Derivation

Pavail Pavail CC1 cc1 Pph (act) Prad (act) v (act) Pph (curr)

Dependent

Variable

Node

1 2 3 4 5

Decision

Variable

Fig.13.Dependentnodesintheexamplederivationgraph.

nonlinear multivariable function, 2013) as an optimization algorithm.

3Setthedecisionvariablesinthebasiccontrolcomponentstothe resultoftheoptimization.

4Iterateovertheabovestepsatacertainfrequency(controlloop).

6.5. MOOcodeweaver

TheMOOcodeweavertoolinstrumentsthebasiccontrol compo-nents.TheoptimizationcodegeneratedbytheMOOcodegenerator usesthis instrumentation tocollectinformation fromthebasic control components and to set the optimized values for the decision variables. In this work, we assumethat get functions arealreadyavailabletoobtaintherequiredinformation. Aspect-orientedmechanismsareusedtointerceptcallstosetfunctions ofthedecisionvariablesandreplacetheargumentwiththevalue determinedbytheoptimizer.

Previously,a layeredarchitecture(Brunatoand Battiti,2010) hasbeenproposed, wheretheimplementationof the optimiza-tiontechniquesaremodularizedat thebottomlayer,providing optimizationfunctionalityasaservicetotheupperlayer(s).Even iftheimplementationofanoptimizationtechniqueis modular-ized, it needs to access and update several variables scattered throughouttheembeddedcontrolsoftware.Therefore,alayered structureisnotsufﬁcientforproperseparationofconcernssince thenecessaryinteractionsofanoptimizercrosscuttherestofthe

controlsoftware.Weemployspecializedaspectualconstructsfor modularizingsuchcrosscuttingconcerns(deRoo,2012).

7. Experimentationandevaluation

WeclaimthattheuseoftheMOOframeworkreduces devel-opmentandmaintenanceeffort,whilebeingabletoimplement controlsoftwarerealizingmulti-objectiveoptimization.Wemake thisclaimforthefollowingreasons.

First,ourapproachisautomatedend-to-endwithatoolset.The manualeffortislimitedtothespecificationoftheinputmodels. Even mostof these models (SIDOPS+specifications)are already beingspecifiedbydomainengineersand directlyreusedin our approach.

Second, theuseof theMOO architecturalstyle makes MOO an explicit part of the architecture models. Decision variables, constraints,trade-offsandtheirdependenciesareexplicitly rep-resented byports, connectorsand components of thesoftware architecture.Assuch, softwarearchitecturedesign directly sup-portstherealizationandmaintenanceofaMOOimplementation.

Third, our approach supports separation of concerns in a uniqueway.The controllogicand applicationspecificconcerns areimplementedinageneral-purposelanguage(GPL).The phys-icalphenomenaisdefinedwithaDSML.Ourtoolsautomatically compose(weave)artifactsdefinedinDSMLswith(into)software modulesdefinedinGPLs.Hence,twodifferenttypesofconcerns

(14)

Java

Control Software Implementation 1, 2, 3 or4

Matlab SimulinkSimulation

sensor values actuator values

Simulink Model

Warm Process Thermodynamics

Seed (scenario) Results

Fig.14. Simulationsetup.

areseparated.Inaddition,theyareimplementedwithdifferent lan-guagesthataremostappropriateforexpressingthecorresponding concerns.

WewerealsoconcernedwiththeimpactoftheMOO frame-workonqualityattributesotherthanmaintainability.Inparticular, customimplementationsofstate-of-the-practiceengineering solu-tionsmightbeconsideredbetterintermsofrun-timeperformance. It turns out that thecontrol software that is generated by the MOOframeworkactuallyperformsevenbetterthanthemanually implementedsystem.Toevaluateourframeworkinthisrespect, thissectiondescribesanexperimentbasedontheWarmProcess case study.We have developed an embeddedcontrol software implementationusingtheMOOframework.Thisimplementationis comparedwiththreeotherstate-of-the-practiceengineering solu-tionswithrespecttotheleveragedsystemproductivity,Wehave usedaMatlabSimulinkmodeltosimulatetheprinterhardware behaviorand employeddifferentsimulation scenariosinvolving alimitedand ﬂuctuatingamountofavailablepower.Inthe fol-lowing,weﬁrstdiscusstheexperimentalsetup,followedbythe implementationandresults.

7.1. Experimentalsetup

WehavedevelopedanexperimentalsetupbasedonaMatlab Simulink(MATLABSimulink,2012)modeloftheWarmProcess thermodynamics.Thismodelhasbeenprovidedbyourindustrial partner,andisarealisticmodelofarealprintersystem.Fig.14 showsthesetupofthissimulation.Thesimulationmodelcanbe seededwithavalueforthepseudo-randomnumbergeneratorthat determinestheamountofpoweravailableintheSimulinkmodel. Afterthesimulation,theresultsconcerningproductivitycanbe obtained.

BesidestheSimulinkmodel of theWarmProcess,thesetup comprises one ofthe alternative controlsoftware implementa-tions.ThecontrolsoftwareisimplementedinJavaandincluded intheMatlabenvironment,whichnativelysupportsaJavavirtual machine.Thefollowing fourcontrolimplementationsaretested andcompared11_:

1MOO:AnimplementationcreatedwiththeMOOframework. 2IntelligentSpeed:TheIntelligentSpeedalgorithm(deRoo,2012)is

thestate-of-the-practiceapproach,aswehavelearnedfromour industrialpartner.Thisalgorithmworksasfollows.Theamount ofpowerthatisnotutilized(Pmargin)iscalculated.WhenPmargin ittoolow,speedisdecreasedby20ppm.WhenPmarginishigher thanacertainboundary(200W),thenthespeedisincreasedby anamountthatisproportionaltotheactualvalueofPmargin. 3Intelligent Speed 2: This is a variant of the Intelligent Speed

algorithm. TheIntelligent Speed algorithmdoesnot optimize thepowermarginPmarginto0W.Instead,itmaintainsacertain

11 _Further_details_about_these_{implementations}_can_be_found_in_de_Roo_(2012).

amountofmargin(varyingbetween0Wand200W)tocopewith suddendropsintheamountofpoweravailable.Inthe exper-iment,sucha marginresultsinlower productivity,asnotall theavailablepowerisutilized.Tomakeafaircomparisonwith respecttotheMOOimplementation,whichoptimizesforapower margin(Pmargin)of0W,wealsotestasecond,adapted implemen-tationoftheIntelligentSpeedalgorithm,calledIntelligentSpeed 2(deRoo,2012).ThisalgorithmadaptsspeedtooptimizePmargin toapproximately0W.

4EcoMode:TheEcoModealgorithm(deRoo,2012)employsa strat-egyasfollows;iftheamountofavailablepowerissufﬁcientto printatthehighestspeed(120ppm),thenprintingisperformed atthehighestspeed.Otherwise,printingisperformedatlowest possiblespeed(60ppm).

Thefollowing settings and conﬁgurationsare usedwiththe experimentalsetup:

• Tcontactismaintainedatthesetpointdeterminedbythe Print-Qualityphysicalmodel(Eq.(1)).

• Thespeedofthesystemcanvarybetween60and120ppm.Itis assumedthatthespeedcanbechangedinstantaneously. • Thepaperheatertemperature(Tph)iscontrolledtoitsdeﬁned

setpointaslongasthespeedandtheavailablepowerpermit. • 11scenariosaretestedwithﬁxedamountofpoweravailable.

Hereby,theamountofpoweravailablevariesinﬁxedstepsof 50Wfrom700W(minP)to1200W(maxP).

• 20 scenarios are tested with fluctuating power. Hereby, the amountofpoweravailablefluctuatesbetweenanamount suf-ficienttoprintatthehighestspeed(maxP)andanamountbarely sufficienttoprintatlowestspeed(minP).Eachscenarioiscreated usingapseudo-randomgeneratorwhichprovidesaneven distri-butionbetweenminPandmaxP.Experimentsareperformedfor thefollowing7differentfluctuationintervals(i.e.,theinterval afterwhichtheamountofavailablepowerchanges):10s,25s, 50s,100s,250s,500s,and1000s.

• Foreachtestedscenario,thesimulationrunsfor20,000timesteps (i.e.,simulatedseconds).

7.2. Experimentresults

Thissectionpresentstheresultsof theexperiment.Thefour differentimplementationsarecomparedaccordingtothefollowing fourcriteria:

• Productivity:Theaveragespeedofthesystem,inpagesperminute (ppm).

• Energyconsumption:Theaverageenergyconsumedperprinted page,inJ/page.

• Powermargin:Theaveragepowermargin(thedifferencebetween theavailableandtheconsumedpower),inW.

• PrintQuality:Theaveragedeviationfromperfectprintquality,as deﬁnedbythePrintQualityphysicalmodel.

Figs.15–18showtheresultsoftheexperimentforeachofthese fourcriteria.Foreachofthesevenpowerﬂuctuationintervalsthe meanvalueoverthe20scenariosisshown.

Fig.15 shows theresultsfor thecriterion productivity. Here wecanseethatforlowerpowerfluctuationintervals,theMOO implementationperformssignificantlybetterthantheotherthree controlimplementations.FortheMOO,EcoModeandIntelligent Speedimplementation, theperformanceis stableforthe differ-entpower fluctuationintervals.However, theIntelligent Speed 2 implementation performs better with higher power fluctua-tionintervals,givingalmostthesameperformanceastheMOO

(15)

0 20 40 60 80 100 120 10 25 50 100 250 500 1000 Average speed (ppm)

Power ﬂuctuaon interval (s)

MOO Eco Mode Intelligent Speed Intelligent Speed 2

Fig.15.Averageprintingspeed.

8,8 9,0 9,2 9,4 9,6 9,8 10,0 10,2 10,4 10,6 10,8 10 25 50 100 250 500 1000

Average Energy Consumpon (J/page)

Fig.16.Averageenergyconsumption(lower⇒better).

implementationforthehighesttwo powerﬂuctuationintervals (500sand1000s).

Fig. 16 shows the results for the criterion energy consump-tion.The ﬁgureshows that theMOO implementationperforms signiﬁcantly better than the Eco Mode and Intelligent Speed

implementation.TheIntelligentSpeed2implementationperforms betterwithhigherpowerﬂuctuationintervals.

Fig.17 shows theresultsfor thecriterion power margin. As expected, theaverage powermargin is high for theIntelligent Speedimplementation.TheEcoModeimplementationalsoshows

0 20 40 60 80 100 120 140 10 25 50 100 250 500 1000

Average Power Margin (W)

(16)

0,00 0,05 0,10 0,15 0,20 0,25 0,30 10 25 50 100 250 500 1000

Average Print Quality Deviaon

Fig.18.Averagedeviationfromprintquality(lower⇒better).

asigniﬁcantaveragepowermargin.Theaveragepowermarginof theIntelligentSpeed2implementationislowerforhigherpower ﬂuctuationintervals.TheMOOimplementationhasalowpower margin.NotethatthepowermarginoftheMOOimplementationis notnecessarily0,becauseforsomescenarios,thereismorepower availablethanneededtoprintatthehighestpossiblespeed.

Fig.18showstheresultsforthecriterionprintquality.Thefigure showsthattheEcoModeimplementationperformssignificantly worsethantheotherthreeimplementations.TheMOO implemen-tationperformsbetterthantheotherimplementations,exceptfor thelowestpowerfluctuationinterval.

Fig.19showstheaveragespeed(i.e.,productivity)ofthefour implementationsforthe11scenarioswithaconstantamountsof poweravailablewithineachscenario.Theﬁgureshowsthatwitha constantamountofpoweravailable,theproductivityofthe Intelli-gentSpeed2implementationisalmostthesameastheproductivity oftheMOOimplementation.TheIntelligentSpeedandEcoMode implementationperformless.

Fig.20showstheaveragespeed(i.e.,productivity)ofthefour implementationsforthe20testscenarioswithaﬂuctuation inter-val of 1000. The ﬁgure shows that the MOO implementation performsconsistently betterthan theEcoModeand Intelligent Speedimplementations.TheperformanceoftheIntelligentSpeed2 implementationisconsistentlyalmostthesameastheperformance oftheMOOimplementation.

7.3. Evaluation&discussion

Inthissubsection,wediscussexperimentresultsandcomment onasetofissueswehaveobserved.Firstofall,Figs.15and19 showsthatMOOimplementationhasthebestperformance con-cerningproductivityinallthetestedscenarios.Thedifferencewith theIntelligentSpeedandEcoModeimplementationsis consider-able,butthisismainlyduetothefactthattheseimplementations havelargepowermargins.TheIntelligentSpeed2 implementa-tionapproachestheperformanceoftheMOOimplementationfor largerpowerﬂuctuationintervals,asitminimizesthepower mar-gin.Forsmallerpowerﬂuctuationintervals,theIntelligentSpeed2 implementationisnotabletoperformasgoodastheMOO imple-mentation.

Alsoontheotherthree criteria,energy consumption,power margin and print quality, the MOO implementation performs equallywellorbetterthantheotherthreeimplementations.So, wecanconcludethattheMOOframeworkleadstosystemsthatare abletofunctionatthesameorahigherlevelthansystemsapplying otherengineeringsolutionstooptimizeasystemquality. Addition-ally,theMOOframeworkprovidestheabilitytooptimizemultiple systemqualitiesanddynamicallymaketrade-offsbetweenthem.In thisway,solutionscreatedwiththeMOOframeworkdiffersfrom theothersolutions,whichtypicallyoptimizeforasinglesystem quality. 40 50 60 70 80 90 100 110 120 130 140 700 750 800 850 900 950 1000 1050 1100 1150 1200 Average speed (ppm) Power available (W) MOO Eco Mode Intelligent Speed Intelligent Speed 2

(17)

60 65 70 75 80 85 90 95 100 105 110 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Average speed (ppm) Scenario MOO Eco Mode Intelligent Speed Intelligent Speed 2

Fig.20.Performanceofthefourimplementationsconcerningproductivityfor20scenarioswithaﬂuctuatingpowersupply.

Inaddition,weobservedthatthecontrolsoftwarecreatedwith theMOOframeworkisabletoprovideapreciseandstablepower margin,as opposed toIntelligentSpeed algorithm, which gives anunpredictablemarginbetweentheamountofpoweravailable and the amountof powerconsumed (de Roo,2012).We have alsoobservedthattheEcoModeimplementationhasveryinstable speedbehavior:thesystemacceleratesanddecelerates continu-ously.Thisbehaviorisundesirablefromauserexperiencepoint ofviewanditincreaseswear-and-tearoftheprintersystem.Also, thefrequentspeedchangesleadtomoredeviationinprint qual-ity.Therefore,theEcoModeimplementationperformsworstwith respecttoprintquality,ascanbeseeninFig.18.Wehaveobserved smoothspeedtransitionsforMOO,IntelligentSpeedand Intelli-gentSpeed2implementations.Experimentalresultsanddetailed discussionsregardingtheseobservationscanbefoundindeRoo (2012).

Figs. 15 and 16 suggest that there is a reverse correlation betweenproductivityandenergyconsumedperprintedpage.This reversecorrelationcanbeexplainedfromthefactthattheprinter losesanamountofenergytotheenvironmentwhichisunrelated tothespeedofthesystem.Ifproductivityislower,theamountof energylosttotheenvironmentisattributedtolessprintedpages, leadingtoahigherenergyconsumptionperprintedpage.

8. Conclusionandfuturework

WehavepresentedtheMOOframework,todesignand docu-mentMOOwithinthearchitectureofembeddedcontrolsoftware. Thisframeworkhasanarchitecturalfocus,basedontheMOO archi-tecturalstyle.AMOOarchitecturalmodelthatconfirmstothisstyle definesessentialelementsofaMOOsolution(i.e.,decision vari-ables,constraintsandobjectivefunctions).ThetoolsoftheMOO frameworkcandetectinconsistenciesinthespecificationofthe MOOsolution.Ifthespecificationisconsistent,itisusedfor gener-atingtheimplementationofanoptimizer.Thetoolsalsoinstrument theimplementationofthecontrolsoftwarecomponents,toconnect thegeneratedoptimizertothecontrolsoftwarecomponents.This deliversanimplementationofMOOinembeddedcontrolsoftware. We have applied the approach in the context of an indus-trial case study from the printing systems domain. Results showedthatthecontrolsoftwaredevelopedwiththeMOO frame-work performs at least as good as, and typically better than state-of-the-practicesolutionstooptimizeproductivity.In addi-tion, theMOO framework enablesdynamic trade-offs between multiple objectives. Above all, the adoption of the MOO style

leverages better separation of concerns, modularity and main-tainability.Thestyleseparatestheimplementationofthecontrol logic and domainmodels that deﬁnephysical phenomena.The controllogicandthedomainmodelsarespeciﬁedindifferent lan-guagesandcanbemaintainedseparately.ThetoolsoftheMOO frameworkautomaticallycomposetheseartifacts.

Currently,theMOOarchitecturestylecapturesonlyastaticview (structureatruntime)oftheoptimizationprocess.Asfuturework, weareplanningtoextendthestylewithdynamicviews.Wealso wanttoextendthestyletoincludeprobabilisticdistributionsas constraints,astherelationshipsbetweendecisionvariablesmight notbealwaysexactlyknown.

Acknowledgements

ThisworkhasbeencarriedoutaspartoftheOCTOPUSproject undertheresponsibilityoftheEmbeddedSystemsInstitute.This projectispartiallysupportedbytheNetherlandsMinistryof Eco-nomicAffairsundertheEmbeddedSystemsInstituteprogram. References

Aleti,A.,Bjrnander,S.,Grunske,L.,Meedeniya,I.,2009. ArcheOpterix:an extend-abletoolforarchitectureoptimizationofAADLmodels.In:Proceedingsofthe WorkshoponModel-basedMethodologiesforPervasiveandEmbedded Soft-ware(MOMPES),pp.61–71.

Aleti,A.,Buhnova,B.,Grunske,L.,Koziolek,A.,Meedeniya,I.,2013.Software archi-tectureoptimizationmethods:asystematicliteraturereview.IEEETransactions onSoftwareEngineering,http://dx.doi.org/10.1109/TSE.2012.64.

Banker,R.D.,Datar,S.M.,Kemerer,C.F.,Zweig,D.,1993. Softwarecomplexityand maintenancecosts.CommunicationsoftheACM36,81–94.

Broenink,J.,1997.Modelling,simulationandanalysiswith20-sim.JournalA38(3), 22–25.

Brunato,M.,Battiti,R.,2010. Grapheur:asoftwarearchitectureforreactiveand interactiveoptimization.In:Proceedingsofthe4thInternationalConferenceon LearningandIntelligentOptimization.Springer-Verlag,Berlin,Heidelberg,pp. 232–246.

Calinescu,R.,Grunske,L.,Kwiatkowska,M.,Mirandola,R.,Tamburrelli,G.,2011. DynamicQoSmanagementandoptimizationinservice-basedsystems.IEEE TransactionsonSoftwareEngineering37(3),387–409.

Clements,P.,Garlan,D.,Bass,L.,Stafford,J.,Nord,R.,Ivers,J.,Little,R.,2002. Docu-mentingSoftwareArchitectures:ViewsandBeyond.Addison-Wesley,Boston. Collette,Y.,Siarry,P.,2003.MultiobjectiveOptimization:PrinciplesandCase

Stud-ies,1sted.Springer-Verlag,Berlin.

Dashofy, E.M.,Hoek,A.V.d., Taylor,R.N., 2001. Ahighly-extensible, xml-based architecturedescriptionlanguage.In:WICSA‘01:ProceedingsoftheWorking IEEE/IFIPConferenceonSoftwareArchitecture,IEEEComputerSociety, Wash-ington,DC,USA,p.103,http://dx.doi.org/10.1109/WICSA.2001.948416. Dashofy,E.,Asuncion,H.,Hendrickson,S.,Suryanarayana,G.,Georgas,J.,Taylor,R.,

2007.Archstudio4:anarchitecture-basedmeta-modelingenvironment.In:ICSE COMPANION’07:CompaniontotheProceedingsofthe29thInternational Con-ferenceonSoftwareEngineering,IEEEComputerSociety,Washington,DC,USA, pp.67–68,http://dx.doi.org/10.1109/ICSECOMPANION.2007.21.

(18)

de,A.R.,Sözer,H.,sit,M.A.,2009. Anarchitecturalstyleforoptimizingsystem qualitiesinadaptiveembeddedsystemsusingmulti-objectiveoptimization.In: JointWorkingIEEE/IFIPConferenceonSoftwareArchitecture,2009&European ConferenceonSoftwareArchitecture,WICSA/ECSA2009,Cambridge,UK,pp. 349–352.

deRoo,A.2012.Managingsoftwarecomplexityofadaptivesystems.Ph.D.Thesis. UniversityofTwente.

Eckenrode,R.T.,1965. Weightingmultiplecriteria.ManagementScience2(3), 180–192.

Ehrgott,M.,Gandibleux,X.,2002. MultipleCriteriaOptimization:StateoftheArt AnnotatedBibliographicSurveys.KluwerAcademicPublishing,Norwell, Mas-sachusetts.

Findminimumofconstrainednonlinearmultivariablefunction,2013.http://www. mathworks.nl/help/toolbox/optim/ug/fmincon.html(accessed2013). Geilen,M.,Basten,T.,Theelen,B.,Otten,R.,2007. Analgebraofparetopoints.

FundamentaInformaticae78(1),35–74.

Gnulinearprogrammingkit,2012.http://www.gnu.org/software/glpk/(accessed 2012).

Hofmeister,C.,Nord,R.,Soni,D.,2000. AppliedSoftwareArchitecture,1sted. Addison-WesleyProfessional,Reading,Massachusetts.

Hwang,C.,Yoon,K.,1981.MultipleAttributeDecisionMaking:Methodsand Appli-cations:AState-of-the-ArtSurvey,vol.13.Springer-Verlag,Berlin.

Keeney,R.L.,Raiffa,H.,1976. DecisionswithMultipleObjectives:Preferencesand ValueTradeoffs.JohnWiley&Sons,Inc.,NewYork.

Kleijn,C.,2009.20-Sim4.1ReferenceManual.

Li, R., Etemaadi, R., Emmerich, M.M., Chaudron, M.V., 2011. An evolu-tionary multiobjective optimization approach to component-based soft-warearchitecturedesign.In:IEEECongress onEvolutionaryComputation, pp.432–439.

lpsolve,2012.http://lpsolve.sourceforge.net/(accessed2012).

Lui,G.,Yang,J.,Whidborne,J.,2002. MultiobjectiveOptimisationandControl. ResearchStudiesPress,Baldock,Hertfordshire,England.

Maier,M.W.,Emery,D.,Hilliard,R.,2001. Softwarearchitecture:introducingIEEE standard1471.IEEEComputer34(4),107–109.

Marler,R.,Arora,J.,2004.Surveyofmulti-objectiveoptimizationmethodsfor engi-neering.StructuralandMultidisciplinaryOptimization26,369–395. MATLAB Simulink, 2012. http://www.mathworks.com/products/simulink/

(accessed2012).

Meedeniya,I.,Buhnova,B.,Aleti,A.,Grunske,L.,2010.Architecture-drivenreliability andenergyoptimizationforcomplexembeddedsystems.In:Proceedingsofthe 6thInternationalConferenceonQualityofSoftwareArchitectures. Springer-Verlag,Berlin,Heidelberg,pp.p52–67.

Octopusproject,2012.ESI.http://www.esi.nl/projects/octopus

Pareto,V.,1896.CoursD’ÉconomiePolitique.F.Rouge,Lausanne,Switzerland. Shaw,M.,Garlan,D.,1996. SoftwareArchitecture:PerspectivesonanEmerging

Discipline.Prentice-Hall,Inc.,UpperSaddleRiver,NJ,USA.

Sozer,H.,Tekinerdogan,B.,Aksit,M.,2011. Optimizingdecompositionofsoftware architectureforlocalrecovery.SoftwareQualityJournal,1–38.

Yoon,K.,Hwang,C.,1995. MultipleAttributeDecisionMaking:AnIntroduction. SagePublications,ThousandOaks,California.

ArjandeRooreceivedhisMScdegreeincomputersciencefromtheUniversityof TwenteintheNetherlandsin2007.HereceivedhisPhDdegreein2012fromthe sameUniversity.Currently,heisanindependententrepreneur.

HasanSözerreceivedhisBScandMScdegreesincomputerengineeringfromBilkent University,Turkey,in2002and2004,respectively.HereceivedhisPhDdegreein 2009fromtheUniversityofTwente,TheNetherlands.From2002until2005,he workedasasoftwareengineeratAselsanInc.inTurkey.From2009until2011,he workedasapost-doctoralresearcherattheUniversityofTwente.Heiscurrentlyan assistantprofessoratÖzye˘ginUniversity.

LodewijkBergmansisapart-timeAssistantProfessorattheComputerScience DepartmentoftheUniversityofTwenteinTheNetherlands.HeholdsanMScand PhDdegreefromthesameinstitute.Hehasampleindustrialexperiencein object-orientedsoftwareengineering,mostnotablyonanalysisanddesign,andsoftware architectureofembeddedsystems.Lodewijk’slong-termresearchgoalistoachieve adeeperunderstandingofsoftwarecomposition.Inaddition,Lodewijkworksatthe SoftwareImprovementGroup,wherehehelpsorganisationsmakingsoundIT deci-sions,throughafact-basedandmetrics-basedanalysisoftheirsoftwaresystems anddevelopmentprocesses.

MehmetAks¸itholds anMSc degreefromthe EindhovenUniversityof Tech-nology and a PhD degree from the University of Twente. Currently, he is workingasafullprofessorattheDepartmentofComputerScience,University ofTwenteandafﬁliatedwiththeinstituteCentreforTelematicsandInformation Technology.