IEEE TRANSACTIONS ON AUTOMATION SCIENCE AND ENGINEERING 1 On the use of UML for modeling me

OntheuseofUMLformodelingmechatronic

systems

CristianSecchi,Member,IEEE,MarcelloBonf`e,Member,IEEE,andCesareFantuzzi,Member,IEEE

Abstract—Thispaperdescribesamodelinglanguage,firstly

proposedin[1]–[3],thataimstoprovideaunifiedframeworkforrepresentingcontrolsystems,namelyphysicalplantscoupledwithcomputer-basedcontroldevices.Theproposedmodelingmethodologyisbasedonthecardinalprincipleofobjectorienta-tion,whichallowstodescribebothcontrolsoftwareandphysicalcomponentsusingthesamebasicconcepts,particularlythoseofcapsules,portsandprotocols.Furthermore,itisillustratedhowthewell-knownobject-orientedspecificationlanguageUMLcanbeadopted,providedanadequateformalizationofitssemantics,todescribestructuralandbehavioralaspectsofcontrolsystems,relatedtobothlogicalandphysicalparts.

IndexTerms—BondGraphs,SystemModeling,Object-OrientedDesign,SoftwareEngineering,UnifiedModelingLan-guage.

I.INTRODUCTION

T

HEobject-orientedapproachisacardinalprincipleformanymodeling,analysisanddesigntechniquesdevel-opedfordifferentbranchesofengineering,notonlyrelatedtosoftwaredevelopment.Infact,object-orientationallowstodefinemodularsystemarchitecturesbasedonreusableandextensiblecomponents,whosefeaturesareappealinginanyapplicationdomain,frommodelingandsimulationofdynamicsystemstocontroldesignandsoftwareprogramming.

Sincemodularityandreusabilityarekeypropertiesforhandlingcomplexity,object-orientedapproacheshavebeenadoptedfortheimplementationofmodelingframeworksandsimulationtoolsforlarge,complexandheterogeneousphysicalsystems.Amongtheseveralobject-orientedmodelinglan-guagesforphysicalsystemsthathavebeendevelopedwithinthelasttwodecadesitisworthtomentionASCEND[4],Omola[5],andULM[6],tonameonlythosethathavesomedistinguishingfeatures.Recently,theeffortstocombinetogetherthefeaturesofthevariousobject-orientedmodelingframeworkshaveledtoaunifiedlanguageforphysicalsystemsmodelingcalledModelica[7].

Modelinglanguageswithgraphicalnotationsarecommonlyusedalsoduringanalysisanddesignactivitiesincomplexsoftwareprojects,inwhichsoftwareengineersarerequiredtobuildfirstaconceptualmodeloftheprogramandthentotranslateitinexecutablecode.Object-orientedphilosophyisbyfarthemostsuccessfulstrategyformodelingsoftwareap-plicationsandseveraldevelopmentmethodologies,supportedbydiversespecificationlanguages,havebeenproposedwithin

C.SecchiandC.FantuzziarewiththeDipartimentodiScienzeeMetodidell’Ingegneria,UniversityofModenaandReggioEmilia,42100,ReggioEmilia,Italy(e-mail:secchi.cristian@unimore.it,fantuzzi.cesare@unimore.it)M.Bonf`eiswiththeDipartimentodiIngegneria,UniversityofFerrara,ViaSaragat1,44100Ferrara,Italy(e-mail:mbonfe@ing.unife.it)

thisframework;theinterestedreaderisreferredto[8]forabriefhistoryoftheobject-orientedapproach.

Currently,theleadingvisualnotationinthesoftwarespec-ificationdomainistheUnifiedModelingLanguage(UML,[9]),whichhasbeendefinedasanintegrationofthemostsuccessfullanguagesforsoftwareanalysisanddesign.TheaimoftheconsortiumbehindthedefinitionofUML,theObjectManagementGroup(OMG),istoprovide“astandardlanguageforspecifying,visualizing,constructinganddocu-mentingalltheartifactsofasoftwaresystem”[10].Thus,UMLshouldbeusedtocreateplatformindependentmodelsthatcanbemappedbyamodelcompilerintoanyplatform-specificapplication;forfurtherdetailssee[9].Moreover,UMLsupportswithanumberofgraphicalviews(i.e.UseCasediagrams,SequenceDiagrams,etc.)thespecificationoffunctionalrequirements,whichisessentialforanysoft-wareproject.AnotherreasonthatmakesUMLappealingisitsextensibility,whichallowstomodeldomain-specificormethodologyorientedconceptsbymeansofstereotypedelements,derivedfromthebasicUMLmeta-modelelements.AconsistentsetofUMLstereotypesiscalledaprofile.

Alsotheemergingtechnologiesforindustrialcontrolsys-temsaremoreandmoreemphasizingconceptslikemodularityandreusabilityofcomponents(bothhardwareandsoftware),inordertoincreaseefficiencyofmanufacturingsystemsdesignandsimulation,reducingthetimespentduringtheinstallationofmachinesandtheoperationalqualificationofproductionlines.Moderntoolstodesignandprogramcontroldevicesforindustrialsettings(e.g.ProgrammableLogicControllers,PLCs)supportengineerswithmanyfeaturesorientedtotheencapsulationandreuseofsoftwaremodules.Forexam-ple,thewell-knownstandardforPLC(ProgrammableLogicControllers)programmingIEC61131-3[12]andthenewerstandardIEC61499-1[13]fordistributedcontrolsystems,defineframeworksfortheimplementationofmodularsoft-warearchitectures,basedonprogramorganizationunitscalledFunctionBlocks.Moreover,severalauthorshaveproposedUMLasaspecificationlanguageforsoftwarearchitecturesbasedonFunctionBlocks[14],[15].

Eventhoughthementionedphysicalandsoftwaremodelinglanguagessharethebasicprinciplesandarewell-knownintheirapplicationarea(i.e.systemssimulationandsoftwareprogramming),itishard,withthecurrentmethodologiesandtools,tointegratethem,inordertodescribealltheaspectsrelatedtothedesignofacomplexcomputer-controlledsystemwithinasinglemodelingframework.Ontheotherhand,sinceinthiskindofsystemsthecontrolsoftware,thephysicalplantandtheirinterconnectionsformatightlycoupledwhole,itwouldbeusefultoexplicitlymodelthemasanaggregate.

