A Model-BasedSystemsEngineering Framework forConceptDevelopmentbyBrian LondonB.S.,ElectricalandComputerEngineering,LafayetteCollege,2002M.S.,ElectricalEngineering, StevensInstitute of Technology,2004Submittedto the SystemDesignandManagementPrograminPartialFulfillment of theRequirementsfor theDegreeofMaster of ScienceinEngineeringand Management_____MASSACHUSETSINSMiTTEattheIOFTECHNOLOGYat theMassachusettsInstitute of Technology MAR0820122012ARCRAIES@2012BrianNathanielLondon.AllrightsreservedTheauthor hereby grantsto MITpermissionto reproduceandto distributepubliclypaperand electroniccopies of this thesisdocumentin whole or in part inany mediumnowknown or hereaftercreated.Signatureof AuthorBrianN. LondonSystemDesignandManagementProgramJanuary2010CertifiedbyDonna H. RhodesThesisSupervisorSeniorLecturer, EngineeringSystemDivisionAcceptedbyPatrickHaleDirectorSystemDesignandManagementProgramAbstractThedevelopment of increasinglycomplex, innovative systems undergreater constraintshasbeenthetrendover thepast several decades.In order tobesuccessful,organizations must developproductsthatmeet customer needsmoreeffectively than the competitors'alternatives.Thedevelopmentofthese concepts is basedona broadset of stakeholder objectives, fromwhichalternativedesigns aredevelopedandcompared.Whenproperlyperformed,this process helps thoseinvolvedunderstand thebenefits anddrawbacksof eachoption.Thisis crucial asfirms needto effectively and quickly exploremany concepts,andeasily determine thosemostlikely tosucceed.It is generallyaccepted that a methodicaldesign approachleads to thereduction indesignflaws andcostover a product's life cycle.Several techniqueshave been developedto facilitate these efforts.However, the traditional tools andworkproductsareisolated,andrequirediligent manualinspection.Itis expectedthat the effectivenessof the high-levelproductdesign anddevelopment will improvedramatically throughthe adoption of computer basedmodelingandsimulation.This emergingcapability canmitigate the challenges andrisks imposedbycomplex systemsbyenforcingrigor andprecision.Model-basedsystems engineering(MBSE)is a methodology for designing systemsusing interconnectedcomputer models.Therecent proliferationof MBSEis evidence of itsability toimprove the designfidelity andenhancecommunicationamong development teams.Existingdescriptions of leveragingMBSEfor deriving requirements andsystemdesignareprevalent.However, very fewdescriptions ofmodel-basedconceptdevelopment havebeenpresented.Thismay bedue tothelack of MBSEmethodologies forperforming concept development.Teams that attempta model-basedapproachwithout welldefined, structuredstrategy areoftenunsuccessful.However, whenMBSEis combinedwitha clearmethodology,designs canbemoreefficiently generatedandevaluated.Whileit maynotbefeasibleto providea "standard"methodology for concept development,aframeworkis envisioned thatincorporates a variety of methods andtechniques.This thesisproposessucha frameworkandpresentsanexamplebased ona simulatedconcept developmenteffort.Thesis Supervisor:Dr.DonnaH. Rhodes,SeniorLecturer,EngineeringSystemDivisionAcknowledgmentsItis withutmostsincerity that I extendthis thanks to allthose whohave contributedto myincredibleexperience withthe SDMprogram.I wouldlike to thankmythesis advisor, DonnaRhodes,forherinvaluable guidance.Donna'sinput andexpertise were essentialinhelping mefocus my attention onatopic that truly interestedme,andhelpingmeto find the resources requiredto complete this thesis.I'dlike to thankPatHale,and therestof my SDMfriends.I enjoyed gettingto knowandlearning fromeachof you.My thanks goes out to allthose whoparticipatedintheinterviews.Yourinsights andexperiencehelpedsculpt andreinforce the theories discussedherein.I'dalsoliketo thankBog,Nick, andtherest of mycoworkerswho constantly challenge meto bea better engineer.Thisachievement wouldnotbepossible without the inspiration, motivation, andconstant support of myfamily.Withoutyou, I wouldnotbewhoI am.I'despecially like to thankmy wonderfulwife,Anne,whogaveme allthe loveand supportneeded to accomplishthis goal.Thank youfor yourpatience.Icouldn't havedone thiswithout you.Table of ContentsAbstract.........................................................................................................................................- ...----..2Acknow ledgm ents ........................................................................................................................................ 3Listof Figures................................................................................................................................................ 61.Introduction.........................................................................................................................................91.1ResearchObjectives.................................................................................................................... 131.2ApproachandResearchOverview ..........................................................................................131.3Thesis Contents...........................................................................................................................142.Background......................................................................................................................................... 152.1System s Engineering ...................................................................................................................152.1.1Life-CycleStages..................................................................................................................162.1.2System s EngineeringProcess.......................................................................................... 182.1.3ConceptDevelopm ent ..................................................................................................... 212.1.4DecisionAnalysis................................................................................................................. 252.2M odel-BasedSystem s Engineering........................................................................................ 312.2.1Benefits ............................................................................................................................... 322.2.2Tools.................................................................................................................................... 422.2.3ViewsandView points..................................................................................................... 432.2.4Languages........................................................................................................................... 442.2.5M ethodology.......................................................................................................................622.3DODAF.........................................................................................................................................713.M BSEFram ework for ConceptDevelopm ent .................................................................................743.1ProblemIdentification ................................................................................................................ 783.2ProblemDefinition......................................................................................................................8243.2.1Glossary Creation ................................................................................................................ 843.2.2Stakeholder Analysis .......................................................................................................853.2.3ContextDefinition .........................................................................................................893.2.4UseCase Development..................................................................................................923.2.5RequirementsDevelopment.............................................................................................1003.2.6RequirementPrioritization...............................................................................................1043.2.7Verification Methods........................................................................................................ 1063.2.8Requirementsand DesignReviews...................................................................................1083.3ArchitectureDefinition............................................................................................................. 1083.3.1FunctionalityAnalysis........................................................................................................1113.3.2Structural Analysis.............................................................................................................1183.3.3Allocation of Behavior to Structure..................................................................................1253.3.4Constraintand RelationshipDefinition.............................................................................1263.3.5Dom ainExpertCollaboration............................................................................................ 1293.4Generationof Alternatives........................................................................................................1313.5DecisionAnalysis....................................................................................................................... 1373.5.1Priority Assessm ent...........................................................................................................1383.5.2Effectiveness Determ ination............................................................................................. 1403.5.3Concept Selection.............................................................................................................1414.Conclusions andRecom mendations .........................................................................................1435.FutureW ork..............................................................................................................................147W ork Cited................................................................................................................................................148List of FiguresFigure1:Ability toInfluenceConstructionCost over Tim e ....................................................................10Figure2;DoDProjectLifecycles.............................................................................................- ..........- .--17Figure3:NASAProjectLifecycles...............................................................................................................18Figure4:W aterfallM ethod....................................................................................................................... 19Figure5:System s EngineeringVeeM odel .............................................................................................. 20Figure6:General SpiralDevelopm ent M odel......................................................................................... 21Figure7:Houseof Quality .......................................................................................................................... 28Figure8:Sam pleUtility Curve..................................................................................................................... 29Figure9:Sam pleDSM................................................................................................................................ 31Figure10:Changingthe Paradigm .............................................................................................................. 33Figure11:Interdisciplinary M odelBasedEnvironm ent..........................................................................40Figure12:Exam ple OPMElem ents............................................................................................................. 46Figure13:FunctionalFlow BlockDiagramExam ple ...............................................................................47Figure14:Exam ple of anEFFBD................................................................................................................. 48Figure15:Relationship betweenSysM L andUM L.................................................................................49Figure16:TheFourPillarsof SysM L.......................................................................................................... 50Figure17: SysM L DiagramTypes................................................................................................................ 50Figure18:Exam ple of UseCaseDiagram................................................................................................ 51Figure19:Exam ple of anActivity Diagram..............................................................................................52Figure20:Exam ple of a SequenceDiagram(AddOne w ith tim ing).......................................................54Figure21:Exam ple of StateDiagram ..........................................................................................................556Figure22:Exampleof BlockDefinitionDiagram...................................................................................56Figure23:Exampleof internalBlock Diagram........................................................................................57Figure24:Exampleof RequirementsinDiagram...................................................................................58Figure25:Exampleof ParametricConstructsandDiagram...................................................................59Figure26:Exampleof MOEDefinition....................................................................................................60Figure27:Exampleof BlockProperties .................................................................................................61Figure28: VitechMBSEActivities Performedat EachLayer..................................................................64Figure29:OOSEMMethodology ................................................................................................................68Figure30:RationalHarmonyIntegratedSystems/EmbeddedSoftwareDevelopmentProcess.........69Figure31:RationalHarmony for MBSE.................................................................................................70Figu re32 :DODA FView s............................................................................................................................72Figure33:Concept DevelopmentMethodology...................................................................................76Figure34:ProblemIdentification ...............................................................................................................78Figure35:Exampleof a UAV'sMost ImportantRequirements.............................................................81Figure36:AllocatingRequirementsto MOE..........................................................................................82Figure37:ProblemDefinition .....................................................................................................................83Figure38:StakeholderNeedIdentification ..........................................................................................88Figure39:Exampleof ActorDecomposition .......................................................................................... 89Figu re 4 0 : UAV Co ntext...............................................................................................................................9 1Figure41:AdditionalInterfaceInformation..........................................................................................92Figure42:UAVCONOPS.............................................................................................................................93Figure43:UseCaseDiagramfor UAVOperations.................................................................................95Figure44:Exampleof Scenario for UAVLaunch........................................ 997Figure45:CapturingRequirementsas UseCaseAttributes.....................................................................103Figure46:Static RequirementPrioritization .........................................106Figure47:VerificationMethodsandTestCases...................................................................................... 107Figure48:ArchitectureDefinition Process ...............................................................................................110Figure49:Exampleof anActivityDiagram.............................................................................................. 113Figure50:AlternativeMethods for DepictingCyclic Activities...............................................................115Figure51:Exampleof UAVSequence Diagram....................................................................................... 116Figure52:Exampleof a UAVStateDiagram.............................................................................................117Figure53:ConceptualUAVDecomposition.............................................................................................121Figure54:Exampleof anImplementationSpecific StructuralDecomposition ........................................ 122Figure55:Exampleof UAVSubsystemInterfaces....................................................................................124Figure56:ParametricDiagramRelatingW eight toPropulsionPower....................................................127Figure57:ParametricModelof UAV CoverageAnalysis ......................................................................... 128Figure58:Generationof Alternatives......................................................................................................132Figure59:ControlledConvergence.......................................................................................................... 133Figure60:AlternativeLift Supplier Techniques.......................................136Figure61:DecisionAnalysis.....................................................................................................................137Figure62:Exampleof ParametricTradeStudy Calculation......................................................................14281.IntroductionSince the beginningof civilization, humanshavesought to developnew productsin order tobetterthemselves and their communities.Associety progressedtechnically, so didthe complexity of theproductscreated.Thecurrent rapidtechnicalexpansion and currentglobalcompetitiveenvironmentisproducingmoredemanding,sophisticatedcustomersin everymarket.Manycompaniesstruggle withanticipating future customers'needs.Thisis partiallydue to customersnot alwaysknowingwhat theywant.Whenthisuncertainty is coupledwith the existing ease of communication,marketschangerapidly.Capabilities initially thought tobefrivolous may quickly become essential.Assessingthecustomers'needs to deliver themostvaluable optionshasalways been the key to success,but productsnowneedto get tomarket fasterandmore efficiently.Speedin developmentis rootedin the ability to adapt to changingrequirementsandrapidly solveproblems.Buildingthe wrong featuresis a costly formof wastein engineeringdevelopment.Toidentify the functionality that will maximize value over theproduct lifetime,a rigorousrequirementcaptureprocess is necessary.Someorganizations chargeaheadwithout realizing thatthe originalstatement of the problemmay notbethebest,or even the right one(Karbanet al.,2011).When the needsareidentified,organizations sometimesstrugglewith settingclear objectives andsharing the project'sintent throughout the organization.Complexsystemdevelopmentusually requiresthecollaborationof multidisciplinary teams, whomusthavea commonunderstandingof thedesignandcustomerneeds.Eachparticipantmustbeable to efficiently capture andcommunicatetheir needs,feasibility assessments, anddesignsto other teams.However,the standardpractice is for domainspecialists to operate infunctional "chimneys"communicatingprimarily throughrequirementdocumentsandoccasionalintegratedproductteammeetings.Thelackof a closely coordinateddesigncanleadto integrationissues.Anextremeexample of thisis thedevelopment of anaircraft componentfactory.As thefactory completionneared,it was determinedthat the doorswerenot largeenough toaccommodatethe wingsit assembled(Wheelwrightand Clark,1992).This gross oversight demonstrateshowcrucialit is to understandthe impact of design decisions.Therelationshipsbetweenrequirements,elements, andfunctions mustbecommunicatedin orderto developrealistic, effective concepts.Thelargestdegree of freedomand greatest numberof possiblesolutions exist when a problemis firstdefined.As designdecisionsaremade,thenumberof possible solutions diminishes, establishing thelife-cycle costs.Figure1 shows therelationshipbetweenlife-cycles costsand the designstages.Thiscommitment tolife-cycle costs andloss of design freedommakethe early stages of concept designamong the mostimportantof a program(Wheelwright andClark,1992).This emphasizesthe necessityof efficient processes for defininglarge,complex systems.However,effective, systematic techniques todevelop conceptual systemsandoperationsarenot wellknown(Shadrick et al.,2005).Ability toConstructionCost100%InfluenceCosts100%ConceptualPlanningandFeasibilityStudies0DesignandEngineeringCDProcurementandConstructionC0-F C)01)-JStartProjectTimeFigure1:Ability to InfluenceConstruction Costover Time(Hendrickson,1998 )Effectiveconceptdevelopmentpresentsa dilemma.Whileexp-loringa largenumberof options isdifficult, innovationis bestachievedbyexploring asbroada set of concepts aspossible.If conceptsareselected tooquickly, a sufficient numberof perspectivesmaynothavebeenconsidered.Organizationsrequiremethodologiesto quickly exploremanyconcepts,andeasily determinethosemost likely to succeed.A frameworkis presentedin this thesis toincrease conceptdevelopmenteffectivenessbyemployingthemost suitable,establishedconcept generationtoolsandprocesses.Itprovides thestructureto convergeona solutionthat answersthe stakeholderneeds witha highdegreeof confidencebysysteminfluences.A standardprocessis notadvocated.Instead,theframeworkprovides theorganizationalstructureandguidancefor a numberof processes,regardlessof conceptdomain.A numberof potentialprocessesaresuggested,but developerscanselect their own.Thisiscrucialaseveryproblemand teamis uniqueandwillrequiredifferenttools andprocesses.Themethodology merges thebest practices of system engineering withthe useof rigorousmodelingandautomation.Modelsareusedtoidentify the requirements,develop candidatesolutions, and assesstheoptions.Theyprovide a cohesive sourcefor allproject information,improvingcommunicationandsystemunderstanding.Thishelpsidentify errors andpoorassumptions earlierin the developmentcycle,saving timeandmoney as fewer errorshave tobecorrected inlater stages.Designis also greatly improvedbyenforcing consistency betweendesign elements.Asananalogy,consider the stateof engineeringdrawingsbeforetheonset of parametriccomputer-aideddesign(CAD).In thepast,engineering solutionsweredocumentedthroughhand-writtenorisolatedcomputerdrawings.A slightchange to oneschematic couldhavea cascadethroughoutmultiple others.Whenevera changewasrequired, eachdrawinghadto beclosely reviewedandupdated tomaintainconsistency.With the adventof parametric CAD,componentscouldbelinkedtoeachother, allowingcomponent changesto cascadethroughthe design, easily identifying anyinconsistencies.Theadoption of integratedmodel-based systemsengineering(MBSE)is expected toprovidesimilarimprovements for systemconcept development.Optimizingspeed,cost,andquality requires arevolutionary changeinproduct development,andthis outcomeis expectedfromMBSE(Paredis,2011).Earlyuses of MBSEareshowing evidence of reduceddevelopment timeandlower errorrates.This canbepartially attributedto betterunderstanding of the problem."Witha traditional functionalrequirements decompositionapproach, weestimatethat we wouldhaveonly captured50% of theproblemunderstanding.Usingoperationalconcepts withuse casesandscenarios, we caughtmorethan90% of the problemunderstanding thefirst time through"(Jorgensen, 2011).Hardnumbersfor thedevelopment timereductions arehardtocomeby, earlysurvey results indicatethat upto 40% fewerrequirementdefects werefoundonMBSEprograms(Long,2011).While, most currentMBSEperformancedatais collectedheuristically, quantitativemetricsarebeing collected toprovidemoreconclusive evidence(Estefanet al.,2011).1.1ResearchObjectivesTheprimaryresearchobjective of this thesisis to investigate andproposea methodology for thedevelopmentof systemconcepts usinganMBSEapproach,specifically usingtheSysML language.Thegoalis proposegenericprocesses that couldapply to different organizations andefforts,but the resultsmaybebiasedby theapplication of this methodologyin theselectedcase studies.Thespecificquestions thatthis thesis will seek to answerinclude:1. CanMBSEsupport concept generation,refinement,andevaluation?2. Howcanthe best practicesof systemsengineering andconcept developmentbeintegrated?3. DoesMBSEimprovetheefficiency andeffectiveness of concept development teams?4. Whatprocesses and externaltools facilitate or enhancethe developmentprocess?5. What views, elements,andconstructsareuseful toimprovecommunication?1.2Approachand ResearchOverviewTheinterviewmethodwasusedtocomparethe methodology proposedinthis thesis against traditional,non-model-basedapproaches.Tworounds of one-on-oneinterviews wereconducted.Thefirstroundedconsist of questions toidentify the unmetneeds,bestpractices, andhindrances toconceptdevelopment.Theinterviewees wereselectedbased ontheir availability andexperiencedevelopingadvancedsolutions toextremely challengingproblems.WhileprimarilyDraperLaboratory systemsengineers wereinterviewed,their backgroundsrepresenteda rangeof engineeringdomains.13Datacollected from the first set of interviewswas comparedagainst the documentedsystemsengineerbestpractices.In addition, concept developmenttechniques fromengineering,marketing, andothercreativedomains were examined.As a result of theliterature survey, theMBSEframeworkfor conceptdevelopmentwas developed.Itwas designedusingSparx System'sEnterpriseArchitect toproducetheviews describedin the thesis.Enterprise Architectwasselectedbased onavailability, andis notspecifically advocatedbyMIT.Thesecondroundof interviews beganafter theinitial establishmentof the framework.In addition toexperiencedsystems engineers, widely recognizedleaders inthe field of MBSEwereinterviewed.Thefocuswas onthe MBSEmethodology, existing systemsbest practices, andtheir integration.Duringtheseinterviews theframeworkwas reviewedandcompared to traditionaldevelopmentpractices.Examplesof goodandbadexecutionweresharedtoobtain a better assessment of thebenefits, witha focus on:eVisualizationandclarity*Impactonknownbestpractices*Ability to assessdesign errorsor inconsistencieseTraceability andknowledgecapture*Easeof useandexpectedlearningcurve"Productivityimpact"Ability to support design decisions1.3ThesisContentsChapter Twosummarizesthe concept development methods,traditionalsystemengineeringpractices,andmodel-basedtools, methodologies, andlanguages. Thischapter providespertinent backgroundinformationto introduce the techniques thatareleveragedin this proposedframework.Itdoes notcontainsufficient details toteach them,but sourcesare citedthat canprovide additionalinformation.14Chapter Threeintroduces a framework toleverage theadvantages of MBSEfor conceptdevelopment.Thechapter introducedthe frameworkthat uses commercially availabletools andSysML.Examplesareprovidedto demonstratetheproposedmethodology from the requirementdefinition, systemarchitecture development, andUAVdesign selection.Theexamples arebasedfrom1998reportdescribing theuseof UnmannedAerial Vehicles (UAV)for a proposednotionalUAVforce structure.TheFourthchapter describes the conclusions of the proposedframeworkregardingits benefits andapplicability across various programs.These conclusions arebased onthe feedback fromexperiencedsystemsengineers and architects afterreviewing the frameworkandthe UAVexampleapplication.ChapterFiveconcludes withrecommendationsfor futurework.2.Background2.1SystemsEngineeringSystemsengineeringis aninterdisciplinary fieldthat emergedas aneffective waytomanagecomplexityandchange.It focuses ondefining customerneeds andrequiredfunctionality early in the developmentcycle, andproceeding throughdesign synthesis to systemvalidation while consideringthe completeproblem(INCOSE).Systems engineeringis basedona holistic perspectiveof problemsand design.Practitioners consider howsystems fit into thelarger context,how they impactit, andhow they areinfluenced.Justasimportantly, they consider howthe interactingsystemcomponentsrelateto eachother.The objectiveof systems engineeringis to ensure that thestakeholder'sneeds aresatisfiedin a cost-effective, timely manner.Theseneeds are translatedinto requirementsand drivetheselection of the15best,implementabledesignfrom a number of alternatives.In order to accomplishthis decision making,systems engineers usea disciplined approachto collaboratewithinterdisciplinary teams.Systemsengineeringcanbetracedback to the early1800's,but experiencedrapidadvancementin the1950's and60's(Oliver et al.).Since thenseveralmethodologies andprocessesemergedto emphasizeandimprovecomplexsystemoptimization andtrade-offs.Amongthesearearchitecture frameworks,systems engineeringprocessstandards,new tools, modelingstandards,anddataexchange standards.A methodologycanbedefinedas a collection of relatedprocesses,methods,and tools.Moreover,itprovides theunderling rulesusedin anapproach.For example,HarvardBusiness Schoolusesa case-basedmethodology for teaching inlieu of a lecturebasedone.Frameworksprovide theunderlyingstructurefor a methodology.Processes arelogicalsequencesof tasks performedtoachieve a particularobjective.A process forbuilding a housecouldincludelaying the foundation,erecting the frame,etc.Itdefineswhatis to bedone, without specifying how.Thespecific techniques are definedinmethods.Themethodcoulddescribethe stepsfor installing a specific type of appliance.Tools areinstrumentsthatcanenhancetheefficiency of a methodwhenproperlyused.Mostprocesses andmethodsuseseveraltools to simplify or improvetheir efficiency.A variety of methodologies,processes, andtools areusedbyengineers to develop complexsystems.Asystemis definedbyInternationalCouncilof SystemsEngineers (INCOSE)as a combinationof interactingelements organizedto achieveoneor morestatedpurposes(SEHandbook Working Group,2011).Itcanalsobe thoughtof asa collectionof different components exhibitingemergentproperties.2.1.1Life-CycleStagesEverysystem haslife cycles stages evenif they arenot formerly defined.They encompassthesequentialphasesof requirementsidentification, development,production,use,andretirement.Onecouldargue that evennaturalsystems stemfromanidentification of requirements as biologicaladvantages andenvironmentalchangesinduce theemergence of naturalsystems.TheUnitedStatesDepartmentof Defense(DoD)has rigidly definedlife-cycle stagesto facilitate systemacquisitions, graphically describedinFigure2. Thislife-cycle modelexists to assist inthe managementof billions of dollars of systemdevelopment efforts.In accordance withDoDstandards, themanagementprocess is structuredinto discretephases separatedbymajor decisionpoints knownasmilestones.*The Materiel Development Decision precedesentry into any phase of the acquisitionUsereedsmanagementsystem.. ........ e Entrancecriteria met before entering phasePrE-SsoeyotutionEvolumsAcusisitionorsinglestep toFull Capability(ProgramALInitiation)C11OCFOCateri:DEgifeeringandProduction&Operations&SolutionManufacturingAivpitAnalysis Development Dpomn uprment--LRIP1IOT&En\Pre-systemsAcquisitioSystems AcquisitionSutimn/Q=DecisionPointL= MilestoneReviewf. '=DecisionPointIf PDRIs not conductedbeforeMilestoneBFigure2:DoDProject Lifecycles(Under Secretary of Defense,2008)Thematerielsolutionanalysis,whichleadstoMilestoneA, istheinitialdevelopmentphaseintheDefenseAcquisition ManagementSystem.It contains a robustanalysis of alternativesto identify thepotentialsolutions, assess their benefits anddrawbacks, identify key technologies, andexamineoperational concepts.Thisis equivalent to the conceptdevelopment described in thisthesis.TheNational Aeronauticsand SpaceAdministration(NASA)also overseesbudgets totaling several billiondollars andhasits ownlifecycle model andmilestones,known askey decisionpoints.Figure3 illustratesthe NASA developmentphases.Projectsin thePre-PhaseA stage generateand evaluatea widerange ofideas andmission alternatives.Thepurposeof this phaseis to determinesystem feasibility, developinitialmission concepts,identify thepreliminary systemrequirements,and identifypotential technologyneeds(Kapurchandet al,2007).PhaseA projects undergomorethrough feasibility andneedassessmentsthan those inPre-PhaseA. Through thePhase A activities, final missionconcepts, systemrequirements, and technology developmentplans are developed.Theconcept development frameworkdescribedhereincould beapplied toeither NASAdevelopmentstages as theprimarydifferentiatorbetweenthe two aretherangeof alternatives consideredor the amountof informationavailable foreachone.NASALife-Cycle PhasesFormulation ImplementationProject Life-Cycle PhasesKey DecisionPointsKPABO1OI'KPIOFigure3:NASAProjectLifecycles (Kapurchandet al)2.1.2SystemsEngineeringProcessIn eachlife-cycle stage, systemsengineering teams followprocesses to define complexsystems.Theygenerally beginwith the developmentof requirementsandculminatein verification and validation.Asthe designof complex systemalwaysincludes a number of unknownunknowns,failure to useadisciplined, holistic approachcanresult inproject failure.Severalalternativeprocesses exist for18organizedsystems engineering development andmanagement.Theydescribe the engineering processacross a system'slife-cycle.Themostcommonare theWaterfall,Vee,and Spiralmodels.2.1.2.1.WaterfallModelTheWaterfallmodelbreaks thedevelopmentprocess into a seriesof sequentialphases asFigure4.Asthenameimplies, the Waterfallmodelassumes a one-waycascadingprogressionof tasks fromrequirementsdevelopment touse(shown asmaintenanceinFigure4).Itassumeseachphaseiscompletebefore moving to thenext one.Forexample, it assumesthat allrequirementsarefullydefinedbeforemoving onto design.ImplementationVerification-,Figure 4:WaterfallMethod(Wikipedia,2011b)Themajor shortcomingwith themodelis that it cannothandledownstreamchanges or incompletestages.Thedevelopmentprocessis simplified to presentanorderly progressionof phases,butproblemswill alwayssurface downstream,inducing changeto the requirementsordesign.Therefore,itpoorly reflectscomplex orlengthprojects,andis widely acknowledgedasa flawedmodel.2.1.2.2.Vee ModelTheVeemodeldepicts the systemevolution fromconceptof operations(CONOPS)anduserrequirementidentification, throughdetailed design and verificationto final systemvalidation.In theVeemodel,time andsystemmaturityproceedfromleft toright, asshowninFigure5. Theleft sideofthe Veemodelindicates thedevelopmentactivities whiletheright side depicts theintegrationandverificationactivities.Eachlevelon thehorizontal axisis associatedindicating therelationshipbetweena developmentand verification(or validationat the CONOPS)level.Itis not feasible to gobackwardsinthemodelsoif anyiterations arerequired, theproject stays at thesamepoint on the verticalaxis.VerificationandValidationProjectnDefinitionDeTeenProjectDesignVeattenTest arndInteg rationIraplernntadenTimeFigure5: SystemsEngineering VeeModel(Wikipedia,2011a)2.1.2.3.Spiral ModelTheSpiral modelcanhavethe samephasesas the Veemodel,but explicitly accounts for riskandreevaluation.Software developershavelongunderstood thatmostprojects arenot well suitedto asequentialprocessandrequire a number of iterations (Maier,2009).In the spiralmodel,showninFigure6, the angular sectionsrepresentprogress,andtheradiusof the spiralrepresents maturity.Developerswork through eachphase(e.g.,requirement development, design,test) ineachiteration.The first cycle is often focusedonassessing the aspects of the design withthe most risk.This is useful insituations whererequirements cannotbefully definedprior tosystemdesign, orif immaturetechnologyis required.Themodelassumesthat missing requirementsor technology viability will berevealedaftereachspiraliteration.At the completionof the first loop, initialprototypes areused toassessriskallowingthe customer to evaluatetheproject future withminimalcost investment.If theprojectcontinues, it iterates througheachphase again.Eachsubsequent spiralbuilds upon the baseline.Detaileddesign /System-leveldesignIntegrationdtestTimeReleasePlanningFigure6: GeneralSpiralDevelopmentModel(UlrichandEppinger,2004)2.1.3Concept DevelopmentConceptdevelopmentis focusedonidentifying a design tomaximizestakeholder value over thesystemlifetime.Effective concept developmentconsiders the needs of eachstakeholder and developsrequirementsthat donot overly constrainthe designspace.Failure to doso canresult insystems that21donot meet a needor arepoorly designed.These efforts thoroughly, yet effectively, explorea widerangeof solutionsbyidentifying optionsandhowthey will meet thespecifiedneeds.Concept developmentis notnew.A number of different mechanismsexist today to helpengineersdetermine the bestsolutions.A variety of mockups, models,simulations, andprototypesareusedtobetterunderstandproblems,develop candidatesolutions, andvalidate their decisions.Theyaredependent onthe typeof problem(e.g.,latentor explicit need),available resourcesandinformation,anddevelopment teamexperience.Like withthepossiblesolutions, there arebenefitsand drawbacksto each toolandmethod.A subset is discussedherein.2.1.3.1.Lead UserObservationAsthenamesuggests, this methodinvolves the observation orrecordingof expertsperformingspecifictasks.It is basedonthe premisethatasking themto actuallyperformtasks generates morevalidknowledgethanasking themto simply describe the requiredsteps (Wright& Ayton,1987).Theexpertsareaskedto"think out loud"whileperforminganassignment sotheir thoughtprocess is understood.Theseexperts areoftenleaduserswho areunusually accurate,skillful, andreliable intheir domain(vonHippel,1986).While this technique is often conductedto identifyneeds, theseleadusers mayalsodisclose innovative solutions, developed toaddress their personalneeds.This informationcansignificantly simplify the alternative generationactivities.2.1.3.2.KnowledgeElicitationKnowledgeelicitationuses interviews tounderstandtheneedsandhabitsof subjectmatter experts.Themethodcanbeused toidentify futureconceptsbyasking experts to generatebest-guess estimatesbasedon ananticipatedsetof new capabilities (Shadricket al.,2005).A series of direct and indirectquestions areposed todetermine howdomain-specific tasksareperformedin a case dependentinterview technique.Oncetheinformationis collected,other subject matter experts areguidedthroughthe thought process to collect other insight andneeds.Theresponsesaggregateinto a singlerepresentation of need(Shadricket al.,2005).Knowledgeelicitation canbeusedto assess how valuablea set attributes aretoindividuals andgroups.However,it must beusedcarefully wheninterviewingleadusersin that they mayhave a differentoutlook than the majority of thepopulation (von Hippel,2005).2.1.3.3.TechnologicalForecastingTechnology is oftena keydriver inthe developmentof anynew product or system.Theability toaccuratelypredict the availability of a given technology will havea critical impact onthe success of agiven program,project, or system.Technologicalforecasting, as the namesuggests, is interestedinforecasting the types of technologies that willbe availablein a futuretimeperiod,thecharacteristicsofthose technologies,anda realistic estimate of their availability. Technologicalforecasting considers theinnovationsdue toscientific andtechnical advancement andthose pulledbyenvironmentalfactors(i.e.,social,economic,political) (Shadrick et al.,2005).Alternatively, teamscanidentify howa desiredfutureshouldlook,and"backcast"to determinehow to get there(Shadrick et al.,2005).This toolis dangerous asit makesconcept developmentdependentontheinventionof new technologyorprocesses.As the results of inventionareunpredictable, this reliance invariably causes delaysin theconcept development.Whenused,a thoroughrisk mitigationplanis required.2.1.3.4.BrainstormingBrainstormingis a problemsolving methodwheresolutions arespontaneously generatedby teamorgroupmembers.Thismethodseeks to addressspecific questionsbycollecting asmany options aspossible.Therefore,the quality of eachcontribution is notaddressedor criticizedduring the session."Bad"or "wild"ideasarewelcomedandencouragedas they maypromote tobettersuggestions.Variations ofBrainstormingrequirememberstoarrive atthe sessionwitha short list of ideas.This canbeusefulto help jumpstartsdiscussions.2.1.3.5.TRIZTRIZ,anacronym for themethod'sRussianname,is a systematic approachfor identifying solutions to aspecificproblem.It was developedbyGenrichAltshuller, whoobservedpatternsof invention.Basedonthetheory thatmostproblemsreflect a need toovercomecontradictionsbetweentwo elements,TRIZprovides 40principles to identify ways to overcome the tension(Altshuller et al.,1998).ExamplesofTRIZprinciples include"segmentation",suchascreatingmodularcouches,and "preliminaryaction",used to createpre-gluedwallpaper.This is anextremelypowerfulmethod,andcanbe combinedwithother suchas Brainstormingor Synectics,a similar methodbased onmetaphors.2.1.3.6.MorphologicalAnalysisMorphological analysis is a solutionidentification method.Itis generally appliedto multi-dimensional,complex problemswherequantifiableanalyses arenotpossible ordesired.Morphologicalanalysisidentifies possible solutions bycreatinga matrix.It lists theproblemor solutionattributes (e.g.aresubsystems,properties,qualities) asrowheadingsandadds thepossiblealternatives ineachrow.Newcombinations andpoorlyconceived conceptscanbediscoveredusingthis methodby varyingthecombinations (Ritchey,2009).2.1.4DecisionAnalysisEngineeringdecisionsoftenrequiresystematic evaluations of multipleoptions, basedona setof criteria.Numeroustechniques for conductingtrade studiesareavailable, anda subset of whicharediscussedbelow.Eachoneseeks to answerthe samebasicquestions: whatarethe potentialsolutions to theproblem,howdo theyperform,andwhichis the best one(Borer et al.,2009)?The objectives orrequirementsfor theselection mustbeclearly andaccurately defined.Whenpossible,the criteriaareprioritized.Not allmethodsrequirethis step.Caremustbetaken toproperly selecttheevaluation criteriaweights asthey canlead to incorrectranking.Thecredible alternatives arethenenumerated.Sometechniques eliminate alternativesincapable of meeting thebasic needs.Thisisusefulas the numberof alternatives that canbeevaluatedis constrainedbyhumaninformationprocessingabilities.Finally,theremaining alternativesarecomparedandranked.Thediverse tools andanalysis fidelities areavailable to meet thespecific needsof thedevelopment team.2.1.4.1.DecisionTreeA decisiontreegraphically illustrates thealternatives andtheir attributes.Theseattributes canbepossible consequences, costs,probabilities, orutilities.Decisiontrees decomposelargetradestudiesinto severalsmaller tradestudies to reducethe total numberof requiredcomparison.Forexample,inlieu of performinga trade study to select the bestmealfroma menu,independentlycompare thedifferentappetizers,main dishes,anddrinks.Thesetechniques canbeusefulto visually assess theavailableoptions.2.1.4.2.DelphiMethodTheDelphimethodwas originally developedto elicit expert knowledgeanddevelop group consensus,whileavoiding the groupthinkbias of interactive groups(Shadrick etal.,2005).In traditionalimplementations,group membersinteract solelywith thefacilitator, not each other.The facilitatorgathersresponses,andprovides them to thegroup anonymously.After reviewingthe responsesprovidedbyothermembers, eachparticipant submits a revisedresponse.Theprocessis repeatedasmany times asnecessary.TheDelphimethodcanalsobeusedto assessavailable options.Individuals areindividually presentedwiththe alternatives and askedto assessthem.Thefacilitator againgathersresponses,andprovidesthemto the group anonymously.Again,the individuals have anopportunity torevivetheir assessment.Thisis an effective techniquefor identifying stakeholderrequirement preferences.2.1.4.3.PughMethodor Pugh DecisionMatrixPughmethodis a quantitativetoolused torank andcompareoptions.Ituses a simplematrix andpre-established criteria to compareoptions.This approachuses subjective opinions to compare alternativeagainsta baseline, whichmaybe oneof the alternativesor thecurrent productor service.The keyattributes areenumeratedandusedto compareagainst a baseline.Often, simplescores of worse(-1),same (0),orbetter (+1)areused.Alternatively, numericalscales canbeused(e.g.,2, 1, 0, -1,-2).Theoptions areratedbymultiplying eachoption bythe weight.Therelative scores aretheused toidentifyif anoptionis better, equivalent, or worsethan thebaseline.2.1.4.4.AnalyticHierarchyProcessThe AnalyticHierarchy Process(AHP)is a multicriteria,pairwisecomparisontechniquethat cancombinequalitative and quantitativefactors forrankingand evaluatingalternatives(Saaty,1983).AHPis usedwhensubjective verbal expressions(e.g.,insufficient, undesirable,satisfactory, good,great) areeasier toprovidethannumerical(i.e.,1 to 10) assessments.Valuesarethenascribed to the wordsin order todevelop a scorefor eachof the options.Therequirementsor measuresof effectiveness (MOE)arealsoevaluatedtwoat a time(Saaty,1983).A scale for assigning importanceis providedbythemethod.Thisapproachallowsfor delineation of the factsandrationale that gointo thesubjective assessmentof eachof the options(Goldberg etal.,1994).2.1.4.5.Houseof Quality/ QFDTheHouse of Quality (HoQ)is a toolusedfor decisionanalysis bytransforminguserneeds into designquality attributes inorder torankalternatives. Througha seriesof matrices, theHoQ mapsoriginatingrequirementsto engineeringcharacteristics.Starting withthecustomer'smostimportantrequirements,the tool decomposes these attributesinto lowerlevelrequirements(Hauser andClausing,1988).This format,basedon Quality FunctionDeployment(QFD),is oftenusedtoevaluate andqualitativelyrankeachdesignoption to enablemulti-criteriadecisionanalysis.TheHoQ is namedafter its structure,showninFigure7, whichresemblesthat of a house.CorrelationsFigure7: Houseof QualityTherelativeimportanceof these customerattributes is identified to calculate the importanceof eachengineering characteristic.The engineering characteristicsare the controllable,measurableparametersthat areprovidethe majordesign tradeoffs.Anassessmentis madeof howwell eachalternative meetsthe engineering characteristicsandis numerically scored.Oftenan absolutescale is used to identify thescores.Using these scores andthe calculatedimportanceweightings, the alternatives areranked.2.1.4.6.Multi-AttributeUtility AnalysisMulti-attributeutility (MAU)is a powerfultool for evaluating alternativesand selecting the "best"option (Ross,2003).Ituses explicit valuefunctions to performdirect comparisonof many diversemeasures.LikeHoQ method, MAUprovides a numericalscore,but somefeelit does somoreexplicitly(TheResearchFoundationof SUNY,2009).Thestructured approachrequires andclearly shows thenumericalimportance values placedoneach parameter,oftenusing 0-1scale with 0representing theworstpreferenceand1 thebest.Whilethis explicit definition of relative importanceis requiredforMAU,it can bedifficult to obtainas the tool is predominantlyusedingroup decisionmaking situationswhereseveralperspectives mustbeconsidered(TheResearchFoundation of SUNY,2009).However,discussing the attributes'overallimportance andthe concept'sability to achievethem withpotentialusers or customerscanbe a great learning experience.Thestakeholder value proposition,what they want fromthe system,canbe definedusingutility curves.Utility curves define the function relating the specific desired capabilities or attributesin terms of itsrangeof values.Often graphsormathematicfunctions areused tocapture thebenefit of anattributeusinga dimensionlessplot (RossandRhodes,2009).Whenconcepts areevaluated,the scoresof eachalternative canbeindependently determinedusingutility curves, such as the oneshowninFigure8, andcombinedusing the relativeimportance weights.ExcludedAttribute ValuesCurveTBDExcess Attribute Values(typically assignedUtility =1)0Attribute valueFigure8: SampleUtility Curve (RossandRhodes,2009)2.1.4.7.Multi-AttributeTradespaceExplorationMulti-attribute tradespaceexploration(MATE)is methodfor fully exploring tradespaces of possiblesolutionsrather thansettling quickly onanoptimum.Ithighlights the importanttrade-offs possiblyoverlookedby traditional methodstohelpidentify compromisesolutions thatmaybea bettersolutionfor themultiplestakeholders.MATEcanbeusedto evaluatesets of designoptions, not justpointsolutions(RossandRhodes,2009).Using thismethodthe feasibility of largenumbersof designchoicescanbe quantitativelyassessedearlyin the concept development process.It is alsousefulinidentifyingthe stakeholder preferences.MATEbroadly scopes themission objectives to avoidexcluding creative solutions.It compares thealternativesbased onthekey, independentattributes, theirlowest acceptablevalue,andhighestmeaningful value.These attributes arerefinedinto utility curves, andaggregatedintoa single functionfor the tradestudy execution.Usingdesignandconstants vectors, theattributes values that cover therangeof realistic possible solutions, andthedesign vector quantities, respectively, theperformanceofeachoption canbe calculatedintermsof attributes,costs, andutilities (Ross,2003).2.1.4.8.DSMUnlikethe other decisionanalysis tools, a designstructurematrix(DSM)is not traditionally consideredatradestudy tool.However,it does assist in the evaluation of complex structuresandbehaviors.Thismatrixassists inthe visualization of the relationships anddependencies betweenelements,interfaces,and dataflows.DSMs canbeusefulinidentifying less complicatedphysical architectures andsequences(UlrichandEppinger,2004).Oneof thebestheuristicsin architectureis "KeepIt Simple Stupid"oftencalledKISS.KISScan increasesystemreliability whiledecreasing lifecyclecosts anddevelopmenttime.Toadhere to this principle,it is advisable to (1) haveclear subsystempartitions, (2) maintainlowexternalcomplexity, and(3) minimize interdependencies.AsshowninFigure9, if DSMwere tobeused toevaluatea process for example, the tasks wouldbeplacedin a sequential order along therowsandcorresponding columnsof the matrix.Dependenciesamong the tasks arelabeledbyonesin thematrix,corresponding to the directedarcsin the graph._JA IRCQDEIFIGHIIJKLMINReceivespecifiationAXXXXgFenerateselect conceDt8XrXXDesigbets cartrideCX1XXProduce beta cartridgeseXDeietestinEXXXTest beta carideFXXDesign prod'n cartrkgGXXxXDeinmold14XXXXDesigassem*toolfIXXO XPurchaseMFG equipmentJXFabricate moldsK XXoIDebug moldsLXCertify cartridgeMXInitial production runNFigure 9:SampleDSM(Ulrichand Eppinger,2004)2.2Model-BasedSystems EngineeringSystems engineeringis oneof thelastengineeringdomainsto embracemodel-baseddevelopment.Inengineeringand the sciences,modelsemphasizecertainpropertiesof interest in order toefficientlyandpracticallycommunicateoridentifyresults.In thiscontext, modelsaredigitalexpressionsof designs.Usedinthe mechanicalandelectrical domains for decades,model-basedengineeringis a methodologyin which electronic abstractions areused to develop and capture designs.Computer-aideddesign(CAD)31programsarenowstandard tools for the creationandmanipulationof digitalmodels.By using the toolsandmethodologies, increasinglydetailedmodelsare createdandintegrated.Theuseof electronicmodelshasbeen shown to greatlyimprovedevelopment efficiently.Model-basedsystems engineering(MBSE)uses a graphicallanguage to generateandrecorddetailspertaining toa system'srequirements,design, analysis, verification, andvalidation.Thisis notnovel.Systems engineers havegenerateddesignabstractionsfor years.However, these descriptions wereuncoupledstatic drawings.Whennewdepictions werecreated or othersmodified,the drawingsbecameout of date.Maintaining theseseparatedsystem descriptionsis anexpensive,manualtask.Complexdescriptions were difficult to evaluate,as consistency wasnot enforced.As a result, errorswerenot apparentuntilmuchlater inthe developmentcycle.With advances intechnology over thepastdecade, computer applicationswere developedto apply object-orientedsoftwareconcepts tosystems engineeringtosupport high-levelcomplex systemsdevelopment.MBSEimplies that the models arecomposedof anintegratedset of representations.Allleading MBSEtools and methodologiesassume thattherepresentations of behavior andstructure areinterconnectedina centralrepository.Eachdescriptiveelement canberepresentedinmanyforms tocreate a varietyof designandarchitecturalrepresentations.Expandingupon theINCOSEdefinition, MBSEis amethodology wheremodelsarecentralto the specification, design,integration, verification, andvalidationof systems (Estefan,2008).Therepresentations of systembehaviorandstructurearecapturedalong withstatements of needs andverificationmethods.2.2.1BenefitsMBSEpromisestobe a morerigorousandeffectivemeans of developingcomplexsystems (Tepper,2010).Themethodologies areintendedto makethecomplete systemsengineeringefforts asefficientaspossible.Thevalue of a model-basedengineering emergesfromthecollection of the allsysteminformationina centralrepository.Thisenables theinterconnectionof modelelements andtheabilityto effectively retrieveany desiredinformation.Thisinterconnectivity enables theautomaticpropagationof designchanges,consistency checking, erroridentification, whichin turnprovidethemajorprimarybenefits.2.2.1.1.Reductionof CostsandScheduleSubstantialefforts andcosts areincurredin thedevelopment of complex systems.AsshowninFigure10, whilemost developmentcosts areincurredlaterin the developmentefforts, early design decisionscommitthe programto these expenses.Thereforetheoverall systemvalue is determinedat thebeginningof a program,andmustbeconsideredaspartof concept evaluations.Betterlife-cycle costassessmentscan bedeterminedbyunderstanding thedesignimplications,risks, anddependencies.MBSEprovides themeansof obtaining this informationto enablestakeholders to makemoreinformeddecisionsin asindicatedin Figure10.100%ConceptDetailProductionUseConceptDetailProductionUseDevelopmentDesignDevelopmentDesignFigure10:Changing theParadigm(RossandRhodes,2009)Developmentcosts areexpected to besubstantially reduced throughtheuseof MBSEasthey canobtaina betterunderstanding of thesystemneedsandimplications.Programscanproceedmorequickly andefficiently if thereis a completeunderstanding about the way the design elementsmovetogether.Document-basedapproachescanbetime consumingasinformationis oftenspread across severaldocuments.Throughits complete descriptionof systembehaviorand structure, themodelbecomesaneffectiveprototype.Thiscanleadto dramatic gainsinproductivity andproduct quality.By morethoroughly defining thestakeholderneeds and assessingdesigns, the risksanduncertaintiescanbemore accurately capturedandreduced.Issues canbediscovered early through the enforcedconsistency andrelationship visibility (Bakeret al.).Moreover, the early discovery of errorswillreducethe costand durationof the expensiveintegration and testphase.In somesituations, identifying stakeholderneedsand priorities is a majorchallenge.Theresultingambiguity often delaysdecisionmaking.MBSEmethodologies andtools facilitate the elucidationoftheserequirements andpriorities.Whensystemrequirementsaremoreeffectively translatedfromthestakeholdersneeds, theprojects aremorelikely to succeed.34Creatingmodelsis expensive, but thishappensregardless of theMBSEapproach.However, withMBSE,less effortis extortedto maintaindependenciesbetween views, orrecreating the sameinformation(e.g.,different diagrams,requirements documents,designdocuments).Asa result, the timespentidentifying,accessing, andperforminganalyses is reduced.2.2.1.2.CommunicationOneof the greatestbenefitsof MBSEis the improvementin communicationsamonga diverse groupofstakeholders(e.g.customers,users,management,andspecialty engineeringdisciplines).Systemsengineers mustbeable to easily andclearly communicatetheproblem,potential solutions,andrationales.Failuretodo soleads to inconsistent systemdesigns andambiguity.In turnthisleads todesign flaws,resulting inurgentcorrectiveactions,delaying schedules,andraisingcosts.This couldinsteadresult inprogramcancelations orunsuccessfulproduct launches.Traditionally, system engineeringprocessesare"documentcentric",focusing onthegenerationof textrequirements,specifications, anddescriptions (Coleet al.,2010).However,standalonerequirementsdocuments areknownto havegaps, conflicts, andprovideaninadequate understandingof the actualrequirements(Oliver et al.,1997).They areisolatedfromtheactualsystemdesignand definedwithambiguous, naturallanguage.AsMBSEtools andlanguages express eachdesignelementusingconstructs witha single, definedmeaning, theyprovideanunambiguous andprecisedescription that canbe evaluatedfor consistency,correctness, andcompleteness.Asthedesigns canbecreatedfrommultipleperspectives,engineerscanmanagethe complexity of eachview.Developers cantradeoff clarity andcompleteness.Viewscanbe createdto providea completedescriptionof oneaspect of a systemdesign.Alternatively, views can35hidesomedetails to clearly presentoneaspect of a design.Usingseveral complimentary,focusedviewsto express the systemstructure,behavior, andinterfaces is a muchmoreeffective way to communicatecomplexsystems(Tepper, 2010).Through the expressivenessandrigor of models, therelationship betweentherequirementsand designcanbemoreclearly conveyed.This traceability is traditionallyperformedmanually.Anemergingstandardis touserequirementsmanagementtools (e.g.,IBMDOORS)tolinkrequirementsto eachother, verificationmethods,anddesign.While suchtools arehelpful, they cannot providea digitalconnection enablingbrowsingbetweenrequirementsanddesign.Integratedmodelsallow developersandreviewerstonavigatethrough views to assessdesignimpact ortoinspect previousdecisions.Theymitigate ambiguityandpromote consistency across the entireprogramand team(Tepper,2010).Notonly canelementsbelinked fromone view toa dependentelement inanother,but themodelprovides traceability to previousdecisions, issues, requirements,orrisks.This mayinvolve traversingthroughdifferent levels of abstraction,severalcomponents, orexternalsources.Through theseconnections, the systemobjectives canbetraced tothe systemcomponentsthat implementit.Whilethe views alonecangreatly enhance communication,MBSEtools providethe capability to greatlyimprovesystemunderstanding.Ideally,allmodels shouldbereadilyunderstood,without extensiveeducationor experience.However, stakeholdershavedifferentexperiences andbackgrounds.Not allof them areinterestedor able toreadmodelinglanguages.Using theviews toreview themodelwiththese stakeholders is ineffective andthe desiredinformationwill not beascertained.This is troublingbecause asGeorgeBernardShawsaid,"Thesinglebiggest problemin communicationis theillusionthatit has takenplace."(Wikiquote, 2011a)Executingthe modelcanpreventthis communicationbreakdown.Theunderstanding obtainedthroughthe dynamic visualization is oneof thekey benefits of MBSE.Consider trying tolearnabout thehumanheart.If depictions of the four chambersandflow of bloodwas presented,a fundamentalcomprehensionof its architecturecouldbe gained.However,if ananimationof thebeating andexchange of bloodinslow motionwasused, a muchdeeperunderstandingwouldberetained.2.2.1.3.KnowledgeCaptureComplexsystem developmentefforts, especially those designedfor themilitary, canexceed ten years.Over that time therationale for design decisions areoftenlost. Thisis unavoidablewhen traditionalsystems engineeringapproaches areused.Maintainingisolateddocuments oftenresultsinlostknowledgeleading toeffort duplication andincreasedcosts.MBSEprovides andeffective means for capturing, assimilating, andretainingdesign decisionsanddetails.In an electronicrepository, theinformationis portable,andcanbereusedif modificationsarerequiredinlater lifecycles.Themodelsserveastheproject memory,preventinginformation frombeinglostdue tostaff turnover.Significant timecanbespentrecreating or discoveringlost knowledge.2.2.1.4.Decision-MakingTheprimarymeansof capturing andcommunication designsis currently throughstatic drawingtoolssuchasMicrosoftPowerPointandVisio.Thisis problematic aschangeis unavoidablein complexsystemdesigns.Currently,a careful reviewof static drawings anddocumentsis requiredtomanually updateeachone to captureandanalyzedesign changes.Obviously, this canbea slow, arduousprocess.In comparison, changesinMBSEtools areinstantly reflectedacross theentire design.This allowsdevelopers tomoreefficiently andaccurateassess the impact of potential changesandreduces thedocumentmaintenanceburden.Increasedknowledge,including apparentuncertainties,allowsbetterdecisions.Whilethesumof informationstored inthemodelmaybetoo muchfor humansto takeintoaccount at onetime,bystoringandrelatingthe dataacross themodel,it canbe effectively accessedwhenneeded.This canbeusefulindesignor requirementreviews.Mostrequirementreviews areisolated fromthe informationabout previousdesigndecisionsor futureimplications.Reviewsleveraging informationinthemodel can facilitate the exposureof thisinformationandimproveteamendorsement.Executablemodelssupport improved decisionanalysis byconductingsystemdesigntrade-offsbasedona setof requirements.Byassessing howwell the system designmeetsthem,designers canmakebetterdecisions.Designrisks andcost canalsobeincorporatedinto themodel toenhance the decision-making processwith tradestudy tools.Therepository canprovide thebasis for the technical decisions,andthemeansof recording them.2.2.1.5.ErrorCheckingand DesignVerificationIn traditionalsystemsengineeringmethodologies, therequirementsanddesign validity arereviewedalmostindependently.Requirements areinspectedindividually andthroughtheir tractability to otherrequirements.Designsareprimarily reviewedafter readingtherequirements.Withintegratedmodels,designsandrequirementscanbeexplicitly tracedto eachother, enablingmorecompletereviews.38Asdiscussedbriefly, modelscanbechecked for correctnessbyengineers andtools.Similar to asoftwarecompiler performingsyntax checking, MBSEtools canvalidate the modelconsistency andconformanceto standards.Successfulmodelexecution indicates thelack of "grammatical"errors.Moreover, byreviewing themodelexecution,developerscanaffirmthat the rightsystemis beingbuilt(Bakeret al.). Usingthis capability, thedesigncompletenessandaccuracy canbeassessed,aformidabletask using traditional techniques.Theidentification of inconsistencies indicates design flaws.Regular designinspection allowsdevelopers tobemoreeffective andconsistent right from the start.Theexpense of correcting anerror is minor in a program'searliest stages,butbecomes significant inlater stages.Simulatingthe modelcanverify thelogical, consistent behavioralflow, interfaces, andtriggers.Somepermit systemanalysis though a discrete eventsimulator.Theintegrationof performancemodelsaidintheanalysis of alternatives to determinethe optimumdesign withinthegivenconstraints.Anemergingcapability is theintegration of MBSEtoolswith thoseusedbyother engineeringdomains.Whendatais automatically exchanged,programswill experiencea significant reductionin errors,development times, andcosts.AsshowninFigure11,aninterfacetool or translator couldbeusedtocreatea cross-discipline modelbased developmentapproach.This would enhancetheentireproductdevelopmentlifecycle,byenhancing of thebenefits of modelbasedengineering.Designparameterswouldbeexchangedautomatically, eliminatingsimpleerrors.Tradestudies couldinclude morevariables or bemoredetailed to findbetter solutions or find thesolutions faster.Toolindependent translators canconvertsystemsengineeringmodels into formats requiredbyotherdisciplines with minimalcustomization.Oncetheinterfacetool adds the capability to reador writedatato a newtool, that datacanbe exchangedwith allother tools.This minimizesthe numberofcustomizedinterfaces andplug-ins requiredto achievea fully integrateddevelopment environment.wBS--p,_cedlwFigure11: Interdisciplinary ModelBasedEnvironment2.2.1.6.DocumentationDocumentsareexpected to remainanessentialpart of MBSE(LoganandHarvey,2011).Consideredbymany to bea "sourceof truth", documentswill remainthe primarymeansfor most stakeholders toexaminethe model's contents.Asit is unlikely that manynon-specialist reviewerswill beable navigatesystems engineeringmodel,documentgenerationwill continue to beimportant tosupport informationexchange, reviews,andcontractual obligations.MBSEtools allow for thedevelopment of templates that automatically generate formatteddocumentsfrom therepository.Using the templates, developerscanautomatically generate documentationbased40softwareToolsoolsE-7 EAnalysisTools ISimulationTC bolsMechanicalTcIs oolsre-sentationTcls ToolsrE01'e c t r ic a Ibosisonthe current designstatus.Unlike the traditional practices wheredocumentsgenerally capturethedesignstatus atthe completion of theprogram,they cannowberegularly createdwith verylittle effort.Whencombinedwithmodelreviews, developers cangeneratecomplete,up-to-date designdescriptionsandrequirementdocumentation tokeep thestakeholdersinformed.2.2.1.7.ReuseThereuse of modelelements is oneof themajor advantages of a MBSEmethodology.Froma singlerepository,multipleconsistent views canbeproduced tocommunicateand analyzedesigns.Manuallymaintainingdiagramsandattemptingtomaintainconsistency fromuncorrelatedelements is errorproneand wastesresources.MBSEallows for the creationof alternative views whilereusing commonelements.Moreover, portionsof systemmodels canbereused for alterativedesigns.This supportstradestudies andinsures consistency, whileproviding traceability withminimaladditionalwork.Reusingof dataitemsallows forthe efficient creationandrefining of datadictionariesor InterfaceControlDocuments.As thesearerefinedthey canbereusedacrossdifferentprogramsbycreatingelementlibraries, domainspecificconstructs,andgenericconceptualpatterns.Thishasbeenshown togreatly reducethe timeneeded to developsimilar systemmodels and documentation(London,2011).Reduceddevelopmentandmaintenancecosts canbeachieved throughtheuseof consistent designpatternsto captureinformationandbyleveraging multiplelevels of abstraction.Considerthebenefitsof electric CADpackages.These toolshave reusableparts ina localrepository, andcan organize theminany(accepted) fashion to designschematics.Somepartproperties arespecified,while othersarecustomizable.Commercialpartsareprovidedby their vendors topromote reuseanddesignefficiency.Perhaps, thiswill beavailable for systemsengineering modelsin the future.41Some toolsallow for elements tobe createdandanalyzed inone graphicallanguage,and tobereusedinanother (Wilson,2011).Thispowerfulcapability canbeusedtoreducethe risk of miscommunicationbycreating stakeholder specificviews inorder.2.2.2ToolsGenerically, tools arethingsusedbypeople to simplify or make their workmore efficient.Tools helppeopleautomate what they already knowhowtodo byhand(Maier,2009).MBSEtools aredevelopedto automateportions of a process,but they mustbeproperly utilized.If usedincorrectly,MBSEtoolswill only exacerbate the situation.Aninvestment in methodologyandtool usetraining is requiredtomakeMBSEadoption effective andcanbe the mostexpensive investment (Oliver et al.).MBSEtoolsareavailable acrossa rangeof cost andcapabilities.Usinganinterconnectedcentralrepository,mosttools provide the capability tomanagerequirements,develop architectures, insuretraceability, andspecify verificationmethods.However, the featuresthey providetosupport theseactivities vary.SomeMBSEtools caneasily support largedistributed teams,and others aremoresuitedfor smaller groups.Whilemosttools areintegrating technologies for tradestudies, others provideinterfaces toexternal analysistools.Therangeof supportedprocessesandmethodologies providesdevelopers withseveral optionsfor MBSEimplementation.OPCAT,short for Object-ProcessCASETool,is intended tosupport theOPMMBSElanguage.Primarilyanarchitecturedevelopment tool, tradestudy supportor modelexecutionis not currently available.However,the tool automaticallygeneratesnatural languagetext fromthe graphicinput and viceversa(Dori,2008).Sparx SystemsEnterpriseArchitectis a MBSEtoolsupporting software,systems andbusinessprocessesmodeling.Basedonan openstandard, severalthird-partyextensionsprovidea widerangeoffeaturestoexpandthe integratedtool capabilities.Almostcompletelyunconstrained,EnterpriseArchitectsupports anyMBSEmethodology.Vitech CORESpectrumandGENESYStools integratemultiplelanguages andrepresentationsto improvecommunicationand analyzedesigns.While thesetools cansimulate designs to validatethe modelusingsimulation,they haveyet to includefeatures that support integratedtradestudies.However, thisfeatureis expectedshortly.Oneof the most expensiveandpowerfuloptions, IBMRationalRhapsodyproduct suiteprovidesMBSEsupportfor systems and softwareengineers.Whileseveralmodelinglanguages aresupported, theIBMtools areintended tobeusedwith specific methodologiesto leveragethebenefits of itsintegratedfunctionality.TheMagicDraw SystemEngineeringsolution developedbyNoMagic,supports the fullrangeMBSEcapabilities through third-partyplug-ins.Whilemultiplelanguages aresupported,MagicDrawprovidesspecific perspectivesfor modelersbasedon theirroleandexperience.2.2.3ViewsandViewpointsIn eachMBSEtool, methodologiesandframeworksareorganizedby"views".Views arediagramsordescriptions thatdisplay a subset of the modelinorder to conveya specificset of information.Toinsuretherearenomisunderstandings, viewsshould bedevelopedto capturea specific aspect of adesign.Asincomplete technicalmessagesfocusononemessage,they cancommunicatethepoint moreeffectively (Long,2011).Oftenthese views arecreatedto meet theneedsof a specific stakeholder.Ananalogyproposedby JimCunninghamina recent discussionwasof a modelof a house(Cunningham,2011).Views of the front, backand eachfloor mustbeused to convey the architecture.One view isinsufficient.Furthermore,specific views mustbeusedto convey the designto the customer,electrician,plumber, etc.Eachstakeholderhas a differentperspectiveandconcern,knownasa viewpoint.Whendeveloping these views,modelers shouldconsider the recipient of theinformation.Whatis theirbackground andexpectations?Whatinformationmustbe communicated?2.2.4LanguagesTheselection of a languageis critical to the MBSEeffort ascomplex systems cannotbe effectivelymodeledusing unnecessarily complex or ambiguouslanguages.Most systems engineersusegraphicalrepresentationsto communicate,selecting the languagebased ontheir educationandexperience.Thereare various modelinglanguagesavailable to the systemsengineers, including:Object ProcessMethodology(OPM),the UnifiedModelingLanguage (UML),EnhancedFunctionalFlowBlock Diagrams(EFFBD),andthe SystemsModelingLanguage(SysML).Thesemodelinglanguages,like any otherlanguage,arecomposedof semantics andsyntax.Semanticsarethemeaningbehindwordsandsymbols.Syntaxis the rules forrepresentingsemantics andtheir relationships.Thelanguage dictateshowelements arecreatedandmanipulatedwithin a tool.MBSElanguagesmust have formal,unambiguoussemanticsandsyntax to eliminatethe chance formiscommunication.Thelanguages shouldsupport the full characterizationof the staticand time-dependantsystemcharacteristics, theirhierarchy, anduse.Relationshipsbetweenelementsshouldbe44explicitly representedto insuretraceability.Effective languagesshouldbe clear andintuitive, so theycanbequickly taught andeasily understood.2.2.4.1.Object-ProcessMethodologyDevelopedby Dr.DovDori, OPMis a genericlanguagethat integratessystem's structureandbehavior inone viewbysimultaneously representingstructureandbehavior using a relatively smallalphabet.OPMis basedon three typesof entities:objects, processes, andstates, withobjects andprocessesbeing thehigher-levelbuilding blocks(Dori,2002).For OPM,they aredefinedas:eObjects arethe thingsthat exist or havethepotential of existence, physicallyor conceptually"Processes transformobjectsbycreating, consuming, or changing their state*States arethe situations that objects canbeinThesymbolsfor objectsandprocesses aredepictedasrectanglesandellipses,respectively as showninFigure12.Objects andprocessesare connectedwithstructuralrelations (i.e.,aggregation,generalization) andprocedurallinks(i.e.,enabling, transformation, andevents).Complexityis managedthrough threerefinement/abstractionmechanisms:(1) Unfolding/folding, whichrefines or abstracts thestructuralhierarchy of an object(2) In-zooming/out-zooming,whichexposes orhides the inner detailsof a object, and(3) state expressing/suppressing,which exposesorhides anobject's state(Estefan,2008).Figure12:ExampleOPMElements(Dori,2008)2.2.4.2.FunctionalFlowBlock DiagramsFunctionalflow blockdiagrams(FFBD)providea chronological,sequential descriptionof behavior.Oneof the oldestsystems engineeringmodelinglanguages,FFBDsdescribeanobject's functions intheorderinwhich they aretobeperformed.Sequencesaredescribedusing arrowsfrompredecessors to theirsuccessors.Functioncompletioncriterioncanbeappendedto arrowsto further specify behavior.AsdepictedinFigure13,FFBDsarerepresentedasrectangleslabeledwith the functionnames.Conditionalconstructs(i.e., AND,OR)areshownin text containedin smallcircles.Using theseconstructs,concurrent anditerativebehaviors canbe defined.Oneof themajordrawbacksof FFBDsis theinabilityto express any informationrelatingto the triggersor flow of databetweenfunctions.1.02.03.04.0Identify need Manufacture Operateandanddetermine Designand--tsystemainsystem developsystem production)requirementsL............-----------Feedback------*------4.0REF4.14.24.3OperateandOperatesystemOperate systemGOOperatesystemmaintain rinmodeAin modeBGinmodeCsystemNO-G14.014.114.214.3RemoveandTransportfaultyIsolate faulttounit toGORepair faultyunit" levelreplacefaultymaintenanceunitunit shopNO-GOFigure13:FunctionalFlow Block DiagramExample(HaleandQuayle,2009)2.2.4.3.EnhancedFunctionalFlow Block DiagramsEnhancedFunctionalflowblock diagrams(EFFBD)overlay the controlstructureand sequencingof FFBD,with the dataexchanges, asshowninFigure14.EFFBDswereone of the first diagramstorepresentsfunctions, controlflows, dataflows,and their dependencies(Long,2009).Thelanguageprovidesconstructs that graphically distinguish triggeringandnon-triggering datainputs.Oneof the drawbacks of EFFBDsis the numberof elementsrequiredto communicatethe design.EdwardTufte, one of the mostinfluential authorities onthe visual communicationof information,contends that non-informative andinformation-obscuringelementsreduce the accuracy andclarity oftheinformation conveyed(Tufte, 2001).Theconditional constructsusedinFFBDsandEFFBDsmayreduce the clarity of designdescriptions.However,these diagramsarethought tobemoreeasilyunderstoodbymilitary trainedpersonal thanothermodelinglanguages (Wilson, 2011).47123Ref--Source ofFunctionSink ofRefExternalInputDecomposedExternalOutputIn NextFigureExternalExternalInputOutputFigure14: Exampleofan EFFBD(Bock,2005)2.2.4.4.UnifiedModelingLanguageUnifiedModeling Language(UML)is a generalpurpose,graphicalmodelinglanguage for object-orientedsoftwareengineering.It was developedin1997by theObject ManagementGroup(OMG),anopenmembership,not-for-profitconsortium.Now widely taughtandused for softwaredesign,UMLis arobust,flexible modelinglanguage.UMLdefines severalsemantics for specifying softwaredesigns,butitis not necessarily touseeachone.Thelanguagedescribes theinteractions betweensystemsandexternalobjects usingusecases.Severalstructure diagramsareused todescribe the system components,classes,andobjects.Statechartsdescribethe conditions that classesassumeover time.Activity diagrams describethe systemworkflows.Severalinteractiondiagrams,describe the flow of control anddataamongsystemcomponents.Additionalinformation canbe foundvia theUMLstandard(Object ManagementGroup,2011b).2.2.4.5.SystemsModelingLanguageSystemsModeling Language(SysML)is a graphicalmodeling languageusedto specifyingrequirements,structure,behavior, andallocationsacross a system'slifecycle.Thelanguageenables the design,analysis, and verification of complex systems.Itwas alsodevelopedunder theauspices of the OMGinresponse to aninitiative sponsoredbyINCOSE.SysML is consideredbymany tobea younglanguagealthoughit is basedon the establishedUML, well knownrequirementconstructs,and other standardsystems engineeringelements (Coleet al.,2010).SysML reuses andextendsmanyUMLdiagrams asshown inthe VenndiagraminFigure15.UML2SysLextensions toUMLnot requiredby SysMLUML reusedbySysML(UMLAysML)Figure15: RelationshipbetweenSysML andUML(ObjectManagementGroup,2011a)Many envision SysMLbecoming the standardsystems engineeringlanguage(Friedenthal,2009).Whileother languagessupport aspects of MBSE,SysMLcan beappliedto eachsystems engineeringactivity.This is achieved byproviding diagramsfor modelingsystemrequirements,behavior, structure,andparametrics.Thesecategories,knownasthe "fourpillars of SysML",areshowninFigure16.1. Structure2. Behaviorinteraction-definitionec...u.11ta4SCtetTr~ci~mPV*t Mad," O"p&mJCoes I atsat ractivity/ ''"*dfunctionV WOO"Robe.usergwV&L3. Requirements4. ParametricsEachgraphicalview expressesone aspectof the design.Byoffering a morecompleterepresentationofsystems,SysMLhelpsreducingerrorsandambiguitiesduring systemdevelopmentprocesses.Whenusedproperly,thelanguagecangreatlyimprove thevalueof systemmodel,comparedtopuretextualsystemdescriptions.The SysMLdiagram typesareidentifiedin Figure17andsummarizedbelow.or& IlorC~uwsDigneuOmagnWiwn~wMSe asUML 2*NemdgnunI---"""""- gFigure17:SysML DiagramTypes(Object ManagementGroup,2011a)50Oneof themost beneficial featuresof SysMLis the variety of constructs it provides to describebehavior.However,SysML diagramscanalsocompletedescribe the systemstructure,depicting its hierarchy,interconnection,andproperties.Thelanguagealsoprovidesspecific constructs for specifyingrequirementsand their relationships.2.2.4.5.1.Use Case DiagramsTheusecase diagram,showninFigure18,depicts the high-levelsystemfunctionality interms of itsusage by externalentities knownasactors.Actors canrepresentanyexternal elements, suchas othersystems,environmental conditions,or people.Usecase diagramsprovidebasic behavioraldescriptionsthroughthe interactionsto each actor andmust beelaborated viaother behaviorrepresentations.ucHSUVUseCases[OperationalUseCases]HybndSUVLextends~eincudea~AcceleratelncludenDriverNlincludenFigure18: Exampleof UseCaseDiagram(Friedenthalet al.,2009)Usecasesarefurther defined throughscenarios,specific pathsof execution that list system interactionwiththe actors.Scenarioscan fully describe the systemfunctionality using a primary andseveralsecondary scenarios.Secondaryscenarios describe alternative paths and errorconditions.Thesescenarios aresometimes capturedusing sequence oractivity diagrams.OtherMBSEtools automaticallygenerate thesediagrams fromtext basedscenarios.2.2.4.5.2.Activity DiagramsActivity diagrams,shownin Figure19,depict the complete flow of systemoperations.Theyareoneofthe most powerful andcomprehensivedepictions of behavior.Thediagramsdescribeall of thepossiblepathsof behavior and the order inwhichthey mustprecede.Forksandjoins, the solid black horizontallines, on the activity diagramareused toshow concurrentpaths.Guardconditions onthe controlflowscan stipulate alternativepaths andwhen they are tobeused.Thediagramsalsorepresent the flow ofdata(e.g.,messages,commands),physical elements(e.g., fluid) or energy(e.g.,force) betweenactivities.Theseexchanges canbeshownusingrectangular constructs as showninFigure19.Figure19:Exampleof anActivity Diagram(Friedenthalet al.,2009)52act PreventLodcup[Activity Diagram]Therichness of this description alsohas a drawback. Theviews cancontaintoo muchinformationandtherefore behardto read.Caremustbetaken to clearly convey theintendedmessage,andinsurethatthe diagrammeets theneeds of itsreaders.Severalcomparisonsof EFFBDsand activity diagramshavebeenmade(Bock,2005; Herzog,2005) toidentify themost intuitive language,howeverthe resultsindicatevery differentconclusions.Therefore,it appearsthatreader's backgroundand educationimpact their abilities to efficiently read thedifferentlanguages.SysML seemstobenatural for softwareandsystems engineers,butmaybedifficult for those withmilitary ormechanical engineeringbackgrounds, whomayhavea morenatural affinity forEFFBDs.Itappears that thosewith softwareandsystems engineeringbackgroundshave a tendency to easily comprehendactivity diagrams,whilethosewithmilitary orother domainexpertisemayprefer EEBDs(Cole,2010;Long, 2011;Wilson,2011).2.2.4.5.3.Sequence DiagramsSequencediagramsdescribethe interactionbetween systemelements andexternalentities asshowninFigure20.They captureindividual threadsof behavior,timing, andexchange of messages.Thesediagramsdonot havethe capability to characterizecontrol(Karban,2011),and thereforeseveralsequence diagrammayberequired toenhance the a singleactivity diagram.Thesemessagesaredisplayedasarrowsandcanbespecified assynchronous orasynchronous,a callorreturn,and a specifictype.Theduration of anaction canbeimportant for somebehavior flows.Sequencediagramscanexplicitly capture thesedurationsas showninFigure20.sd[Package]SystemBehavior[SetUAV]:UAVLauncher:GroundAssetsI Settings(Lat/Long,METData,TargetPostion)Statusseconds}IInitializationMessage(GPSKeys, LaunchPos, TargetPos) :Status{0.5seconds}Status()-rFigure20: Exampleof a SequenceDiagram2.2.4.5.4. State DiagramsState orstatemachinediagramsareused to group similarbehavior, describing a periodof time with aninvariant condition.AsshowninFigure21, theydepict the triggerinitiating the transition fromonestate toanother, andthe actions performedinresponseto events.Statediagramsarefrequentlyusedto show thelife cycle of a block (Friedenthal,2009b).They canbeleveraged with other states to act as"modes".:UAVFigure21:Exampleof StateDiagram(ObjectManagementGroup,2010)2.2.4.5.5.Block Definition DiagramsBlockdefinition diagrams,suchastheone showninFigure22,areused todescribehowelements relateto eachother.These viewsareprimarily usedto statically decomposeelements.Bybreaking systemsdownthroughmultiplelevelsof abstraction, simplifiedrepresentationscanbeused toclearly conveyandcharacterize the elements.While thediagramsgenerally capture the physicalhierarchy andclassifications, they canbeused to decomposeactivities as well.Other commonrelations such asassociations,generalizations, andmultiplicity canbe specifiedinblock definition diagrams.Thediagramscan alsobeusedto specify therelationshipbetweenblocksand otherconstructs (e.g.,requirements,activities, andactors).bdd[Package]Structure [ OveralStructure JFigure22: Exampleof Block Definition Diagram(Friedenthal,2009b)Blocksaretheprimary unit of structureinSysML andcanrepresenthardware,software,people, oranyother element(ObjectManagementGroup,2011a).Other descriptive characteristicscanbeassigned tothe blockssuch interfaces,parts, values, andattributes.Portsand flow portsrepresent the inputstoandoutputs fromblocks.Interfacesaredefinedusing standardports and flowports, whichspecifyrequiredoperationsor signals, andwhat canflowin or out of theblock respectively.Constraints andattributes arethe block'sproperties.They mayhave default values,or couldbe selectedlaterin thedesign.2.2.4.5.6.InternalBlock DiagramsInternalblock diagramsareusedtodescribe the Blocks'internal structurein termsof itsparts, ports,andconnectors.AsshowninFigure23,they specify how theinternal elementsandportsareconnectedaswellas theobjects that flowbetweenthem.Internalblock diagramsgenerally show a framerepresenting the enclosing block andspecifying its externalinterfaces.Allinternal elementsareinstances of block componentsspecifiedinblockdefinition diagrams.Figure23:Exampleof InternalBlock Diagram(Friedenthal, 2011)2.2.4.5.7. Requirements DiagramsRequirementdiagramsareused to graphically depictthehierarchybetweenrequirementsandtheirrelationshipsto othermodelelements.Usinggraphicalconstruct tocapture text basedrequirements,these diagramscan clearly convey theelements that satisfy,refine, andverify therequirements.Theycanalsoprovidea bridge betweenthe traditionalrequirementsmanagementtools andSysML models(Object ManagementGroup, 2011a).ibd [Block][ ConnectingNested Partswith Ports})Asshown inFigure24,requirementsderivations andrationales canalsobeexpressed.SysML definessevenconstructs to capture the relationshipsbetweenrequirements, suchas (e.g.,containment,derive)andothermodelelements (e.g.,satisfy, trace)(2009; RosenbergandMancarella,2010).req Safety test2.2.4.5.8.orequirmentaAdhesionudlizadon370ereqerani)37-9D0exlPavementfrctOnorequirerrthodcoversid.aS6.2IVeocnApeaktextThe roadestof pavedsurfaceproducesa peakda"S74,andardfncuoncoeflcient(FC)oftex0O9 whenirmeasured usingSRTT) asanlcaSceforicationNdenveReqt*TesandMaterialsger car refereuitest trIn Testandprocedacc.dancewVthASTMconMetiodE 1337-90,text=(a) IBT65IC(212F)(uf) Test sud"ace:PFFigure24:Exampleof Requirementsin Diagram(ObjectManagementGroup,2010)enti.ditianaUiParametricDiagramsParametricscansupport tradestudies andanalysis of non-functionalrequirements(e.g.,cost, weight,performance,quality, flexibility).Using constructssuch asthoseshowninFigure25,parametricdiagramscanperformcalculations basedontheblock's valueproperties.In additionto trade studies,they canbeusedto computetechnicalperformancemetrics orother critical budgets based ontheattributes of lowerlevel components.orequirernASTM R13id =A24241'texixTbis test fmthe measurementabrakingcoefficientsurfaces using a streferencetest tire (described in SpeciE1136that represetechnology passenradial tiesIaeconckbonsC(149F),5100C of atleast0.4uconstraint))ConstraintBlock1cons tranfs{{L1} x > y}nested:ConstraintBlock2paratesx:Real parBlock1y:Realleng th:Realx: Real Cl:Constraint1width:RealCl: Constraint1y:y:RealconstraintaC1:ConstraintL]x: Real]y: RealFigure25: Exampleof ParametricConstructsandDiagram(ObjectManagementGroup,2010)Parametricdiagramsuseconstructs that expressequations, parameters,andlogicalrelationships toconstrainor calculateblock properties.Theconstraintblocksandconstraints areshown inFigure25witha constraint instance.The figurealso specifies theparameters,x and y, and their valueproperties,"real".A constraintblock is a generic definition of a constraint thatcanbereusedto formorganizedequationnetworks.Constraints areequationssuchas"F=m*a".In constraint blocks, the equationvariables (e.g.,force,mass, acceleration)knownasparameters,arenot specified asinputsor outputs.Parametersarespecifiedas variablesor productsof theequationusing constraintproperties, theinstancesof constraintblock.Constraintproperties explicitly define thequantifiable characteristic, suchasforce ormass.Theparametersknownas valueproperties aretypically defined withvalue types suchasunits, quantities, orprobability distributions (Peaketal.,2007a).Oncetheinput and outputparametersof eachconstraint block arecaptured,the constraint equationscanbe explicitly defined.Thisis generally achievedusinga scripting languageproviding themathematicalbasisfor execution.Whiletools canaccommodatea numberof different scriptinglanguages, they mustbeconsistent throughout the model.Parametricscansupport tradestudies andanalysis of non-functionalrequirements(e.g.,cost, weight,performance,and the "ilities").This canbeperformedbyspecifying the relationshipbetweenasystem'smeasuresof effectiveness(MOEs)andeachimplementation.By formallyspecifying therelationship,robustness analysescanbeperformed.Anexample of a parametricdiagramspecifyingMOEscanbe seeninFigure26.Foradditionalinformation,refer to (Peaket al.,2007a;Peak et al.,2007b).par[block]MeasuresOfEffectiveness[HSUVMOEs]Figure26:Exampleof MOEDefinition (ObjectManagementGroup, 2010)2.2.4.5.9.Element AttributesSysMLelementsareoftendefined throughtheexplicit specification of their attributes.Thesedescriptorsprovideaneffective wayof describing systempropertiesandmanaging critical parameters.Attributescan capturethe operations, values,assumptions,constraints, characteristics, or qualities ofanyelement.Figure 27demonstratesthe definitionof a block usinga variety of attributes. Qualitiessuchassecurity,response time,or reliability canbe associatedwith theseconstructs andrefinedatlower levels.Most toolsenable thedirect inheritance of attributes sothat they canbeidentifiedinconceptualelementsandspecifiedin theimplementations.Thespecification canalsobeperformedusingparametricdiagrams.(block)){encapsulated}Block1constraints{x>y}operationsoperation 1(p1: Type 1):Type2partspropertyl:Block2referencesproperty2:Block3[0..*] {ordered}valuesproperty3:Integer= 99 {readOnly}property4:Real= 10.0propertiesproperty5:TypelFigure27:Exampleof BlockProperties(ObjectManagementGroup,2010)Whilealmostinfinite descriptionscanbeadded to the constructs, it is importantto select only thequality attributesthat addvalue.They shouldbe key andrelevant to the application andmodel.Eachattributeshouldbeclearly namedandhave a well defined type andvalue.In addition, it is alsobeneficial toadd a rationale statementor linkto source describing theneed for the attribute.2.2.5MethodologyFormalmethodologiesinsurethat consistent approachesareusedtomeet theexpectations of allstakeholders.Theyprovidestructureto standardizethedevelopmentprocess anddeliverables,andessentialpractice for largeprojectsto communicateeff