IEEE COMPUTER 1 Developing Applications Using Model-driven Design Environments

DevelopingApplicationsUsingModel-driven

DesignEnvironments

KrishnakumarBalasubramanian,Member,IEEE,AniruddhaGokhale,Member,IEEE,GaborKarsai,Senior

Member,IEEE,JanosSztipanovits,Fellow,IEEE,andSandeepNeema,Member,IEEE

Abstract—Model-drivendevelopment(MDD)isanemergingparadigmthatimprovesthesoftwaredevelopmentlifecycle,particularlyforlargesoftwaresystemsbyprovidingahigher-levelofabstractionfordesigninganddevelopingthesystemthanispossiblewiththird-generationprogramminglanguages.TheMDDparadigmreliesontheuseof(1)Domain-SpecificModelingLanguagesthatincorporateelementsofthedomainbeingmodeledandtheirrelationshipasfirst-classobjects,and(2)modeltransformationsthattransformthemodelsintoplatform-specificartifacts,suchascode.ThispaperillustratesseveralkeycharacteristicsoftheMDDapproachthatdifferentiateitfromtraditionalsoftwaredevelopmentapproaches.Additionally,thepaperdescribesmeta-programmabletoolsusedtocon-structdomain-specifictool-suites,andprovidestwoexampletoolsuitesdrawnfromdifferentdomains.Thesetool-suitesare(a)PICML,whichsupportsthedevelopmentofstandards-compliantcomponent-basedapplications,and(b)ECSL,whichsupportssoftwaredevelopmentfordistributedembeddedcontrollers.IndexTerms—Model-IntegratedComputing,GME,CCM,CoSMIC,Deployment&Configuration

I.INTRODUCTION

H

ISTORICALLY,softwaredevelopmentmethodologieshavefocusedonimprovingtheindividualtoolslikeprogramminglanguages,muchmorethantoolsthatassistsystemcompositionandsystemintegration.Component-basedmiddlewarelikeEnterpriseJavaBeans,Microsoft.NETandtheCORBAComponentModel(CCM)havehelpedimprovethere-usabilityofsoftwarethroughtheabstractionofcom-ponents.However,assystemsarebeingbuiltmorefrequentlyusingcommercial-off-the-shelf(COTS)technologies,awidegaphasbeencreatedintheavailabilityandlevelofsophis-ticationoftoolsthathelpwithsoftwaredevelopmentlikecompilers,debuggers,linkersandvirtualmachines,asopposedtotoolsthatallowdeveloperstocompose,analyzeandtestacompletesystem,orsystemofsystems.Asaresult,thetaskofsystemintegrationcontinuestobeaccomplishedusingadhocmethodswithoutthesupportofautomatedtools.

Model-DrivenDevelopment(MDD)isanemergingparadigmwhichsolvesanumberofproblemsassociatedwiththecompositionandintegrationoflarge-scalesystemswhilealsoleveragingtheadvancesinsoftwaredevelopment,suchascomponent-basedmiddleware.ThefocusofMDDistoelevatesoftwaredevelopmenttoahigherlevelofabstractionthanthatprovidedbythirdgenerationprogramminglanguages.TheMDDapproachreliesontheuseofmodelstorepresentthesystemelementsofthedomainandtheirrelationships.In

ContactAuthore-mail:kitty@dre.vanderbilt.edu

TheauthorsarewithVanderbiltUniversity,Nashville,TN,USA.

MDD,modelsareusedinmostsystemdevelopmentactivities,i.e.,modelsserveasinputandoutputatallstagesofsystemdevelopmentuntilthefinalsystemisitselfgenerated.

ThispaperdescribesonevariantofMDDcalledModel-IntegratedComputing(MIC)[1],whichfocusesonusingDomain-SpecificModelingLanguages(DSMLs)torepresentsystemelementsandtheirrelationships,andtransformationsfromtheselanguagestoplatform-specificartifacts.WehavesuccessfullyappliedtheconceptofMICtodevelopanum-berofDSMLtool-suites.Inthispaperwewillfocusontwosuchtoolsuites:(1)Platform-IndependentComponentModelingLanguage(PICML),whichassistsdevelopersinthedevelopment,configurationanddeploymentofsystemsbuiltusingcomponentmiddlewaretechnology,suchasCCM;(2)EmbeddedControlSystemsLanguage(ECSL),whichsupportsdevelopmentofdistributedembeddedautomotiveapplications.

Bothofthesetool-suitesarebuiltusingtheGenericModelingEnvironment(GME)[2],anopen-sourcemeta-programmabledomain-specificdesignenvironment,whichal-lowsdevelopmentofbothDSMLsandthemodelsthatcon-formtotheseDSMLs,withinthesamegraphicalenvironment.AnotherpopularvariantofMDDistheObjectManage-mentGroup’sModel-DrivenArchitecture(MDA)[3],whichreliesonrepresentingsystemsusingtheUnifiedModelingLanguage(UML),ageneralpurposemodelinglanguage,andtransformingthesemodelsintoartifactsthatrunonavarietyofplatformslikeEJB,CCMand.NET.UnlikeMDA,whichfocusesontheuseofageneral-purposemodelinglanguagelikeUML(alongwithspecificprofiles),MICfocusesondevelopingmodelinglanguagesthataretailoredtoaparticulardomainofinterest.