2Motion ControllerMechanical load{VoltagePIDcommandTrajectorygeneratorPowerDC motor +converterposition sensor ControllogicPosition measurementFig.1.Amotioncontrolsystem

Moreover,aunifiedlanguageembeddingstructuralandbe-havioralaspectsofcontrolsoftwareandphysicalcomponentswouldprovidealinguafrancaforthecommunicationbetweenmechanical,processandsoftwareengineers.Incomplexcon-trolsystemsthephysicalcharacteristicsoftheplanthaveadeepimpactonthesoftwareitself[16]and,therefore,ifitwaspossibletodescribephysicalsystemsusingalanguagewidelyacceptedbythesoftwarecommunity,thiswouldsimplifytheprogrammers’task.

ConsiderforexamplethemotioncontrolsystemreportedinFig.1,whichisaquitetypicalmechatronicsystem.

Thesystemconsistsofseveralphysicalcomponents(aDCmo-tor,apowerconverter,somegearsandacrank-rodmechanism)andofalogicalpart(thecontrollaw,thetrajectorygeneratorandthecontrollogic)thatcanbeimplementedasanobject-orientedsoftwareapplication.Thissimpleexamplehighlightstheheterogeneousnatureofmechatronicsystems,whicharemadeupbytheaggregationofphysicalandlogicalelements.ModelinglanguageslikeModelicaortheBond-graphs[17],[18]allowtodescribewithanobject-orientedapproachthestructureanddynamicsofthephysicalpart,namelytheDCmotorandthemechanicalload,buttheyarenotsuitableforrepresentingneitherthecontrollawnorthecontrollogic.Ontheotherhand,anetworkofFunctionBlocks[12],[13]wouldbeanaturalchoiceforthedesignofthecontrolsoftware,butthisframework,whichisbasedonanevent-drivenmodelofcomputation,cannotbeeasilyadaptedfordescribingphysicalsystems,whichareessentiallytimebased.Recently,anactor-basedmodelingstrategyandasoftwaretoolformodelingsystemswithheterogeneousmodelsofcomputationhasbeenproposedwithinthePtolemyproject[19].However,evenifthisframeworkallowstobuildandsimulateamodeloftheoverallcontrolsystemreportedinFig.1,itlacksoftheexpressivenessofUML:forexample,itdoesn’tallowanyrequirementspecification,whichisinsteadnecessaryduringthefirstphaseofthecontrolsystemdesign.Thus,Ptolemywouldnotbeabletosupportcontrolengineersfromtheverybeginningofthedevelopmentprocess.

Ofcourse,acriticalreaderwouldremarkthatUML,despitethefactthatitofferstoolsforrequirementsspecification,isstillalanguagewhoseapplicationdomainislimitedtosoftwaredesign.Nevertheless,thelanguageitselfcanbethoughtasanabstractsystemmodelinglanguage,whosesemanticscanbeadaptedandextendedtomakeitsuitablefordifferentdomains.Actually,severalresearchersexploredthepossibilitytouse

IEEETRANSACTIONSONAUTOMATIONSCIENCEANDENGINEERING

softwareengineeringtoolsformodelingphysicalsystems.In[20],[21]physicalsystemsaremodeledastheinterconnectionofblockscharacterizedbyacontinuousbehaviorandUMLisproperlyextendedtobeabletorepresentthiskindofsystems.In[22]aphysicalsystemismodeledasagenericresourcewhichprovidessomeservicesandUMLisusedtodescribeacomplexsystemmadeupbothofalogicalandofaphysicalpart.Morerecently,aconsortiumofindustriesandpublicorganizationshasproposedaUMLprofileforsystemsengineering,calledSysML[23],whichaimstosupportspeci-fication,designandverificationofcomplexsystemsincludinghardware,software,informationandprocesses.However,thisprofileiscurrentlyatanearlystageofdevelopmentanditisnotclearenough,inouropinion,howtoformalizewiththeSysMLlanguagethedynamicbehaviorofphysicalsystems.Inordertoprovideapreciseframeworkforintegratedmodelingofphysicalsystemsandcontrolsoftware,themaincontributionofthispaperisaproposalforanextensionofUMLbasedonanalreadyexistingandwell-knownpro-file,calledUML-RT,introducedbySelicetal.in[24].TheUML-RTprofileallowstomodelreal-time,event-drivenanddistributedsoftwarearchitectures,bymeansofhighlyencapsulatedcomponentscalledcapsules,interactingwitheachotherthroughportsfollowingacertaincommunicationprotocol.Portsmaketheinternalimplementationofcapsulesindependentofthecommunicationwiththeexternalworld,increasingsignificantlythereusabilityofthecomponent.TheconceptofportasaninteractionpointbetweenacomponentanditsenvironmenthasbeenincludedalsointhedraftofthenewerUML2.0specification[25],sinceithasbeenuniversallyrecognizedasanecessaryfeaturetoemphasizemodularityandreusabilityofdesignmodels.Theconceptofprotocol,instead,allowstomodeltheglobalbehaviorofthesystemindependentlyoftheparticularimplementationofthecapsules,thusmakingtheprotocolspecificationbothafunctionalrequirementandadesignspecification.Thekeyideabehindthepaper’scontribution,istounifytheconceptsofportandprotocolofUML-RTwiththeconceptsofpowerportsandinterconnectionstructuresofBond-graphs,sothatnetwork-basedmodelingapproachesforphysicalsystemsmaybeeasilyre-interpretedinordertoadoptthegraphicalnotationofUML.

Inparticular,thepaperextendstheresultsproposedin[1]–[3]withsomeremarksrelatedthepracticalapplicationoftheproposedobject-orientedapproachtomulti-domainsys-temsmodeling.ThisapproachexploittheBond-graphsbasedmodelingframework[17],[18]andtheirrecentmathematicalformalizationasport-Hamiltoniansystems[26],[27],toshowthatanyphysicalsystemcanbedescribedwithintheUML-RTprofile.

Withinthisframeworkacontrolsystemcanbemodeledasahierarchicalsetofphysicalandlogicalobjectsendowedwithportsthroughwhichtheyexchangeinformationwitheachotherfollowingpropercommunicationprotocols.Inthisway,itispossibletoclearlydistinguishtheactors,bothphysicalandlogical,thatcomposethesystemandtheglobalbehaviorthatderivesfromtheircollaboration.Thankstotheconceptsofportandprotocol,modularityandreusabilityare

SECCHIetal.:ONTHEUSEOFUMLFORMODELINGMECHATRONICSYSTEMS3

extendedtoalltheelementsthatcharacterizeanycomplexautomatedsystem,bothfromthesoftwareandthehardwarepointofview,sothatengineerscananalyzeatanylevelofdetail,followingthehierarchicaldecompositionoftheobject-orientedmodel,bothfunctional(i.e.sequenceofoperations)andnon-functional(i.e.minimumtorqueorspeedrequiredbyanelectricmotor)designrequirements.WealsoprovideadescriptionofageneralphysicalsystemusingUMLformalismanditsextensionmechanisminordertoovercomesomemodelingaspectsnotdirectlyaddressedinthestandardsuchasthecontinuousbehaviorofthephysicalcapsules.Inthisway,UMLcanbeusedtodescribebothphysicalandlogicalelementsbecoming,consequently,asuitableunifiedlanguageformodelingcomplexcontrolsystems.

Thepaperisorganizedasfollows:inSec.IIweprovidesomebackgroundonUML-RTprofileandontheBond-graphsmodelinglanguageandinSec.IIIwespecifytheconceptualscenarioofmulti-domainobjectorientedsystemswereferto.InSec.IVweshowhowitispossibletomaptheBond-graphsdescriptionofaphysicalsystemintotheUML-RTprofileandinSec.VweprovideaformaldescriptionofaphysicalsystemusingUMLanditsextensionmechanism.InSec.VIweprovideanexampletovalidatetheresultsobtainedinthepaperand,finally,inSec.VIIsomeconclusionsaredrawnandfutureworkisaddressed.

II.BACKGROUND

A.TheUML-RTProfile

TheUMLRealTimeProfile(UML-RT)addressesmodelingconceptsthathaveprovensuitableformodelingthesoftwarearchitectureofcomplexreal-timeeventdrivensystemsinapplicationdomainssuchastelecommunication,aerospaceandindustrialcontrol.UML-RTextendsstandardUML(usingthestandardextensionmechanism)byaddingfivenewstereotypesthroughwhichreal-timearchitecturesaremodeled:capsule,port,connector,protocol,protocolrole.Inthefollowingwegiveabriefdescriptionoftheseelementsfocusingonmodelingaspectsratherthanontheirsoftwareaspects;foramorecompleteintroductionsee[24].

CapsulesarethecentralmodelingconstructsinUML-RT.Theyrepresentthemajorarchitecturalelementsofcomplexreal-timesystemsandtheircollaborationallowstomodelthewholesoftwarearchitecture.Acapsulecanhaveoneormoreportsthroughwhichitcancommunicatewiththeothercapsulesanditmaycontainoneormoresub-capsuleswhichcollaboratetogether.Thebehaviorofa(sub-)capsulecanbedescribedbyastatemachine.Portsareboundaryobjectsthatare“owned”byacapsuleandthatprovidetheonlywaythroughwhichacapsulecaninteractwiththerestoftheworld.Portscaneitherberelayportsorendports(alsocalledbehaviorportsinUML2.0[25]).Arelayportisconnectedwithaportofasub-capsule.Itsimplyprovidesanopeningintheencapsulationshellthatallowsthesub-capsulestocommu-nicatewiththeexternalworldwithoutbeingdirectlyexposed.Anend-portisaportthatisdirectlyconnectedtothestatemachineofthecapsule,thusthemessagesflowingthroughtheportdirectlyaffectthebehaviorofthecapsule.Aconnector

representsthemeansalongwhichcapsulescommunicateanditisthephysicalmediumoverwhichacommunicationprotocoltakesplace.Aprotocolisaspecificationofaclosedgroupofparticipants(protocolroles)andoftherulesthatdefinethecommunicationthatcantakeplaceovertheconnectorthatjoinstheparticipants.Aprotocolrolespecifiesthemessagesthataspecificparticipantcansendandreceiveduringthecommunicationandhowthosemessagesmustbeexchanged.FormallyaprotocolPisdefinedbya4-tuple[28]:

P=(E,R,B,Q)

(1)

Eistheeventalphabet,namelythesetofalltheeventtypesthatcanbepassedbetweentheparticipantsinaprotocol.Raretheprotocolroles,namelytherolesthattheparticipantstotheprotocolcanplay.Brepresentstheprotocolreferencebehaviorandidentifiesthesetoflegalbehaviorsthatconstituteaprotocol.Qrepresentstheexpectedqualityofserviceoftheprotocol.

IntheUML-RTframework,acomplexreal-timesoftwareapplicationcanbemodeledasasetofcapsulesendowedwithports.Thecapsulesarejoined,throughtheirports,bymeansofsomephysicalconnectoroverwhichacommunicationprotocolisimplemented.Eachportplaysaprotocolroleandthecollaborationbetweenthecapsulesallowstoachieveadesiredgoal.B.Bond-graphs

Ineveryphysicaldomain,thereisapairofvariables,defined

onapairofdualvectorspaces1Fpower.Thesevariablesp0andEarep0generally=Fp∗

0,whosedualproductiscalledflowandeffortand,forexample,inthemechanicaldomaintheyarevelocityandforceandintheelectricaldomaintheyarecurrentandvoltage.Apowerport[26]isdefinedbyapair(e,physicalf)∈Ep0×Fsystemp0andrepresentsthemeansthroughwhichacanexchangeenergywiththerestoftheworld.

TheBond-graphsmodelingstrategy[17]allowstorepresentanylumpedparametersphysicalsystemthroughasetofbasicelements:elementsthatstorepotentialorkineticenergy,elementsthatdissipateenergyandsourcesofenergy.Eachofthesebasicelementsisendowedwithoneormorepowerportsthroughwhichitcanexchangeenergy.Thedynamicbehaviorofaphysicalsystemisduetotheexchangeofenergythattakesplaceamongtheseelements.Abond-graphshowsexplicitlythenetworkstructurealongwhichthevariouselementsinteract;thepathsalongwhichenergyisexchangedarerepresentedbybonds:aneffortandaflowareassociatedtoeachbondandtheirdualproductrepresentsthepowerexchangedthroughthebond.Thenetworkstructureisrepre-sentedbytheinterconnectionofthevariousbondsbymeansofjunctions,whosebehaviorisgovernedbyKirchhoff-likelaws,andofenergypreservingtransformations(transformers,gyrators).

1Given

avectorspaceF∗isthevectorspaceofthelinearoperatorsonFp0,itsdualEp0=Fp0

p0.Givenf∈Fp0ande∈Ep0,theirdualproductisgivenby󰀄e,f󰀅=e(f)4Each(andonly)elementthatcanstoreenergyhasstatesassociatedtoit;eachstatemodelsthestorageofenergyflowingthroughapowerport.EvenifBond-graphsareingeneralacausal[17],itispossibletoassignacausalitytoeachelementandthustofixaninputandanoutputforeachpowerports.Veryoften,energystoringelementshaveanintegralcausalityassociated⎧

andtheirbehaviorisrepresentedby

⎨x

˙i=ui⎩i=1,...,m(2)

yi=∂H∂xiwheremisthenumberofpowerportsassociatedtotheelement,H(·)isafunctionofthestatethatrepresentstheenergystoredintheelementinagivenconfigurationanduiandyiaredualpowervariablesrepresentingtheithpowerport.Dissipativeelementsimposeanalgebraicrelationbetweentheinputandtheoutputvariablesuchthatu(y)≥0,namelysuchthatpowerisabsorbedbytheelement.Sourcesofenergycanbemodeledintwoways:bymeansofsourcesofflow,whichfixtheflowtoacertainvalue,andbymeansofsourcesofeffort,whichfixtheefforttoacertainvalue.EncapsulationispossiblewithintheBond-graphsframework.Aphysicalsystemiscomposedbyaninterconnectionofphysicalsubsystemsthroughtheirpowerports.Eachphysicalsubsystemiscomposedbyfurtherphysicalsubsystemswhichexchangeenergyontheirown.Thisencapsulationprocessendswhenbasicelementsareencountered.

Recently,thepowerpreservinginterconnectionstructurehasbeenmathematicallyformalizedintroducingtheconceptofDiracstructure[26].Onceacoordinatesethasbeenfixed,severalrepresentationsofaDiracstructureareavailable;averyeffectiveoneistheso-calledkernelrepresentation,definedasfollows.Supposethattherearempowerportsexchangingenergythroughtheinterconnectionstructureandbuildthefollowingvector:

⎛f⎞

⎛e1⎞f=⎜1

⎝...⎟

⎠∈Fpe=⎜⎝...⎟⎠∈Ep

(3)fm

em

wherefiandeport.iaretheflowandtheeffortassociatedto

theithpowerThebehaviorofanypowerpreservinginterconnectioncanberepresentedbythefollowingrelation:

E(x)e+F(x)f=0

(4)

wherexisthestateofthephysicalsystemandE(x)andF(x)arematricessuchthat:

F(x)ET(x)+E(x)FT(x)=0

(5)

dim[F(x)E(x)]=dimFpIII.MECHATRONICOBJECTS

Inthissectionweprovideaconceptualframeworkformodelingcomplexmechatronicsystems,likemanufacturingmachinestogetherwiththeircontrolsoftware,andweshowtheimportanceofaunifiedmodelinglanguagefordescribingthesesystems.

IEEETRANSACTIONSONAUTOMATIONSCIENCEANDENGINEERING

Mechatronic ObjectPackFolderXXXENFB_PackFolderENOInternal FBSwnetworkPortServo motors,Hwkinematics, sensors, etc.PortFig.2.Conceptualrepresentationofamechatronicobject

Inordertomodel,analyzeanddesignacomputer-controlledphysicalsystemwithinanobject-orientedperspective,itisnecessarytotreatsoftwareandphysicalobjectsastightlycou-pledelements,whichshouldneverbeperceivedseparately.Forexample,consideramanufacturingmachinewithitscontroldevice.Ingeneral,thesemachinesarecomposedofphysicalsub-systemseachoneperformingaspecificfunctionalityofthemanufacturingprocess(e.g.materialtransportation,sealing,etc.).Inordertodesignamodularcontrolsoftware,aneffec-tiveapproachwouldbetosplitthesystemaccordingtothephysical-functionaldecompositionandthendesignacontrolmoduleforeachoneoftheresultingmachinecomponents.Acontrolmodulewillhaveawell-definedinterface,relatedtoinput/outputelectricalsignals,tointeractwithsensorsandactuatorsonitsphysicalcounterpart,andanevents/datainter-facetointeractwithothercontrolmodules.Thefirstinterfacerepresentsthehardwareportofthecontrolmodule,whilethesecondisconceptuallythesoftwareport.Theaggregationofacontrolmodule,itshardwareandsoftwareportsandtherelatedphysicalcomponentsiswhatweconsideramecha-tronicclass,withinanintegratedobject-orientedapproach.AschematicrepresentationofamechatronicclassinstanceisshowninFig.2,inwhichthecontrolmoduleisdepictedwiththenotationofIEC61131-3FunctionBlocks[12],whicharebydefinitionsoftwarecomponentswithaninterfaceofinput/outputports.Noticethatthehardwareportandthephysicalcomponentsareencapsulatedintothemechatronicclassconcept,toemphasizetheircloserelationshipwiththecontrolsoftware.Moreover,itisworthtonotethatthesoftwaremoduleitselfisacompositeobject,whichcontains,forexample,trajectorygeneratorsandservocontrolalgorithmsformotiontasks,sequencingandexceptionshandlinglogicandsoon.Inasimilarway,thephysicalpartisanaggregationsofelectricalmotors,mechanicalloads,heaters,etc.interactingwitheachotherbymeansoftheexchangeofenergy.

Therefore,anobject-orientedapproachtomechatronicsys-temsmodelingshouldallowtodescribebothphysicalandsoftwarepartsasanetworkofgeneralizedobjects,exchangingenergy,iftheyhaveaphysicalnature,andevents/data,iftheyarepurelylogical.Ofcourse,Bond-graphshavethisfeatureformodelingphysicalsystems,whileUML,especiallyincludingtheconceptsofportsandprotocols,canbeadoptedtomodelindustrialcontrolsoftware,asdescribedin[14],[15].Inaddition,sinceUMLcanbeextendedtoincludedomain-specificconcepts,itispossibletodefineauniqueobject-orientedmodelinglanguageformechatronicsystems,

SECCHIetal.:ONTHEUSEOFUMLFORMODELINGMECHATRONICSYSTEMS5

bymeansofapropermappingbetweenBond-graphselementsandUMLelementsandanadequatedefinitionofthesemanticsoftheinteractionbetweensoftwareandphysicalcomponents.Inparticular,itiseasytoseethattheinter-domainaccesspointisrepresentedbyhardwareports,whoseroleinthemodelistoembedoperationsliketime-triggeredsamplingofsensorsignalsandupdateofcommandsforactuators.Thefirstkindofoperationisameasurementofeitheroneofthestatevariablesofthephysicalsystem(i.e.thepositionofamechanicalpart)oroneeffortorflowvariable(i.e.voltage,velocity,pressure,etc.),whilethesecondoneconsistsinapplyingthecontrolactionbymodulatingeitheraneffort/flowsourceorapowertransformer/gyrator.Signalportsandmodulatingports,asmeanstodefinetheinteractionofaphysicalsystemwithafeedbackcontroller,arestandardtoolsinBond-graphs[17],inadditiontopowerportsmodelingtheexchangeofenergy.Innextsection,wewillshowhowtoformalizealloftheBond-graphselementswithintheUMLframework.IV.USINGUML-RTFORMODELINGPHYSICALSYSTEMSBond-graphscanbeinterpretedinanobject-orientedfashion,asshownin[29],butthankstotheconceptofDiracstructureweshowthatanyphysicalsystemcanbedescribedasasetofactorsthatcooperateforachievingthephysicalbehaviorcharacterizingthesystemasithappensinUML-RTmodelingframework.InthissectionweshowhowitispossibletodescribeaphysicalsystemwithaUML-RTmodel.ThiswillbedonebymappingtheconceptsofBond-graphs[17]andport-Hamiltonianmodeling[26]intotheUML-RTframework.TothisaimwefirstgiveasystemtheoreticdescriptionofaUML-RTmodel.Asystemmadeupofpcapsulesandmportscanbedescribedasa5-tuple(A,P,C,α,ψelementsaredefinedinthefollowing.Theset

P),whoseA=A1×···×Ap

a=(a1,...,ap)

(6)

isthesetoftheattributesoftheoverallsystem,inwhicheachsetAirepresentsthesetofattributesofthecapsulei.EachsetAbei,andconsequentlyA,ingeneralhasnostructureanditcancomposedofseveralandheterogeneouselementssuchaslists,integers,datastructures,andsoon.TheinteractionbetweencapsulesisdefinedbytheprotocolP=(E,R,B,Q),asdetailedinSec.II.Inparticulartheeventsetisgivenby:

󰀎mE=

Ei

(7)

i=0

whereEirepresentstheeventalphabetthattheithportcan

exchangeintheprotocol.Itispossibletodefinethefollowingset:

E=E1×···×Emε=(ε1,...,εm)(8)whoseelementsdescribetheeventswaitingtobeprocessedin

agivenportsconfiguration.Obviouslysomeεimaybeempty,meaningthatnomessageiscrossingthecorrespondingport.Crepresentstheinterconnectionstructure,whichisthemediumthroughwhichcapsulesexchangeinformationandoverwhichtheprotocolPisimplemented.Themapα:A×E→Aistheattributetransitionmapanditdescribeshowtheattributes

ofthecapsuleschange,accordingtothebehaviordefinedbythecapsules’statemachines.ThemapψistheporttransitionmapanditdescribesPthe:Adynamics×E→Eofeventsacrosstheports,accordingtothereferenceprotocolandtothecapsules’statemachines.Thisdynamicsdependbothontheattributesofthesystemandonthesignalsacrosstheportsand,implicitly,ontheprotocolthroughwhichallthecapsulesexchangemessages.Ingeneralwhenaspecificeventtakesplaceboththeportandtheattributesconfigurationscanchange.

Nowwecanshowhowtomapanyphysicalsystemintothismodelingframework.Sinceaphysicalsystemismadeupbyasetofbasicphysicalelementsthatexchangeenergy,weconsiderthesestructuralcomponentsasUML-RTcapsules.Letpbethenumberofcapsulesdescribingaphysicalsystem.Theattributesofeachcapsulearerepresentedbythephysicalstates,thereforethesetAbecomes:

A=X1×···×Xn=X

x=(x1,...,xn)

(9)

inwhichXisusuallyadifferentiablemanifold.Thenumberofphysicalstatesis,ingeneral,differentfromthenumberofcapsules,sinceeachcapsulecanbecharacterizedbyseveralstatesorbyzerostates(e.g.purelydissipativeelements).Inordertoformalizetheprotocolmodelingthedynamicsofaphysicalsystem,wemustfirstdefinewhichkindofinfor-mationareexchangedbetweenitscomponents.Thedynamicevolutionofaphysicalsystemisdeterminedbytheexchangeofenergythattakesplaceamongitsconstitutiveparts.Thus,thefundamentalinformationisenergywhichisexchangedthroughpowerports.Apowerportcanbemodeledasaportwhoseeventalphabetisgivenbythespaceofpowervariables,namelybyFp0×Ep0,whereFtotheportp0andErespectively.

p0aretheflowandtheeffortspacesrelativeEachcapsulecanbefurtherdecomposedinsub-capsules,namelyinfurtherinterconnectedsubsystemsthatexchangeenergy,whichmeansthatitispossibletodistinguishbetweenpowerrelayportsandpowerendports.

Apowerrelayportpassestheenergy,flowingthroughit,toasub-capsule.Itprovides,asrelayportsinUML-RTmodelsforsoftwarearchitectures,an“opening”intheencapsulationthatcanbeusedbysub-capsulestoexchangeenergywiththeexternalworld.

Apowerendport,instead,playsaspecificroleintheinterconnectionstructureofthevarioussub-capsules.Physi-callyspeaking,itprovidesameanstoinject(extract)energyinto(from)theinterconnectionstructureand,therefore,itaffectsthedynamicbehaviorofthecapsule.InUML-RTendportssendeventsdirectlytothecapsulestatemachineand,therefore,theycanchangetheoverallbehaviorofthecapsule.Withinthephysicaldomain,thebehaviorofacap-suleisdeterminedbytheinterconnectionstructurealongwhichsub-capsulesexchangeenergyANDbytheamountofenergythatisexchanged.Energyendportsallowdirectinjection/extractionofenergyontheinterconnectionstructureandthustheyallowtomodifytheoverallbehaviorofthecapsule.Thekeypointisthatwhiletheoverallbehaviorofacapsuleineventbasedmodelingisdeterminedbytheinterconnectionofthesub-capsulesandbyastatemachine,

6theoverallbehaviorofacapsule,inphysicalmodeling,isdeterminedbytheinterconnectionofthesub-capsulesandbytheamountofenergythatiscirculating,continuously,alongtheinterconnectionstructure.Moreover,eachphysicalcapsulecanhaveportsthatarenotdirectlyrelatedtotheexchangeofenergy.Forexample,theseportstransmitsignalsrelatedtothephysicalstateofacomponent,orrelatedtothemodulationofasourceorofatransformer.Theseportscanonlybeconsideredrelayportssincetheycannotinject(extract)energyinto(from)theinterconnectionstructure.Nevertheless,theseportscanplayaroleintheexchangeofinformationamongcapsules.

Whenmodelingphysicalsystems,itispossibletodis-tinguishbetweenthemeansthroughwhicheachcapsuleisinterconnectedtotheothersandthewayinwhichthevarioussubsystemsarejoined,namelythetopologyoftheinterconnection.Morespecifically,themeansthroughwhichcapsulescommunicateisrepresentedbytheinterconnectionstructureC,whichismadeup,forexample,byelectricalwires,pipes,mechanicaljoints.Thetopologyoftheinterconnection,ontheotherhand,representstheenergeticpaths,namelytheprotocolP,implementedovertheinterconnectionstructureC,throughwhichthecapsulesexchangeenergy.Sincephysicalsystemsbehavioriscontinuous,theeventsetEhasinfinitecardinalityand,therefore,inordertoremarkthisfeature,wecalliteventspace.Aseffortsandflowsareexchangedthroughthepowerportsoftheinterconnection,theeventspacecontainsbothFcanpandEplayap.Oncecausalityhasbeenfixed,eachpowerportspecificrole:itcanprovideaflowand,therefore,receiveaneffort,oritcanprovideaneffortandreceiveaflow;wecalltheserolesenergyroles.Therecannotbeotherrolesapartfromthoseofeffort-supplier/flow-receiverandflow-supplier/effort-receiver,sinceaportcannotsupply(orreceive)botheffortandflowasaconsequenceofthefirstprincipleofthermodynamics[17].Ingeneral,thewayenergyisexchangeddependsonthestatescharacterizingtheinterconnectedcapsules.Thisdependencedoesnotrepresentenergyinjection/dissipation,butratheramodulationinthetransferofenergyalongtheinterconnectionstructure.Thusportsthatcarrysignalsthatareusedtomodulatetheintercon-nectionstructureplayafurtherroleintheprotocol,namelyamodulatingrole.Eachcapsulecanparticipatetotheprotocolbothbyexchangingdirectlyenergythroughportsthatplayenergyrolesandbymodulatingtheenergytransferthroughportsthatplayamodulatingrole.Therefore,thestatemanifoldXofthephysicalsystemisalsopartoftheeventspace,whichis,summarizing,givenbyE=Fphysicalsystemiscontinuous,p×Ep×X.SincethedynamicsofatheprotocolbehaviorBiscontinuous.Whileinsoftwareapplicationsthebehaviorofthecommunicationprotocolcanbearbitrarilyimposed,allprotocolsusedformodelingtheinterconnectionofphysicalsubsystemssharethesamecharacteristic:theyareenergypreserving,meaningthatalongtheinterconnectionenergyisneitherstorednordissipatednorproducedbutsimplytransferred.ThebehaviorofphysicalprotocolscanberepresentedthroughthemathematicalobjectofDiracstructureandthrough,forexample,apairofstatedependentmatricesE(x)andF(x)asreportedinEq.(4).SinceE(x)andF(x)

IEEETRANSACTIONSONAUTOMATIONSCIENCEANDENGINEERING

satisfyEq.(5),itisalwayspossibletocalculatetheeffortsorflowsthathavetobesenttothepowerportsinwhichtheyappearasreceivedsignals,usingtheeffortsorflowsincomingfrompowerportsinwhichtheyappearassuppliedsignals[26].Physicalprotocols,or,equivalently,Diracstructures,describethewayinwhichthecomponentsofaphysicalsystemexchangeenergy.InSec.VItheywillbeusedtodescribetheinterconnectionbetweentheelectricalandthemechanicalpartandbetweentheelectricalsub-componentsoftheDCmotoroftheexamplereportedinSec.I.Diracstructures,andconsequentlyphysicalprotocols,canbeusedtomodelanylumpedparametersystem;someexamplesoftheuseofDiracstructuresformodelingcomplexmulti-domainphysicalsystemscanbefoundin[26],[27].Whenmodelingphysicalprotocols,weconsidermeaninglessanyqualityofserviceassessment,thereforewedonotformalizeQ.

Letm≥nbethenumberofpowerportsoftheoverallsystem.Oncecausalityhasbeenassigned,itispossibletodistinguishaninputsignaluThus,itispossibleiandanoutputsignalytodefinetheattributeipereachpowerport.transitionmapasacontinuousfunction:α:Fp×Ep×X→X

(f(t),e(t),x(0))→x(t)

(10)

Thefunctionαdefinesthecontinuousinternalbehaviorofeachinterconnectedcapsule.Inparticular,assumingintegralcausality,foreachstatewehavethat:

󰀍t

xi(t)=α(f,e,x(0))=xi(0)+

u0

i(τ)dτ(11)whereuicanbeeitherfioreidependingontheportcausality.

Theporttransitionmapisgivenby:

ψP:Fp×Ep×X→Fp×Ep×X

(12)

Eachsignalcrossingtheportattimetcanbecalculatedthroughthestateinformationandtheportconfigurationattimet.Inparticular,pereachpowerportassociatedtoanenergystoringelementwehavethat:

y∂H󰀁i(t)=

∂x󰀁i=1,...,n(13)ix(t)whereyicanbeeitherethefunctionthatiorfexpressesidependingontheportcausality.H(x)istheenergystoredintothesystem.Incaseofpowerportsassociatedtoenergydissipation,wehavethat:

yi(t)=gi(ui(t))

i=n+1,...,m

(14)

wheregiisthealgebraicfunctioncharacterizingtheport.Incaseofsignalports,thosethatplaythemodulatingroleinthecommunicationprotocol,wehavethat:

mi(t)=zi(t)

i=1,...,n

(15)

inwhichzicanbeanykindofphysicalvariableei,forxii.Oncethesignalscrossingtheportsassociatedtotheoutputofpowerportsandthosethatcrossthemodulatingportsareavailable,itispossibletocalculate,throughtheprotocolbehaviorequation,theinputsofthepowerports,thuscompletingtheportsconfigurationattimet.Thuswehaveproventhefollowing:

SECCHIetal.:ONTHEUSEOFUMLFORMODELINGMECHATRONICSYSTEMS7

Proposition.AnylumpedparametersphysicalsystemcanberepresentedasaUML-RTmodel

Summarizing,wehaveshownthatalsointhephysicaldomain,asinUML-RT,itispossibletoputinevidenceasetofmainactorscollaboratingtogetherthroughacommunicationprotocolinordertoachieveagiventask,i.e.acertainbehavior.ThekeypointforhighlightingthisstructureistorecognizethattheinformationthatencodesthedynamicevolutionofaphysicalsystemisenergyandthatthecommunicationprotocolcanbedescribedthroughaDiracstructure.

Thus,withintheUML-RTmodelingframework,acomplex,possiblydistributed,automationplantcanbemodeledasasetofphysicalandlogicalcapsulesexchanginginformationthroughcommunicationprotocols.Whatisimportantfortheglobalbehaviorofthesystemisnotthecapsuleitselfbutbythewayinwhichitprocessestheinformation(eitherlogicalorphysical)exchangedwiththerestofthesystem.Thismakesbothlogicalandphysicalcapsuleshighlyreusableandtheintegrateddesignautomationplanteasiertomaintain.

V.UMLSTEREOTYPESFORPHYSICALSYSTEMSOnceithasbeenproventhatphysicalsystemscanbemodeledwithintheUML-RTframework,itisnecessarytoprovideaunifiedformalismfordescribingbothphysicalsystemsandsoftwarearchitectures.ThemostnaturalcandidateisUMLwhichisalreadywidelyusedformodelingsoftware.Theaimofthissectionistoformalize,usingUML,aphysicalsysteminordertoprovideanunifiedformalismtomodelbothsoftwareandhardware(i.e.physicalsystems)ofacontrolsystem.InUML-RTcapsulesaremodeledbythe<>stereotypeofclass.Portsarerepresentedbythe<>stereotypeofclassandeachcapsuleisinacompositionrelationshipwithitsports.Aconnectorismodeledbyanasso-ciationbetweentheportsthatareinterconnected.Aprotocolismodeledbythe<>stereotypeofCollaborationandisinacompositionrelationshiptoeachofitsprotocolrolesthatarerepresentedbythe<>stereotypeofClassifierRole.

Physicalcapsules,modeledwiththestereotype<>,caninteractwiththeotherphysicalcapsulesbymeansofthephysicalprotocol,whichisastereotypedcollaboration,whosestereotypeis<>,ofphysicalelements.Theformalsemanticsofthephysicalprotocolistheonedefinedinprevioussection.Theportscollaboratinginaphysicalprotocolcanhaveoneofthefollowingroles:effort-supplier/flow-receiver(ES-FR),flow-supplier/effort-receiver(FS-ER)andmodulating(M).Thefirsttwokindofrolesarerelatedtopowerports.Itisimportanttonotethatapowerportalwaysconveystwosignals:effortandflow.Therefore,wecanalsoassumeastandardtextualnotationtoreferthesesignals,withthestylePortName.eandPortName.f.Moreover,weallowaphysicalcapsuletohavestandardsignalports,likethoseofsoftwarecapsules,whichprovideinformation(i.e.measurements)relatedtoefforts,flowsorstates.Thesesignalports,eveniftheycannotparticipatetothephysicalprotocolbecausetheyarenotabletoaffectits

behavior,allowtomodelthesensorsusedbythecontrolsoftwaretoimplementfeedbackstrategies.Fig.3showshowthestereotypesdefinedinthissectionmayappearonaUMLClassDiagram.

Eachphysicalcapsulecanhaveseveralphysicalsub-capsules.Thesesub-capsulesareclassesontheirownandareinacom-positionrelationshipwiththecontainerclass.Classdiagramsareveryusefultomodelthestructureofasystem,butinordertomodelexplicitlythetopologyoftheinterconnectionstructure,stereotypedcollaborationdiagramswiththenotationintroducedin[24]areveryuseful.Multipleassociations,quitecommonwhenmodelingphysicalsystems,aremodeledthroughthestandardUMLdiamondnotation[9].

WhileintheirstandarduseinUML-RTcapsulesrepresentevent-drivenentities,whenmodelingphysicalsystems,cap-sulesrepresentcontinuouslytimedrivenentities.TherearetwoissuestobeaddressedinordertodefinethebehaviorofphysicalcapsulesinUML:theconceptoftimeandtheconceptofcontinuousbehavior.

Sincephysicalsubsystemsevolvecontinuouslyintimeweneedtodefineaconceptoftimethatisnotdiscrete(e.g.associatedtoaclock),butcontinuous.Asreportedin[16],thegeneralUMLstandarddoesnotimposeanyrestrictionsonthemodelingoftimeanditneitherassumesthattimeiscontinuousordiscretenorthatthereisasinglesourceoftimeinasystem.Thissemanticflexibilityallowsseveralmodelsoftimethatcanbeusedtomodelbothdiscretelyancontinuouslytime-drivensystems.“Physical”timecanbethoughtasacontinuousandunboundedprogressionofphysicaltimeinstants,whichimposesapartialorderonevents.Thus,weassumethateachcapsule,representingaphysicalsubsystem,isinassociationrelationshipwithaPhysicalTimeclass,thatprovidesthecontinuousflowoftimeinstants.Thephysicaltimeclassisalsoassociatedtoalltheprotocolrolesofaphysicalprotocol,sincetheirflowofinformationisalsocontinuous.

Theattributesofeachphysicalcapsuledependcontinuouslyontheenergyexchangedwiththeotherphysicalcapsulesalongthephysicalprotocol.Therefore,thebehaviorofaphysicalcapsulecannotberepresentedbyastatemachine,asisinsteadcommonwhendealingwithsoftwareapplications.TheUMLextensionthatweproposetorepresentcontinuousbehaviorsistoattachan<>constrainttoeachphysicalclass,whoseexpressionmustcontainthemathematicalequa-tiongoverningthedynamicsofthephysicalelement.Infacttheequationexpressingtherelationbetweentheinputandthevariationofthestateandthestateandthevalueoftheoutputisnothingelsethananinvariantbetweenstateandinputandstateandoutputrespectively.

VI.EXAMPLE

Animportantpartofthesoftwaresystemcontrollingaman-ufacturingmachineisrelatedtomotioncontrol,includingthegenerationofreferencetrajectoriesforthepositionorvelocityofagroupofelectricmotors,thetrackingofthesetrajectoriesandthemanagementofelectricpowerconverterslike,forexample,PWM-controlledtransistorbridges.Inthissection

8IEEETRANSACTIONSONAUTOMATIONSCIENCEANDENGINEERING

*<>PhysicalClass<>portClassFS-ER<>FS-ER*<>PhysicalProtocolA*<>portClassES-FR<>ES-FR**<>portClassM<>M*Fig.3.UMLrepresentationofaphysicalsubsystem

<>Controllerportsp1:HC::slavep2:MC::slavep3:CM::masterp4:SW-INT::S<>DCMotorportsp1:CM::slavep2:MC::master11<>TrajectoryGeneratorportsp1:SW-INT::TG11<>PowerMonitorports11<>Controlportsp1:SW-INT::CT11p1:SW-INT::PM1<>x-∫(kp1.f)dt=0kp1.e-x/L=0<>Kinstoringportskp1:Phys2::FS-ER1<>Armatureportsp1:CM::slaveap1:Phys1::FS-ERap2:Phys2::ES-FR1<>Mechanicalportsp1::MC:mastermp:Phys1::FS-ER1<>Dissipatingportsdp1:Phys2::ES-FR<>dp1.e-R*dp1.f=0Fig.4.TheClassDiagramoftheoverallcontrolsystem

werepresentthemotioncontrolsystemreportedinSec.IusingtheUML-RTbasedmodelingframeworkdevelopedinthepaper.Asanexampleofasystemthatrealizethetypicalfunctionalitiesofanindustrialmotioncontroller,weconsiderasinglepermanentmagnetsDCmotortoghetherwithitscontrolsoftware.Thephysicalplantinteractswiththecontrolsoftwarethroughapositionsensorcoupledwiththemotor’sshaftandthroughacontrolledvoltagesourcewhichaffectsdirectlythemotor’sarmaturevoltage.Thecontrolalgorithmisimplementedasareal-timesoftwareprogramrunningoveramicrocomputerwhich,initsturn,interactswithanexternalentity,thatmaybeahumanoperatororahigherlevelcontrolunit.TheUML-RTmodeloftheoverallsystemisreportedinFig.4where,inordertorepresentmoreconciselyacapsuletogetherwithitsports,theportsofeachcapsulearelistedinaspecificportcompartment.Thenameoftheportisreported

SECCHIetal.:ONTHEUSEOFUMLFORMODELINGMECHATRONICSYSTEMS9

first,followedbythenameoftheprotocolitparticipatestoandfinallybytheprotocolroleitplays;furthermore,theattributesofeachcapsulearenotlistedinthediagram.Thesystemiscomposedoftwomaincapsules:theController,thatrepresentsthecontrolsoftwareandthatischaracterizedbyadiscretebehavior,andtheDCMotor,thatrepresentsthephysicalplantandthatischaracterizedbyacontinuousbehavior.Thecontrollercapsulecontainsthreesubcapsules:

•thePowerMonitorcapsule,thatisresponsibleofswitch-ingonandoffthepowerconverterrequiredtocontroltheDCmotor’sarmaturevoltageanddetectingitsabruptfailures;

•theTrajectoryGenerator,thatcomputesateachsamplingtimethereferencepositiononthebasisofapredefinedsetofmotionprofilesstoredinthememoryofthemicrocomputer;

•theControlcapsule,thatcomputesthecontrolactionandsetsthemotor’sarmaturevoltageonthebasisofthecurrentvaluesofthereferenceposition,receivedfromtheTrajectoryGeneratorcapsule,andofthemeasuredpositionofthemotor.

Thecontrollercapsuleisendowedwith4portsbywhichitinteracts,throughproperprotocols,withtheexternalsupervi-sorunit,withtheDCmotorandwithitssub-capsules.Thecommunicationbetweentheexternalentityandthecontrollertakesplacethroughthemaster/slaveprotocolHC.Theportp1ofthecontrollerplaystheslaveroleintheprotocolHCwhichrepresentsthefactthatcontrolsystemmodeledherereceivesoperatingcommandslike,forexample,ON,OFForSTARTsignals,fromtheexternalworld.TheinteractionbetweenthecontrollerandtheDCmotortakesplacethroughtwomaster/slaveprotocols:MCandCM.Theportp2playstheslaveroleintheMCprotocolandthismodelsthefactthatthemotorsetsthevalueofthepositionthatisusedinthecomputationofthefeedbackcontrollaw,whiletheportp3playsthemasterroleintheCMprotocolandthismodelsthefactthatthearmaturevoltageissetonthemotor’spowersourcebythecontrolsoftware.Portsp2andp3arerelayportssincethesensorvalueisacquiredbytheControlandtheTrajectoryGeneratorsubcapsulesandthevoltageissetdirectlybytheControlsubcapsule.

TheinteractionprotocolbetweenthecomponentsofthecontrolsoftwareisdescribedbyFig.5,whichshowsthebehavioralstatemachinesofthethreesubcapsules,playingtheprotocolrolesdenotedwithCT(ConTrol)TG(TrajectoryGenerator)andPM(PowerMonitor),andthestatechartoftheprotocolitself,thatdescribesthebehaviorofthesoftwareaggregateinresponsetobothexternalandinternal(i.e.fromsubcapsules)stimuli.

Whenthecontrolsystemisswitchedoff,theprotocol’sstatechartisinthe“Idle”state.WhenitreceivestheOnevent(denotedasEX.On)fromtheactorplayingthe“external”,thesystementersintothe“Energize”state,inwhichthePowerMonitorcapsuleswitchesonthepowerconverterand,iftherearenofaults,enablesthesystemtowaitforsubsequent“running”commands.ThefirstcommandthatforcesthesystemtoactuallymovethemotoristheHomingrequest:whenthissignaleventisdetected,theTrajectoryGenerator

generatesamotionprofilethatapproachesataverylowspeedthemotor’s“zero”position.Whenthemotoris“homed”(conditiondenotedasMP=0inFig.5),thesystemisabletoaccepttheStartcommand,towhichthesystemrespondsenteringastateinwhichthetrajectorygeneratorcomputesarepeatingmotionprofile,asrequiredbythe“production”cycleofthemanufacturingmachineconnectedtothemotor.

WhenthecontrolsystemisintheRunstate,therepeatingmotioncanbestoppedinthefollowingways:

1)ifaStopcommandisreceivedbytheControllercapsule,thetrajectorygeneratorcomputesforthelasttimeacompletecycleofthemotionprofile,sothatthemotorstopsexactlyinits“zero”position,whichallowsthecontrolsystemtorestartthecyclicmotionassoonasanotherStartcommandisreceived;

