data item description 2. identification number …...the ocd also describes the expected external...

of21

DATAITEMDESCRIPTION

1.TITLE

OPERATIONALCONCEPTDESCRIPTION(OCD)

2.IdentificationNumber

PPA-000950-1620March2018

3. DESCRIPTION/PURPOSE

3.1 TheOperationalConceptDescription(OCD)isasystem-centricdescription,forasystem,subsystem,HWCI,CSCI,componentorotheritem,hereinreferredtogenericallyas“thesystem”,ofwhotheusersofthesystemareandtheirrelevantcharacteristics,whataretheirintendedusesofthesystem,howandwherethesystemisintendedtobeused,andarepresentativesetofscenariosofuse.Thesescenarios,eachassociatedwithaparticularintendeduse(mission),arechosentorepresentbothtypicalandlimitconditionsofuse.TheOCDalsodescribestheexpectedexternalconditionsduringuse.OthernamesforanOCDareCONUSE,OpsConandStatementofOperatingIntent.Inaddition,aCONEMPisalimitedformofOCD.

3.2 TheOCDisusedasavehicleforachievingacomprehensiveandsharedunderstandingofthe informationlistedabovebetweenthesystemsponsor,users,operators,maintainers,acquirers,requirementsanalysts,designers, constructors and testers, as a basis for validation of the system requirements, system design,subsystemsandthesystem.ThroughoutthisDID,theterm“system”maybeinterpretedtomean“segment”,“subsystem”,“element”,“HWCI”,CSCIcomponentorotheritem,asapplicable,thatisthesubjectoftheOCD.

4. APPLICATION/INTERRELATIONSHIP

4.1 ThisDataItemDescription(DID)maybecitedinaSystemRequirementsSpecification(SyRS),StatementofRequirement (SOR), Statement of Work (SOW), a Contract Data Requirements List (CDRL), or within astandardinvokedbyaSyRSorSOWorCDRL.

4.2 TheOCDisnotaCONOPS(ConceptofOperations).Thelatterdescribestheintentofanenterpriseastoitsuseofhumanandtechnicalresourcestoachieveanenterpriseoutcome.

4.3 This DID incorporates and adapts some non-copyrighted material contained in a draft RecommendedTechnicalPracticeoftheAmericanInstituteofAeronauticsandAstronautics(AIAA)oftheUnitedStatesofAmerica,titled“OperationalConceptDocument(OCD)PreparationGuidelines”.

5. PREPARATIONGUIDELINES

5.1 GeneralInstructions

a. Automatedtechniques.Useofautomatedtechniquesisencouraged.Theterm"document"inthisDIDmeansacollectionofdataregardlessofitsmedium.

continuednextpage

6. SOURCE

CopyrightProjectPerformanceInternational.Thisdocumentmaybereproducedanddistributedwithoutrestrictionexceptasbelowprovidedthatallreproductionscontaintheoriginalcopyrightstatementintheoriginalformandlocation.Derivativeworksmaybeproducedprovidedeachderivativeworkcontainsacopyrightstatementreferringto the content in which PPI holds copyright, in a form and in a location no less prominent than the copyrightstatementontheoriginal.Copiesandderivativeworksmaynotbeusedforthedeliveryoftrainingforprofit.

www.ppi-int.com Page2of21

5. PREPARATIONGUIDELINES(continued)

b. Alternative presentation styles. Diagrams, tables,matrices, and other presentationstylesare suitable substitutes for textwhendata requiredby thisDIDcanbemademorereadableusingthesestyles.

c. Titlepageoridentifier.Whendataaresuppliedintheformofapaperdocumentorword processing file, the document should include a title page containing, asapplicable: document number; volume number; version/revision indicator; securitymarkings or other restrictions on the handling of the document; date of issue,document title; name, abbreviation, and any other identifier for the system,subsystem,oritemtowhichthedocumentapplies;contractnumberifapplicable;CDRLitemnumber ifapplicable;organization forwhich thedocumenthasbeenpreparedandnameandaddressofthepreparingorganization.Fordatasuppliedinanalternativeform, this information should be included on external and internal labels or byequivalentidentificationmethods.

d. Tableofcontents.Whendataaresuppliedintheformofapaperdocumentorwordprocessingfile,thedocumentshouldcontainatableofcontentsprovidingthenumber,title, and page number of each titled paragraph, figure, table and annex. For datasupplied in an alternative form, this information should consist of an internal orexternaltableofcontentscontainingpointersto,or instructionsfor,accessing,eachparagraph,figure,tableandannexortheirequivalents.

e. Pagenumbering/labeling.Whendataaresuppliedintheformofapaperdocumentorwordprocessingfile,eachpageshouldcontainauniquepagenumberanddisplaythedocumentnumber,includingversion,volume,anddateofissue,asapplicable.Fordatasupplied in an alternative form, files, screens, or other entities should be assignednamesornumbersinsuchawaythatdesireddatacanbeindexedandaccessed.

f. Response to tailoring instructions.When data are supplied in the formof a paperdocument, paragraphs that have been tailored out of the DID should result in thecorresponding paragraph number and title in the document, followed by “Notapplicable” or alternatively, paragraph numbering may be varied to allow for themissing paragraph. For data supplied in an alternative form, the “Not applicable”representationmaybeincorporatedinthetableofcontentsorequivalent.

g. Multipleparagraphsandsubparagraphs.Anysection,paragraph,orsubparagraphinthis DID may be written as multiple paragraphs or subparagraphs to enhancereadability.

h. Standard data descriptions. If a data description required by this DID has beenpublished in a standard data element dictionary, reference to an entry in thatdictionaryispreferredoverinclusioninthedataitemitself.

i. Declarativestyle.Whereanon-declarativeguidancestyleisusedinthisDID(“should”)butadeclarativestyle(“shall”)isrequiredbytheuseroftheDID,theDIDshouldbetailoredaccordingly.

j. Substitutionofexistingdocuments.Otherexistingdocumentsmaybesubstitutedforallorpartofthedataitemiftheycontaintherequireddataandareinvokedinthedataitemasapartofthedataitem.


5.2 Acronyms

Acronymsusedinthisdocumentshallbeinterpretedasfollows:

AIAA AmericanInstituteofAeronauticsandAstronautics

AO AnnouncementofOpportunity

CDRL ContractDataRequirementsList

CDS CommandandDataSubsystem

CSCI ComputerSoftwareConfigurationItem

DID DataItemDescription

ECCM ElectronicCounter-Countermeasures

HWCI HardwareConfigurationItem

I/O Input/Output

MOE MeasureofOperational(mission)Effectiveness

OCD OperationalConceptDescription

SOR StatementofRequirement

SOW StatementofWork

SyRS SystemRequirementsSpecification

5.3 Abbreviations

Abbreviationsusedinthisdocumentshallbeinterpretedasfollows:

CONEMP ConceptofEmployment

CONOPS ConceptofOperations

CONUSE ConceptofUse

OpsCon OperationsConcept

SI InternationalSystemofUnits

5.4 GuidelinesinthePreparationofanOCD

5.4.1 OperationalConceptDescription

5.4.1.1 PurposeoftheOCD

ThepurposesofanOCDareto:

a. serveasareferenceforvalidationofrequirements;serveasareferenceforvalidationofdesign,subsystemsandsystem,i.e.serveasareferenceforfitnessforintendeduse;

b. communicatethesystemcharacteristicsfromanend-useperspective;