Theremainderofthepaperisorganizedasfollows:Sec-tionIIdescribestheconceptofDSMLandthekeyele-mentsdefinedinit;SectionIIIdescribesPICMLandshowshowPICMLaddressesthechallengesinvolvedindevelopingcomponent-basedapplications;SectionIVdescribesECSLandshowshowECSLresolvesthechallengesindevelopingembeddedautomotiveapplications;SectionVcomparesourworkwithotherMDDframeworksandtools;andfinallySectionVIpresentsconcludingremarks.

II.DOMAIN-SPECIFICMODELINGLANGUAGES

DSMLsarethebackboneforrealizingthevisionofModel-IntegratedComputing(MIC),avariantofMDD.Onediffer-encebetweenothervariantsofMDDlikeMDAandMICis

IEEECOMPUTERtheemphasisonthe“domain-specific”aspectofthemodelinglanguages.ThissectionprovidesanoverviewofDSMLsandexplainsthestepsneededtocreateaDSML.A.OverviewofDSML

ThedomainofinterestofaDSMLcanrangefromsome-thingveryspecific,suchastheelementsofaradarsystem,orcanbeasbroadasthesetofallthecomponent-basedmiddlewareapplicationsbuiltusingplatformssuchasEJB,orCCM.ThekeyideabehindDSMLsistheirabilitytocapturetheelementsofthedomainasfirst-classobjects.

ADSMLcanbeviewedasafive-tuple[4]consistingof:1)ConcreteSyntax(C),whichdefinesthespecificno-tation(textualorgraphical)usedtoexpressdomainelements,

2)AbstractSyntax(A),whichdefinestheconcepts,re-lationshipsandintegrityconstraintsavailableinthelanguage,

3)SemanticDomain(S),whichdefinestheformalismusedtomapthesemanticsofthemodelstoaparticulardomain,

4)SyntacticMapping(MC:A→C),whichassignssyntac-ticconstructs(e.g.,graphicaland/ortextual)toelementsoftheabstractsyntax,and

5)SemanticMapping(MS:A→S),whichrelatesthesyntacticconceptstothoseofthesemanticdomain.Thustheabstractsyntaxdeterminesallthe(syntactically)correct“sentences”,i.e.,models,inthelanguage.ADSMLisalsoknownasa“metamodel”,sinceaDSMLis(itself)amodelthatdefinesallthepossiblemodelsthatcanbebuiltusingit.TosupportthedevelopmentofDSMLs,wehavede-velopeda“meta-programmable”modelingenvironmentcalledtheGenericModelingEnvironment(GME).B.CreatingaDSMLusingGME

DSMLsaredefinedvisuallyinGME.ThefollowingarethetypicalstepsincreatingaDSMLusingGME:

1.Identifyingthedomainelementsandtheirrelationships.ThefirststepincreatingaDSMListoidentifythedifferentelementsofthedomainthatwewanttomodel,andtheirrelationships.Thisisusuallydonewithinputfromadomainexpert.Itisunlikelythatalltheelementsaredefinedinasingleiteration.Justlikesoftwaredevelopment,MDDisalsoaniterativeprocess,andanyMDDtoolinfrastructureshouldallowmodificationoftheelements(orrelationshipsbetweenelements)withease.

2.MappingtheelementsofthedomaintoconceptsinGME.Sidebar1providesmoreinformationabouttheGMEconcepts.Oncewehaveenumeratedtheelementsofthedomain,weneedtomapthesedomainconceptstoGMEconceptslikeModels,Atoms,etal.ThisprocessisverysimilartodefiningthetypesinaprogramwhencodingusingalanguagelikeC/C++.

3.UsingGMEconcretesyntaxtorealizethemapping.WiththemappingofelementsofthedomaintoconceptsinGMEcomplete,thenextstepistousetheconcretesyntax

2

Sidebar1:GenericModelingEnvironment

GenericModelingEnvironment(GME)isanopen-source,visual,configurabledesignenvironmentforcreat-ingDSMLsandprogramsynthesisenvironments,availablefordownloadfromescher.isis.vanderbilt.edu/downloads?tool=GME.AuniquefeatureofGMEisthatitisameta-programmableenvironment.Bymeta-programmable,werefertothefactthatGMEisnotonlyusedtobuildDSMLs,butalsotobuildmodelsthatconformtoaDSML.Infact,theenvironmentusedtobuildDSMLsinGMEisitselfbuiltusinganotherDSML(alsoknownasthemeta-metamodel)called“MetaGME”.GMEprovidesthefollowingelementstodefineaDSML:

•Project,whichisthetop-levelcontainerinaDSML,•Folders,whichareusedtogroupcollectionsofsimilarelementstogether,

•Atoms,whicharetheindivisibleelementsofaDSML,andusedtorepresenttheleaf-levelelementsinaDSML,•Models,whicharethecompoundobjectsinaDSML,andareusedtocontaindifferenttypesofelementslikeReferences,Sets,Atoms,Connectionsetal.(theelementsthatarecontainedbyaModelareknownasparts),•Aspects,whichareprimarilyusedtoprovideadifferentviewpointofthesameModel(everypartofaModelisassociatedwithanAspect),

•Connections,whichareusedtorepresentrelationshipsbetweentheelementsofthedomain,

