Elegant Systems: Engineering at the System Level

1. Engineering Elegant Systems: Engineering at the System Level Consortium Team UAH George Washington University Iowa State Texas A&M University of Colorado at Colorado Springs (UCCS) Missouri University of S&T University of Michigan Doty Consulting Services AFRL Wright Patterson 11 July 2017Michael D. Watson, Ph.D.

2. Outline • Understanding Systems Engineering • Postulates • Hypothesis • Principles • Systems Engineering Domain • System Integration • System State Variables • Goal Function Tree • State Analysis Model • System Value Model • System Integrating Physics • System Autonomy • Multidisciplinary Design Optimization (MDO) • Engineering Statistics • Methods of System Integration • Discipline Integration • Sociological Concepts in Systems Engineering • Information Flow • System Dynamics • Cognitive Science • Policy and Law in Application • Supporting Processes • Summary

3. Understanding Systems Engineering

4. Motivation • System Engineering of Complex Systems is not well understood • System Engineering of Complex Systems is Challenging • System Engineering can produce elegant solutions in some instances • System Engineering can produce embarrassing failures in some instances • Within NASA, System Engineering does is frequently unable to maintain complex system designs within budget, schedule, and performance constraints • “How do we Fix System Engineering?” • Michael D. Griffin, 61st International Astronautical Congress, Prague, Czech Republic, September 27-October 1, 2010 • Successful practice in System Engineering is frequently based on the ability of the lead system engineer, rather than on the approach of system engineering in general • The rules and properties that govern complex systems are not well defined in order to define system elegance • 4 characteristics of system elegance proposed as: • System Effectiveness • System Efficiency • System Robustness • Minimizing Unintended Consequences

5. Consortium • Research Process • Multi-disciplinary research group that spans systems engineering areas • Selected researchers who are product rather than process focused • List of Consortium Members • Michael D. Griffin, Ph.D. • Air Force Research Laboratory – Wright Patterson, Multidisciplinary Science and Technology Center: Jose A. Camberos, Ph.D., Kirk L. Yerkes, Ph.D. • Doty Consulting Services: John Doty, Ph.D. • George Washington University: Zoe Szajnfarber, Ph.D. • Iowa State University: Christina L. Bloebaum, Ph.D., Michael C. Dorneich, Ph.D. • Missouri University of Science & Technology: David Riggins, Ph.D. • NASA Langley Research Center: Peter A. Parker, Ph.D. • Texas A&M University: Richard Malak, Ph.D. • Tri-Vector Corporation: Joey Shelton, Ph.D., Robert S. Ryan, Kenny Mitchell • The University of Alabama in Huntsville: Phillip A. Farrington, Ph.D., Dawn R. Utley, Ph.D., Laird Burns, Ph.D., Paul Collopy, Ph.D., Bryan Mesmer, Ph.D., P. J. Benfield, Ph.D., Wes Colley, Ph.D., George Nelson, Ph.D. • The University of Colorado – Colorado Springs: Stephen B. Johnson, Ph.D. • The University of Michigan: Panos Y. Papalambros, Ph.D. • The University of Texas, Arlington: Paul Componation, Ph.D. • The University of Bergen: Erika Palmer • Previous Consortium Members • Massachusetts Institute of Technology: Maria C. Yang, Ph.D. • Stevens Institute of Technology – Dinesh Verma • Spaceworks – John Olds (Cost Modeling Statistics) • Alabama A&M – EmekaDunu (Supply Chain Management) • George Mason – John Gero (Agent Based Modeling) • Oregon State – IremTumer (Electrical Power Grid Robustness) • Arkansas – David Jensen (Failure Categorization) ~50graduate students and 15 undergraduate students supported to date

