Systems Engineering Interfaces: A Model BasedApproachElyse Fosse, Christopher L. DelpJet Propulsion Laboratory, California Institute of Technology4800 Oak Grove DrivePasadena, CA 91109elyse.fosse@jpl.nasa.govAbstractThe engineering of interfaces is a critical function ofthedisciplineofSystemsEngineering. Includedininterfaceengineering are instances of interaction. Interfaces provide thespecicationsof therelevant propertiesof asystemorcom-ponent that can be connected to other systems or componentswhile instances of interaction are identied in order to specifythe actual integration to other systems or components. CurrentSystems Engineering practices rely on a variety of documentsand diagrams to describe interface specications and instancesof interaction. The SysML[1] specication provides a precisemodel based representation for interfaces and interface instanceintegration. This paper will describe interface engineeringasimplementedbytheOperationsRevitalizationTaskusingSysML, startingwithagenericcaseandculminatingwithafocus on a Flight System to Ground Interaction. The reusabilityof the interface engineering approach presented as well as itsextensibility to more complex interfaces and interactions will beshown. Model-derived tables will support the case studies shownand are examples of model-based documentation products.TABLE OF CONTENTS1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 INTERFACE PATTERNS AND POINTS OF VIEW . . 13 MODELING INTERFACES WITH SYSML. . . . . . . . . 24 OPERATIONS REVITALIZATION INTERFACEENGINEERING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 SUMMARY. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8ACKNOWLEDGMENTS. . . . . . . . . . . . . . . . . . . . . . . . . . . 8REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8BIOGRAPHY. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81. INTRODUCTIONThe topic of Interfaces is at the heart of the multi-disciplinarynatureof SystemsEngineering. Thisareacoverswhat isnecessaryinorder toconnect theindividual piecesoftheSystem together into a working System. To accomplish theconnection the relevant properties and behavior of each partof the Systemmust be specied. It is also necessary to specifythe particular connections between each part and the natureof those connections in terms of limitations,protocols,andvarious operational conditions or scenarios.The describing and specifying of interfaces in a general wayis a challengingproblem. Current Systems Engineeringpracticesrelyonavarietyof documentsanddiagramstodescribe interface specications for different Systems as well978-1-4577-0557-1/12/$26.00 c 2012 IEEE.c 2012CaliforniaInstituteofTechnology. Government sponsorshipac-knowledged1IEEEAC Paper #2562, Version 2, Updated 5/1/2013.as existing industry standards for specic kinds of interfaces.SysML[1] provides a precise model based representation forspecifyingtheinterfacesof partsandintegrationbetweenparts through those interfaces. The language also allows fordomain-specic semantics to be applied as an extension to thebasic modeling capability of SysML.TheinterfaceengineeringworkperformedbytheOpera-tions Revitalization(Ops Rev) Task[2], sponsoredbytheMultimission Ground Systems and Service Ofce of NASA,utilized a model based approach to represent the interfacesandinteractionsrequiredforaMissionOperationsSystem(MOS).MissionOperationsSystemsEngineeringconcernswith interfaces begin with the Flight-Ground Interface. Theinterface focuses on the interaction between the Flight Sys-tem and the Ground System. Within the Ground System theMOSmustinterfacewithgroundstations, networks, andahostoforganizations. WithintheMOS, MissionServices,Operations Roles, andSoftwaremust interfacewitheachother.This paper will describe the key Viewpoints used to denethe patterns for modeling MOS interfaces. These Viewpointswill then be complemented by examples from the MOS 2.0Architecture [2]. Beginning with the Flight-Ground Interface,examples from these models will be used to illustrate speci-cation of Interfaces, Interactions between Interfaces, and thelimitations and operational contexts of those interactions.2. INTERFACE PATTERNS AND POINTS OFVIEWOps Revitalization is building a model of a Mission Opera-tions System (MOS). The interfaces for Mission OperationsSystems cover a broad range of systems, software, hardware,and human interactions. In order to model this broad rangeof interfaces andinteractions, it is useful todescribethesystem from different points of view [3]. Ops Revitalizationhas developed the Mission Service Architecture Framework(MSAF)[4]. TheMSAFdenestheatomicinterfaceen-gineering components (Table 1) as well as a set of patternsfor modeling this broad set of integrated systems and otherpatterns intheMOS. ThesebasicViews canbeusedtodescribe the different interfaces related to the MOS.Table 2 identies the Viewpoints that address important con-cerns with respect to the topic of interfaces. Part InterfaceViewpointsofthesystemdescribewhatinterfacesthepartpresents. TheInterfaceLayeredViewpoints describetheinterfacesinarecursivemannerandareaspecial caseofthe Part Interface Viewpoint. In systems where software ispart of thesystem, it iscommontohavelogical layeringof software interfaces on top of hardware. Interface Speci-cation Viewpoints describe the individual specications of1Table 1. Interface Engineering DenitionsTerm DenitionInterface The system boundary that is presented by a system for interaction with other systems.Interface Specication Describes the nature of the boundary presented by a system or component in terms of propertiesand functionality.Interaction An instance of an operational entity (system, organization, or services) interface. The interactioncan connect to other operational entities according to its Interaction Specication.Interaction Specication Describes howanoperational entity(system, organization, or service) caneffect anotheroperational entity when a connection exists.Table 2. ViewpointsViewpoint Purpose ConcernPart Interface Identify Interfaces for a given Part. What are the interfaces for a given Part?Layered Part Interface Specifylayeringof interfaces suchasapplication, protocol and data layers.What is the structure of the different in-formation aspects on the interface?Interface Specication Specify a given Interface in terms offunctions and properties of that interface.What is the detailed set of functions andproperties of a given interface?Interface Connection Specify the integration of 2 or moreParts through their respective Interfacesintermsof thespecicconditionsandfunction occurrences that dene the inte-gration according to the Interface Speci-cation.What Parts are connected to each other?Interface Object Flow Specify how objects (materials, informa-tion)owacrossagivenintegrationofinterfaces for a set of Parts.What are the ows between parts of thesystem?Interface Function Occurrence Specicationfor behavioral interactionacross interfaces.How do functions occur between Parts ofthe System?Performance and Limitations on In-terfacesSpecify constraints on interfaces suchas policies, agreements and performanceconstraints.What are the expectations and limits ofthe given integration?eachInterface. ThePartInterface, LayeredPartInterface,andInterfaceSpecicationViewpointsdescribethepartofthe system in terms of interfaces without explaining how theywill be integrated. Providing these views of the system allowsthe Systems Engineer to evaluate and analyze parts based ontheir interfaces separately from how they will be integrated.The remaining set of Viewpoints in Table 2 refer to how Inter-faces may be instantiated into Interactions in order to describecontext-specic integrations and behavior. Interface Connec-tionViewpointsidentifywhatpartswillbeintegratedwitheach other and howthey will behave when they are integrated.Interface Object Flow Viewpoints describe how objects areallowed to ow across the interfaces of the integrated parts inthe context with which the parts are integrated in. The objectscould be physical objects, like shipping a spacecraft to CapeCanaveral, or Radio Waves in deep space. The objects couldalsobelogicallikedatamovingthroughcables. InterfaceFunction Occurrence Viewpoints show behavior interactionbetweenparts. Fromthisvantagepointthesystemcanbedescribed in terms of the occurrence of functions and eventsamong the interfaces of components. Interface ConstraintsViewpoints describe how the interface is constrained. Thiscould be in the form of expected performance or operationallimitations. Together, these Viewpoints describe integrationof parts through their interfaces.3. MODELING INTERFACES WITH SYSMLThe SysMLspecicationprovides a precise model-basedrepresentation for interfaces and interactions. Interface spec-ications are described using SysML ow ports, operations,andsignals whichcorrelate tothe systemor componentinterface properties, as shown in Table 3.Table 3. Interface Specications To SysMLInterface Property SysML PropertyFunctions OperationsSignals SignalsInformation I/O Flow PortsMaterials I/O Flow PortsA simple system will be used to describe the Ops Rev TaskssSysML interface engineering implementation. The followinggures and tables are views into the SysML model describingthesystemshowninFigure1, whichiscomprisedoftwosystems, A and B. The previously identied viewpoints willbeelaboratedpresentlyusingSystemAsinterfaceanditsinteraction with System B2Figure 1. System IdenticationInterface Specication ViewpointEvery system or component that is intended to be composedintoagreatersystemhassomefunctionalitythatthecom-prising system needs. The functionality is a property of thesystemorcomponent, independentfromwhomthesystemor component isintendedtointeract with. TheInterfaceSpecication Viewpoint focuses on identifying the function-ality properties as operations owned by a SysML block.Thefunctionality identied is the generic set of functionality thatis available to any system or component when an interactionexists.Figure 2. Functionality SpecicationFigure 2 illustrates that an interface element named SystemA Interface Functionality Specication is used to describethe functionality of SystemA. The functions that are availablefor use by other systems or components during an interactionare shown on the interface element as operations. The param-eters of the operation are suppressed in Figure 2 for the sakeof readability and are instead shown in Table 4. Noticationsare also specied on the interface element and are accessibleduring an interaction with System A.The System A Interface Functionality Specication is real-ized by the System A Interface Specication which meansthatthefunctionalityidentiedisavailableforusewhenaSysML port is typed with the System A Interface Specica-tion block. Describing the functionality in this way allowsfor the reusability of the interface specication. Any SysMLport that is typed by the System A Interface Specicationwill automatically have the functionality specied.Note that Ops Rev utilizes the extensibility of SysML to cre-ate a Domain Specic Language (DSL) by extending SysMLBlock to Interface Specication and SysML operation toInterfaceOperation, asseenasstereotypes(enclosedbyguillemets)fortheirrespectiveelementsinFigure2. Ex-tendingSysMLandcreatingtheappropriatecustomizationclasses allows for anyproperties or relationships that aretrue for any interface specication or interface operation tobecreatedonceandbereusedbyapplyingtheappropriatestereotype. For example, if all interface specications havesome property that identies the time for which the specica-tion is valid, then this property can be a part of the block thatis associated with the customization class for the InterfaceSpecicationstereotype. Whenthestereotypeisappliedtoanotherelement, theelementwillalreadyhavethetimeproperty associated with it.ExtendingSysMLinthismanneralsoallowsSystemsEn-gineers implementing the interface pattern to now work andimplement SysML elements that make sense for their domain,such as Interface Specication or Interface Operation.Table 4. System A Operation I/OOperation Inputs OutputsDo Something Raw Input Manipulated OutputTable5identiesthetypeofinformationparametersusedin System A interface operations. The parameter types arethemselves SysML Blocks and can have properties specicto them such that when applied as the type of a parameterthat parameter has those same properties. The overall patternthat is emerging is that SysML provides the ability to spec-ify properties in a recursive fashion (an interface has someinformation property which in turn has some other deningproperty, and so on). A Systems Engineer is able to identifyand dene properties at any level of delity that is necessary.For example, currently the Information Specication blockthat types the functional inputs and outputs has no propertiesexplicitly identied, which is assumed to be the correct levelofdelity. Ifat alaterpoint intimeaSystemsEngineeridenties some propertythat is true for all InformationSpecications the property can be added to the element in asingle place in the model and all other elements that are typedby the Information Specication will receive that update.Table 5. Operation I/O Information TypesFunction Input/Output TypeRaw Input Information SpecicationManipulated Output Information SpecicationThe model-derived gures and tables described in this sectioncomprise a interface specication view for System A. Thisviewcouldbeincorporatedintosupportinginterfacedocu-ments or presentations by a Systems Engineer to provide anaccurate and explicit denition of the interface functionalityof System A.Layered Interface ViewpointSysMLowports onaninterface specicationprescribesomesort oflogical layeringwhichtheSystemsEngineer3Figure 3. Information Interface Layerwants to abide by. Layering interfaces contributes to the sep-aration of concerns methodology driven out by Viewpoints.In particular it is possible to create ports on an interface spec-ication, thus creating nested ports. The ports nested uponthe interface specication concern themselves with propertiesthat provide greater detail about the specication.Figure3illustrateshowtheSystemAInterfaceSpeci-cationfurtherderivespropertiesabout thetypesofinfor-mationSystemAexpectsorprovidesinordertofulllitsfunctionality. It follows then that the information identiedasportsarerelatedtothefunctional parametersidentied(referbacktoTable5). Thisrelationatthesimplestlevelcould be an equivalent, but could also be a subset relationshipwheretheinformationinputsandoutputsforthefunctionscouldbeasubset of theinformationactuallyexpectedorprovidedontheport. Theimplicationthenisthatthereissome system functionality that is not used by another systemor component, but is neededfor that systemtomeet itsobjectives.Interface ViewpointThepropertiesdesignatedbyaninterfacespecicationareappliedtoasystemsinterfaceinSysMLbyassigningthetypeoftheinterfaceporttobethatoftheinterfacespeci-cationelement. Thismeansthatthesystemspecicationhas the details of the interface, regardless of with whom thesystem is expected to interact. Decoupling the systems inter-action(s) and interface in this way allows a systems engineerto describe the concerns of the interface without convolvingthose concerns with that of interactions. The implication isthat a systems interface can be identied and specied oncewith as many instantiations as needed to achieve the expectedinteractions.Figure 4 shows that the SystemAport stereotyped Interfaceis typed by the System A Interface Specication that waspreviously dened. The assignment means that System AInterface has all of the functionality and information proper-ties as dened by the System A Interface Specication. Theinterface for System A has been fully dened with no regardto System As interactions. As interactions with System Aareidentied, theSystemAInterfaceisinstantiatedandrened to meet the explicit needs of the specic interaction.Interface Connection ViewpointThe method of instancing an interface involves redening theinterface specication into an interaction specication. TheFigure 4. System A Interfaceredenition involves redening port and operation propertiesto meet the specic needs of the interaction. The assertion isthat all instances contain a subset of the properties dened inthe interface specication. Mathematically, letS be the setof interface properties specied by an interface specicationand let S