•References,whichareusedtorefertootherelementsindifferentportionsofaDSMLhierarchy(unlikeconnec-tionswhichcanbeusedtoconnectelementswithinaModel),

•Sets,whicharecontainerswhosecontainedelementsaredefinedwithinthesameaspectandhavethesamecontainerastheowner.

ofGME,i.e.,UMLclassdiagrams,tocapturetheelementsoftheDSMLasshowninFigure1.ItisimportanttonotethattheconcretesyntaxoftheelementsofyourDSML,i.e.,visualizationofelementsoftheDSML,isdefinedwhenyouaredefiningthetypesofyouryourDSML.GMEprovidestheabilitytocustomizetheconcretesyntax,i.e.,customizethevisualizationofelementsinyourDSML.CustomizationofvisualizationisdoneusingdecoratorsinGME.Adecoratorisacomponent(writtenusingatraditionalprogramminglanguage)thatimplementsasetofstandardcallbackinterfaces.OnceadecoratorisregisteredwithGME,GMEinvokesthecallbackswheneverGMEneedstodisplaytheelement.

4.DefiningstaticsemanticsoftheDSML.TheuseofUMLclassdiagramsasthenotationforconcretesyntaxofDSMLsinGMEallowscapturingsomesemanticsoftheassociationbetweenthedifferentelements.Thisisbecausesomesemanticslikecardinalityofassociationscanbesuffi-cientlyrepresentedusingthenotationsofferedbyUMLclassdiagrams.Forconstrainingtheassociationsbetweenelementsfurther,GMEprovidesabuilt-inconstraintmanager.GME’sconstraintmanagerallowsthedefinitionofconstraintsusingOMG’sObjectConstraintLanguage(OCL)[5]asshowninFigure2.ThesemanticsoftheDSMLthatareenforceableusingOCLcanbeviewedasstaticsemantics,sincetheydonottakethesystemdynamicsintoaccount.

IEEECOMPUTER3

Fig.1:RealizingthedomainmappingusingconcretesyntaxinGME

Fig.2:DefiningstaticsemanticsinGME

5.GeneratingtheDSMLenvironment.NowthatwehavedefinedtheelementsoftheDSMLandtheassociatedstaticsemantics,weinstructGMEtogenerateourcustomizedDSMLenvironment.Thisisdoneusingaprocesscalledmeta-interpretation.Meta-interpretationtakesthedefinitionoftheDSMLfromthepreviousstep,runsasetofstandardtransformations(whichensureconsistencyofthelanguage)justlikeatraditionalcompilerandcreatesaparadigm.Theparadigmfile,whichactuallydefinestheDSML,isthen

registeredwiththeGMEenvironment.ItisnowpossibletocreatemodelsthatconformtotheDSMLthatwehavebuiltusingGME.

6.DefiningdynamicsemanticsoftheDSML.Thoughwehavedefinedtheelements,relationshipsandthestaticsemanticsoftheDSML,itisnecessarytodefinedynamicsemanticstomaketheDSMLusefulforcomplexreal-worldapplications.DynamicsemanticsofaDSMLcanbeenforcedusinginterpreters.Aninterpreterisacomponentthatiswritten

IEEECOMPUTERusingatraditionalprogramminglanguagelikeC++,PythonorJava.InterpretersneedtoberegisteredwithGME.Whenaninterpreterisinvoked,itisgivenaccesstothemodelhierarchybyGME,andcanbeusedtoperformdifferentkindsofvalidationandgenerativeoperationsonthemodels.Onesuchoperationcanincludegeneratingplatform-specificartifactslikecodedirectlyfromthemodels.

III.APPLYINGMICTODEVELOPCOMPONENT-BASED

APPLICATIONSThissectiondescribesaDSMLcalledPlatform-IndependentComponentModelingLanguage(PICML).Firstwedescribethechallengesinsystemcompositionandintegrationwhenusingcomponent-middlewaretechnologieswithoutadequatetoolsupport.ThenwedescribehowwehaveappliedtheMDDapproachtodevelopPICML,andshowhowthefeaturesinPICMLhelpresolvethechallengeswithdevelopment,config-urationanddeploymentofcomponent-basedapplications.A.Component-basedApplicationDevelopmentChallengesAcommontrendinthetransitiontocomponentmiddlewaretechnologiesistheuseofmetadatatocapturepropertiesofapplicationsthatwerepreviouslytightlycoupledwiththeimplementation.Thisallowsdeclarativespecificationofpropertiesofapplicationsusingplatform-agnostictechnologieslikeXML,whicharereadbytoolsduringdeployment,andallowsforautomatingthedeploymentandconfigurationofapplications.

Theavailabilityofhigher-levelabstractionslikevirtualmachines,executioncontainers,andextrainformationaboutsystemsviarichmetadata,hasanindirecteffectinallowingpeopletobuildsystemsthataremoreheterogeneousthanpreviouslypossible.Thisresultsinanincreaseintheamountofinformationthatmustbemanagedbythesystemdeveloperaswellasanincreaseinthecomplexityofsystemintegra-tion.However,theinfrastructureformanagingsuchcomplexdeploymentwasessentiallylackinginpreviousgenerationmiddleware.Mostdeploymentsweredoneinanadhocbasisandtherewashardlyanyreuseofthedeploymentinfrastructure.Moreover,theseadhoctechniqueshadnobasisforscientificallyverifyingandvalidatingthecorrectnessofthesystem.Theamountofheterogeneityinthesystemsbeingdeployedwasalsolesscomparedtosystemsbuiltusingcomponent-basedmiddleware.Thelackofsimplificationandautomationinresolvingthechallengesoutlinedabovecansignificantlyhindertheeffectivetransitionto–andadoptionof–componentmiddlewaretechnologytodevelopsystems,therebynegatingthebenefitsofcomponentmiddlewaretech-nologies.