2)ifaSafeStoprequestisreceived,thetrajectorygeneratorcomputesamotionprofilethatreachesassoonaspossibletheconditioninwhichthemotor’sspeedisequaltozero(conditiondenotedasMS=0inFig.5);3)iftheControlcapsuledetectsthatthefollowingerrorishigherthanasafetylimit,thesystementersanErrorstate,inwhichthearmaturevoltageofthemotorissettozeroandthepowerconverterisswitchedinaconfigurationthatbrakesthemotorasmuchaspossible;4)ifthePowerMonitordetectsafaultinthepowercon-vertercircuitry,thesystemreactsinthesamewaydescribedinthepreviouscase.

TheDCmotorcapsulecanbedecomposedintotwosub-capsules:thearmaturesub-capsuleandthemechanicalsub-capsule,thatrepresentthearmaturecircuitandthemechanicalpartofthemotorrespectively.Thearmaturesub-capsuleisen-dowedwithaport(p1)fromwhichitreceivesthevalueoftheinputvoltagefromthecontrollercapsule.Furthermorethetwosub-capsulescommunicate,namelyexchangeenergy,throughtheprotocolPhys1.Boththearmatureandthemechanicalsub-capsuleshaveapowerportthatimplementstheroleofeffort-supplier/flow-receiver:thisisduetothefactthattheirinterconnectionisbymeansofanidealpowergyrator[27],whichrelatesproportionallytheeffortofonephysicaldomain(i.e.electrical)totheflowofanotherdomain(i.e.mechanical)andviceversa.Intheproposedmodel,thisisrepresentedbytheassociationbetweenthetwocapsulesandbytheformalizationoftheinteractionprotocolbymeansoftheDiracstructuredescribed󰀂by10