6. Understanding Systems Engineering • Definition – System Engineering is the engineering discipline which integrates the system functions, system environment, and the engineering disciplines necessary to produce and/or operate an elegant system. • Elegant System - A system that is robust in application, fully meeting specified and adumbrated intent, is well structured, and is graceful in operation. • Primary Focus • System Design and Integration • Identify system couplings and interactions • Identify system uncertainties and sensitivities • Identify emergent properties • Manage the effectiveness of the system • Engineering Discipline Integration • Manage flow of information for system development and/or operations • Maintain system activities within budget and schedule • Supporting Activities • Process application and execution

7. Systems Engineering Postulates • Postulate 1: Systems engineering is product specific. • Postulate 2: The Systems Engineering domain consists of subsystems, their interactions among themselves, and their interactions with the system environment • Postulate 3: The function of Systems Engineering is to integrate engineering disciplines in an elegant manner • Postulate 4: Systems engineering influences and is influenced by organizational structure and culture • Postulate 5: Systems engineering influences and is influenced by budget, schedule, policy, and law • Postulate 6: Systems engineering spans the entire system life-cycle • Postulate 7: Understanding of the system evolves as the system development or operation progresses

8. System Engineering Hypotheses • Hypothesis 1: If a solution exists for a specific context, then there exists at least one ideal Systems Engineering solution for that specific context • Hypothesis 2: System complexity is greater than or equal to the ideal system complexity necessary to fulfill all system outputs • Hypothesis 3: Key Stakeholders preferences can be accurately represented mathematically

9. Systems Engineering Principles • Principle 1: Systems engineering integrates the system and the disciplines considering the budget and schedule constraints • Principle 2: Complex Systems build Complex Systems • Principle 3: The focus of systems engineering during the development phase is a progressively deeper understanding of the interactions, sensitivities, and behaviors of the system • Sub-Principle 3(a): Requirements are specific, agreed to preferences by the developing organization • Sub-Principle 3(b): Requirements and design are progressively defined as the development progresses • Sub-Principle 3(c): Hierarchical structures are not sufficient to fully model system interactions and couplings • Sub-Principle 3(d): A Product Breakdown Structure (PBS) provides a structure to integrate cost and schedule with system functions • Principle 4: Systems engineering spans the entire system life-cycle • Sub-Principle 4(a): Systems engineering obtains an understanding of the system • Sub-Principle 4(b): Systems engineering models the system • Sub-Principle 4(c): Systems engineering designs and analyzes the system • Sub-Principle 4(d): Systems engineering tests the system • Sub-Principle 4(e): Systems engineering has an essential role in the assembly and manufacturing of the system • Sub-Principle 4(f): Systems engineering has an essential role during operations and decommissioning

10. Systems Engineering Principles • Principle 5: Systems engineering is based on a middle range set of theories • Sub-Principle 5(a): Systems engineering has a mathematical basis • Systems Theory Basis • Decision & Value Theory Basis (Decision Theory and Value Modeling Theory) • Model Basis • State Basis (System State Variables) • Goal Basis (Value Modeling Theory) • Control Basis (Control Theory) • Knowledge Basis (Information Theory) • Predictive Basis (Statistics and Probability) • Sub-Principle 5(b): Systems engineering has a physical/logical basis specific to the system • Sub-Principle 5(c): Systems engineering has a sociological basis specific to the organization • Principle 6: Systems engineering maps and manages the discipline interactions within the organization • Principle 7: Decision quality depends on the system knowledge represented in the decision-making process • Principle 8: Both Policy and Law must be properly understood to not overly constrain or under constrain the system implementation • Principle 9: Systems engineering decisions are made under uncertainty accounting for risk

11. Systems Engineering Principles • Principle 10: Verification is a demonstrated understanding of all the system functions and interactions in the operational environment • Ideally requirements are level and balanced in their representation of system functions and interactions • In practice requirements are not balanced in their representation of system functions and interactions • Principle 11: Validation is a demonstrated understanding of the system’s value to the system stakeholders • Principle 12: Systems engineering solutions are constrained based on the decision timeframe for the system need

12. Methods of System Integration Goal: Techniques to Enable Integrated System Design and Assessments by the Systems Engineer