B.Platform-IndependentComponentModelingLanguageToaddresstheproblemsoutlinedabove,wehavedevelopedaDSMLcalledPlatform-IndependentComponentModelingLanguage(PICML).PICMLisanopen-sourceDSMLavail-ablefordownloadaspartoftheCoSMICMDDframeworkatwww.dre.vanderbilt.edu/CoSMIC.PICMLenables

4

developersofcomponent-basedsystemstodefineapplicationinterfaces,QoSparameters,andsystemsoftwarebuildingrules,aswellasgeneratemetadata,XMLdescriptorfiles,thatenableautomatedsystemdeployment.PICMLalsopro-videscapabilitiestohandlecomplexcomponentengineeringtasks,suchasmulti-aspectvisualizationofcomponentsandtheinteractionsoftheirsubsystems,componentdeploymentplanning,andhierarchicalmodelingofcomponentassemblies.Currently,PICMLisusedinconjunctionwiththeComponent-IntegratedACEORB(CIAO),ourCCMimplementation,andDeploymentandConfigurationEngine(DAnCE)[6],aQoS-enableddeploymentengine.However,PICML’sdesignhasbeendrivenbythegoaltoallowintegrationofsystemsbuiltusingdifferentcomponenttechnologieslikeMicrosoft.NETandEJB.

PICMLisdefinedasametamodelinGMEfordescribingcomponents,typesofallowedinterconnectionsbetweencom-ponents,andtypesofcomponentmetadatafordeployment.Fromthismetamodel,∼20,000linesofC++code(whichrepresentsthemodelinglanguageelementsasequivalentC++types)isgenerated.Thisgeneratedcodeallowsmanipulationofmodelingelements,i.e.,instancesofthelanguagetypesusingC++,andformsthebasisforwritingmodelinterpreters,whichtraversethemodelhierarchytogenerateXML-baseddeploymentplandescriptors(describedinSidebar2)neededtosupporttheOMGDeploymentandConfiguraion(D&C)specification[7].