󰀃the󰀂

following:

mp.e󰀃󰀂󰀃󰀂󰀃󰀑0󰀐󰀏1

󰀒

ap1.e+󰀑k0−ktmp.ft󰀐󰀏0=0(16)

󰀒ap1.fE(x)

F(x)

wherektistheelectro-mechanicalconstantoftheDCmotor.

ThepairofmatricesreportedinEq.(16)representthebehaviorofthephysicalprotocolwhichdescribesthewayinwhichthemechanicalandthearmaturesub-capsulesexchangeenergy.Furthermore,eachsub-capsulecanbefurtherdecomposedintheinterconnectionofbasicsub-capsules.Forexample,thearmaturecapsulecanbedecomposedintwosub-capsules:Kinstoring,anelementstoringgeneralizedkineticenergy,inthiscaseaninductor,andDissipating,anelementdissipating

10IEEETRANSACTIONSONAUTOMATIONSCIENCEANDENGINEERING

WorkingEX.On/PM.OnIdleEX.Off/PM.Off; TG.Off; CT.Off;FastStopPM.FailureErrorEX.Reset/PM.Reset; CT.Reset; PM.Off; TG.Off; CT.Off;INTERACTIONPROTOCOLEX.SafeStop/TG.SafeStopCT.ErrorEX.Start/TG.StartRunEX.Stop/TG.StopHomingTG.DoneHomedTG.DoneEX.Homing/TG.Homing; CT.Reg;EnergizePM.EnReadyWorkingHomingIdleStop[MP = 0]/DoneSearchHomeIdleRegOffRegulateCONTROLRole: CTResetError[|SP - MS| > ErrorLimit]/ErrorOff[MP = 0][MS = 0]/DoneFastStopReadyWorkingStartStoppingOnIdleOffCheckPwrPwrOK/EnOperatingSafeStopStopRunningTRAJECTORYGENERATORRole: TGPOWERMONITORRole: PMResetErrorPwrFailure/FailureFig.5.Statechartsofthecomponentsofthecontrolsoftware