13. System State Variables Goal: Utilize system state variables to understand the interactions of the system in relation to system goals and system execution

14. System State Models • System Stage Models represent the system as a whole in terms of the hardware and software states that the system transitions through during operation • Goal Function Tree (GFT) Model • “Middle Out” model of the system based on the system State Variables • Shows relationship between system state functions (hardware and software) and system goals • Does not contain system physical or logical relationships and is not executable • System State Machine Model • Models the integrated State Transitions of the system as a whole (i.e., hardware states and software states) • Confirms system functions as expected • Checks for system hazardous, system anomalies, inconsistent state progression, missing states, improper state paths (e.g., short circuits in hardware and/or software design) • Confirms that the system states progress as stated in the system design • Executable model of system

15. Booster – CS Ascent GFT System Works

16. System State Machine Model • The state analysis model is split into two main components: • Manager software model • System Plant • Modeled using MATLAB Stateflow • Allows the software model to look like the SysML Activity Diagrams • Allows the SystembPlant to be modeled as State Machines • Allows those two models to interact with each other within the MATLAB environment • Facilitates the ability to generate custom analysis tools • Reads in command sequence to execute model

17. State Analysis Model for SLS M&FM Faults Physics Values Control (SysML to Stateflow) Commands Plant (State Machines) Sensor Values Commands From Launch Countdown Doc • 14% of R12 modeled • Over 7,200 Transitions in the Vehicle and Software • Over 3,500 States in the Vehicle

18. System Value Goal: Utilize system state variables to understand the interactions of the system in relation to system goals and system execution

19. System Value Model • A System Value Model is a mathematical representation of Stakeholders Preferences (Expectations) for the system • The basic structure is straight forward • The sociology/psychology of representing the Preferences can be a challenge • The System Value Model is the Basis of System Validation!!! • The Requirements and Design Models form the basis of System Verification • The System Value Model forms the basis of System Validation • Constructing an SLS Value Model to compare to System Validation results • Can expand to Integrated Stack with input from MPCV and GSDO • System Value model also provides basis for a measure of System Robustness • How many mission types are supported by the system?

20. Integration with the Capability Model Congressional Model Development Cost Capability Value Mission 3 Mission 1 Mission 2 SLS Attributes

21. Production Function • 𝑌𝑇 = 𝐴𝑅∗[𝛿∗𝐾𝑇(𝜎−1)/𝜎+(1−𝛿)∗𝐿𝑇(𝜎−1)/𝜎]𝜎/(𝜎−1) +Other Preferences • 𝑌𝑇 = Total output (Best Value from substituting 𝐾𝑇 and 𝐿𝑇) • 𝜎 = Elasticity of Substitution • 𝛿 = Distribution Parameter • Value between 0 and 1 • 𝐴𝑅 = Productivity Factor • 𝐾𝑇 = Value of capital/services from Program 1 (SLS) • Societal Benefits, Resource Value, and New Information from program 1 • 𝐿𝑇 = Value of capital/services from Program 2 (Other) • Societal Benefits, Resource Value, and New Information from program 2

22. Fundamental Objectives • Value model must quantitatively answer the question: “How does the SLS contribute to NASA’s top-level objectives?” • Concrete contributions of the SLS are shown below as “sub-goals”. • Note that SLS contributes to the four positive objectives indirectly (for the most part) by enabling missions – the missions themselves are the actual engines of value generation. • Prior work on launch vehicle value models is in the context of specific missions – these value models, while useful, are really value models for the missions, not the launch vehicle itself. • A value model for the SLS should value the mission-enabling capability of the vehicle in the generic sense. Top-Level Objs. Enable Missions Impress other Nations Impress the Public Create Jobs & Support Industry Minimize Environmental Damage Minimize Loss of Life Generate National Prestige Further Scientific Knowledge Increase Military Capability Support Economic Growth Minimize Negative Impacts Sub-Goals Impress other Nations Impress Public Enable Missions Create Jobs & Support Industry Minimize Environmental Damage Minimize Loss of Life