Component PackageComponentComponentComponentComponentComponentComponentAssemblyAssemblyComponentComponentComponentComponent(3r)otCpnoHiireomrComponentciastpearorc PackagerDesih)ntiic4eo(GnalgComponentAssemblyonenComponentComponentoera(2) InteractionopsDeployerocmnComponentDefinitionyPICML(5) DeploymentplanningDeploymentbgAssemblynmnenComponentComponentsasapAssemblyspecificationComponent AssemblerDAnCEeFrameworkcanforitAssemblyeitnnifI eComponent)1D Developer(ComponentImplImplImplResourcePropertiesRequirementsFig.3:Model-drivenApplicationDevelopmentLifecycleFigure3showsthetypicalstepsinvolvedindevelopingcomponent-basedapplicationsusingPICML’sMDDapproach.Thefollowingdescribesthekeystepsincomponent-basedapplicationdevelopment,whiledescribingthefeaturesinPICMLusedinthisprocess:

1.Visualcomponentinterfacedefinition.Asetofcom-ponent,interfaceandotherdatatypedefinitionsdefinedviaCORBA’sInterfaceDefinitionLanguage(IDL)maybecreatedinPICMLusingeitherofthefollowingtwoapproaches:(1)AddingtoexistingdefinitionsimportedfromIDL.Inthisapproach,existingCORBAsoftwaresystemscanbeeasilymigratedtoPICMLusingitsIDLImporter,whichtakesanynumberofCORBAIDLfilesasinput,mapstheircontentsto

IEEECOMPUTERtheappropriatePICMLmodelelements,andgeneratesasingleXMLfilethatcanbeimportedasaPICMLmodel;(2)Cre-atingIDLdefinitionsfromscratch.Inthisapproach,PICML’sgraphicalmodelingenvironmentprovidessupportfordesign-ingtheinterfacesusinganintuitive“draganddrop”techniquemakingthisprocesslargelyself-explanatoryandindependentofplatform-specifictechnicalknowledge.CORBAIDLcanbegeneratedfromPICMLenablinggenerationofsoftwareartifactsinlanguageshavingaCORBAIDLmapping.

2.Validcomponentinteractiondefinition.ByelevatingthelevelofabstractionviaMDDtechniques,thewell-formednessrulesofDSMLslikePICMLactuallycapturesemanticinformation,suchasconstraintsoncompositionofmodels,andconstraintsonallowedinteractions.ThereisasignificantdifferenceintheearlydetectionoferrorsintheMDDparadigmcomparedwithtraditionalobject-orientedorproceduraldevelopmentusingaconventionalprogramminglanguagecompiler.InPICML,OCLconstraintsareusedtodefinethestaticsemanticsofthemodelinglanguage,therebydisallowinginvalidsystemstobebuiltusingPICML,i.e.,PICMLenforcesthecorrect-by-constructionapproachtosys-temdevelopment.

3.Hierarchicalcomposition.Inacomplexsystemwiththousandsofcomponents,visualizationbecomesanissuebecauseofthepracticallimitationsofdisplays,andthelim-itationsofhumancognition.Withoutsomeformofsupportforhierarchicalcomposition,observingandunderstandingsystemrepresentationsinavisualmediumdoesnotscale.Toincreasescalability,PICMLdefinesahierarchyconstruct,whichenablestheabstractionofcertaindetailsofasystemintoahierarchicalorganization,suchthatdeveloperscanviewtheirsystematmultiplelevelsofdetaildependingupontheirneeds.ThesupportforhierarchicalcompositioninPICMLnotonlyallowssystemdeveloperstovisualizetheirsystems,butalsoallowsthemtocomposesystemsfromasetofsmallersubsystems.Thisfeaturesupportsunlimitedlevelsofhierarchy(constrainedonlybythephysicalmemoryofthesystemusedtobuildmodels)andpromotesthereuseofcomponentassemblies.PICMLthereforeenablesthedevelopmentofrepositoriesofpredefinedcomponentsandsubsystems.ThehierarchicalcompositioncapabilitiesprovidedbyPICMLareonlyalogicalabstraction,i.e.,deploymentplansgeneratedfromPICMLflattenoutthehierarchytoconnectthetwodestinationportsdirectly(whichifnotdonewillintroduceadditionaloverheadinthecommunicationpathsbetweenthetwoconnectedports),therebyensuringthatatruntimethereisnoextraoverheadthatcanbeattributedtothisabstraction.4.Validdeploymentdescriptorgeneration.Inadditiontoensuringdesign-timeintegrityofsystemsbuiltusingOCLconstraints,PICMLalsogeneratesthecompletesetofdeploy-mentdescriptorsthatareneededasinputtothecomponentdeploymentmechanisms.ThedescriptorsgeneratedbyPICMLconformtothedescriptorsdefinedbythestandardOMGD&Cspecification[7].Sidebar2showsanexampleofthetypesofdescriptorsthataregeneratedbyPICML,withabriefexplanationofthepurposeofeachtypeofdescriptor.

5.Deploymentplanning.Systemsareoftendeployedinhet-erogeneousexecutionenvironments.Tosupporttheseneeds,

5

PICMLcanbeusedtospecifythetargetenvironmentwherethesystemwillbedeployed,whichincludesnodes,inter-connectsamongnodes,andbridgesamonginterconnects,allofwhichcollectivelyrepresentthetargetenvironment.OncethetargetenvironmentisspecifiedviaPICML,allocationofcomponentinstancesontonodesofthetargettargetenviron-mentcanbeperformed.PICMLcurrentlyprovidesfacilitiesforspecifyingstaticallocationofcomponents.

Sidebar2:DeploymentMetadata

PICMLgeneratesthefollowingtypesofdeploymentdescrip-torsbasedontheOMGD&Cspecification:

•ComponentInterfaceDescriptor(.ccd)–Describestheinterfaces–ports,attributesofasinglecomponent.•ImplementationArtifactDescriptor(.iad)–Describestheimplementationartifacts(e.g.,DLLsandexecutables)ofasinglecomponent.

•ComponentImplementationDescriptor(.cid)–De-scribesaspecificimplementationofacomponentinter-face;alsocontainscomponentinterconnectioninforma-tion.

•ComponentPackageDescriptor(.cpd)–Describesmultiplealternativeimplementations(e.g.,fordifferentOSes)ofasinglecomponent.

•PackageConfigurationDescriptor(.pcd)–Describesacomponentpackageconfiguredforaparticularrequire-ment.

•ComponentDeploymentPlan(.cdp)–Planwhichguidestheruntimedeployment.

•ComponentDomainDescriptor(.cdd)–Describesthedeploymenttargeti.e.,nodes,networksonwhichthecomponentsaretobedeployed.

IV.APPLYINGMICTODEVELOPEMBEDDEDAUTOMOTIVE

APPLICATIONS

Embeddedautomotivesystemsarebecomingnotoriouslydifficulttodesignanddevelop.Overthepastyearstherehasbeenanexplosioninthescaleandcomplexityofthesesystems,owingtoapushtowardsdrive-by-wiretechnologies,increasingfeaturelevels,andincreasingcapabilitiesintheem-beddedcomputingplatforms.Inordertoaddressthislevelofcomplexity,theautomotiveindustryhasingeneralembracedthemodel-basedapproachforembeddedsystemsdevelopment.However,theapproachisconfinedtoonlythefunctionalaspectsofthesystemdesign,andrestrictedtoalimitedsuiteoftools,mostnotablytheMathworksfamilyofMatlab®,Simulink®(SL),Stateflow®(SF)tools.Undeniably,SimulinkandStateflowareverypowerful,graphicalsystemdesigntoolsformodelingandsimulatingcontinuousanddiscreteevent-basedbehaviorofadynamicsystem.However,thesetoolsbynomeanscovertheentirespectrumofembeddedsystemsdevelopment.Thereareseveralothercomplexactivitiessuchasrequirementsspecification,verification,mappingontoadistributedplatform,scheduling,performanceanalysis,andsynthesisintheembeddedsystemsdevelopmentprocess.Althoughtherearetoolswhichindividuallysupportoneormoreoftheseotherdevelopmentalactivities,theintegrationamongthesetoolsandtheMathworksfamilyoftoolsis

IEEECOMPUTERoftenlacking,whichmakesitextremelydifficulttomaintainaconsistentviewofthesystemasthedesignprogressesthroughthedevelopmentprocess,andalsorequiressignificantmanualeffortincreatingdifferentrepresentationsofthesamesystem.Toaddressthedeficienciesinthedevelopmentprocessfordistributedautomotiveembeddedsystems,webuilttheEmbeddedControlSystemsLanguage(ECSL)thatprovidestheabilitytoimportexistingSL/SFmodelsintoaGMEenvironment,andsupports:(1)Theannotationofstructuraldesign,SW-componentdesign,andbehaviorimplementationtosupplyinformationneededbyacodegenerator,(2)Cre-ationofHW-topologydesignmodels,ElectronicControlUnit(ECU)-designmodels,andfirmwareimplementationdesignmodels,and(3)Creationofdeploymentmodelsthatcapturecomponentandcommunicationmapping.A.EmbeddedSystemDevelopmentusingECSL

Figure4depictstheconceptualviewofactivitiesinanautomotiveembeddedsystemsdevelopmentprocess,assup-portedbytheECSLtools.Eachroundedblockdenotesaparticularactivityandarrowsindicatetheworkflowbetweendifferentactivities.Activitiescanroughlybegroupedinthreeblocks:HardwareDesign,SoftwareDesign,andMapping.RequirementsEngineeringisnotwithinthescopeofthistool-suite,althoughitisthebasisformostofthemodelinganddevelopmentactivities.

Requirements Analysis

Hardware DesignSoftware Design(Refinement)HW-TopologyDesign

StructuralDesign

FS/ECU-Design

SW-ComponentDesign

LSLMappingSCML2ECSL

EComponent/EFirmwareMapping

BehaviorMGImplementation

Implementation

Communication

Mapping

FirmwareCode Generation

ECU IntegrationBehaviorCode GenerationSystem Code

Generation/Integration

Code Generation

ECSL/CG

Fig.4:ECSLProcess

SoftwareDesigndealswith:a)Structuraldesign,whichreferstothehierarchicaldecompositionoftheembeddedsystemintosubsystemsandsub-subsystems,fromafunctionalviewpoint,b)Componentdesign,whichisanotherformofdecompositionnotindependentofthefunctionaldecomposition,dealswithmoreoftheclassicalembeddedsoftwareconcernssuchasreal-timerequirements,real-timetasks,periodicity,deadline,andscheduling,andc)Functional/behavioraldesign,whichreferstotheelaborationoftheleafelementsofthehierarchicalstructuraldesignintermsofasynthesizablerealization.

