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