ReactionSystem (RCS)Thruster5

J Module (CM)__4; 1Service

Module (SM)

IM,V,^,7 Pip-

Orion MainEngine (OME)

The Orion GN&C Data-Driven Flight Software Architecture forAutomated Sequencing and Fault Recovery

Ellis King17629 El Camino Real, Houston TX 77058, 281-212-1107, ekingkdraper.com

Jeremy HartHouston, TX 77058, 281-483-0001, ieremy.i.hart?_nasa.Qov

Ryan Odegard17629 El Camino Real, Houston TX 77058, 281-212-1140, rodegard&draper.com

The Orion Crew Exploration Vehicle (CET) is beingdesigned to include significantly more automationcapability than either the Space Shuttle or the InternationalSpace Station (ISS). In particular, the vehicle flightsoftware has requirements to accommodate increasinglyautomated missions throughout all phases of flight. A data-driven flight software architecture will provide an evolvableautomation capability to sequence through Guidance,Navigation & Control (GN&C) flight software modes andconfigurations while maintaining the required flexibility andhuman control over the automation. This flexibility is a keyaspect needed to address the maturation of operationalconcepts, to permit ground and crew operators to gain trustin the system and mitigate rmpredictability in humanspaceflight. To allow for mission flexibility andreconfrgurability, a data driven approach is being taken toload the mission event plan as well cis the flight softwareartifacts associated with the GN&C subsystem. A databaseof GN&C level sequencing data is presented which managesand tracks the mission specific and algorithm parameters toprovide a capability to schedule GN&C events withinmission segments. The flight software data schema forperforming automated mission sequencing is presented witha concept of operations for interactions with ground andonboard crew members. A prototype architecture for faultidentification, isolation and recovery interactions with theautomation software is presented and discussed as aforward work item.

TABLE OF CONTENTS

supervisory role in the configuration of the flight software.This has been accomplished by designing the Orion vehicleto include capabilities to automatically make hardware andsoftware reconfigurations according to predefined sequencesresident onboard the spacecraft. The design requirementsfor automated functionality and represent a departure fromthe limited automation in the software on-board the SpaceShuttle with the intent of creating increased automationcapabilities and reducing the burden of manualconfiguration on the crew [2]. Astronauts aboard the SpaceShuttle are required to manually configure spacecrafthardware and software via command for even the mostroutine and pre-defined events. The Orion spacecraft isdesigned to include automated functionality to perform thistype of configuration allowing the role of the crew to shift

1.INTRODUCTION ................................... ..............................1 Figure 1: The Orion Crew Exploration Vehicle (CEV)