HardwareDesignincludesthespecificationofECUsinanetworkandtheirconnectionswithbuses,definingan

6

architecturaltopologyofthedistributedembeddedplatform.RefinementsofthisactivityincludedesignofindividualECUs,selectingtheprocessors,determiningthememoryandI/Orequirements.

Mappingincludesactivitiesinvolvingbothsoftwareandhardwareobjects,likedecisionsregardingthedeploymentofcertaincompleteorpartialfunctionstohardwarenodeswhicharepartofthenetwork,andtheassignmentofsignalstobusmessages.

CodeGeneration/Implementationinvolvescreationoflow-levelcodingartifacts,whichincludeRTOSconfiguration,firmwareconfigurationcode,andbehavioralimplementationofthecomponents.

Figure4capturesanabstractionofthedesignprocess,whichismadeconcretebyanumberofsupportingtools,whichinclude:GME/ECSL.ThisistheGenericModelingEnvironmenttailoredtosupporttheECSLmodelinglan-guage.ECSL/CG.Aspecializedcodegeneratorthatproducesvariousproductionartifacts(e.g.,sourcecode,configurationfiles)fromECSLmodels.ML2ECSL.ImporttranslatorsthatallowimportingSLandSFmodelsintotheECSLmodelingenvironment.SL/SF.ThesearetheSimulinkandStateflowtools.

B.EmbeddedControlSystemsLanguage

ECSLisagraphicalmodelinglanguagebuiltusingGME.Itcontainsmodelingconceptsforspecificationofthedesignactivitieslistedabove.Thelanguagehasbeendesignedasacompositionofasuiteofsub-languagesasshownbelow:FunctionalModeling.TheSimulinkandStateflowsub-languagesofECSLweredesignedtomirrorthecapabilitiesfoundinSLandSF,suchthatallmodelscouldbeimportedintotheGMEenvironmentconfiguredtosupportECSL.Simulinkfollowsadataflow-diagramlikevisualnotation,whileStateflowsupportsStatechart-likehierarchicalfinitestatemachines.

ComponentModeling.Thissub-languageallowssoftwaremodelingintwostages:(1)integratingmodelsthatwereimportedfromSL/SF,and(2)allowingtheircomponentiza-tion.Acomponentisdefinedasaportionofthesoftwaremodel,whichisdeployedasaunit.ThecomponentizationisspecifiedusingtheGMEcontainmentandreferencecapabil-ities:ComponentsareGMEmodelsthatcontainreferencestoelementsofthefunctionalmodel(importedfromSL).Componentsconsistofportswhichallowthespecificationofinter-componentcommunication,aswellasinterfacestophysicaldevicesincludingsensorsandactuators.Attributesofportscapturetherequiredcommunicationpropertieslikedatatype,scaling,andbitwidth.Theintra-componentdataflowexistswithinthefunctionalmodelsanditisimportedfromSL/SF.Theinter-componentdataflowisintroducedbythedesigneraftercreatingcomponentsfromtheimportedSL/SFmodels.