23. Constructing the Value Model • A generic value model maps a design, described by an envelope of top-level attributes, to a scalar value. • This model can (and should) be capable of accepting uncertain attributes and propagating them through to output an uncertain value. • This uncertain value can then be adjusted for risk attitude if desired, or (if decision-maker is risk-neutral) the expected value can be used as the final “score” for the design. • A proposed valuation paradigm for the mission enabling capability of SLS should have two distinct components: • Capability model (from system behavioral models – “what can it do?”) • Value model (from preference elicitation – “how does this benefit us?”) Design variables, environmental variables, operational variables (includes uncertainties) Value Model (preferences) Lower-level Attributes System Value Top-level Attributes Capability Model (physics, software, etc.)

24. Constructing the Value Model • Modifications to basic value model framework for SLS: • Because the SLS does not create value directly (instead enabling missions that create value), the basic value model framework must be modified. • Instead of mapping capability directly to value, instead capture all relevant capabilities of the vehicle and interface them with a portfolio of individual mission value models. Design variables, environmental variables, operational variables (includes uncertainties) Value Model (preferences) Lower-level Attributes System Value Top-level Attributes Capability Model (physics, software, etc.)

25. The Capability Envelope • The first step in constructing the value model is to determine the appropriate abstractions for capturing the capabilities of any given launch vehicle. • What are the “top-level attributes” for a launch vehicle? • A top-level attribute is defined as any system attribute that directly impacts value delivery – or to put it another way, any system attribute that a potential “customer” of SLS might care about. • It is important to identify which system attributes are top-level attributes. • Top-level attributes (such as cost, payload mass to orbit, and weather envelope) are derived from other attributes (such as materials used, engine specific impulse, and controllability) via various behavioral models. • Any given system design is represented by an N-dimensional envelope in top-level attribute space. • This envelope is here called the “capability envelope”. • It is then mapped to value by interfacing with mission value models.

26. The Capability Envelope • The capability envelope is the fundamental abstraction that allows for valuation of any given launch vehicle design. • Why an envelope specifically? • Systems are commonly represented with vectors in attribute space. • “Envelope” implies instead a bounded region of attribute space. • For many top-level attributes, a vector is sufficient to represent capability. • However, certain relationships should be expressed as continuous relationships or envelopes in order to accurately model value. • Definition of “capability envelope”: The Capability Envelope is the combination of all top-level attribute values and all relationships between top-level attributes that fully define any individual design concept.

27. The Capability Envelope • One of the most important parts of the capability envelope is the answer to the question “how much can it carry, and how far?” • This is expressed as an envelope bounded by the curve representing the relationship between max payload mass and total energy imparted. • Can be expressed as “C3 vs payload mass” or “DV vs payload mass”. • Converting between the “C3 vs payload mass” and “DV vs payload mass” curves is trivial as long as the required DV to some reference orbit can be assumed or estimated from aerodynamic and trajectory models. OR

28. The Capability Envelope • Other top-level attributes included in the capability envelope: • Cost (including production, integration, launch, etc.) • Reliability (probability of mission success for any given launch) • Payload services provided (power, thermal conditioning, etc.) • Load factors imparted to payload (max Q and during dynamic events) • Shock loads imparted to payload (max Q and during dynamic events) • Controllability envelope (wind speeds vs fairing dims vs CoG offset) • Allowable payload volumes (related to fairing dimensions) • Time between launches (including assembly time, pad time, etc.) • Injection accuracy (altitude and inclination) • Ability to operate in loss of communication (autonomy) • Important to capture relationships that may restrict variables, even if the variables may affect different aspects of value. • Example: controllability envelope relates wind speeds (affects value by determining how often vehicle can launch) to fairing dimensions (affects value by determining which payloads can be carried).