energy,inthiscasearesistor.TheseelementscommunicatethroughtheprotocolPhys2,inwhichtheArmatureparteci-patesbyprovidingamodulatedvoltagesourcethroughtheportap2.Thebehaviorofthesub-capsulesKinstoringandDissi-patingisreportedexploitingthe<>stereotypeavailableinUML,whereLandRaretheinductanceandtheresistanceofarmaturecircuitrespectivelyandtheirinteractionisgovernedbytheDiracstructurerepresentedasfollows:⎛1⎝00󰀑

⎞⎛⎞⎛

ap2.e011

00⎠⎝kp1.e⎠+⎝1

dp1.e000

󰀑󰀐󰀏󰀒⎞⎛⎞

00ap2.f

−10⎠⎝kp1.f⎠=01−1dp1.f󰀐󰀏󰀒F(x)

(17)

ThematricesreportedinEq.(17)representanotherDiracstructurethatdescribesthebehaviorofthephysicalprotocolthatmodelsthewayinwhichtheinductor,theresistorandthevoltagesourceexchangeinformation(i.e.energy)throughtheirpowerports.Finally,inordertokeeptheClassDiagramsimple,theassociationbetweentheDCmotorandthePhysi-

E(x)

calTimeclasshasbeenomitted.

Noticethattheoverallsystemcanberepresentedasasetofcapsulesthatexchangeinformationfollowingpropercom-municationprotocols.Thecapsulescanbeeitherdiscrete(asthecapsulescomposingtheController),andinthiscasetheirbehaviorcanberepresentedthroughastatechart,orcontinuous(asthesubcapsulesoftheDCMotor),andinthiscasetheircontinuousbehaviorcanberepresentedthroughthe<>stereotype.Theprotocolsgoverningtheexchangeofinformationbetweendiscretecapsulescanbeofseveralkind(master/slave,client/server,etc.)whilethosegoverningtheexchangeofinformationbetweencontinuouscapsuleshavetobepowerpreservingandthereforerepre-sentablethroughaDiracstructure(e.g.Phys1andPhys2).