HardwareTopologyModeling.Thehardwaremodelingsub-languageofECSLallowsthedesignertospecifythehardwaretopology,includingtheprocessorsandcommunicationlinksbetweentheprocessors.ECUmodelsrepresentspecificpro-cessorsinthesystem.AnECUmodelhastwokindsofports

IEEECOMPUTERforrepresentingtheI/Ochannelsandthebusconnections.I/Ochannelportscomeintwovariants:sensorportsandactuatorports.ThespecificsoftheECUfirmware,characterizationwithrespecttomemorysizesandCPUspeed,arecapturedwithattributes.BusmodelsrepresentcommunicationpathwaysusedtoconnectECUs.BusesareexpressedasGMEatomsandtheirattributesspecifyvariouspropertiesofthephysicalcommunicationsystem(e.g.bitrates).

Deployment(Mapping)Modeling.Thismodelingsub-languagecaptureshowsoftwarecomponentsaredeployedonthehardware.TheECUmodelhasa“deploymentaspect”thatallowsthedesignertocaptureSWcomponenttoECUmappingusingGME’sreferenceconcept.Notethatdeploy-mentmodelsareseparatefromsoftwaremodels,thusallowingthereuseofsoftwaremodelsindifferentHWarchitectures.Furthermore,componentportsareconnectedtoECUports(sensor,actuators,andbusconnections)toindicatehowthecomponentsoftwareinterfacesmaptoactualsensors,actuatorsandbuses.

C.Generatingcodeandotherartifacts

TheECSL/CGtoolisacodegeneratorthatproducescodeartifactsnecessaryforsystemimplementationasshownonFigure5.

ExtendedSL/SF-Model

OSEK OSOSEKApplicationApplicationGlue CodeCAN DriverOilFileTasks and CodeBehaviour-Code.c, .h FilesConfiguration

GenerateCode

Configure

OSEK OSspecific .h FilesCAN DriverCANoeEmulation

OSEK OS LibsCompile+CANoeEmulation

Link

NodeLayer-DLLFor each HW node

for CANoe

Generatedby Vanderbilt Code-GeneratorCANoe

VectorTools orStandard Code-Modules

Fig.5:ECSLCodeGeneration

Thefollowingtypesoffilesaregenerated:(1)OSEKImplementationLanguage(OIL)File-ForeachECU-nodeinthenetworkanOILfileisgenerated,thatincludesalistingofallusedOSEK[8]objectsandtheirrelations,(2)OSEKTasksandCode-AlltasksareimplementedinoneormoreCfiles,(3)ApplicationBehaviorCode-Aseparatefunctionisgeneratedforeachapplicationcomponentthatimplementsthebehaviorofthecomponent.Thisfunctioniscalledoutfromwithinataskframe,(4)GlueCode-ThegluecodecomprisesoneormoreCcode/headerfilesthatresolvethecallstotheControllerAreaNetwork(CAN)driverorthefirmwareinordertoprovideaccesstoCANsignalsorHWI/Osignals.

7

V.RELATEDWORK

Thissectionsummarizesrelatedeffortsassociatedwithde-velopingdesignenvironmentssupportingtheMDDapproachandcomparestheseeffortswithourwork.

A.Cadena

Cadena[9]isanintegratedenvironmentdevelopedatKansasStateUniversity(KSU)forbuildingandmodelingcomponent-basedsystems,withthegoalofapplyingstaticanalysis,model-checking,andlightweightformalmethodstoenhancethesesystems.Cadenaalsoprovidesacomponentassemblyframeworkforvisualizinganddevelopingcompo-nentsandtheirconnections.UnlikePICML,however,Cadenadoesnotsupportactivitiessuchascomponentpackagingandgeneratingdeploymentdescriptors,componentdeploymentplanning,andhierarchicalmodelingofcomponentassemblies.TodevelopacompleteMDDenvironmentthatseamlesslyintegratescomponentdevelopmentandmodelcheckingca-pabilities,weareworkingwithKSUtointegratePICMLwithCadena’smodelcheckingtools,sowecanacceleratethedevelopmentandverificationofDREsystems.

B.KennedyCarterModelingTool-suite

KennedyCarter[10]providesasolutioncallediUML,whichusestheMDAapproachtodevelopsystemsusingexecutableUML.iUMLprovidesafullfledgedmodelingframeworkaswellasamodeltesting,debuggingandexecutionenvironment.iUMLalsoprovidesareadytousecodegener-ationframeworksothatdeveloperscantranslatethemodelsusingaproprietarycodegenerationframework.LikeUML,iUMLisalsoagenericframeworkandthedeveloperswillhavetocustomizethetooltocreatedomain-specificartifacts.ItispossiblethatKennedyCarterwilltargetDSMLsforverticaldomainswhichusethisgenericframework.

C.EclipseModelingFramework