29. The Capability Envelope • Note that the capability envelope is quite specifically the inherent capabilities of any given single design (see slide 15). • The capability envelope is not a design trade-space envelope. • The former is an abstraction of a single design in the space of all possible designs, while the latter is a representation of all designs that are possible. • Example: the relationship “max wind speed vs fairing diameter” is part of the capability envelope (assuming multiple fairings exist for a single design), while the relationship “cost vs reliability” is not (unless you’ve designed an SLS that literally allows for trading those off on any given launch). • The capability envelope is not a mission trade-space envelope. • The former is the inherent capabilities of the vehicle, while the latter is related to specific mission planning. • Example: the relationship “max payload mass vs max transfer energy” is part of the capability envelope, while the relationship “flight duration vs transfer energy” (as shown on a porkchop plot) is not.

30. Mapping Capability to Value • This is only the basic framework for the valuation model. • Implementation may vary, but these core elements should remain. • There is not necessarily a “correct” specific implementation of this framework – the implementation is limited in detail only by the designer’s knowledge of their preferences and/or ability to codify them. • The “mission portfolio” valuation paradigm is beneficial because it allows for the consideration of the entire gamut of launch vehicle applications throughout its lifetime. • The following slide presents a general illustration of how the mission portfolio maps the capability envelope to value. Mission C Mission B Mission A • 20,000 m/s dV required • Value = $50000 * m • Demand = 25% of total • 15,000 m/s dV required • Value = $30000 * m • Demand = 60% of total • 32,000 m/s dV required • Value = $80000 * m • Demand = 15% of total

31. Mapping System Capability to Value & Missions Attempted “Will it work?” (Reliability) • “How expensive is it?” • Production cost • Launch cost • etc. • “What can it carry?” • Load Factors • Shock Loads • Payload Volume • Payload Services • Injection Accuracy Missions Succeeded Total Value Delivered by Launch Vehicle

32. Mapping Capability to Value • Possible variations on this valuation framework: • Mission Classifications: • While location is used in the example as the sole classifier for missions, it is far from being the only potentially useful classifier. • Missions could also be broken up by purpose (science/military/commercial), manned/unmanned, etc. – it is up to the designer to decide what is most useful. • The important thing is that each unique mission archetype has a characteristic C3/DV requirement, valuation function, and demand. • Value Curve: • Instead of having a required C3/DV for each mission and value being a function of mass, value for each mission could simply be a function of C3/DV and mass. • This is a more complicated formulation that would be much more cumbersome to construct, but it would allow for more realistic representations of certain situations (such as scientific mission to a specific location that can accomplish more with a smaller payload and greater DV than with a larger payload and smaller DV). • Again, it is up to the designer to decide which formulation will best serve the project – in essence trading model fidelity for model effort.

33. Mapping Capability to Value • Possible variations on this valuation framework: • Mission Demand: • Various restrictions could potentially be placed on any given mission’s demand to more accurately reflect real-world limitations – “no more than X launches of Y mission type every Z years”, etc. • These would allow for more realistic modeling of the change in value delivery granted by having a vehicle that can launch more frequently. • Example: It could be the case that no matter how often the launch vehicle can launch, you do not want to (or cannot) launch more than 2 Jupiter missions every 10 years, but would instead do many more LEO and Luna missions). • General: • Various restrictions could potentially be placed on individual missions – “this mission requires at least X kg of payload to be attempted”, that sort of thing. • Any small tweaks which increase the fidelity of the model are welcome, however designers must remain conscious of the increased effort that will result. • It is recommended to start with a low-fidelity model (similar to that which is shown in the example formulation) and refine as needed instead of attempting to construct a highly detailed model from the start.

34. System Physics and System Integrating Physics Goal: Utilize the key system physics to produce an elegant system design