VII.CONCLUSIONANDFUTUREWORK

InthispaperithasbeenshownhowitispossibletomodelcomplexmechatronicsystemswithaunifiedapproachbasedonObject-Orientation.Theproposedapproachallowstocon-siderallthecomponentsofamechatronicsystem,either

SECCHIetal.:ONTHEUSEOFUMLFORMODELINGMECHATRONICSYSTEMS11

belongingtothecontrolsoftwaredomainortoanyphysicaldomain,aselementsofasetof,possiblycompound,objectswithgiveninterfaceports.Theinteractivebehaviorofthesystemismodeledasanexchangeofinformationbetweenitscomponents.Ageneralizedobjectofamechatronicsystemcanbeeitherasoftwareelement,thatexchangeinformationthroughaconnectorthatimplementsanevent-basedcommu-nicationprotocol,oraphysicalelement,thatexchangeinfor-mation,namelyenergy,throughaphysicalconnectorwhichimplementsacertaincontinuouscommunicationprotocol,thatcanbemathematicallyformalizedthroughaDiracstructure.ThegraphicallanguageofUML,withtheextensionsincludedintheUML-RTprofile,hasbeenusedtoprovideaunifyingframeworkformodelingbothphysicalsystemsandsoftwarearchitecture.Finally,itisimportanttoremarkthatthemainconceptsofUML-RThavebeenincludedintheofficialUML2.0[25]andarefullysupportedbysoftwaredevelopment