c. facilitatecommonunderstandingoftheoverallpurposeofthesystembetweenusers(includingrecipientsoftheproductsofthesystem,whereapplicable),acquirers,suppliers, implementers,architects,testersandmanagers;

d. formanoverallbasisforlong-rangeoperationsplanningandprovideguidancefordevelopmentof subsequent system definition documents such as the system requirements specification,interfacerequirementsspecifications,etc.;

e. provide,duringandaftersystemrequirementsanalysis,thecontextwithinwhichrequirementsandgoalsshouldbeinterpreted;


f. provideoneormorereferencepatternsofuseforincorporationinthoserequirementsthatareuse–dependent,suchasreliability,availabilityanduseability;and

g. actasainfluenceinthedevelopmentofdefinitionoftheuserorganizationandmission,fromanintegratedsystem/userpointofview.

TheOCDisanimportantcomplementarydocumenttothesystemrequirementsspecification.TheidealtimingforpreparationoftheOCDisbeforethesystemrequirementsspecification.

TheuseofanOperationalConceptDescriptionshouldnotbeconstrainedtoonlythehighestsystemlevel;OCDscanandoftenshouldbedevelopedforelementsatlowerlevelsinasystemhierarchy.TheOCDisbestpreparedbyorfortheusersofasystem;ifthisisnotdone,theOCDshouldbepreparedbytherecipientofsystemrequirementsinperformingasystemrequirementsanalysis.

5.4.1.2 OverviewoftheRoleoftheOCD

5.4.1.2.1 Definitionof"System”

A"system",inthecontextofthisdocument,isdefinedas"acollectionofhardware,software,people,facilitiesandprocedures,asapplicable,organizedtoaccomplishsomecommonobjectives".Asystemmayconsistofseverallevels,whereeachelementateachlowerlevelmaybythisdefinitionitselfbeconsideredtobea"system",i.e.asubsystemofalargesystemmayitselfpossessalloftheattributesofasystem.Forthisreason,theOCDmaybeappliedattheselevelsaswell,resultingpotentially inmultipleOCDs,eachrelatingtoasubsystemofalargersystem.

5.4.1.2.2 PerspectivesofOCDApplication

AnOCDcommunicates to systemusers, suppliers,developersandother stakeholders, in theuser'slanguage,thedesiredinteroperationandothercharacteristicsofthesysteminitsenvironmentofuseintermsofintendeduse,bymeansof:

a. identificationofeachoftheintendedusers,andtheirrelevantcharacteristics;

b. identification,foreachuser,ofthatuser’sintendeduse(s);

c. descriptionforeachuseranduseofhowthesystemisintendedtobeused;and

d. description of the conditions external to the system expected during use. These externalconditions may be of any nature that is relevant, including natural, man-made, procedural,economic,policy…

Todotheabove,twodifferentcategoriesofinformationmustbeprovided.Theseare:

a. the"usagecontext",whichincludes,asapplicable:

(i) useobjectivesincludingpotentiallyrationalefortheseobjectives;

(ii) overallsystemusephilosophies;

(iii) constraintsplacedonthesystemusagebyitsenvironmentofuse;

(iv) user organizational structures and policies relevant to use of the system,togetherwithrelatedfunctions,responsibilities,capabilitiesandinterfaces;and

(v) identificationofinteroperatingsystemsandrelatedsystemexternalinterfaces.

b. a user’s operational view. This view comprises both static and dynamic views of use of theproposedsystem,operatinginitsenvironment,withtheneededoperationalcharacteristics,andwithinapplicableconstraints.TheOCDprovidestherationalebehindtheproposedsystemandshouldcontainatleast:

(i) use(s)/mission(s)nameorotheridentifier;

(ii) descriptionoftheoperationalenvironment(s)forthisuse;and