be the set of interaction properties specied by aninteraction specication. Based on SysML redenition rules,it follows then that, S

S.Figure 5 shows that the System A interface specication isspecialized to be an interaction specication for the exchangebetween System A and System B. For completeness all prop-erties of the interface need to be inherited as well and as aresult the functionality of System As interface is specializedtobe specicforthe exchange. Functionalityfor SystemB redenes the interface operation found on System A In-terface Functionality Specication. The redenition meansthat the the properties of the Functionality For System Binterface operation, such as its parameters, are either of thesametypeastheredenedinterfaceoperationDoSome-thing or have a type that further renes the type that is beingredened. Theinformationimplementedintheinteractionspecicationisaspecializationof theblockusedtotypeinformationinthe interface specication. Similarly, theinformation property schema renes the generic propertyinformation property. Completing the redenition involvescreating a new port on the System A block and having thatportredenetheSystemAInterfaceport. Additionally,thenewportistypedwiththenewlyinstancedinteractionspecication. System A now has the port needed to fulll itsneed to interact with System B.Creating the interface and interaction with this model basedapproach allows a Systems Engineer the ability to implementautomation (exploiting the patterns and stereotypes used) inorder to completely and rapidly redene an interface for eachnecessary interaction. The automation employs the DSL tocapture and replicate (e.g., specialize) inheritance, composi-tion, and dependency relationships and the afliated modelelements, thus ensuring that all interactions are implementedinasimilar manner andtherebyremovinganyambiguityfrom their specications or descriptions.Figure 6andTable 6together describe the functionalityoccurrencesinSystemAsinteractionwithSystemB. Thegure shows explicitly that there is a connector between the4Figure 5. Complete Interface InstanceTable 6. Interaction Functionality DescriptionInteraction Spec Inputs OutputsSys A - Sys B Interaction SpecFunctionality for System B I.P. B I.P. ASys B - Sys A Interaction SpecSystem B Interface Operation I.P. A I.P. Btwo interface instances. The table implements a nested tabletechnique such that the interface is identied and,indentedwithinthe next row, are the functional properties of theinterface as well as the operations corresponding inputs andoutputs. For conciseness, I.P. means Information Productand Spec means Specication.Figure 6. System InteractionWhile SystemBs interface andinteractionspecicationswerent derived explicitly, the assumption has been made thatSystem B has a single interface operation and its inputs andoutputsaretheexact conjugatesofSystemAsinputsandoutputs.Interface Object FlowFigure7andTable7togetherprovideaninformationex-change view of System As interaction with System B. Eachinteraction is expanded to show their respective nested owports, whichidentifytheexpectedinputsandoutputsthatoccurduringaninteractionbetweenthetwosystems. Allinformation described in Tables 6 and 7 have InformationProduct as their type, which is also shown in Figure 7 asthe information that is conveyed during the interaction. Con-necting the interactions and typing the connections with theinformation ows completes the interaction denition. It canbe seen then that an interaction is comprised of two or moreinterface instances with conveyed information connections.Figure 7. System Information InteractionTable 7. Interaction Information DescriptionInteraction Spec Inputs OutputsSys A - Sys B Interaction Spec I.P. B I.P. ASys B - Sys A Interaction Spec I.P. A I.P. BTheinstantiationprocesscanbereusedasmanytimesasneeded to specify all of System As interactions. Thus thismethodallowstheSystemsEngineertospecifysystemorcomponent interfaceproperties onceandredenespecicaspects as needed on an interaction-by-interaction basis. Theredenition part of the approach can be automated such thattheSystems Engineer is abletofocus ontheaspects ofinteractionthat aredifferent andallowtheautomationtotake care of the repetitive mechanics of interface instancing.The views shown can be queried from the model such thatthe Systems Engineer can provide stakeholders with accurateinformation about interfaces and interactions in a template-able manner.Performance Limitations on Interfaces ViewpointAlmost every interaction a Systems Engineer identies hassome sort of timing (e.g.,duration or frequency) or quality(e.g., lossless)constraintthatmustbemetinorderfortheinteraction to be successful. To accommodate this, themodel basedapproachisextendedtoincludeSysMLcon-straint blocks as agreements among two or more systems orcomponents. These agreements can contain all constrainingparameters andareplacedbetweentheconnectors of theinteraction, as seen in Figure 8.5Figure 8. System Interaction with AgreementThepropertiesthat pertaintotheagreement couldincludebut are not limited to the quality of the Information Productsexchanged between System A and B as well as the timelinesswith which System A expects to receive Information Productsfrom System B.4. OPERATIONS REVITALIZATIONINTERFACE ENGINEERINGTheinterfaceandinteractionmodelingapproachwas ex-tended by the Ops Rev Task in order to represent interfacesand interactions required throughout mission operations as itpertains to a Multi Mission Operations System(MMOS). Thenecessary extension was for the pattern to be implemented ina deeper nested port manner (two levels of nested interfacesrather thanone) inorder toseparateout control concernsthat the Ops Rev Task is addressing. A Mission OperationsSystems Engineer (MOSE) is particularly interested in howtheMMOSinteractswithothersystemssuchasaProjectorFlightSystem, aswellashowtheMMOSisorganizedinternally based oninteraction. The following section willshow the Ops Rev Tasks implementation of the approach asit applies to a ight system and ground interaction, which is ahigh valued interaction for an MOSE to describe. Anotherimplementation will be shown that focuses on howtwoMission Services, components of the MMOS, interact witheach other in order to achieve the MMOSs over-arching goal.Theunionoftheseimplementationswillshowthegenericapproachs extensibility and reusability.The description that follows is comprised of views, each ofwhich conforms to a previously described viewpoint. The ab-sence of a viewpoint can be understood as future or ongoingwork for the Ops Rev Task.MMOS - Flight System Interface Connection ViewTheinterfacespecicationfor theMMOSis assumedtobefullyspeciedandthereforereadyforinstancing. Theassumptions made on the interface are that the functionalityavailableis delegatedtotheMMOSfromits componentMissionServices(i.e., theMMOSdoesnot carryout thefunctionality but delegates the appropriate work to the appro-priate Mission Service), and that the functionality parametersas well as informationrequiredor providedaretypes oftimelines[4]. The specication of the Flight System interfaceis outside of the purview of the Ops Rev Task and as a resultthe functionality is undened. Figure 8 and Table 7 togetherprovideafunctional viewoftheMMOSsinteractionwitha Flight System. The functionality shown to be that of theMMOS is delegated to the MMOS by one of its componentMissionServices, theMissionEngineeringService. Forconciseness, Cfg means Conguration, Telem means Teleme-try and portions of the MMOSs interaction functionality arehidden.There is added complexity compared to the previous sectionduetotheinclusionoftheGroundDomain. TheGroundDomainactsasadelegatefortheMMOSinteractionwiththe Flight System, and as such nests the MMOS Interactionwith the Flight System onto its own interaction port with theFlight System. That is, the Ground Domains interaction withthe Flight System specication includes a property that is theMMOSs interaction with the Flight System specication. Forthis reason, Table 8 excludes the Ground Domains interactionspecication in order to eliminate redundancy.Figure 9. MMOS Functionality InteractionTable 8. MMOS Interaction Functionality DescriptionInteraction Specication Inputs OutputsMMOS - FS Interaction SpecUpdate Commands Cmd TelemUpdate Conguration Cfg Loads Cfg TelemFS - MMOS Interaction SpecN/AMMOS - Flight System Object Flow ViewFigure 9 and Table 9 provide an information exchange viewof the MMOSs interaction with a Flight System. There isadded complexity compared to the previous section due to theaddition of a MMOS-Flight System Controller Interactionport. The Ops Rev Task sought to not only separate interfaceandinteractionfunctional andinformational concerns, butalso to further decompose information concerns as to the typeof control trying to be achieved. A controller/controlled inter-action is one type of control that the task has identied. Notethat the conveyed information is an information type specicto Mission Operations such that the notion of Timeline[5]isextended to include mission operational concepts as conveyedinformation between the MMOS and other systems.6Figure 10. MMOS Control Information InteractionTable 9. MMOS - FS Interaction Information DescriptionInteraction Spec Inputs OutputsMMOS - FS Controller Int Spec FS Telem FS CmdsFS - MMOS Controlled Int Spec FS Cmds FS TelemMMOS Internal Interaction Object Flow ViewThe Ops RevTaskalsoimplementedthe same interfaceengineeringapproachtospecifyinterfacesandimplementinteractions for MMOS components, known as Mission Ser-vices. Mission Services exert a different type of control oneach other, called director/directed control. Figure 4 is a viewof howthe MMOSs MissionEngineeringService(MES)interacts with the MMOSs Flight Systems Engineering Ser-vice(FSES). The information identied in the view describesinformationpertainingtostate, whichis a subset of theinformation that may be conveyed between these two Mis-sion Services in pursuit of directional control. Informationpertaining to commands and activities would also need to beincluded in this view for it to be considered complete. Forconciseness, the supporting tables are suppressed here but canbe queried and rendered out of the model.This section has shown that the generic interface engineeringapproachwascompetentenoughtobeimplementedinthecontext of mission operations for the Ops Rev Task. Not onlywas the approach sufcient, it was shown to be extensible andreusable. The approach allows the Ops Rev Task to reduce theamount of effort focused on creating documents , and insteadfocus on specifying the interfaces and interactions in a model-basedwaysothatthecorrespondingviewscanbederivedin a formulaic manner. Further automation endeavors haveallowed the Ops Rev Task to capitalize on this approach byreducing the effort needed for the instantiation of interfaces.VericationA model-driven interface engineering approach provides theSystems Engineer with some useful verication functionality.Whendealingwithcomplexsystems it is arduous for ahumantocondentlyverifythatallinformationexchangesare appropriate and correct. Using blocks to type the owports on the interfaces, as well as to type the parameters ofoperations, allows the Systems Engineer to query the modelto check that all interactions have allowable types connected.Rulescanbecreatedthat identifytheallowableport typeconnections. Themodelcanthenbequeriedandalistofinvalid connections can be produced. Further, implementinga generalization hierarchy to the blocks used as informationtypes, as seen in Figure 5, affords the Systems Engineer theability to use generic types early in the interface engineeringtask. These types can be later rened to include more specicinformation types as that information becomes available, oras it is needed to describe the interfaces and interactions at aprescribed level of delity.Interface Function Occurrence ExtensionTheinteractionacrossinterfacescanbespeciedthroughSysML Sequence Diagrams. A current limitation of SysMLis that it is difcult to associate operations on a block withfunctions calls on a Sequence Diagram. This limitation disal-lows that ability to have the functionality of a system tracedacross interactions. It is possible, with some adaptations andextensionstoSysMLtoextendthemodel basedapproachtoincludefunctionoccurrencesamongtwoormorecom-ponents. These occurrence would be shown on a SequenceDiagramalongwiththeirassociatedtimelinessandqualityconstraints.7Figure 11. MES to FSES Interaction5. SUMMARYThe Ops Rev Task implemented a model-based engineeringapproach to provide a more rigorous and formulaic descrip-tion of interfaces and interactions. The task uses a separation-of-concerns methodologytobothprovide descriptions ofthe interfaces and interactions, as well as to decouple theirspecications. The implementation was shown to be reusableinbothagenericmanner, aswellasinitsapplicabilitytoengineering the Multi Mission Operations Sys- tem(MMOS)interfacesfortheOpsRevTask. Itsextensibilitywasalsoshown through the MMOS cases presented. The efciencyof the approachinterms of viewgenerationandmodelverication has afforded the Ops Rev Task more time to focuson the engineering of the interfaces and interactions and lesson document generation and narrative descriptions.ACKNOWLEDGMENTSThe work described in this paper was performed at the JetPropulsionLaboratory, CaliforniaInstituteof Technology,underacontract withtheNational AeronauticsandSpaceAdministration.REFERENCES[1] ObjectManagementGroup, OMGSystemsModelingLanguage (OMG SysMLTM), version 1.3, OMG, Tech.Rep. OMGdocument number formal/12-06-02, June2012.[2] D. Bindschadler, C. L. Delp, and M. McCullar, Princi-ples to Products: Toward Realizing MOS 2.0,in Pro-ceedings of the 12th International Conference on SpaceOperations, Stockholm, Sweden, June 2012.[3] ISO, ISO/IEC42010 Systems and software engineering-Architecture description, Tech. Rep., 2011.[4] e. a. Chris L. Delp, Mission Service Architecture Frame-work: Model Based Mission Operations Systems Engi-neering.[5] S. H. Chung and D. Bindschadler, Timeline-based Mis-sionOperationsArchitecture: AnOverview, inPro-ceedings of the 12th International Conference on SpaceOperations, Stockholm, Sweden, June 2012.BIOGRAPHY[Christopher L. Delpis the Systems Ar-chitect for the Ops Revitalization task inMGSS and a Lead Systems Engineer forMBSE on the Europa Mission. He is afounder of the Modeling Early Adoptersgrass roots Model BasedEngineeringworking group. Chris continues to leadthe INCOSE Space Systems WorkingGroupMBSEChallengeTeamfor theINternational Council On Systems Engi-neering. Previously he served as Flight Software Test Engi-neer for MSL and Software Test Engineer for the Tracking,Telemetry, andCommandEnd-to-EndDataServices. Healso leads the INCOSE Space Systems Working Groups entryin the Model Based Systems Engineering Grand Challenge.Additionally, he has performed research on software verica-tion and tools for Service-Oriented Architecture in support ofthe Deep-space Information Services Architecture. Prior tocoming to JPL, he worked as a software engineer performingDO-178bLevel FAAight qualiedsoftwaredevelopmentand testing on Joint Tactical Radio System (JTRS) and the T-55 Full Authority Digital Engine Controller (FADEC). Chrisearned a Master of Science in Systems Engineering from theUniversity of Arizona where he studied Model Based SystemsEngineering, Simulation and Software Engineering. Previousto graduate studies, Chris performed his duties as a systemsengineer on Missile Systems Verication and Validation.Elyse Fosse is a Software Systems En-gineer for theOps Revitalizationtaskin MGSS. She developed ground systemcost modelsfordeepspaceandEarthmissions. SheisalsoamemberoftheMultimission Ground Data System Engi-neering group at the Jet Propulsion Lab-oratory. Her interests include softwareandsystems architecture, applicationsof model-based system engineering, andcost model implementation and analysis. Elyse is also a partof the INCOSE Space Systems Working Groups entry into theModel Based Systems Engineering Grand Challenge. ElyseearnedherM.A. inAppliedMathematicsfromClaremontGraduate University and her B.S. in Mathematics from theUniversity of Massachusetts Amherst.8