35. System Integrating Physics • Consortium is researching the significance of identifying and using the System Integrating Physics for Systems Engineering • First Postulate: Systems Engineering is Product Specific. • States that the Systems are different, and therefore, the Integrating Physics for the various Systems is different • Launch Vehicles • Thermodynamic System • Spacecraft • Robotic • Integrated through the bus which is a thermodynamic system • Each Instrument may have a different integrating physics but integrates with the bus thermodynamically • Crew Modules • Integrated by the habitable volume (i.e., ECLSS) • A thermodynamic system • Entry, Descent, and Landing (EDL) • Integrated by thermodynamics as spacecraft energy is reduced in EDL • Other Thermodynamic Systems • Fluid Systems • Electrical Systems • Power Plants • Automobiles • Aircraft • Ships • Not all systems are integrated by their Thermodynamics • Optical Systems • Logical Systems • Data Systems • Communication Systems • Biological Systems • System Integrating Physics provides the engineering basis for the System Model

36. Launch Vehicle System Exergy Efficiency . S-II Center Engine Cut-Off S-1C Stage Separation S-II Stage Separation S-1C Center Engine Cut-Off S-IVB Burn 1 Cut-Off LEO Insertion S-IVB Burn 2 Engine Mixture Ratio Shift S-II Engine Mixture Ratio Shift S-IVB Burn 2 Cut-Off Max Q S-!VB Separation

37. Spacecraft Integration Model

38. Crew Module Exergy Balance: ISS ECLSS • Calculate Efficiency

39. System Autonomy Goal: Establish system interfaces to provide autonomy algorithms with system information necessary and sufficient to manage system

40. System Engineering of Autonomous Systems • Elegant System Engineering requires • Understanding the Mission Context • System Applications • System Environments (operational, test, abort, etc.) • Understanding the Physics of the System • System Interactions with themselves and with their environments are governed by their physics • Information Theory provides linkages between physical state representations and actual physical states • Managing the organizational influences on system design and the system context influences on the organization • Understanding Policy and Law Constraints • National Space Policy • International Space Treaties and agreements • Space Debris, Contamination, Property

41. Autonomy in Context: What and Why? • Spacecraft and Surface System Autonomy is the enabling capability for Human Exploration beyond Lunar Sortie Missions • Autonomy is necessary for complex system operations • Timely response to unplanned or unscheduled events • Propulsion, Structure, Thermal Conditioning, ECLSS, Electrical Power, Avionics, RCS, Communication are all understood sufficiently to allow engineered solutions to be reliably produced • Challenges do exist in terms of Space Environmental Effects, efficiency, compact size • Radiation Hardened computer processors needed • Physics and demonstrated solutions are available from which to engineer a vehicle • Operations are sufficiently understood for terrestrial based execution, not on-board execution • Manual operations provide a rich knowledge base of planning and execution processes • Manual operations have a generic template (derived from Apollo/Saturn) applied uniquely to each spacecraft • Terrestrial based manual operations will not support operations beyond 5 light minutes from Earth • Autonomous Operations are essential to Human Exploration of the Solar System

42. Operations Concept Drivers • Small Crew Size (4-6) • 1 crew member per shift available for vehicle operations • Limited systems experts • Complex Systems • Nuclear Power and Propulsion Systems • Life Support and Environmental Protection • USN Attack Submarines are similar complexity systems but have 134 crew members • ~525 high level functions to manage an interplanetary crewed spacecraft. • Abort Scenarios • Unambiguous determination • Extremely low latency • Fully autonomous/automated (crew incapacitated conditions) • Vehicle reconfiguration necessary • Long Communication Latency/Blockages • 15 minutes one way, 30 minutes round trip to Mars • Ground based intelligence not responsive to maintain crew safety • 1 hour blockage by Moon each Lunar orbit • Harsh Environment • Solar flare radiation • Meteorites

43. 25 min. 15 min. 5 min. Mercury 1.28 sec. 2.5 min. Moon Mars 1 min. Earth SUN Venus AU .387 1.0 1.5236 .723 (Not to Scale)

44. Spacecraft Systems Overview • Beyond Earth Orbit (BEO) crew transport vehicle are comprised of several unique and intricately integrated subsystems • Propulsion • Structure • Electrical Power • Avionics • Thermal Management • Flight control system • Communication and Tracking • Vehicle Management (Guidance, Navigation and Control (GN&C) and Mission and Fault Management (M&FM)) • Environmental Control and Life Support Systems (ECLSS) • Each of these subsystems are driven by unique physics and information theory relationships • Control Theory governs the control of each subsystem both independently and at the vehicle level