(iii) a representative set and a set representing extremes of operational scenarios (anoperationalscenario isadynamicviewofthesysteminoperationinteractingwithusers,operatorsandotherthingsinitsenvironment,againwithemphasisontheuser'spointofview).

The OCD may contain an envelope of system capabilities and constraints (in users’ terminology),includingmeasuresofeffectiveness,theirvaluerangesandtheirrelationships.

TheOCDprovidesamechanismtotriggerquestionsandraiseissuesregardinguser-relatedneedsanddesigntrade-offs.TheOCDcanserveinwaysthatinclude:

a. actingasacatalysttostimulatethedevelopmentofcomplete,consistent,testablerequirementsanddesigns,withemphasisuponthoseattributesthatinfluencetheusefulnessofthesystemtotheuser;

b. providing input to the development of the subsequent systemdefinition documentation (e.g.,system requirements specification, interface requirements specifications, interface controldocuments,etc.);and

c. providinga foundation for long-rangeoperationalplanningactivities (i.e., staffing,provisionoffacilities,training,security,safety,logistics,etc.).

TheOCDshouldnotcontainspecificimplementationordesign-dependentconstraintsunlessspecificpartsrequiredofthesystemeachserveasystemend-usepurpose.

5.4.1.2.3 IntendedAudience

The information inanOCD is intended forcommunicationand fosteringofunderstandingbetweenseveralkeyplayers.TheseplayersandthespecificusesthateachwillmakeofanOCDarelistedbelow:

a. System sponsors. These people use theOCD to capture and communicate their purpose(s) inacquiringorfundinganewsystemormodifyinganexistingsystem.

b. Systemusers/operators.ThesepeopleusetheOCDfor:

(i) planningorganizationandoperationalaspects,includingavailableresources;

(ii) determiningattributesconcernedwithhuman-machine interfacesand interactions, interand intra-system hardware and software interfaces, components, locations, sequences,functionsandrequirements;and

(iii) early definition of user constraints, capabilities, operating procedures, resources,responsibilitiesanduser/systemintegration,forusebythedevelopmentcommunity.

c. Requirementsandbusinessanalysts.ThesepeopleusetheOCDto:

(i) assistincapturingmissingsystemrequirements;

(ii) aidinvalidatingallsystemrequirements;and

(iii) communicating within the system requirements specification a context to aid ininterpretationofrequirements.

d. Systemdevelopers.ThesepeopleusetheOCDasaframeworkto:

(i) aidininterpretingrequirements;

(ii) provideareferenceforvalidationofdesign;

(iii) developunderstandingofmissionobjectivesandprioritiesandtherationalebehindthem,tosupportdesignoptimization;and

(iv) determinerelationshipsofthesystemtorelevantuserorganizationalelementswithintheuserorganizationstructure.


e. Maintenancesystemdevelopers.ThesepeopleusetheOCDfor:

(i) planninglogisticalsupportaspects,includingavailableresources;and

(ii) developmentofstrategiesandpoliciesregardingoperationalanddepotlevelmaintenancelevels, operational constraints related to maintenance, accessibility of the system,maximumacceptabledowntimes,etc.

f. Systemconstructors.ThesepeopleusetheOCDtoprovide:

(i) abriefoverviewofthesystemcontext,withemphasisontheobjectivesandconstraints,together with high-level information on operational issues such as logistics, facilities,standards,timelines,end-to-endinformationflows,etc.;

(ii) anunderstandingoftherationalebehindsystemobjectives;and

(iii) insight intotheroleoftheproposedsystemwithrespectto interfacingsystems,andtheplaceoftheproposedsystemintheoverallenvironment.

g. Acquirers.ThesepeopleusetheOCDto:

(i) facilitate an understanding ofmission objectives, system goals, constraints and externalinterfaceagreements;

(ii) formaninputtodevelopmentofsystemrequirementsandacceptancecriteria;and

(iii) placeintopropercontexttheinfluenceofrelevantfundingandscheduleconstraints.

h. Testers.ThesepeopleusetheOCDto:

(i) facilitate an understanding of mission objectives and system goals, in order to ensurecorrectprioritizationoftesttimeandfocus;

(ii) understandoperationalstrategies,tofacilitateappropriatetestfocus(e.g.,effectiveuseofoperationalsequencesanddata);and

(iii) understandtheoperationalattributesofexternalinterfaces,toensurethoroughtestingoftheassociatedsystemelements.

i. Managementofcustomeranddevelopmentorganizations.ThesepeopleusetheOCDto:

(i) focusonthesystemcontext,withemphasisonmissionobjectivesandsystemgoals,policiesandstrategiesandconstraints;and

(ii) facilitateanunderstandingoftheeffectoftheenvisionedsystemupontheelementsandactivitiesexternaltothesystem.

5.4.1.2.4 WhentoGenerateanOCD

ThebesttimetogenerateanOCDispriortothedevelopmentofthesetofrequirementsonthesystemandanysubsequentrequirementsanalysisregardingthesystem.DevelopmentofanOCDshouldbeginpriortothecommencementofsystemrequirementspecificationactivity,and,infact,shouldsupportthisactivity.

Systemsarenormallystructuredinahierarchicalmannerandconsistofmultiplelevelsofitemswithinsystems.ThegenerationofanOCDshouldbeginduringtheearlieststepsintheconceptualdefinitionofeachsystematagivenlevel.InthisDID,nodistinctionisintendedregardingthehierarchicallevelofthesystemandtheremaybeseveralOCDsonsystemsatvariouslevelsinasystemhierarchy.Atsomelevelinthehierarchy,thevalueaddedbygenerationofanOCDforeachelementwillnotjustifythecost.DevelopmentofOCDsatthislevelisnotrecommended.


5.4.1.2.5 MaintenanceoftheOCD

Since OCDs are used to aid communications throughout system definition, development andenhancementphasesinthelifecycleofasystem,theyshouldbeconsidered"livingdocuments"andupdatedas the systemuseevolves.Thisupdating shouldbedoneviaa configurationmanagementprocess,withchangeapprovalauthorityplacedatthelowestpracticallevel.Forsystemsexpectedtobeinplaceformanyyearsafterbeingputintoservice,andparticularlythosethatareplannedtobeevolvedduringtheirlifetimes,theOCDshouldbeusedafterinitialsystemdeploymenttosupportthedevelopment of enhancements or new system capabilities. This practicewill enable developers tobetterunderstandtheoperationalimpactsofproposedmodifications.MaintainingtheOCDconsistentwith thecurrent intendeduseprovidesa veryuseful sourceof information tohelp familiarizenewpersonnel.

5.4.1.2.6 ApplicationoftheOCD

TheOCDsgreatestvalueisinsupportingtheacquisitionanddevelopmentoflarge,complex,end-useoriented,mixedtechnologysystems, irrespectiveofapplicationdomainandtypeofacquisition.ButOCDsalsooftenaddvalueinmuchlessdemandingcircumstances.

TheOperationalConceptDescriptionisconsideredbyProjectPerformanceInternationaltobeaveryimportantdocumentinthesuccessfulimplementationofsystemsthatmeettheneedsofsystemusersorthemarket.DevelopmentofasetofOCDsandrelatedscenariosateachappropriatelevel inthesystem hierarchy should become a planned activity of any development life cycle, with OCDsincorporatingscenariosdefinedasspecificlifecycleproductstobecreated.

5.4.3 ContentsofaPracticalOCD

5.4.3.1 Overview

The OCD should be written in a narrative style, describing in user-oriented non-specification-typeprose,thewayinwhichthesystemisenvisionedtofitandfunctionwithintheproposedorexpectedenvironmentofuse.Graphics,functionalflowdiagrams,timelines,etc.,shouldbeusedwheretheywillenhancethecommunicationofrelevantinformation.

5.4.3.2 ContentoftheOCD

Inviewofthepreceding,agoodOCDshould"tellastory",that is, itshouldbeanarrative,pictorialwhereappropriatedescriptionofthesystem’sintendeduse.Thiscanbeaccomplishedbydescribingthewho,what,where,howandunderwhatconditionsaspectsofsystemintendeduse,notnecessarilyinthatorder.Thesearesummarizedasfollows:

Whos:Thesearetheintendedusers,andtheirkeycharacteristicsrelevanttofitnessofthesystemforintendeduse.Theydescribetheinteractionsamongthevarioushumanelementswithinorassociatedwiththesystem.TheOCDandrelatedscenariosshouldalsoidentifynecessarydecisionsastouse,andwho(title)hasauthoritytomakethosedecisions.

Whats:Thesearewhatthesystemistobeusedfor,theintendeduses.

Wheres:Thesearetheenvironments(geographicalandphysicallocationsofuse,interfacingsystems,etc.),inwhichthesystemistobeused.

Hows:Thesetietogethertheaboveelementstodescribehowthesystemisexpectedorintendedtobeused,fortheintendeduse(s),inthegivenenvironment(s),underallsignificantlydifferentconditionsofuse,forrepresentativescenariosofuse.

Thedescriptionmustidentifyactionstobeperformedbythesysteminrelationtoactionsperformedon the system, by users, operators and interfacing systems, at a conceptual level of detail. Suchdescriptionsshouldincludesequences,concurrencies,workloads,dutycycles,states,modesandothertime/sequence-related aspects necessary to describe the intended uses sufficient to provide areferenceforfitnessforintendeduse.


Theemphasisshouldbeon"blackbox"conceptsofuse;anysystemdesignorimplementationcontentnotintegraltotheintendeduseshouldbeavoided.

Underwhatconditions:Thesearethesignificantconditionsduringwhichactionsareperformedonthesystem,andthesignificantexternalconditionsduringwhichactionsaretobeperformedbythesystem.

5.4.4 PreparationGuidelines

5.4.4.1 Goals

Twoprimarygoalsinthepreparationofanoperationalconceptdescriptionare:

a. to provide a vehicle which effectively stimulates information exchange on major use andprogrammatic issues among the stakeholders in the system in order to facilitate a clearunderstandingofthesystemcontextandtheusers’viewofintendeduse;and

b. togenerateadocumentwhichcanbeutilizedbyallstakeholdermembersoftheOCD"audience"asdescribedinSection5.2.1.2.3above.

5.4.4.2 FormulationProcess

5.4.4.2.1 IntroductiontoFormulation

While not a part of generating an OCD per se, it may be necessary to convince the appropriatemanagementandtechnicalpersonnelofthebenefitsofsuchanactivity.Thisprocess isbeyondthescope of this document. However, if schedule, staff and budget are not specifically allocated fordevelopmentofOCDs,forsystemsandsubsystems,andOCDsarenotlistedamongthedevelopmentworkproducts, chancesarehigh that this "sales" stepwillbenecessarybefore theworkdescribedbelowcanbeaccomplished.

The content and format of an OCD should be defined and understood by all participants. In thisguideline,Section5.3describesonerecommendedcontentforanOCD.However,otherformatsmaybeappropriateor,insomecases,imposed.

5.4.4.2.2 Participants

A key element in any major systems development endeavor should be the establishment of aninterdisciplinaryteamfordevelopmentoftheOCD.SometimesthecontentofanOCDwillbecapturedand validated within a requirements analysis that also produces the corresponding systemrequirementsspecification.Theteammaybeledbyasenioruserrepresentativeorseniorengineerorbusinessanalystandshouldbecomprisedofpersonnelcompetentinallofthedisciplinesrelevanttothesystemcontext.Thesecompetenciesmaybeoperational,technical,requirements/OCDprocess,oralmostalways,amixtureofthethree.

IfthedevelopmentoftheOCDistoconveyvalidinformationtoandfromstakeholderssuchasusers,system engineers/architects, system implementers, testers, customers/buyers and customer andcontractormanagers,thenrepresentativesfromeachofthesecommunitiesshouldactivelycontributeto theOCD. Theusers shouldbeproviding thewho,what,where,how andunderwhat conditionscontentof theOCD, facilitatedbyotherteammembers.Allcategoriesofuserdisciplinesshouldberepresented.Thesystemengineers/architects,systemimplementersandtestersshouldprovideanynecessarybridgebetweenwhattheusersenvisageandwhattechnologyiscapableof.

5.4.4.2.3 CapturingOCDContent


5.4.4.2.3.1 Overview

The first step in creatinganOCD is toestablish a cleardefinitionof theboundariesof the system,defining specifically the border betweenwhat is inside the system andwhat is outside of it, thusestablishingtheexternalinterfaces.Oncetheseareestablished,otherconstraints,includingenterprisepolicies,operationalstrategies,andnegotiatedchangestoexistinginterfacingelements,outsideofthesystemcontextbutnecessaryfortheproposedsystemtointerfaceandbeusableasenvisioned,canbeidentified.These,coupledwiththeend-useobjectives,allowtheOCDdevelopertobegintocaptureandrecordtheoperationalconcepts.Ofcourse,theavailablebudgetandschedulewillalsoinfluencetheextenttowhichthisworkmaybeaccomplished.ThefollowingsectionsoverviewstepsthatmaybeusedtocapturethecontentmaterialofanOCD.Requirements/businessanalystsprovidetheskillstoexpressandorganizetheinformationintoaneffectiveOCD,iftheseskillsarenotpossessedsufficientlybytheusers.

5.4.4.2.3.2 DefiningUsefulOperationalScenarios

ThekeytoasuccessfulOCDisthedevelopmentof"OperationalScenarios".Thesedescribethedynamicviewsofthesystem'soperation,primarilyfromtheusers'pointsofview.Itisthisarticulationofhowthesystem is tobeacteduponand is intendedto respondthrough (potentially)variousstatesandmodes, for a given use and given scenario of use, that provides an important framework for thevalidationofsystemrequirements.

Ausefulscenarioisonethatdescribeshowasystemistobeusedduringaspecifictime,use(mission)phase,operationalmode,criticalsequenceofactivities,etc.,withinadefinedenvironment,underadefinedsetofcircumstances.Itenablesonetoestablishthewho,what,where,howandunderwhatconditions for the system. For example, a scenario in which the system operates under extremeconditions,suchasinfine,winddrivendust,orbeingrequiredtoprocessthehighestinputdatarateswhile staffed with the lowest expected personnel levels, provides insight into important systemrequirements.Attributessuchashuman-machineinterfacebottleneckswhichcouldresultinanoverallsystemfailureiftheconditionspersistformorethanjustafewminutes,couldbeuncoveredbywalkingthroughsuchascenario.Inanotherexample,asystemconstraintlimitingpointingofaradaremitterwithin some number of degrees of a building, which appears to be adequately met via rigorousoperationalprocedures,couldbefoundtobeviolatedwhennormalcommunicationsareinterruptedby a failure mode which limits the pointing control capability. This type of interaction would beuncoveredbyanalysisofcarefullyselectedoperationalscenarios.

Typically,a setof scenarioswillbenecessary.Eachshould focusuponaspecificareaof interestorconcernandnotattempttocoverallaspectsatonce.Commonlythescenarioswillbeembeddedwithinanoverallintegratedproblemdomainfunctionalmodelhavingalifecyclebasis.Thescenariosshouldbe selected such that the complete set contains scenarios dealing with all phases of operationsincluding,asapplicable,deployment,startup,typicalexamplesofnormalandcontingencyoperations,shutdown, etc. Operations under typical and "stressful" conditions (e.g., most stressful physicalenvironments,maximum I/O rates and loads,minimumpersonnel staffing, element failuremodes,etc.),shouldbeemphasized.Oneshouldbeginwithatypical,normalsystemoperationalscenarioandlaterdevelopthosescenarioswhichfocuson"stressed"conditionsandoperationsinthepresenceofsystemelementfaults.Theprimaryfocusshouldbeupontheuser'sviewofthesystem,butwithsomescenariospossiblydevotedtotheviewsofotherstakeholderssuchasdeliverers,installers,maintainersanddisposers.Ifthesystemoperationincludesdecisionpointswhereoperatorsorusersmustchooseacourseofactionwithinsomelimitedtimeframe,asetofscenariosshouldbeincludedwhichcoverstheseinteractions,particularlythoseunderwhichthereisstressonthepersonnel.

5.4.4.2.3.3 DevelopingtheScenarios

Developing the scenarios is a matter of combining the topics listed above, that is, assembling aninterdisciplinaryteamwiththerightsetofexpertise,definingagoodsetofscenarios,walkingthrougheachscenariostep-by-stepandrecordingtheresults.Thefollowingsectionsdescribehowtodevelopthesescenarios.


Manyscenariosmaybeneeded.Therewillnormallyfalloutoflifecycle-basedfunctionalmodeling.Ifscenariosarebeingdevelopedinisolation,initially,onethatistypicalofnormalexpecteduseofthesystemundernormalenvironmentalconditionsformsagoodbaseline.Identifyingthisscenariomaynotbeasimpletasksincetheremaybemanyopinionsregardingtheseseeminglyobviousthings.Tobegin,conductaseriesofinterviewswithorpresentationsbythepeoplewhocanauthoritativelydefinewhatnormaluseisexpectedtobe.Upondefiningthenormalscenarios,createadditionalscenarioswhichfocusonspecificaspectsofinteraction,e.g.,systemoperationsnearboundaryconditions,underpeak loads or worst case conditions, operations in the presence of failures or degraded systemcapabilities,etc.

A list of topics that prompts the presenterwill be helpful to ensure that all necessary aspects areaddressed.Thislistwillvarywiththetypeofsystembutagoodstartwouldbe:

a. Overview:

(i) summaryofwherethesystemis(context),whatitistobeusedforandhowitwillbeused.

b. Sequence:

(i) functionalflows;

(ii) modetransitions;and

(iii) decisionpoints(particularlyhumaninteractions).

c. Performanceandsimilarparameters:

(i) responsetime;

(ii) delaypoints/times;

(iii) throughput/turnaroundtimesexpected;and

(iv) reliability,availability,maintainability.

d. Organizationalissues:

(i) usertypes,technicalexpertise,etc.;

(ii) usertrainingconstraints;and

(iii) user/operatorresponsibilitiesanddecisionauthority.

e. Systemenvironmentandexistingfacilities:

(i) environmentinwhichsystemmustoperate;

(ii) geographicalissues;

(ii) safety,security,systemintegrityneeds;and

(iv) descriptioninterfacingsystemsandrelateddataflows.

5.4.4.2.3.4 DeterminingLogicalFunctionalFlows

Oncearelativelycompletesetofdataisavailable,theinterdisciplinaryteamcanbegintodeterminethefunctionalflowofactivitiesnecessaryforthesystemtoexecuteasetofnormaloperations.Fromtheinterviewsorpresentations,itshouldbepossibletodefineasequenceofactionsoveraperiodoftimethatrepresentssomegenerallycompleteaspectofuseofthesystemthatoncecommenced,tendstoruntosomeend.Forexample,inthecaseofanaircraftthatperformsaweaponsdeliverymission,atypicaloperationalscenariowouldbe:

a. missionplanning;

b. missionbriefing;

c. groundpreparation;

d. take-off;


e. cruisetotargetarea;

f. typicalweaponsdeliveryanddefensivemaneuvers,including,forexample,ECCMactivities;

g. cruisetobase;

h. land;

i. assessmentofmissioneffectiveness;and

j. missiondebriefing.

Havingselectedausecaseandscenario, theteamshould then iteratively"walk through"allof thestepstheenvisionedsystemandrelatedhumansandexternalsystemsmustexecuteinthescenario.Thismaytakesometime,becausestates,modetransitionsteps,etc.,maynotbeclearlydefinedorunderstoodbyall teammembers. Theremay, in fact,be significantdisagreements regarding thesedefinitions.Amajorpurposehere istocometoagreementandrecordclearlythesedefinitionsanddescriptions.AnexampleofscenariodevelopmentisprovidedinAnnexAtothisDID.

5.4.4.2.3.5 ValidatingtheScenarios

Validationofthescenariosisaccomplishedbyperformingscenariowalkthroughsinaccordancewithanygoverningpoliciesandprocedures.Thescenariowalkthroughexaminesthesequenceofevents,extremesofenvironmentandinputsandtheresultantexercisingofsystemfunctionsandresponses.TheuserandOCDdevelopmentcommunitiesmustprovidetheevaluationsrequiredtovalidatethescenarios.

5.4.4.2.3.6 RelationshiptotheUseStudy

SomeofthedatafortheOCDmayhavebeendevelopedfromaUseStudy,performedasaLogisticsSupportAnalysistask.MIL-STD-1388-1A,nowcancelled,definestheUseStudy.

5.5 ContentRequirements

Contentrequirementsbeginonpage13.Thenumbersshowndesignatetheparagraphnumberstobeused in thedocument. Each suchnumber isunderstood tohaveaprefix “5.5”within thisDID. Forexample,theparagraphnumbered1.1isunderstoodtobeparagraph5.5.1.1withinthisDID.


TABLEOFCONTENTS

1. INTRODUCTIONANDSCOPE 13

1.1 Identification 13

1.2 DocumentOverviewandUse 13

1.3 SystemPurpose 13

1.4 Background(optional) 13

2. REFERENCEDDOCUMENTS 13

3. DEFINITIONS,ACRONYMSANDABBREVIATIONS 13

3.1 Definitions 13

3.2 Acronyms 13

3.3 Abbreviations 134. DESCRIPTIONOFINTENDEDUSE 13

4.1 Users 14

4.1.1 Identificationofusers 14

4.1.2 OrganizationalStructure 14

4.1.3 ExternalSystems 14

4.1.4 SystemContext(optional) 14

4.2 Personnel 14

4.2.1 TypesofPersonnel 14

4.2.2 PersonnelProfiles 14

4.2.3 PersonnelInteractions 14

4.2.5 PersonnelActivities 15

4.3 Use(s)orMission(s) 15

4.4 HowtheSystemistobeUsed 15

4.4.1 OperationalPolicies 15

4.4.2 OperationalConstraints 15

4.4.3 OperationalProcesses 15

4.4.3.x UseandScenario 15

4.5 OperationalEnvironments 15

5. SYSTEMWORKLOAD 16

6. OTHERSTAKEHOLDERSANDTHEIRINTERESTS 167. SYSTEMEVOLUTION(OPTIONAL) 16

8. SYSTEMREQUIREMENTSOVERVIEW(OPTIONAL) 16

A. ANNEXES 16

AnnexA 17


1. INTRODUCTIONANDSCOPE

Thissectionshouldbedividedintothefollowingparagraphs.

1.1 Identification

ThisparagraphshouldcontainafullidentificationofthesystemtowhichtheOCDapplies,including,asapplicable,identificationnumber(s),title(s),abbreviation(s),versionnumber(s)andreleasenumber(s).Where the system to which the document applies includes variants of the system, the aboveinformationshouldbeprovidedforeachvariant.Wherethesystemtowhichthedocumentappliesincludes incremental builds of the system that are subject to individual specification, the aboveinformationshouldbeprovidedforeachsuchbuildwhichisthesubjectoftheOCD.

1.2 DocumentOverviewandUse

Thisparagraphshouldsummarizethepurpose(includingintendedaudience)andcontentsoftheOCDandshoulddescribeanysecurityorprivacyconsiderationsassociatedwithitsuse.

1.3 SystemPurpose

ThisparagraphshouldbrieflystatethenatureandpurposeofthesystemtowhichtheOCDapplies.

1.4 Background(optional)

Thisparagraph,ifused,mayprovideanyrelevantbackgroundsuchasrelationshiptoexistingsystemsandcurrentorfutureprojects.

2. REFERENCEDDOCUMENTS

Thissectionshouldlistthenumber,title,revision,anddateofeachdocumentreferencedintheOCD.Thissectionshouldalsoidentifythesourceofeachdocumentnotavailablethroughnormalchannels.If OCD content is invoked by reference to other documents, this section should be renamed“APPLICABLEANDOTHERREFERENCEDDOCUMENTS”andsub-paragraphedaccordingly.

3. DEFINITIONS,ACRONYMSANDABBREVIATIONS

Thissectionshouldbedividedintothefollowingparagraphs.

3.1 Definitions

Thisparagraphshouldlistalphabeticallyanddefineeachwordortermusedinsubsequentsectionsforwhichrelianceondictionarydefinitionsisnotappropriate.Asaguide,termswhicharenotlikelytobeinthevocabularyoftheintendedusersoftheOCD,termswhichhavemultipledictionarymeaningsbutonlyasingleOCDmeaning,technicaltermsandtermswhichareusedwithspecialmeaningsshouldbedefinedinthisparagraph.

3.2 Acronyms

Thissectionshouldlistalphabeticallyeachacronymusedinthedocument,togetherwiththeacronym’sexpandedmeaning.

3.3 Abbreviations

This section should list alphabetically each abbreviation used in the document, together with theabbreviation’s expanded meaning, except that abbreviations within the International System (SI)systemofunitsshouldnotbelisted.

4. DESCRIPTIONOFINTENDEDUSE

This section should be written from an operations point of view, describing the users, uses andoperationsastheyareintendedtobecarriedout,inordertoprovideaclearreferenceforintendeduse.


Thissectionincludes:

a. personnelorganization,activitiesandinteractionsthatdescribewhotheusersareandwhattheusersdoinaccomplishingthemission;

b. identification and characterization of external non-human systemswithwhich the systemwillinterfaceandinter-operate;

c. operationalstrategies,tactics,policiesandconstraintsthatdescribehowtheexistingmissionisaccomplished;

d. operationalprocessesthatprovideaprocessmodeldescribingwhenandinwhatorderoperationstakeplace,includingsuchthingsasdependenciesandconcurrencies;and

e. informationontheexpectedconditionsexternaltothesystemduringuse.

Theinformationmaybeorganizedinanywaythatiseffectiveinthecircumstances.Wheretherearemultipleusers,uses,andenvironmentsofuse,amatrixstructuremaybeappropriate.Sectionsdefinedbelowarenotintendedtoconstrainhowthissectionisstructured.

4.1 Users

4.1.1 Identificationofusers

Thissectionshouldidentifyanddescribetheintendedusers(beneficiariesofuse)ofthesystem,andoperatorsofthesystemonbehalfofusers,intermsoforganizationsand,whereapplicable,individuals.

4.1.2 OrganizationalStructure

Thissubsectionshouldidentifyanddescribetheorganizationalstructure(s)ofthepersonnel.Itshouldstate the charter of each organizational element involved in use and describe any reportingrelationships.

4.1.3 ExternalSystems

This subsection should identify and characterize the external non-human systems with which thesystemwillinter-operate,ifany.Theroleofeachinterfacingexternalsystemshouldbedescribed.

4.1.4 SystemContext(optional)

This subsection, if used,may show graphically the thingswithwhich the systemwill interface andinteract.The levelofdetailshouldbeconceptual,andhumansshouldbeshown inrelationtotheirroles.

4.2 Personnel

4.2.1 TypesofPersonnel

Thissubsectionshouldidentifyandcharacterizethevarioustypesofpersonnelexternaltothesysteminvolvedintheuseandoperationofthesystem.Typesofpersonnelmayaligndirectlywithroles,ormayinvolvecombinedroles,asapplicable.

4.2.2 PersonnelProfiles

This subsection, with sub-paragraphing, should describe for each personnel type, the relevanteducational, training and experience background and skill levels, together with any relevantphysiologicalandpsychologicalcharacteristics.

4.2.3 PersonnelInteractions

Thissectionshoulddescribetheinteractionsofpersonnelwithinthesametypeandbetweentypes,withintheorganizationalboundariesandbetweenorganizations,relevanttouseofthesystem.Bothformalandinformalinteractionsshouldbeidentified.


4.2.5 PersonnelActivities

Thissubsection,withsub-paragraphing,shoulddescribeforeachpersonneltype,thevariousrolesthatmaybeassumedaswellasthedutiesandactivitiesperformedwithineachrole,inrelationtouseofthesystem.Thesubsectionshoulddescribe,foreachtype,relevantworkloadlimitations,limitationsonphysicalpresence,andotherdutiesnotrelatedtouseofthesystem.

4.3 Use(s)orMission(s)

This subsection should identify anddescribe each applicable primary and any secondary uses(s) ormission(s)thatthesystemisintendedtoaddress.Thesubsectionshouldstatetheoverallpurposeandintent of each use. It should overview, if applicable, such things as geography of operations, andstrategiestobeusedtoaccomplishtheintendeduse.Itshouldidentifythreatstosuccessfuluse.

This subsection should identify eachmeasure of operational (mission) effectiveness (MOE), if any,togetherwith,foreachMOE,theminimumandtargetvaluesforthatmeasure.ThissubsectionshouldalsodescribetherelativeimportanceofMOEsintermsoftherelativevaluesofimprovementsofeachfromminimumtotarget.

4.4 HowtheSystemistobeUsed

This subsection should discuss the operational processes used to accomplish themission. Processmodelsshouldbeprovidedthatillustratetheoperationalflowandsequenceofoperations.Processesmaybedecomposedfromhigher-leveltolower-levelprocesses.

4.4.1 OperationalPolicies

This subsection should reference thepolicies and standards, if any, governing theuse/mission anddescribetheeffectonuseandapplicabilityofthesystemwithrespecttothosepoliciesandstandards.

4.4.2 OperationalConstraints

This subsection should list and describe any other operational constraints that govern or limitoperations(e.g.,personnelavailability,acceptableweather,etc.)

4.4.3 OperationalProcesses

Thissubsection,throughitssub-paragraphs,shoulddescribeamodelforeachuseandscenarioofuse.Theprocess,includingitssequenceandinterrelationshipswithotherprocessesshouldbedescribed.Inputstoandoutputsfromeachprocessshouldbestated.Methodsandtechniquesemployedshouldbedescribed,aswellastraceabilitytostrategies,businessrulesanddoctrine,asapplicable.

Thissectionshoulddescribe,foreachidentifiedoperationalprocess,howthesystemisusedintermsofandrelatedtotheelementsdefinedabove.Itshouldprovidetypicalusagescenariosforeachoftheoperational processes servedby the system. Scenariosdescribe typical detailed sequencesof user,systemandenvironmentevents.BasedonthemotivationsforpreparinganOCD,thissectionisbyfarthemostimportantandshouldreceivesubstantialemphasis.

4.4.3.x UseandScenario

This subsection should provide, for each use process, the scenario(s) of the sequence of user,interfacingexternalsystemandsystemoperations.Eachscenarioshouldberelatedtospecificusers,usesandthesystem.

Several different types of scenarios should be considered, including those that address normaluse/missionmodes,naturalenvironments,threatenvironments,anomaly/exception/operationalerrorhandling,missioncriticalactivities, safetycriticalmodes/activities,operationalmaintenancemodes,etc.

4.5 OperationalEnvironments

This subsection shoulddescribeany relevantenvironmentswithinwhich the systemwill beused–physical,political,regulatory,procedural,security,social,etc.,andrelatethemtothescenarios.


5. SYSTEMWORKLOAD

Thissectionshoulddescribenormalandpeaksystemworkloads intermsof,asapplicable,multiplesimultaneoususersanduses,anticipatedandasvaryingoverthestatedintendedeconomiclifeofthesystem,fromfirstusetolastuse.

6. OTHERSTAKEHOLDERSANDTHEIRINTERESTS

Thissectionshouldidentifyother(i.e.non-user)stakeholdersinthesystem.Foreachstakeholder,thesectionshoulddescribetheirinterestinthesystemandhowtheyintendorareexpectedtosatisfythatinterest.

7. SYSTEMEVOLUTION(OPTIONAL)

Thissection,ifapplicable,shoulddescribeanyplannedorpredictedupgradeofordowngradetothesystem,keyedtotimeandwithreferencetotheintendedeconomiclifeofthesystem.

8. SYSTEMREQUIREMENTSOVERVIEW(OPTIONAL)

ThissectionifusedshouldprovideanoverviewofkeysystemrequirementsandMOEsexpressedinusertermsandrelatedtouse.

Thesectionservestointegratethedetailedsystemrequirements(foundinthesystemrequirementsspecification)withtheoperationalperspectiveprovidedbytheOCD.

A. ANNEXES

Annexes to the OCDmay be used to provide information published separately for convenience indocumentmaintenanceoruse(e.g.,charts,classifieddata,interfacespecifications).Asapplicable,eachannexshouldbereferencedinthemainbodyofthedocumentwherethedatawouldnormallyhavebeenprovided.Annexesmaybeboundasseparatedocumentsforeaseinhandling.Annexesshouldbeletteredalphabetically(A,B,etc.).

Appendicesmaybeusedtoannexes.Appendicesshouldbenumberednumerically(1,2,etc.).


AnnexA

1. EXAMPLESCENARIODEVELOPMENT

1.1 Overview

Thefollowingexampleshowshowengineersandscientistsusedtheoperationalconceptapproachandasetofoperationalscenarios.Theywereusedtosupportthedevelopmentofaspacecraftcapableof"flying"agroupofinstrumentsonaninterplanetarymissiontocollectscientificdataaboutabodyinour solar system. The example, based upon an actual situation, is somewhat atypical in that theoperational conceptactivitywas initiatedmuch later in the life cycle than is recommendedby thistechnicalpracticedocument.Itdoes,however,indicatethebenefitsoftheapproachandimplieshowitsearlierapplicationcouldhavehelpedfocusmoreattentiononsomeimportantuser-relateddesignattributes.

Whilethisexampleindicatesthevalueofinitiatingtheoperationalconceptworkearly,itmakesthepointthatevenifinitiatedlaterthanrecommended,itcanstillbeasignificantbenefittothesystemdevelopment.Inthisexample,thespacecraftsystemdesignhadbeengoingonforsometimebeforetheoperationalconceptworkwasinitiated.Thespacecraftsystemdesignwasbasedheavilyuponthatofprevioussimilarmissionsandthespecificscienceinstrumentcomplementforthismissionhadbeenselected.Thishadbeenaccomplishedinanatmosphereofseverebudgetandscheduleconstraints.Instrument selection was done based upon the data provided in a formal "Announcement ofOpportunity" (AO). The AO is an initial high-level description of the type of mission to be flown,includingthingssuchasthetrajectoryfromearthtothebody,thegeneralapproachtoencounteringthebody,andvariousgeneralassumptionsregardingthecapabilitiesofthespacecraftsystem.Typicalof these are the pointing accuracy of the platform on which remote sensing instruments will bemounted,availabledatatransmissionbandwidth,capacityofon-boarddatastorage,etc.Sincethesewereallpredefined,theyhadtobeconsideredasconstraints.Furthermore,severalphysicalconstraintslimitedthedesigners invirtuallyeverydimension.Theamountofavailablespacecraftmass,power,volume,computerprocessingspeed,andmemorycapacitywerealsopredefined.Thismissionwastobe based upon the experience of similarmissions. During the pre-project phase, initial operationsdiscussionswithscientists,missionoperationspersonnelandspacecraftoperatorswereconductedtoestablishabasisforinitialspacecraftuser-relateddesignrequirementsdefinition.Sincethisinputwasfelt to be adequate, a formal operational concept activity was not conducted during the earlydevelopmentphases.

Laterinthespacecraftsystemdesignphase,asthespacecraftengineersbegantofirmupthespacecraftsystemdesign, theengineersandmanagersresponsible for themissionoperationsdesignbegantointeractmoreheavily.Itthenbecomesevidentthatthespacecraftsystemdesignhadevolvedtoapointwhereamoredetailedunderstandingofitsoperationalcapabilitiesandconstraintshadbeengained.From this understanding, it also became clear that some elements of the current design impliedpotentiallysignificantoperationaldifficultiesifimplementedinthemannerspecified.

Consequently,aninterdisciplinaryteamwasformedtodooperationalconceptstudiestogainmorein-depthunderstandingoftheuser-orientedaspectsoftheevolvingspacecraftsystemdesign.Thisteamsearched for potentialmajor problem areas and constraints, whichwere then further analyzed todetermine what solutions could be implemented to ease perceived operational difficulties. Thefollowingnarrativedescribestheoperationalconceptstudyapproach,whichwastakenandindicatesthebenefitsofsuchanactivity.


2. EXAMPLEOPERATIONALCONCEPTSTUDY

2.1 DefinedPurposeoftheStudy

Thepurposeofthisoperationalconceptstudywasto:

a. describethecurrentspacecraftsystemdesignfromseveralperspectives(e.g.,thescientistswhowanttooperatetheirinstrumentstocollectdata,navigationsystemengineerswhodeterminethespacecraft operations necessary tomaneuver the spacecraft to the areas in space where thescience data can be obtained, and mission sequence system engineers who coordinate theinstrumentoperationsactivitieswithalloftheotheractivities,thespacecraftsubsystemengineerswhoanalyzeandmaintainthespacecrafthealthandpredictthecapabilitiesavailabletoconductthe desired operations [e.g., telecommunications bandwidth, spacecraft power utilization,thermalbalance,etc.,versustimeandoperationalmodes]);

b. describetheintendedscientificobservationsforeachinstrumentnecessarytomeettheindividualandcoordinatedscientificmissionobjectives;

c. describethecurrentlyplannedprocess fordefiningspacecraftsequencesofevents,generatingand validating the spacecraft command sequences necessary to implement those events, andschedulingthefacilitiestotransmitthosecommands;and

d. describe the currently planned operational teams, interfaces and interactions necessary tocoordinatealloftheaboveactivitiesintoafeasible,cost-effectivemissionoperationsentity.

2.2 InterdisciplinaryTeamComposition

Giventhenatureofthemissionandsystem,theinterdisciplinaryteamwascomposedofengineersandscientistswiththerangeofexpertiseindicatedinTable2.2-1below.

This tableprovidesexamplesof the typesofexpertisewhichweredeemed tobenecessaryon theinterdisciplinaryteamforthedeepspacescientificmission.Indicated,foreachtypeofexpertise,aretheperspectives(eitheruserordeveloper)fromwhichthatpersonwouldparticipate.Incaseswhereanindividualwouldrepresentbothviews,theyarelistedhighestpriorityfirst.Inaddition,anasterisk(*) followinganentry indicatesapersonthat isalso involved inpost-launchsupportof themission(maintenance).

SystemManager(developer)

ProjectSystemEngineer(developer)

SpacecraftSystemEngineer(developer)

FlightOperationsEngineer(user,developer)*

MissionDesignSpecialist(user,developer)

ScienceInvestigator(user)

ScienceDataProcessingEngineer(user,developer)*

InstrumentDesigner(developer,user)*

CelestialNavigationEngineer(user,developer)

Guidance&ControlEngineer(user,developer)

InformationSystemEngineer(developer,user)*

SoftwareSystemEngineer(developer,user)*

DeepSpaceTelecommunicationsEngineer(developer,user)*


SpacecraftPowerSystemEngineer(developer,user)*

SpacecraftMechanical,Structural&ThermalSpecialist(developer,user)*

SystemIntegration&TestEngineer(developer)

Table2.2-1TeamComposition

2.3 TheApproach

Itwasa requirement that the interdisciplinary teammembersparticipate inallworkingsessions toensurethateachgainedanunderstandingoftheoverallcontextplustheexpectations,pointsofview,biases, etc., of the othermembers. As a result, a significant amount of clarification of issues wasaccomplished in real-time at each session, enabling the team to distil the essence ofmany issuesrelativelyquickly.

Theteamleaderestablishedaseriesofworkingsessionstodeterminethe"what","when","where","who","why"and"how"ofthecurrentlyplannedorexpectedelementsoftheend-to-endsystem(i.e.,instrument sensor through spacecraft and ground systems to enduseroutputproducts) thatwereperceivedtobenecessarytoaccomplishthemissionobjectives.Thiswasaccomplishedthroughthedevelopmentofvariousscenarioswhicharediscussedbelow(note:thefollowingaretypicalitemsandarenotcompletelists):

a. science "scenarios" wherein the operational needs and science data acquisition and handlingexpectationsofthescientistsandinstrumentengineerswereestablished:

(i) what parameters are involved in typical sensor data collection sequences for yourinstrumentandwhatisinvolvedincontrollingthem?

(ii) whatparametersofyourinstrumentrequirecalibrations?Howoften,whatground-basedoperationsarenecessary,etc.?

(iii) whatinformationdoyouneedpriortodeterminethevaluesoftheaboveparameters?

(iv) whatarethecharacteristicsofthedatareceivedfromyour instrumentduringtheaboveoperations(e.g.,datarate,numberofobservationsmodechangesrequired,etc.)?

(v) whatdatafromotherspacecraftelementsarerequiredtosupportyourobservationdata(e.g.,platformpositiondata,spacecrafttime,datafromotherinstruments)?

(vi) Howsoonaftertheobservationsdoyouneedthedata,inwhatform,andwhatdoyoudowiththatdata?Particularly,whatdoyouneedfromthedatawhichinfluenceswhatyoudoonsubsequentobservations?

b. spacecraftengineering"scenarios"whereinasimilarsetofitemsweredefinedbytheengineersresponsible for the operation of the spacecraft engineering subsystems which support theinstruments (e.g., telecommunications, power, guidance and control, command and datahandling,etc.):

(i) whatstandardsequencesmustberunonyoursubsystemduringflightforeitheroperationalverification or calibration? How often must they be run, what are typical verificationactivities,howmuchtimeisrequired,whatsupportfromothersubsystemsisrequired,etc.?

(ii) whatsubsystemanalystvisibilityintoyoursubsystem'soperationisrequiredduringnormalflightoperations(lowactivityandhighactivity)periods?

(iii) what is done with the data from a sequence?What form is expected, how soon afterexecution,etc.?


(iv) whatclosed-looporautonomousfunctionsdoesyoursubsystemperformordependuponsomeothersubsystemfor?

(v) whatroledoesyoursubsystemplayinnavigationmaneuverandwhatdataisrequiredforyoutoprepareforamaneuver?

c. uplinkprocess"scenarios"whereintheaboveinformationformedaframeworkinwhichtheteamcoulddiscusstheprocessandactivitiesnecessarytodefineoperationalsequences,generateandvalidate the necessary spacecraft command loads, and schedule their transmission andverificationweredefinednext:

(i) howmuch sequence activity can be incorporated into a single spacecraft commandingsessionandhowoftencan/shouldcommandloadsbetransmittedtothespacecraft?

(ii) howlongisthesequencedevelopmentandgenerationprocess?

(iii) howmanysequenceloadsmustbeinsomeformofdevelopmentconcurrently?

(iv) whatisthestrategyforon-boardsequencememorymanagement?

(v) whatistheprocessforvalidationofasequencepriortotransmissiontothespacecraft,howlongdoesittake,whattoolsarerequired,etc.?

(vi) what process is needed to review the proposed sequences, who is responsible for theapproval,howlongdoesthisprocesstake,howmanylevelsofapprovalareneeded,etc.?

d. downlink,process"scenarios"whereintheprocessesnecessarytocapturedatatransmittedbythespacecraft,processit,androutetheoutputproductstotheenduserswerethendefined:

(i) whattypesofspacecraftactivitiesrequireon-linereal-timeanalysisbywhatlevelsofanalystexpertise?

(ii) howoftenareeachoftheseexpected?

(iii) what is the requiredminimum time from receiptof each typeofdata todistributionofprocessedoutputtoeachuser?

(iv) whatcapacityofdatastorageisrequiredandwhatsafeguardsarenecessarytomaintaindataintegrityafterreceipt?

e. spacecraft engineering subsystem and instrument performance analysis "scenarios" werediscussedtoestablishtheexpectationsandneedsofanalyststoensurecorrectflightequipmentoperationanddetecttrends.Itshouldbenotedherethatsubsequentteamactivitiesareplannedtoaddressalloftheabovescenarios inthepresenceofflightandgroundsystemanomaliesorfailures,includinganalysisofspacecraftautonomousfaulttolerancefunctions:

(i) what data is required and how often to ensure continued, correct operations of allspacecraftelements?

(ii) whattoolsarenecessarytoperformthisanalysis?

(iii) whatpersonnelwithlevelsofexpertisearerequiredandwhattypesofworkingshiftswillbenecessary?


2.4 ExamplesofDifficultiesUncoveredByThisStudy

Followingareafewrepresentativeexamplesofdifficultiesuncoveredbytheaboveoperationalconceptstudy. These indicate the value of such an activity and emphasize the importance of performingoperationalconceptdevelopmentearlyinthesystemdefinitionprocess.Italsoprovidessomeinsightintohowoperational scenarioscanprovidea frameworkuponwhich tobase theanalysis.Exampledifficultiesuncoveredwere:

a. mismatchbetweenavailabletelemetrymodesandtargetbodyencountersequencingactivities:ThedesignofthespacecraftCommandandDataSubsystem(CDS)hadproceededbasedupontheassumptionthatthemaximumnumberofdifferenttelemetryformatsneededduringanymajortime period would not exceed ten. Analysis of the proposed instrument designs and theoperationalmodechangesthatwouldberequiredforeachtoacquiretheoptimumamountofscienceobservationsduringatypicalencountertimeperiodresultedinsignificantlymoremodechangesanddataratechanges.Becauseofthedesignapproachalreadytaken,therewouldbeamajorincompatibilitybetweenscienceobservationneedsandtheon-boardtelemetrydatamodecapability.Aspacecraftdesignteamactivitywasdefinedtoresolvethisproblem;

b. impact of small power margins on instrument operations: In the vicinity of the target bodysignificantamountsofdustparticledebrisareexpectedtobeencountered.Toprotectinstrumentsensorsandopticsfromimpactorbecomingcoatedwithdust,covers,whichcanbeclosedandopened,areincludedinthedesign.Unfortunately,thesedustcoversandthemotors,whichdrivefilterwheels,requireasignificantamountofpowercomparedtotheavailablepowermargin.Insomespacecraftoperationalmodes,thepowermarginissosmallthatmanycombinationsoffilterwheeland/orcoveroperationswouldrequireapeakpower,whichexceedstheavailablepower.This could result in an autonomous responseby the spacecraft fault protection system,whichwouldsensethisconditionasafault.Thus,theoperationalconceptsdiscussionsbroughttolightseveralindividualinstrumentandsystem-leveldesignandassumptioninconsistencies.Asabove,nowthatthesehavebeenuncovered,theywillbeworked;and

c. theaboveitemandseveralothersimilarissuesbroughtintofocusthefactthattherehadbeenno"operability" requirementsdefinedorallocated to the instruments.What isneeded isa setofsystem level requirements and constraints allocated to each instrument which relate to theoperationoftheinstrumentinthespacecraftsystemenvironmentandinthemissionoperationalsequencingarea.Someexamplesofthetypesofrequirementswhichneedtobedefinedare:

(i) requirements to minimize the interactions necessary from other subsystems or groundoperationspersonneltoinitializetheinstrumentuponapplicationofpower.Thisisduetothefactthat,becauseoflimitedspacecraftpowermargins,instrumentsmayberequiredtobefrequentlypoweronandoffduringsomeperiods;

(ii) requirementsonthestructureofcommandandtelemetrymessageswhichenableclear,unambiguous translation from human readable formats intomnemonics and commandmessagestobetransmittedtoorreceivedformtheinstrument;and

(iii) requirementsontheprocessesneededtocalibratetheinstrumentormodifyoperationalparameterswhich facilitate simple ground systemoperational procedures to implementthem.

2.5 Summary

Whiletheaboveexampleisveryspecifictoauniqueandnarrowapplication,it isapparentthattheapproach described can be applied to the development of any system. The key elements areformulationoftheinterdisciplinaryteamwitharangeofexpertisewhichcoversallimportantaspectsofthesystem;andinvolvementoftheseteammembersinanalysisofsystemoperationalattributesthroughthegenerationofasetofoperationalscenarios.

data item description 2. identification number …...the ocd also describes the expected external...

Documents