toolsforreal-timesystemslike,forexample,RationalRose󰀁

RRealTime[30].SincethistoolcangeneratefullyexecutableC++orJavacodebasedonUML-RTmodels,itispossibletodevelopalibraryofphysicalelements,eitherbasic(i.e.energystoringblocks,sources,etc.)orcomplex(e.g.DCmotors),whoseinternalimplementationallowstosimulatethedynamicbehaviorofthephysicalpartofacontrolsystem.Inthisway,theprojectofacomplexmechatronicsystemcanbefullysupportedbyrequirementsspecification,designmodelsandclosed-loopsimulationsusingaunifiedlanguageandasinglesoftwaretool.

Whenworkingoncomplex,possiblydistributed,plantsthereisoftentheneedtoreplaceaphysicalcomponent(e.g.withanothercomponentthatperformsagivenphysicalprocess,likewelding,inadifferentway).

Futureworkaimstoexploittheproposedunifiedlanguagetoformalizetheconceptofbehavioralinheritanceformulti-domainsystems,whichincludesoftwareandphysicalcom-ponents,extendingtheresultsdescribedin[31].Infact,theinheritancemechanismssupportedbycurrentobject-orientedlanguages,bothforsoftwareprogrammingandphysicalsys-temsmodeling,arefocusedonthestructure,ratherthanonthebehaviorofsystemcomponents.However,preservingthebehaviorofabaseclassinalltheclassesderivedbyextensionfromitisveryimportanttoguaranteethatthesubstitutionofsomecomponentsinanautomatedsystemdonotaffecttheinteractivebehaviorofthemechatronicaggregate,whichisanecessityformanufacturingsystemsdesigners.