EclipseModelingFramework(EMF)[11]isamodelingframeworktargetingtheMDAapproachtoMDD.EMFusesMOF[12]astheunderlyingmeta-metamodel.EMFsupportsspecificationofthemodelsusingXMLMetadataInterchange(XMI),annotatedJava,andXMLSchema.EMFgeneratesJavacodethatallowsausertomanipulatetheelementsinamodel.ThereareeffortslikeGraphicalModelingFramework(GMF)whicharecurrentlyunderwaywiththegoalofaddingcapabilitiesforvisualspecificationofDSMLsjustlikeGME.D.MicrosoftDSLTools

MicrosofthasrecentlyreleasedasetoftoolswiththegoalofrealizingthevisionofSoftwareFactories[13].LikePICML,thereleaseincludesaDSMLforbuilding.NETbasedWebServicesapplicationscalledVisualStudioforTeamArchitects(VSTA),whichprovidestightintegrationwithcode,andgeneratesdescriptorsnecessaryfordeployingtheseapplications.Microsoftisalsodevelopinganothersetoftoolscalledthedomain-specificlanguage(DSL)tools.TheDSLtoolsarelikeGMEandEMFandallowdevelopmentofDSLsusingaproprietarymeta-metamodel.

IEEECOMPUTER8

VI.CONCLUDINGREMARKS

Model-drivendevelopment(MDD)isapromisingparadigmtotacklethesystemcompositionandintegrationchallenges.MDDelevatesthelevelofabstractionofsoftwaredevelop-mentandbridgesthegapbetweentechnologydomainsbyallowingdomainexperts(whomaynotbeexpertsinsoftwaredevelopment)tobeabletodesignandbuildsystems.ThehigherlevelofabstractionprovidedbyMDDalsoallowstransformationbetweenmodelsindifferentdomainswithouttheneedtoresorttolow-levelintegrationsolutionslikeusingstandardnetworkprotocols.MDDguaranteesthesemanticconsistencyofthesystemsthatarebuiltbyenforcingthephilosophyof“correct-by-construction”.MDDalsosolvesalotoftheaccidentalcomplexities,duetotheheterogeneityoftheunderlyingcomponentmiddlewaretechnologies,thatariseduringsystemintegration.Forexample,applyingMDDtodevelopcomponent-basedapplicationsusingPICMLrelievestheusersfromhavingtocapturethemetadataintheformofXMLdescriptors,whicharetediousanderror-pronetowritemanually.

Withimprovementsingenerativetechniques,MDDhasthepotentialtoautomatethegenerationofcodejustlikecompilersreplacedassemblylanguage/machine-codeprogramming.Thisallowspeopletoaugmenttheirexistingsoftwaremethodolo-gieswithMDD,andhelpsineasingthetransitionfromapurecodingbasedapproachtoapureMDDapproach.

REFERENCES

[1]J.SztipanovitsandG.Karsai,“Model-IntegratedComputing,”IEEE

Computer,vol.30,no.4,pp.110–112,Apr.1997.

[2]A.Ledeczi,A.Bakay,M.Maroti,P.Volgysei,G.Nordstrom,J.Sprinkle,

andG.Karsai,“ComposingDomain-SpecificDesignEnvironments,”IEEEComputer,pp.44–51,November2001.

[3]D.Frankel,ModelDrivenArchitecture:ApplyingMDAtoEnterprise

Computing.Indianapolis,IN:JohnWileyandSons,2003.

[4]G.Karsai,J.Sztipanovits,A.Ledeczi,andT.Bapty,“Model-Integrated

DevelopmentofEmbeddedSoftware,”ProceedingsoftheIEEE,vol.91,no.1,pp.145–164,Jan.2003.

[5]UnifiedModelingLanguage:OCLversion2.0FinalAdoptedSpecifi-cation,OMGDocumentptc/03-10-14ed.,ObjectManagementGroup,Oct.2003.

[6]G.Deng,J.Balasubramanian,W.Otte,D.C.Schmidt,andA.Gokhale,

“DAnCE:AQoS-enabledComponentDeploymentandConfigurationEngine,”inProceedingsofthe3rdWorkingConferenceonComponentDeployment,Grenoble,France,Nov.2005.

[7]DeploymentandConfigurationAdoptedSubmission,OMGDocument

mars/03-05-08ed.,ObjectManagementGroup,July2003.

[8]OSEK,“Opensystemsandthecorrespondinginterfacesforautomotive

electronics,”www.osek-vdx.org/.

[9]J.Hatcliff,W.Deng,M.Dwyer,G.Jung,andV.Prasad,“Cadena:

AnIntegratedDevelopment,Analysis,andVerificationEnvironmentforComponent-basedSystems,”inProceedingsofthe25thInternationalConferenceonSoftwareEngineering,Portland,OR,May2003.[10]K.Carter,“KennedyCarteriUML2.2,”www.kc.com,2004.

[11]F.Budinsky,D.Steinberg,E.Merks,R.Ellersick,andT.J.Grose,

EclipseModelingFramework.Reading,MA:Addison-Wesley,2003.[12]MetaObjectFacility(MOF)2.0CoreSpecification,OMGDocument

ptc/03-10-04ed.,ObjectManagementGroup,Oct.2003.

[13]J.Greenfield,K.Short,S.Cook,andS.Kent,SoftwareFactories:

AssemblingApplicationswithPatterns,Models,Frameworks,andTools.NewYork:JohnWiley&Sons,2004.