2. ORION MISSION SEQUENCINGERROR! BOOKMARK NOT DEF3. GN&C ARCHITECTURE ....""""""""""""""""""""".... .34. PSANI SCHEMA ................................................................95. PSANI DATABASE ..........................................................126.FoRwARD WORK ...........................................................147. CONCLUSIONS ................................................................17REFERENCES ......................................................................17BIOGRAPHY .....................ERROR! BOOKMARK NOT DEFINED.

1. INTRODUCTION

As compared to NASA's previous human spaceflightprograms, the design of the Orion vehicle (Figure 1) allowsfor the astronaut crewmembers to take on a more

IN$Ybm primarily manual configuration to monitoring andsituational awareness of pre-defined events. These eventsare implemented in the Orion design as sequences ofparameters that specify the confi guration of hardware andsoftware components for a given mission plan.

The choice to implement the sequences of automatedconfigurations via parameters is to allow the software to beversatile enough to accommodate changes to the missionplan needed to safely adapt to the often dynamic nature ofhuman spaceflight. When unexpected contingencies occurthe design must allow changes to the pre-definedconfigurations that are no longer valid. The alternative ofhard-coding automated capabilities would also be too brittle

https://ntrs.nasa.gov/search.jsp?R=20100001314 2018-06-02T11:16:42+00:00Z

to allow for changes in crew and operational preferencesthat change and mature over time. This flexibility is criticalsince Orion is being designed to operate for the next 30years. Over the lifetime of the Orion project the operationalpreferences and even missions themselves will continue tomature and evolve. A flexible and `data-driven' architecturespecified via parameters allows for many different types ofmissions and operator interaction, but also presents uniquedesign challenges.

The following sections describe how the data-drivenconfiguration items are created and managed, in particularfor the GN&C subsystem. This paper represents aspects ofthe Orion design as baselined at the Preliminary DesignReview (PDR) in the summer of 2009. The design willcontinue to mature and undergo development as the Orionprogram proceeds towards the Critical Design Review(CDR).

The first section describes the Orion vehicle-level missionsequencing handled by the Timeline Management (TM)software, which is responsible for coordinating the Orionsubsystems. The Orion nussion sequencing is importantbackground to understand how GN&C is coordinated withthe other subsystems for both nominal operations and forfault recovery. The next section illustrates how the GN&Csoftware architecture relates to the configuration andautomated sequences. This section includes an example ofthe typical sequence of events involved in the execution ofan on-orbit burn maneuver. The example includes an in-depth description of how the individual software algorithmsare grouped, activated for execution ; and configured. Afterthese sections the reader will have the background necessaryto understand the data-driven parameters described in thefollowing sections. In particular, the hierarchy of datadecomposed into Mission Phases, Mission Segments,GN&C Activities and GN&C Modes, referred to as PSAM.

Following the description of the GN&C softwarearchitecture, the PSAM schema section presents the dataschema for the data-driven artifacts used to configure theGN&C software. This schema follows the hierarchymentioned above and also specifies parameters that each ofthe al gorithms will use during execution. The overview ofthe PSAM schema includes details of key design featuresthat are important to the overall goal of data-driven missionsequencing. After the description of the schema, the nextsection describes the PSAM database tool that can be usedto create and mana ge the GN&C configuration sequences.This tool serves the critical role of helping to manage,visualize, and understand the data-driven parameters bothduring development and throughout the life of the program.

Forward work is then discussed ; including the preliminarydesigns for the interactions between GN&C and externalVehicle Systems Management (VSM) software. Thisincludes Fault Detection, Isolation, and Recovery (FDIR)for both Orion-level and GN&C-level faults. In additionforward work design decisions are presented which are

being considered as display and control softwarerequirements are flowed into the GN&C sequencer designs.Finally, conclusions summarize the important and novelaspects of the Orion GN&C design that have been addressedin this paper.

2. ORION MISSION SEQUENCING

This section describes the vehicle-level mission sequencinghierarchy of the Orion TM Flight Software as it relates tothe Orion Subsystems, includin g the GN&C subsystem.Each of level of the mission Vsequencing hierarchy isimplemented via data-driven parameters.

Orion Vehicle-Level Sequencing

The responsibility for sequencing and coordinating Orionmission events is distributed among the TM software andthe vehicle subsystems. The TM software is responsible forthe overall mission timeline and coordination of the Orionsubsystems, including GN&C. This knowledge of theoverall timeline is based on a sequence of Mission Phasesand Mission Segments, which is designed and tested on theground prior to flight and loaded onto the vehicle as data-driven parameters.

Mission Phases and Mission Segments represent the high-level and intermediate-level decompositions of the overallmission timeline, respectively. The Mission Phasesrepresent the major operational portions of the timeline,such as Ascent, Low-Earth Orbit (LEO) Configuration,Entry, etc. Each Mission Phase contains multiple MissionSegments, which correspond to the major events that willoccur during that Mission Phase. The Mission Phases andMission Segments are used to coordinate the configurationof the Orion vehicle subsystems. The current Mission Phaseand Mission Segment are conununicated to and used by theOrion Subsystems to provide knowledge of the point in themission plan. For example, during the Ascent MissionPhase the subsystem configuration will change in responseto the transition from the First Stage Mission Segment to theSecond Stage Mission Segment. In some cases thesubsystem response to the current Mission Phase andMission Segment will be internal sequencing, as is often thecase for GN&C as detail in the following section. Figure 2shows an example decomposition of an Orion mission to theInternational Space Station (ISS). In this example thecurrent Mission Segment is designed to perform an orbitalplane change bum, called `NPC Burn'. The Mission Phaseand Mission Se gment communicated to the Orionsubsystem software will result in all of the necessaryconfigurations and subsystem sequencing to execute thatburn event. Each subsystem will provide a `SegmentTransition Indication' when it has completed the necessarymission objectives for that Mission Segment. The MissionPhases and Mission Segments are then sequenced by TMbased on mission elapsed time and the Segment TransitionIndications provided by the Orion subsystems.

iviission iviissionPhases Segments

Ascent

- Coast to

)a',l Earth 01-bit Plane

ConfigContingency {. ha I I r--j e

Coast segment (J,Jf'i_BUrrl

ATP 4 - ATPRndx, iProxOps, and NPC Burn

Docking contingency

Burn Segment

4 —` asst toeight

LAdju st( NH)d Burn

ion;he

ATPNH

Burn

Timeline ManagementSoftware

(F GN&CSubsystem

Envi ronme ntalControl j Life

Support (ECLSS)Subsystem

Etc....

Orion SubsystemSoftware

Figure 2: This figure shows the Orion mission sequencing hierarchy as it is decomposed between the TimelineManagement software and GN&C Subsystem software.

Another aspect of the Orion mission sequencing design isthat the Mission Segments can be configured to require acrew- or ground operator-issued Authority-To-Proceed(ATP). If an ATP is required, a ground or crew operatormust issue a specific command before a transition to thenext Mission Segment will be permitted in the flightsoftware. This mechanism is used as a gate to providecontrol over automated functionality of the vehicle.Therefore, an ATP is often desired prior to the start of acertain critical mission event. [2] This type of operatorinteraction is also implemented using a data-drivenapproach to allow the required mission flexibility.

An example path for fault recovery is also shown in Figure2. The two segments denoted as `Contingency' and shownin red can be predefined as the response to a vehicle fault.This path would allow the completion of the NPC Burn withan alternate set of vehicle configurations corresponding tothe fault conditions. As with the nominal sequence thecontingency paths; of which there could be many, arespecified via data-driven parameters. Specifying thecontingency sequences as data-driven allows the faultrecovery plans can also mature over time as the commonvehicle faults and their desired responses mature over time.

3. GN&C FSW ARCHITECTURE

As described in the previous section, the TM software isresponsible for broadcasting the current Mission Phase andMission Segment to each of the Orion vehicle subsystems.The subsystems are each responsible for helping to achievethe objective of the Mission Phases and Segments byperforming the desired subsystem functionality and makingthe necessary configuration updates. Because MissionSegments are defined at a course level of granularity, inmany cases the GN&C subsystem must be furtherdecompose the Segments into lower level sequences ofconnnands to accomplish the objectives of a given MissionSegment. As a result ; automated sequencing capability isdistributed to the GN&C subsystem as well. This sectionpresents the GN&C architecture in place to permitautomated sequencing at the subsystem level and fulfill thevehicle level requirements for Orion automation [1]. Thefollowing subsections describe the GN&C Flight Softwarearchitecture and provide the necessary context to understandhow the GN&C subsystem uses data-driven parameters toperform the required automation, which is detailed in latersections. An example of these concepts that summarizes allof the functionality and integrated capability required withinthe GN&C automation software is included in the finalsubsection.

Automated GN&C Sequencing Software

The GN&C subsystem has a unique role on the vehicle inthat it directly affects the trajectory and attitude throughoutthe mission. Therefore many of the parameters sequencedinternally to GN&C dictate mission profile, attitudetimelines and other vehicle operating constraints and thusimpact the entire vehicle. From the perspective of missionsequencing, GN&C parameters effectively define themission being flown. To keep these mission levelparameters and constraints flexible to accornrnodatesequences for as yet undefined future mission sequences, adata-driven design approach is taken at the GN&Csubsystem level to permit adaptable mission sequences to bedeveloped over the life of the program. As with vehiclelevel automation software, the onboard GN&C sequencingsoftware must work together with -- or as part of -- theintegrated fault recovery lo gic on the vehicle. It must becapable of responding to Vinhibits, overrides and otherparameter updates from the ground or onboard crew toprovide control over the automation at all times [1].

Together the guidance, navigation and control algorithmswithin the GN&C subsystem require a complex interactionof these tightly integrated software components. Acentralized onboard sequencing engine provides the primarycontrol over these interactions as well as the capability toupdate static parameter data required to operate each ofthese algorithms. This functionality is collectively referredto as the GN&C Executive software. The executivesoftware is architected as a data-driven state machine enginewhich processes parameterized sequences of GN&CActivities. A GN&C Activity refers to the commands issuedby the GN&C Executive used to configure the GN&CSubsystem.

Within the GN&C executive software. GY&C Activitiesprovide the capability to 1) specify the active GN&Calgorithms (by issuing fli ght software modes), 2)configuring the GN&C algorithm behavior via staticparameters, and 3) initiate algorithm re-initialization.GN&C Activities provide a useful and convenient means tocollect groupings of functionality and parameters togetherfor one or more GN&C software components, for exampleone GN&C Activity can specify and configure the activealgorithms for the entire subsystem. GN&C Activities maybe strung together into a sequence to form a list of updatesto the configuration GN&C subsystem. Each Activity mayperform one or many actions thereby providing thecapability to define and execute coordinated actions for theentire subsystem. More detail will be provided in theexample to follow. The following section features keyderived design requirements for internal GN&C Activity listsequencing and data-driven logic specification.

GN&C Sequencing logic

To satisfy the requirement for truly reconfigurable missionsequences, it is necessary to provide a means to

parameterize the logical conditions between GN&CActivities as well as the Activities themselves. Thiscapability permits mission designers to recombine or addnew logic to existing sequences or even create entirely newsequences without rebuilding the flight software, savingconsiderable rework and testing expense over the life of theprogram [REF?]. On Orion the use of logical normal formswill be employed to permit mission designers to definelogical expressions of multiple variables, static parameters,and operations (AND/OR/NOT) [2]. These logicalparameterization schemes are straightforward, efficient andeasily extended to provide for multiple logicalinstantiations, wherever necessary.

Within the GN&C subsystem, this data-driven designpermits the transition criteria between each GN&CActivity to be parameterized along with the other details ofeach Activity. In this design each Activity has anassociation to a single logical object whose purpose is todefine that Activity's transition conditions. SatisA ing thetransition conditions in an Activity enables sequencing tooccur to subsequent Activities in the list. As shown in Ref.[2], transition conditions may be composed of complexlogical expressions of multiple variables.

In addition to nominal sequencing GN&C provides thecapability to define one or more logical paths through eachActivity list. These logical paths may be utilized to invokesimple nominal logic, or provide responses for detectedfaults. Within the GN&C subsystem; activation criteriadefine the conditions which permit one or more Activities tobe dynamically skipped, as needed. An example Activitylist making use of both transition and activation criteria ispresented at the end of this section.

Figure 3 depicts the relationship of GN&C Activityactivation and transition criteria schematically in a flowchart. It depicts several key aspects of the sequencing logicdesign. The "GN&C Reconfiguration" block represents theautomated commanded updates to the GN&C software atthe start of each Activity. These commanded updates defineboundaries of algorithm execution or changes to parameterswithin the software. When the GN&C subsystem is "inActivity A" it implies that Activity A's softwarereconfiguration commmands have been issued and theexecutive software is monitoring for the successfulcompletion of the Activity transition criteria. Vdhen thetransition criteria are satisfied, the software enablessequencing to subsequent Activities in the list. As depictedin Figure 4, the GN&C Activity activation criteria are notassociated with the GN&C Activities directly, rather theyare parameterized within a parent "Activity List" object.This relationship permits activation criteria to bedynamically evaluated to skip over several Activities in alist, without knowledge of any of the particular Activitydetails. (This particular implementation detail will berevisited again in Section 4). The logical parameterizationof activation criteria is the same as GN&C transitioncriteria; as such it is possible to define complex logical

GN&C GN&C Domain FunctionalityDomainGCI GN&C Command InterfaceNVA Absolute NavigationNVR Relative Navigation (Rendezvous)WE Ephemeris ProcessingNHM Navigation Health ManagerGMP Vehicle Mass PropertiesGDA Ascent GuidanceGDE Entry GuidanceGDO On-Orbit GuidanceGEM Guidance Health ManagerCNC Command-Module (CM) Control (Entry)CNS Service-Module (SM) Control (Ascent Aborts, on-orbit)CNL Launch Abort System (LAS) Control (Ascent Aborts)CNE Propulsion Engine ControlsCNP Propulsion Systems ControlCHM Control Health Manager

conditions if required. In the event that none of theActivity List activation criteria are valid, the executivesoftware simply remains in the currently active Activity anddoes not make any transition.

In Section 2 the concept of Segment transition indicationfrom the vehicle subsystems was mentioned. Thisindication signals to the TM software that each subsystem,including GN&C, has completed the objectives of theSegment and is ready to be commanded to a new MissionSegment. Although it is not depicted in Figure 4, thislogical condition is parameterized in exactly the samemanner as the Activity transition criteria, using a data drivenlogical association. This condition may be specifiedindependently of any of the Activity transition criteria, or itmay be setup to use exactly the same logical conditions.This is an important association as it completes the datadriven logical parameterization for the Mission Segment andmakes the mission sequencing information a completelyparameterized aspect of the mission plan.

In summary, this subsection has provided an overview ofthe executive software in place to parameterize sequenceswithin the GN&C subsystem. It has been designed toprovide the necessary level of flexibility for both nominaland contingency sequencing capability. The followingsubsections will focus on the GN&C architecture design inplace to support the automated updating of GN&C flightsoftware modes as well as providing the capability to makethe parameter updates to individual GN&C algorithms.

GN&C Executive and FSWDomain Interaction

The previous subsection described the GN&C executivesoftware Activity sequencing capabilities in response toMission Segment commands received from the TMsoftware. This subsection deals with the GN&Carchitecture used to distribute Activity commands within theGN&C subsystem. In addition, a description of theinfrastructure for updating static GN&C algorithmparameters is detailed.

The GN&C software is divided into 16 separate Gi &CFlight Software Domains, which each represent a groupingof common GN&C functionality. The GN&C FSWDomains are divided across functional categories(Guidance, Navigation and Control) as well as by majoroperational flight phase (Ascent, On-Orbit and Entry). Thisbreakdown facilitates distributed model-based development[ 3] and also has CPU throughput advantages to effectively`Idle' large portions of the code when they are not in use.Table 1 presents a complete listing of the GN&C FSWDomains by GN&C function. Note that the GN&C HealthMana ger Domain interaction with the rest of the GN&Carchitecture is described in Section 6, after concepts relatedto the nominal sequencing capability are presented. TheGCI Domain contains the GN&C Executive software aswell as other software components not related to thediscussion at hand.

N

MnJ

aN

N

Y

Activity AN.. r

Y

Y

Activity BN

Y

Activity CN

Y

Figure 4: Flowchart of activation and transition criteriafor GN&C Activity sequencing.

Table 1. The GN&C FSW Domain Definitions, sorted byNavigation, Guidance and Control function respectively.

The GN&C subsystem behavior is defined by the currentlyexecuting GiVI&C Domain _Modes. Each GN&C Domainhas a list of possible modes of execution that define theactive GN&C algorithms, thereby defining the behavior ofthat domain. The Domain Mode for each Domain is issuedby the GN&C Executive software and may be changed viaGN&C Activity updates. In many cases the Navigation,Guidance and Control Mode updates must be coordinated tooccur at the same time to ensure algorithm validity. Hence,the centralized GN&C executive software is responsible forcoordinating these actions across Domains via GN&CActivities.

In addition to the Domain Mode, the GN&C executive isresponsible for providing configuration information tospecify both Domain and GN&C algorithm-related staticparameters. These parameters may be specified via GN&C

F^ Gxecut

GDE Mode &Configuration GDE Domain

Status & ConGDE Domain Variables

Executive40 Hz

Monitor

1 Hz Guid.Data

EntryPointin

1Hz

Pred-Guidance

NVA NavAlpha C

Domain Data Loads Beta ►Bank DoMana ed

CMRaisePointin

CMRaise^^ Tar et

(a) Entry Guidance Domain (GDE), Entry Mode

F^GNC Executive

GDE Mode &Configuration GDE Domain

Status & Control

GDE Domain VariablesExecutive

40 Hz

1 Hz

EntryPointin

Pred-Guidance

1 Hz

VAlpha

.a Loads Beta

Mana ed Bank

_ CMRaisePointing

CMRaiseTarget

(b) GDE, Loads Managed Mode

Figure S: Example GN&C Executive and Domain Mode Functionality for the Entry Guidance Domain (GDE).(a) The active CSUs corresponding to the (Guided) Entry Mode(b) The active CSUs corresponding to the (Unguided) Loads Managed Mode

Activity independently of the Domain Mode, or as part of acoordinated update.

Figure 4 illustrates the GN&C Flight software architectureincluding a representative GN&C Flight Software Domain.The GN&C executive broadcasts the Domain Mode andconfiguration updates to each Domain in the GN&Csubsystem as specified in the GN&C Activity sequence.Each Domain receives a unique Mode and configurationcommand specific to that Domain (not depicted in thegeneric example of Figure 4). The GN&C Domains eachcontain a "Domain Executive" which is responsible forreceiving the Mode and configuration update commands andensuring they get distributed to the appropriate algorithms inthe Domain as described below.

Domain Executive and GN&CAlgorithm Execution

The GN&C algorithms themselves are partitioned intospecific Computer Software Units (CSUs) that are activatedas a function of the Domain Mode command received fromthe GN&C executive. The CSUs are each defined atmanageable levels of complexity to facilitate distributedmodel based development within the Domain [3]. Asshown in Figure 4, each CSU is defined with interfaces fordynamic I/O data (in blue) from other GN&C CSUs orexternal subsystems. Generally there are very complex I/Orelationships between Domains and CSUs within the GN&C

subsystem. Static input parameter structures are also defined(in pink) for each CSU. The static parameter values may becomprised of different types of quantities used for differentpurposes. For example; guidance parameters might includevalues of gains and control parameters might includedeadband values. These parameter values are controlled viathe GN&C executive software as configuration updates asspecified by GN&C Activities. More detail and examplesof the Domain and CSU parameters are provided in thesubsequent sections.

Domain Modes are defined such that each Mode activates aunique combination of CSUs within the Domain.Activation of a particular Mode causes the Domainexecutive to trigger the fixed-rate execution of CSUs for theconunanded Domain Mode. The Domain executive alsorelays to each CSU which parameter set to use for thecurrent GN&C Activity, as well as when to perform re-initialization functions.

The concept of CSU execution via Domain Mode commandis illustrated through a specific example in the EntryGuidance Domain (GDE) shown in Figure 5. The CSUs inthis Domain are responsible for collectively generating thecommanded bank angle of the Crew Module (CM) (shownin Figure 1) during the Entry phase of flight ; as well as otherfunctions not pertinent to this example. Figure 5a and 5bdepict the difference between two distinct entry guidance

schemes and the distinct set of active CSUs for two exampleGDE Domain Modes (Entry and Loads Mana ged Mode,respectively). In this example, the Entry Monitor CSU isresponsible for monitoring for time-critical events; such astriggering the parachute deployment. The outputs of theEntry Monitor CSU are required by the GN&C executivefor triggering the pertinent GN&C Activity and MissionSegment transitions. Although static parameter structuresare not depicted here, each of the active CSUs shown wouldrequire commanded updates from the GN&C executivesoftware to function properly in each of these anodes. Thefollowing subsection provides more detail and examples onthe mechanisms for making parameter updates withinGN&C CSUs for this purpose. .

CSU Parameter Structures

The previous subsection provided an overview of theDomain Modes and how they are used to control the GN&Csubsystem behavior through CSU activation. CSU staticparameters are also important in controlling the GN&Csubsystem behavior and performance as they are theprimary means by which mission level sequencinginformation is connnnunicated to the GN&C algorithms. Inthis context CSU parameters refer to mission specific targetvalues, performance thresholds, physical constants or othernon-dynamic data. In many cases CSU parameters are alsoused to intemally change the algorithm from one executionstate to another, through flags, enumerated types or othermeans. As a result, the mechanisms by which theseparameters are updated in the software are a very importantaspect of the automated sequencing capability of the Orionspacecraft. The following is a discussion of the GN&Carchitecture infrastructure required to support static CSUparameter updates on Activity boundaries.

In the existing GN&C architecture, the algorithmparameters fed into a CSU may come from one of threeseparate sources.

O GN&C — Level StructureO Domain — Level StructuresO CSU — Level Structures

The implication is that a particular CSU parameter mayhave scope at different levels of the software depending onthe definition of the parameters in other parts of the GN&Csoftware. The highest level is the GN&C parameterstructure which is defined and updated by the GN&Cexecutive software directly and contains parametersdestined for all of the GN&C Domains. The intermediatelevel is a Domain parameter structure that containsparameters connnon to multiple CSLJs within a Domain.The Domain parameter bus is updated by the Domainexecutive software since these parameters are needed bymultiple CSUs within the domain and not destined for anindividual CSU. The lowest level source of parameters isthe CSU parameter structure which contains parameters thatare only specific to a particular CSU. (The three parameter

update sources are not depicted in Figure 5 to maintainsimplicity of the Figure)

In some cases it is appropriate to elevate parameters out of aCSU-level parameter bus to either the Domain or the GN&Cparameter. One reason to separate these parameters todifferent levels is to ensure parameter consistency acrossmultiple CSUs. When a specific parameter is required inmultiple CSUs within the same domain it may be elevatedto the Domain parameter bus as long as its scope is limitedto one domain. Similarly if a parameter has scope inmultiple CSUs across multiple FSW Domains, it becomes acandidate for being moved to the GN&C parameter bus.Elevating parameters in this fashion ensures that theaffected CSUs are obtaining the exact same instance of aparticular parameter whenever it is updated. Examples forparameters of this type include physical constants (g, ft, c,etc.) as well as specific vehicle constants (engine thrust, Ispetc.).

Another reason to elevate parameters above the CSU bus isbased on the frequency of change of the parameter. Whenparameters are frequently modified in a mission sequence orvia command from the crew or ground, they could becandidates for assignment from the GN&C parameterstructure. These types of parameters are refereed to asGN&C command parameters because they often representthe items in software which are specific to a particularmission objective that crew or ground operators requireaccess to command updates, such as the target landing site,spacecraft attitude and rendezvous burn targets. Suchvalues change on a mission to mission basis or even morefrequently. These parameters may be elevated up to theGN&C level parameter structure even if only a single CSUrequires them. Assigning a parameter directly from thislevel provides a large benefit in that the quantities whichfrequently change can be segregated from the parameterswhich are more fixed and tightly controlled. The advantageof having direct access to the command parameters will bedemonstrated through example in the following section.However before moving on to this section it will be helpfulto present an example summarizing the concepts presentedin this section.

GN&C Activity Sequencing Example

This section has summarized the GN&C architecture tosupport automated sequencing and data-driven missionplanning for the Orion spacecraft. This final subsectionpresents a high-level sequencing example utilizing theconcepts and architecture presented thus far.

Figure 6 depicts an example for how a list of GN&CActivities may be used to sequence through a typicalautomated `Burn" Mission Segment using the Orion MainEngine (OME). In this example, the burn Segment isgenerically defined such that targeting for the burn haspreviously been achieved in the prior Segment. Upon thestart of the burn Segment, the vehicle first performs an

attitude maneuver to the desired attitude obtained from thetargeting solution. Once the attitude maneuver has beencompleted, the OME (shown in Figure 1) is used to executethe rendezvous burn to within some nonzero threshold of thetargeted burn velocity (called Velocity-to-Go (VGO)). Ifnecessary, a second "trim burn" is performed innnediatelyfollowing using the Reaction Control System (RCS) tocomplete the burn execution within a higher accuracytolerance since the RCS system is capable of achievingmuch lower residual Velocity-to-Go (VGO) threshold.Finally, the vehicle is placed into a safe Post-BurnConfiguration to await the next Mission Segment.

Figure 6 shows the current GN&C Activity as the RCS TrimBurn. The GN&C Executive sends active GN&C ModeCommands to the Absolute Navigation (1VVA), OrbitGuidance (GDO), and SM Control (CNS) Domains as wellas updated confi guration parameters to the GDO and CNS

Domains. The GN&C Executive also sends `Idle'commands to the remainder of the Domains.

In the Burn Segment example, the RCS Trim Burn Activitywill become active only if the residual VGO is above thethreshold for RCS trim burns. If that activation criterion istrue, the RCS Trim Burn Activity will execute. When thetransition conditions are true (residual VGO below thethreshold), the GN&C Executive will transition to the nextActivity in the list, Post-Burn Configuration. If the residualVGO happens to be less than the RCS threshold followingthe OME burn, the RCS Trim Burn Activity is skipped andGN&C sequences to the Post-Burn Configuration Activityinnliediately. In this case there is no need to start the RCSburn and the Activity sequence logic defined toaccommodate that.

sraasegment

Activity: Attitude Maneuver N

_ Y NAVIGATION GUIDANCE CONTROLrl LeoNav Idle Idle DA: Id Ie PreBurn 'DE: IdIe Auto RCS ^.'NC: Id Ie CNLldle

N = - _ Y

ty: Orion Main Engine (OME) Burn Execute N

ENAVIGATIONY GUIDANCE CONTROL _: GDO: CNS:v Idle Idle MA, Idle EGaGuitl 'DE: Idle SA-Trans ,..NC. Idle ,.NL:IdIe

y N —_ Y_J

Activity: Reaction Control System (RCS) Trim Burn Execute FNQY NAVIGATION GUIDANCE CONTROL

DA idle DO: 3DE: Idl CNS: ^NC Idle _ NL: IdIeLeoNav

Idle Idle -G4Guitl MA-Burn

N = = Y

Activity: Post-Burn Configuration NY NAVIGATION GUIDANCE CONTROL

N

NVA GDODA: IdIe DE: IdIe CNS: ..NC:IdIe NL:IdIeLeoNav

Idle Auto RCS— — Y

U

StartN

O O segment

m y r GO<=RCS Thre Send Se ment Transition

E c .2 && 9urn_complet Y Indication to TM

Figure 6: Example of GN&C Activity sequencing for a `Burn" segment utilizing the Orion Main Engine (OME)followed by a conditional clean up "Trim Burn" Activity using the Reaction Control System (RCS). The Changes toGN&C domain modes are shown highlighted with the domain configuration parameter updates for each Activity.The Segment transition indication criteria is shown as a separate logical condition required to complete the segment.

missionPhases

Ascent

^v) Earth Orbit

C-onfig,

ATPRnClz, Proxops, andDocking

ISS Attachedoperation TP

ivilsslonSegments

C oast toPlaneChange

r NPC ) Btarn

NP( Burn1

Coast toHeight

Adjust (NH)Burn

Activities

Attitude Nlaneaver

Orion Main Engine{ONIE)BurnExecution

Reaction Control GNC DomainSystem (RCS) ^ ^ ModesTrint Burn

NH

Burn Post-BurnConfiguration

Timeline Management GN&C

Software SoftwareFigure 7: PLACEHOLDER FIGURE ILLUSTRATING THE PSAM. shows the Orion mission sequencing hierarchyas it is decomposed between the Timeline Management software and GN&C Subsystem software.

When the objectives of the GN&C subsystem for the BurnSegment are completed (the burn has been completed), the`Se gment transition condition' is set true resulting in theSegment Transition Indication being sent to the TMsoftware. In this case the segment transition criteria is thesame as the completion of the final Activity in the ActivityList, but there is enough flexibility built in to the executivesoftware to allow for different conditions to be specified.Upon receiving indication that the Burn Segment iscomplete, the TM software is responsible for commanding anew Mission Segment to all of the vehicle subsystems.

A potential extension of this automated burn exampleincorporates additional logic within the Activity list toacconunodate the case that the OME fails during the burnand an immediate fault response to switch engine effectorsis required. In this case the Orion auxiliary engines (notrepresented in Figure 1) are used as a backup to completetime critical burns. To encode this fault response within theBum sequencing example shown in Figure 4 ; a separate"Aux Burn" Activity with associated activation andtransition criteria would be included between the OME andTrim Burn Activities. The Aux Burn Activity would benominally skipped, but in the event an OME failureoccurred the logic would be in place to respond to thefailure by jmmediately activating it. This type offunctionality is not fully defined at this stage of theprogram, but there are many instances where it may beapplied.

This example has provided details of how several aspects ofthe data-driven GN&C automated sequencing capabilitiescan be used. The following section will describe the schema

used to capture each portion of the Orion MissionSequencing hierarchy, including Mission Phase, MissionSegment, GN&C Activity, and GN&C Domain Mode (alsoreferred to as the PSAM schema)

4. PSAM SCHEMA

The previous sections described the mission sequencingcapability within the GN&C software and mechanismsthrough which this sequencing may be controlled. Asdescribed in these sections; the hierarchy of automationsoftware collectively forms a mission plan which isdistributed between the Timeline Manager and GN&Csoftware. This hierarchy of mission plan information iscomposed of Mission Phases, Segments, GN&C Activitiesand Domain Modes (PSAM). This hierarchy of sequencinginformation is depicted in Figure 7, showing the allocationbetween both TM & GN&C. For each nussion segment, asequence of Domain modes and reconfiguration commandsare issued to the Guidance, Navigation and ControlDomains via the list of configured GN&C Activities. In thissection, the software artifacts facilitating data-drivenmission design are presented. In addition, the designphilosophy and concept of operations for building a data

driven sequencer onboard a married system is discussed.

Because Orion is required to perform automatedsequencing, mission data for the nominal and contingencyMission Phases and Segments will be stored onboard thevehicle[l]. The current FSW design provides for an

onboard memory store of GN&C configuration data fromwhich sequencing can be performed. This data is loadedfrom configuration files at the start of the mission and may

be refreshed from these files at discrete points during themission, or reloaded if changes need to be made to theexisting configuration data onboard the vehicle. Sequencingfrom configuration data in memory requires that a dataschema is established whereby the configurations for all ofthe CSU parameters may be assigned to specific storagelocations in memory; queried and reinitialized if necessary.This data schema permits configurations from multiplelevels of the PSAM hierarchy to be defined, linked andsequenced as needed during the particular mission beingperformed.

The design provides for configuration elements at each tierof the FSW hierarchy to make it possible to configure thevehicle at each level of detail. Each lower level in thehierarchy provides access to specific parameters within theGN&C FSW. In this sense colnlmanding can be performedat a very high level (Segment), or very detailed; parameterlevel (CSU). The intermediate Activity and Domain levelsprovide corresponding intermediate levels of access toparameters at those levels of detail.

GN&C Automation Parameter Hierarchy

An overview of the GN&C PSAM Data Schema is depictedin Figure 8. This schema depicts the structure of the dataelements required by GN&C to sequence through Mission

Segments and GN&C Activities, with configurationsspecified for the GN&C Domains and CSUs. Each of theseelements represents a specific instance of configuration datawhich is linked to others through memory addresses andmay be accessed via the onboard software as needed toexecute the mission plan..

Segment transition criteria, Activity activation criteria andActivity transition criteria are all parameterized through thePSAM data schema. All of these logical conditions may beparameterized through the same data specification and arelinked with the appropriate parameter field as shown inFigure 8. The Segment configuration contains anassociation to the Segment transition criteria, associations toeach of the Activities in the sequence, and an association toan Activity activation criteria for each of the Activities inthe list. A GN&C Activity specifies how each of theGN&C Domains is configured by specifying the GN&CDomain Mode and configurations for each Domain. TheActivity configuration contains the Domain Modes, theDomain configurations to be used for that Activity, as wellas the transition criteria associated with that Activity.

In addition to Domain Modes and configurations, GN&C-level parameters are specified within each GN&C Activity.Recall from Section 3 that these parameters may have beenelevated because they are parameters which must be

Scenario Configurations are -GN&C simulation artifactsrequired to emulate TimelineManagement functionality

Segment, Activity &Domainconfigurations permitpartial specification ofparameters forsequencing flexibility

CSU configurationsrequire completespecification for dataintegrity

Scenario Cfq.

Segment List

11

Segment Cfq.Segment IDSegment TransitionActivity ActivationActivity List

y 1... m

Activity Cfq.(* . acts)

\

Activity IDActivity TransitionDomain ModesDomain configurations

I SegmentTransition

VCriteria

1 m ActivityActivation

Criteria Transition & Activationlogic are allparameterized usingthe same interfaces inConjunctive NormalForm (CNF)

ActivityTransition

Criteria

Domain A Cfq.

CSUa CsUb CsUcINIT=1 INIT=1 INIT=O

Domain B Cfg.CSUd CSUeINIT=1 INIT=1

er

Domains

etc..---____- •-------- -------------------------------

Other CSUCSUa Cfa. CSUbCfa. CSUe Cfa CSUd Cfq. CSUe Cfa. ParamlParaml Paraml Paraml t^araml Paraml Param2Param2 Param2 Pa2 Par Param2 Param3Param3 Param3 Param3 Par

Pa-2 Param3

Figure 8: The GN&C PSAM Data Schema depicting the primary configuration elements required to perform missionsequencing.

10

coordinated among CSUs in multiple Domains, or becausethey contain very mission specific parameter information.An example of how this parameter hierarchy might be usedin practice to segregate parameters is presented in thefollowing subsection on the "CSU Parameter Structure"

Figure 8 shows that GN&C Activities may be instantiatedwith 0...1 (zero or one) associations to each domainconfiguration structure. This is meant to imply that anActivity is not required to completely populate theparameter list of domain configurations. If a Domainconfiguration update is not present in an Activity itcontinues processing without changes. Although it is notdepicted in the figure, this is also true for the Domain Modeparameters specified in the Activity. This is an importantaspect of the Orion GN&C automation design whichpermits the automated sequence to be specifically targetedto only the areas of the software which need to be updated.Without this capability, the ground and the crew may havedifficulty making any changes to the vehicle softwarewithout first disabling the automation onboard the vehicle.

The GN&C data schema is architected to permit thespecification of a new set of Domain configurations for eachActivity. The purpose of each Domain configurationelement is to define changes to Domain and CSU level. Aswith the hi gher levels of the PSAM schema, only those CSUconfigurations which need to be updated are specified at thislevel: when a CSU configuration set is left unspecified itcontinues to run with the previously specified values. Thisis indicated in Figure 8 schematically using 0...1 (zero orone) associations to each CSU parameter element.

CSU Parameter Structure

The CSU configuration element controls all of the CSU-level parameters for a CSU and specifies the values forthose parameters for the current Activity. CSU parametersare subdivided into groups of parameters that are specific toa particular function within the CSU, or parameters that arefrequently updated. For example, it is common for a CSUto split parameters into groups which are related to

(1) Hardware Interfaces includin g IMU mounting angles,lever arm corrections, or other similar quantities.

(2) Mathematical / Physical Constants specific to aparticular algorithm.

(3) Algorithm Performance such as control gains, filtercoefficients, etc.

These groups are largely defined by the CSU form andfunction, and each CSU may be defined with a number ofdifferent configuration elements within the overall schema.As shown in Figure 8, these confi guration sets may beupdated independently from one another or in a coordinatedfashion. CSU Command parameters such as attitude targets,landing site targets, etc. are not handled within these

confi guration sets to provide more direct access to themthrough GN&C Activities.

A basic example illustrating this CSU parameterspecification hierarchy comes from the SM Control Domainparameterization for attitude pointing utilized while onorbit. To operate the attitude pointing algorithm, a detailedlist of algorithm-specific constants related to performanceand computation method are required. In addition, anumber of parameters define the specific pointing targets, aswell as the pointing method desired. In this case all of theattitude target parameters as well as the pointing method areelevated into the GN&C parameter bus to make it part of theActivity specification, while algorithmic detail parametersare separated out into separate configuration elements forselection as part of the Domain configuration. The detailedparameter sets include generic options for high accuracy,medium accuracy and low accuracy for general use, as wellas configuration sets which are specifically tailored forparticular nussion events. In this software architecturemission planners and analysts are able to specify themission specific parameters at the Activity level as well asdefine which configuration set is required for each particularActivity. In this sense the GN&C Activity parametersprovide a high level "user interface" to the GN&CSubsystem and insulate the details of the GN&C algorithmsinto lower level configurations.

GN&C Schema Specification Standards & Evolveability inOrion Automation

The Orion GN&C automation software is being designedwith the flexibility to make large configuration changes aswell as individual parameter updates on Activityboundaries. This type of commanding refers to the ability tospecify only those values which have to be updated on aparticular Activity boundary. However, this does notpreclude a nussion planner from fully specifying a largesubset (or complete set) of GN&C parameters within anActivity. Parameters which are not updated remain staticacross each Activity boundary. Likewise, GN&C DomainModes may be specified in the same manner. Only thoseModes which need to be updated have to be set within theGN&C Activity.

The capability to build up lists of Activities which are notcompletely specified is important to ensure that the Activitylists are robust to external changes by the ground or crew,FDIR responses and contingency cases. Providing thisfeature permits Activity lists to be built up whichincrementally affect the confi guration of the GN&Csoftware. In this paradigm ground or crew operators canmake updates to the GN&C configuration or potentiallyupdate Domain modes without necessarily being forced toinhibit the automation software or make large updates tosubsequent Activities configurations. The key to this isdesigning mission sequences which only affect the minimalset of GN&C parameters required as they are executed.

Operationally partial Activity specification is also a benefitbecause the automation software behaves similarly to themanner in which the onboard crew would if they wereissuing the same conunands. If the crew wished tomanually issue a sequence of commands, the exact samemechanisms to update the GN&C software could be used.Activity sequences which completely specify the full set ofGN&C parameters must be updated if crew or groundcommands are required to persist across Activityboundaries. Partial Activity specification is thus necessaryto mitigate complex interactions between the sequencingand FDIR software, as well as the crew.

This concept of operations requires a very well understooddecision tree to progress between each Mission Segment toensure that the software is not put into an unsafe orundesirable configuration. It is likely that each MissionSegment will include an initial Activity that is completelyspecified to setup the necessary preconditions in enteringthe Mission Segment. This procedure ensures that theGN&C software is properly configured regardless fromwhich Mission Segment it is transitioning.

The flexibility to partially specify GN&C parameters is apowerful capability which permits mission designers theability to make changes to specific areas of the GN&C flightsoftware and leave others unaffected as the missionprogresses. However this capability requires missionplanning tools and good visibility into the confi guration ofthe vehicle as a mission is executed. The following sectionaddresses how the PSAM mission sequence might bevisualized, manipulated and updated using prototypedatabase tools.

5. PSAM DATABASE

The PSAM data schema is used to parameterize automatedsequences for the GN&C subsystem, and it enablescoordination among all of the elements of the GN&C flightsoftware. For a particular nussion, there will be parameterdata associated with the Mission Segment, Activity, GN&CDomain Mode, as well as parameter data for individualCSUs. Prior to and during each flight, algorithmdevelopers, analysts, and mission planners will need tomanage and manipulate this data for many nominal andcontingency scenarios. Because of the potentially imposingtask of managing this data manually through dataconfiguration files, a database was developed to manage thePSAM data content associated with a variety of missionscenarios.

Motivation

The Orion GN&C development is currently at a stage wherethe vehicle flight software for guidance, navigation, andcontrol is nearing complete integration. Subsequent to thateffort will be extensive analysis and testing, which requiresthe mana gement of data as described in the previous section.It is therefore desirable to have a means of storing andmanipulating this data in a flexible and reliable way. This is

part of the motivation for building a database for the PSAMdata content. Furthermore, useful features of databasesinclude:

• Queries to extract the relationships between datasets• Flexibility in making changes• Consistency in data records• Ability to build user interfaces to easily manipulate the

underlying data and generate summary reports.

These database features will be useful for assessing timelinesequences, GN&C configurations, and the effects changeshave on both. For example, the modification of CSUparameters that are also used in another portion of themission may have effects that need to be understood, andthe database could readily provide information on theseimpacts. The database will evolve into a critical aspect ofusing the GN&C: sequencing software.

Microsoft Access was chosen as the initial prototypeapplication for its ease of use and availability. Oncestability is achieved and other database tools are developedacross the Orion project; this work will be transferred to amore permanent platform. Future versions of this tool willbe essential for managing and trackin g the hundreds, if notthousands, of confi guration items required to operate andconfigure the GN&C subsystem.

PSAMDatabase Features

The "PSAM Database" consists of a series of tables andrelationships that correspond to the data schema of theGN&C subsystem. The full hierarchy of configuration data,from the scenario level down to the algorithnvCSU level iscaptured in the schema of the database, and mirrors thePSAM data schema.

There are several beneficial features of the database. Oneuseful capability is the quick and easy replication of data.This allows PSAM scenario confi guration data to be quicklymodified. For example, if one scenario is set up to test anominal entry, another scenario testing an alternateguidance scheme can be built by copying the nominalscenario hierarchy and altering which guidance mode runs.Both scenarios can be saved in the ydatabase for futureanalysis.

Another benefit of the database is that it facilitates access toand visualization of the data. A series of user interfaceforms have been built to enable easy manipulation of PSAMdata. The primary form in the database, the scenariomanagement form shown in Figure 9, enables user input forinformation related to the Mission Segments and the GN&CActivities, including Domain Mode and configurationspecification. There are also regions on the form to specifythe criteria for Segment and Activity transitions, as well asActivity activation criteria. )Vhen a user needs to specify anew transition condition, a button brings up a separatetransition form for buildine the transition and activation

12

ActivationlTransition Information

Activation Criteria View Criteria For —

TRUE Tina C' Activation

Activity Transition Criteria r Acty Tim

ARHold_RateDamp ATM C Seg Tins

ActvTins: 1 I47 & X2 & X3 & X4 & X5 & XG & X7] I XB

criteria. Once a condition is created using the transitionform, it can be applied to Segments and Activities on thescenario management form. When a user needs to specify anew domain configuration, a button brings up a separatedomain configuration form. With this interface the user canspecify which CSU parameter sets to use for a particularActivity. The specification at this level is what dictates thedata values that will be used by the GN&C algorithmsduring different portions of the mission.

There are certain aspects of the GN&C architecture designthat will change on occasion and affect the PSAM dataschema. One example is the set of variables that is used tocompose transition conditions. To readily adapt to theseperiodic changes, the the database incorporates utilities toautomatically read in external data. This allows for updatesto be readily merged with the data in the database.

Another feature of using a database is the automaticgeneration of configuration artifacts and suininary reports.Once the mission data is input for a particular scenario; thegeneration of configuration files can be performedautomatically. These instances of confi guration data arewhat will be loaded into the flight vehicle for use by theflight software during a mission- Also, this automatic filegeneration allows analysts working on testing algorithmsand software to quickly manipulate data sets, run simulation

and analysis tests, verify vehicle performance, and testsoftware functionality. Alternatively, this would have to bedone by manually editing and managing numerousconfiguration sets that contain the y PSAM data.Furthermore, this capability also insulates users fromchanges to the format of the configuration artifacts since thefiles can be regenerated to match a new standard.

Generation of summary reports can be automated fornumber of purposes. These include, but are not limited to:

• Assessment of Segment and Activity content• CSU parameters being used• Attitude timelines• Trajectory timelines

User Communities

Use of the PSAM database in the near-term will be byGN&C analysts who are developing scenarios that includespecific Segment and Activity sequences they wish toanalyze. The database allows users to enter ; store, andoutput the data associated with the tests they need to carryout. Therefore, the primary function currently is for GN&Canalysis and test case development.

Scenario 0MT-SC-02_NornFD1Asce ^ J ' AddlEdit Scenario

1 Segment CoastT001Bur1-1 4] ► AddlEdit Segment Reorder Segments 'Segment Transition TaigelComplete_TlGminus Trns

Activity

Activity ListH sw Activity

Rename Activity Delete.Activity AttitudeManeuver

Reorder Activities I Save Activity BurnTargetingActivity DescriptionManeuver to 01 burn attitudel

J

x'

New

nJI

nJI

Domain Mode and ConfigUration Specification

Domain Mode Configuration

NVA . ILEONavIINVA_CSUFiles_vl.conf JCNS - AutoRCS_Cntl CNS_CSUFiles vi.conf JGDO - Inactive - GDO_CSUFiles_vl.conf J

J

Tronsilion Literal Exnressions

31M

X[: CIUS_SMBLOG_OUT.dv_Mu1JAxis_0B [2]<= 0.1 [1]

X3:CNS_SMBLOG_OUTAv_MultiAxis_OB [3]<= 0.1 [1]

X4:CN5_SMBLCG_OUT.dv_Mu1tiPxis_CB [1]>_ -0.1 [1]

X5:CNS_SMBLOG_OUT.dv_MultiAxis_OB [2]>_ -0.1 [7]

Figure 9: The GN&C PSAM Database scenario management form is used to specify the Segment, Activity,and domain data for each scenario.

13

A future step will be to integrate the GN&C data andschema into the databases being developed for the entireOrion vehicle. The consistent use of data variables as wellas vehicle sequencing that includes interactions between allthe subsystems are important steps in the overall design ofOrion.

Eventually the process of controlling the GN&C domainsthrough Activity sequences will also be merged withmission planning and ground operations during flights. Thetesting of mission plans is an important effort, and the data-driven nature of the Orion flight software architecture willbe simultaneously powerful and adaptable . Because of thisflexible approach, ground tools that enable operationspersonnel to understand and manage data not only forGN&C but also for the entire vehicle will be needed. A toolwith user interfaces will aid in this greatly because it canprovide indications of valid configurations for the vehicleand quickly generate flight software products for testing.The PSAM database currently under development willprovide guidance on how to establish those planning andoperational capabilities for the future.

6. OFF-NOMINAL GN&C AUTOMATION

The previous sections described the nominal sequencingcapability and touched on certain preliminary aspects of thedesign related to contingency sequencing and fault recovery.This final section presents issues related to off-nominalinteractions with the architecture for issues related to faultdetection support as well as manual interactions with theautomation software. These issues represent some of thecomplication in architecting automation software on a faulttolerant, man-rated vehicle and intersect directly with thePSAM data-driven schema in the specific ways presentedhere. At the time of writing of this abstract, these topics areless mature than the material presented in earlier sectionsand should be taken as forward work items. These areas areof critical interest to the GN&C conrnunity and will beaddressed on the forward path to CDR.

GN&C Fa tilt Recovery Software

The Orion Fault Detection Isolation and Recovery (FDIR)software is distributed between VSM and GN&C, much likethe mission sequencing software described in the previoussections. All failures that affect multiple subsystems orrequire changes to the vehicle power or resource states areaddressed by VSM software, specifically SystemsManagement (SM) and Timeline Management (TM)software. The SM software handles vehicle level FDIRlogic by collecting health and status from all the vehiclesubsystems, resolving anomalies using root-causedetermination, and commanding responses via the

contingency commanding mechanism introduced in Section2. This contingency Mission Segment results in the GN&Csubsystem transitioning to a new set of GN&C Activities forthat Segment, however it should be noted that this behavioris identical to actions taken during any nominal Segmenttransition. In this case, the GN&C Activities are insteaddesigned to respond to the specific contingency situation athand.

The GN&C FDIR logic is responsible for responding tofailures that must be resolved quickly within the subsystem,as well as reporting all internal faults to the VSM anddisplay software such that the appropriate actions can betaken at that level. In a most cases, the appropriate GN&Caction is to place the software into a "safe" state until theTM/SM software can respond with a new Segment, howeverthere may a select few cases in which GN&C must takeaction.

Figure 10 represents a block diagram of the key interactionsbetween GN&C and VSM related to FDIR, as well asseveral options for how the GN&C Health Managerdomains may interact within the existing GN&Carchitecture. A similar version of the GN&C architecture(Figure 3) is depicted with an example "FDIR CSU"included. From an architecture perspective, a FDIR CSUsimply has embedded logic which provides capability todetect or isolate faults in hardware, sensors, or thealgorithms themselves. They may be distributed throughoutthe flight software and respond to parameter updates andMode changes like any other CSU. In addition FDIR CSUsare capable of providing dynamic input to any other CSU asa dynamic switching mechanism to affect direct changeswithin the FSW domain as shown in Figure 10.

As referenced in Table 1, the GN&C Subsystem includesNavigation, Guidance and Control health manager domainsfor the purpose of consolidating status signals and providingcornmon interfaces to both internal and external sources. Itis likely that the health managers will require sequencinginformation as well as parameter updates for specificSegments or Activities. For example, there may be a set ofalgorithms that perform FDIR durin g an Orion Main Engineburn. These monitoring al gorithms will not be requiredduring other portions of the mission, and the healthmanagement parameters may be specific to that particularburn. Since the ability to mode algorithms into differentstates is accomplished in the other GN&C domains throughenacting GN&C Domain Modes, a similar approach may beused for the health management domains in this respect. Toimplement this functionality in the existin g architectureadditional associations in the PSAM schema would be madeto include details for each of the Health managers assimilarly shown for the existing GN&C Domains.

14

Vehicle Systems Management (VSM) SoftwareOth?r VSM SW

16111111LOW-

Timeline Vehicle FDIR Info SystemsOMission Management Management

Segment

GN&C SubsystemGNC Executive

omain ModeContig u ration..........

.a in3.om

Domain--- --- Executive

DynamicInput

eters II

Health Mgr

•S ,

taut ti

Dynamic 1----^Input FDIR FDIRCSU

Static CSU OutputParameters

•----------------------------------------------------------

Figure 10: GN&C-level and VSM-level FDIR Architecture components related to off-nominal sequencing and faultresponse. At least three potential options are described for providing fault responses within the GN&C subsystem viathe Health Manager Domains.

Figure 10 describes three non-mutually exclusive optionsfor fault response logic which may be architectd utilizingthe Health Manager domains for each of the GN&Cdomains grouped in Table 1. Option 1) relies on theSystems Management software to correctly update theMission Segment to a valid contingency response based onthe indicated fault(s) from GN&C as well crew/grounddecisions. Option 1) is the preferred method for most faults,since issuing new Segments via TM is also the nominalcommanding mechanism. However there will also belatency associated with Segment changes, and in some casesthis latency may be greater than safely allowable, therebymaking one of the other options more suitable.

Option 2) describes the use of the GN&C Executive todirectly update the modes and/or configurations of theaffected GN&C Domains utilizing the centralizedsequencing logic described in Section 3. In this case theHealth Managers (or CSUs themselves) report faults to theGN&C Executive software as well as the vehicle levelsoftware. One benefit of this method is that it is possible toachieve coordinated GN&C responses to particular faultsand this scheme will be at least as fast as the proposedcommanding path described in option 1). Depending on thecomplexity of the fault responses required, option 2 wouldpotentially require updates to the PSAM data schema toaccommodate complex interactions of Domains.

Option 3) provides the least reconfiguration latency at theexpense of additional distributed complexity within theDomain Executive and Health Manager software. Thisoption provides some limited capability within the Health

Manager software to update modes and configurations inother GN&C Domains immediately after faults are detected.In this scheme Domain Executives would be required toaccept reconfiguration commands from either the GCIDomain, or one or more of the Health Manager Domains asshown in Figure 10. For example, assume that Table 1represents the GN&C Domain execution order (from top tobottom), and the health manager Domains have thecapability to change Modes or update the Domainconfiguration to a predefined state in the event a particularfault occurs. In this example, it is plausible to trace a faultrecorded in Navigation through to the NHM Domain andimmediately trigger an `Idle' Mode change in the currentlyactive control Domain. This action would effectively "safe"the vehicle by preventing thruster firings until such time thata contingency Segment were provided by the TM software.There are many variations on this particular example, and itmay be extended these other cases as well.

'Mille option 3) provides almost no response time to protectthe GN&C software from faults, it requires the mostcomplex interaction of GN&C recovery software. An openquestion left to be resolved is how many faults of this typewill need to be covered with this sort of protection. Inaddition, since the Health Managers may have reloadableparameters like any other GN&C Domain, it is conceivableto use a data-driven specification to define faults as well astheir responses onboard the vehicle. In this case, the PSAMschema would be impacted and modified to include thenecessary artifacts to parameterize these logical conditionsand their responses in a very similar way to how the existingarchitecture is parameterized. If implemented this

15

architecture would enable the GN&C community tocontinue to redefine and create new fault responsefunctionality within GN&C throu gh the use of configurationdata and extensions to the PSAM database over the life ofthe program.

Displays & Control Interactions, Manual Commanding

The Orion Display & Control requirements are currentlyunder development and these requirements will imposeadditional complexity within the GN&C subsystem. Onearea of complexity may be in crew initiated Activitycommanding. It is currently uncertain as to the level ofActivity commanding that will be required by the onboardcrew. At a minimum the crew will have the capability toinhibit and enable Activity sequencing, as well as perform aseries of manually initiated Activities. The modification ofspecific parameters within the Activity list will also beavailable for edit by the crew via display interfaces.However, the capability to insert, delete and reorder GN&CActivities within the current or an upcoming Activity listwould not be available given the current automationarchitecture. In this commanding scheme, ground operatorswill have the primary responsibility to reload any Activitylist or CSU configuration(s) if the situation requires suchactions.

A more sophisticated commanding capability might includefeatures such as insertion, deletion and possibly reorderingof Activities within a current or fitture Activity list whennone of the pre-planned contingency Segments[l] suit thesituation at hand. This functionality would pernut onboardor ground operators to modify Activity lists whenunforeseen events occur, however this capability wouldcome with an increased risk that an Activity list couldmistakenly put the vehicle into an unsafe configuration orcause the Mission Segment objectives to becomeunachievable. Insertion, reordering and capabilities of thisnature inherently make validation much more difficult toperform. This type of commanding capability has to beweighed against the cost of the extra software validation itwould require.

To support such features not only would the displaysoftware have to support it, but GN&C Activity sequencingwould likely need to become more sophisticated as well.Figure 11 depicts a modified Activity sequencing flow chartwith both entrance criteria as well as exit criteria associatedwith every Activity. The extra entrance criteria would beneeded in this case to collect all of the preconditions whichmust be satisfied before the Activity can be issued to theGN&C Domains. Contrasted with Figure 4 shown earlier,the primary benefit is that specific conditions can be morereadily associated with the Activity with which they belong,rather than being collected together in one larger and morecomplex logical expression called the `transition criteria.'Note that permitting this extra logical association would addone additional logical association to the Activity parameterspecification depicted in Figure 8. Making this extra logical

NActivity A

YN

Activity BNJ W2

<

N

Q N Y

7N

Activity C

Y_Y - :149

N Y

Figure 11: Activity sequencing logic with entrancecriteria, exit criteria and activation (skipping) logic.Providing the capability for sequences to specify entranceas well as exit criteria makes it operationally feasible toconsider Activity insertion and reordering features.

association makes it explicitly clear what preconditionsmust be achieved to perform each GN&C Activity as wellas what confirmation / indication conditions are required toproceed onward in the list. These associations make it morelikely that an operator would be able to confidently insert,remove or reorder Activities without having to makechanges to the remainder of the data in the Activity list. Itprovides a means by which each Activity may be logicallyisolated from the others in the list and thereby reordered, orremoved without being required to make complex changesto multiple elements of the schema.

As an example of how this new association schema aids inActivity insertion, recall the Burn Segment Activity listshown in Figure 6. In this example the first transitioncriteria is listed as "attitude maneuver complete" &&"mission elapsed time" >= "time of ignition." In this case,the first condition clearly belongs as the exit condition to thefirst Activity (the attitude maneuver), while the secondcondition belongs as the entrance condition to the "Burn"Activity. Separating these conditions pern7its an operator toconceivably insert an Activity between them without havingto make changes to the preceding or subsequent Activity inthe list. If these conditions were to be kept within onetransition criteria logic statement. it would be necessary tomodify the attitude maneuver Activity for the list to functionas intended and make such a function much more difficult toperform operationally. The capability to add GN&CActivities will be evaluated in more detail as the designmatures and human-in-the-loop evaluations are conductedgoing towards CDR.

16

7. CONCLUSIONS

This paper has presented an overview of the flight softwarearchitecture as it relates to the latest design for automationimplementation within the GN&C subsystem for Orion.The hierarchy of configuration elements was presented toclarify a basic concept of operations for the automationsoftware as well as how the automation capabilities will beparameterized and maintained by GN&C analysts andmission planners.

Several forward work items were detailed on the path to theproject CDR. First, the interactions between the vehicle-level FDIR software as well as the distributed GN&C FDIRsoftware must be further understood and integrated.Secondly, the interactions between GN&C and the vehicle-level confi guration management software must be furtherunderstood and documented. Finally, the conunand andcontrol interfaces with displays and GN&C automationmust be designed. The GN&C community recentlyestablished a simulation environment for testing thesecapabilities in a closed-loop engineering simulation andmore fidelity will continuously be added to these simulationenvironments to aid in driving out the correct functionalallocation for all of these software functions.

ACKNOWLEDGEMENTS

There are several people and organizations we would like tothank... Funding provided by...

REFERENCES

[1] Hart, J., King, E., Miotto, R, Lim, S., "Orion GN&CArchitecture for Increased Spacecraft Automation andAutonomy Capabilities" AIAA Aug 2008

[2] King, E., Hart, J., Miotto, P. "Orion GN&C ExecutiveArchitecture for Increased Automated aid AutonomousSpacecraft Operations" AAS Feb 2009

[3] Tamblyn., S., Henry, J., King, E. "A Model-Based Design andTesting Approach for Orion GN&C Flight SoftwareDevelopment" IEEE Mar 2

17

18