REFERENCES

[1]C.Secchi,C.Fantuzzi,andM.Bonf´e,“Ontheuseofumlformodeling

physicalsystems,”inProceedingsofIEEEInternationalConferenceonRoboticsandAutomation,Barcelona,Spain,April2005.

[2]——,“Unifiedmodelingofcontrolsoftwareandphysicalplants,”in

ProceedingsofIFACworldCongress,Prague,CzechRepublic,July2005.[3]M.Bonf´e,C.Fantuzzi,andC.Secchi,“Object-orientedmodelingof

multi-domainsystems,”inProceedingsofIEEEConferenceonAutoma-tionScienceandEngineering,Edmonton,Canada,August2005.

[4]P.Piela,“ASCEND:Anobject-orientedcomputerenvironmentfor

modelingandanalysis,”Ph.D.dissertation,CarnegieMellonUniversity,19.

[5]S.MattssonandM.Andersson,“Theideasbehindomola,”inProceed-ingsoftheIEEESymposiumonComputer-AidedControlSystemDesign,March1992,pp.23–29.

[6]A.Jeandel,F.Boudard,P.Ravier,andA.Bushing,“ULM:amodelling

language,”inProceedingsoftheCESAIMACSMulticonference,Lille,France,July1996,pp.781–7.

[7]M.Tiller,Ed.,IntroductiontophysicalmodelingwithModelica.Kluwer

AcademicPublisher,2001.

[8]L.Capretz,“Abriefhistoryoftheobject-orientedapproach,”ACM

SIGSOFTSoftwareEngineeringNotes,vol.28,no.2,2003.

[9]O.M.G.,“UMLv.1.4,OMGspecifications,”DocumentN.formal/2001-09-67,2001,www.omg.org/uml.

[10]T.Quatrani,“IntroductiontotheUnifiedModelingLanguage,”Objec-TimeLimited/RationalSofwareCorp.whitepaper,2001.

[11]J.Rumbaugh,I.Jacobson,andG.Booch,TheUnifiedModelingLan-guageReferenceManual.Addison-Wesley,1999.

[12]I.E.C.,“IEC61131-3.ProgrammableControllers-Part3:programming

languages(2ndedition),”Finaldraftinternationalstandard(FDIS),2002.[13]——,“IEC61499-1.FunctionBlocksforIndustrialProcessMeasurment

andControl-Part1:Architecture,”PublicAvailableSpecification(PAS),2000.[14]M.Bonf´eandC.Fantuzzi,“Designandverificationofindustrial

logiccontrollerswithUMLandstatecharts,”inProceedingsofIEEEConferenceonControlApplications,Instanbul,Turkey,June2003.[15]K.Thramboulidis,“Usingumlincontrolandautomation:amodel

drivenapproach,”inProceedingsofIEEEInternationalConferenceonIndustrialInformatics,Berlin,Germany,June2004,pp.587–593.

[16]B.SelicandL.Motus,“Usingmodelsinreal-timesoftwaredesign,”

IEEEControlSystemsMagazine,vol.23,no.3,pp.31–42,June2003.[17]H.Paynter,AnalysisandDesignofEngineeringSystems.M.I.T.Press,

1961.

[18]D.Karnopp,D.Margolis,andR.Rosenberg,SystemDynamics:A

UnifiedApproach,2nded.JohnWiley&SonsInc.,1990.

[19]E.Lee,“OverviewofthePtolemyproject,”UniversityofCalifornia,

Berkeley,USA,Tech.Rep.,July2003.

[20]J.Axelsson,“Real-worldmodelinginUML,”inProceedingsofthe13th

InternationalConferenceonSoftwareandSystemsEngineeringandtheirApplications,Paris,France,December2000.

[21]——,“Unifiedmodelingofreal-timecontrolsystemsandtheirphysical

environmentsusingUML,”inProceedingsoftheInternationalConfer-enceontheEngineeringofComputerBasedSystems,Washington,USA,April2001.

[22]B.Selic,“AgenericframeworkformodelingresourceswithUML,”

Computer,vol.33,no.6,June2000.

[23]S.Partners,“SystemModelingLanguage(SysML)specification,”Draft

v.0.9,January2005,www.sysml.org.

[24]B.SelicandJ.Rumbaugh,“UsingUMLformodelingcomplexreal-timesystems,”ObjecTimeLimited/RationalSofwareCorp.whitepaper,March1998.

[25]O.M.G.,“UMLv.2.0,OMGrequestforproposal,”DocumentN.ad/2003-03-02,2003,www.omg.org/uml.

[26]A.vanderSchaft,L2-GainandPassivityTechniquesinNonlinear

Control,ser.CommunicationandControlEngineering.SpringerVerlag,2000.

[27]G.Golo,A.vanderSchaft,P.Breedveld,andB.Maschke,“Hamiltonian

formulationofbondgraphs,”inNonlinearandHybridSystemsinAutomotiveControl,R.JohanssonandA.Rantzer,Eds.Springer-Verlag,2003,pp.351–372.

[28]B.Selic,“Protocolsandports:reusableinter-objectbehaviorpatterns,”

inProceedingsoftheSymposiumonObject-OrientedReal-TimeDis-tributedComputing,Saint-Malo,France,May1999.

[29]W.Borutzky,“Bondgraphmodelingfromanobjectorientedmodeling

pointofview,”Simulationpracticeandtheory,vol.7,pp.439–461,1999.

[30]“RationalRoseRealTime,”http://www.ibm.com/software/rational.[31]M.Bonf´e,C.Fantuzzi,andC.Secchi,“Inheritanceofbehaviorinobject-orienteddesignsforindustrialcontrolsystems,”inProceedingsofIFAC

worldCongress,Prague,CzechRepublic,July2005.