45. State Variable Methodology • Goal/Function Tree • State Variable to define System Performance • State variables are defined as inputs and outputs to functions: y=f(x) • x = inputs to the functions f • f transforms the inputs into the outputs y • Goals = Requirements => define intended range of the output state variables y • Failure = state (value) of output state variable y is out of intended range • State variables enforce strong connection of the functional decomposition to the system’s physical laws and causation • The state variables are the connection between function and design—exist in both function and design representations • Allows system to be analyzed in each mission phase and goals which can have different ranges and values for each state variable • Allowed leak rates vary inversely with time from Earth Return date ≤ ≤  G Function f

46. Mars Mission simplified GFT Example Functioning Crew Performs Mars Mission & Returns to Earth X, V, Θdot, A, Struc T, Cabin T, O2 X, V, Θdot, A, Struc T, Cabin T, O2 LV “Ready”, StrucT, Cabin T, O2 X, V, Θdot, A, Struc T, Cabin T, O2 Land on Earth Achieve Mars Orbit Complete Mars Science Achieve Earth Orbit Reach Mars Vicinity Mars Landing A, Cabin T, O2, Θdot X, V y Deliver to Destination Keep crew alive y = f (x) f x A, LV Struc T X, V Θ P, Cabin T, O2 Crew A Capsule A, Capsule StrucT Θdot Maintain Struc Integrity Control Attitude Control Trajectory limit accelerations on crew provide life support Control Crew Roll Rate keep capsule intact Capsule StrucT Capsule A X Err, V Err control structural temp control structural loads Control Error Between Desired & Measured Pos/Vel Struc Crack Size, Alloy Purity Meas X Meas V • Crewed BEO Mission Goal Types • Transportation • Crew health and safety • Scientific and Technical Θ Err Des X Des V LV Struc T LV Struc A Control Attitude Error provide desired Pos/Vel Measure actual Pos/Vel Control Structure Defects Control LV Struc Temps Control LV Struc Loads

47. Transportation Goals • Position, Velocity, Acceleration • Earth Departure, Mars Departure • Propulsion System • Flight Control System • Interplanetary Coast • Propulsion System • Flight Control System • Planetary Orbital Insertion • Propulsive • Aero Braking • Surface Descent • Propulsive • Aero Surfaces • Planetary Mobility • Drive force • Control System

48. Crew Health and Safety Goals • Provides link between human health and System Performance • Biological • Psychological • Biological State Variables are linked directly with System State Variables • Biological • Heart rate • Respiration rate • Food intake • Water intake • Solid and Liquid waste production rate • Spacecraft Systems • Breathable air (oxygen concentration, carbon dioxide concentration, atmospheric pressure) • Oxygen can be stored as LOX and converted to gas as needed • Drinkable water (mass) • Consumable food (mass) • Solid and Liquid waste processing/disposal (mass) • Vehicle acceleration rates (linear and rotational accelerations) • Crew Cabin/Suit temperature (temperature and humidity) • Activity (work and exercise) and sleep times (hours or minutes / crew day) • Communication System (family communications (email, video, audio), entertainment, etc.) • Ranges vary with mission phases

49. Science and Technology Goals • Information Return • Communication systems • Transmission rates • radiated power • signal strength • beam width • Sample Return • Containment System (mass, pressure, leakage rate) • Samples (mass)

50. Autonomy Stack • Autonomy must operate consistent with the physical control laws of the vehicle systems • Multiple subsystems exist within the vehicle • Management algorithms must match subsystem physical control laws • Vehicle level integration is a unique set of relationships dependent on the subsystem types chosen • Type of Propulsion • Type of Flight Control System(s) • Type of ECLSS • Type of Electrical Power Generation • Etc.