NASA A LTAIR Lunar Lander Project Avionics System Architecture Study
NASA A NASA A LTAIR LTAIR Lunar Lander Lunar Lander Project Project Avionics System Architecture Study Avionics System Architecture Study Minimum Functional Architecture Minimum Functional Architecture (Subsystems & Components) (Subsystems & Components) 09 April 2008 09 April 2008
NASA A LTAIR Lunar Lander Project Avionics System Architecture Study
NASA A LTAIR Lunar Lander Project Avionics System Architecture Study Minimum Functional Architecture (Subsystems & Components) 09 April 2008. ALTAIR Avionics System Definition. Generic Avionics System Definition: The integrated group of all Lunar Lander Vehicle - PowerPoint PPT Presentation
NASA ANASA ALTAIRLTAIR Lunar Lander Project Lunar Lander ProjectAvionics System Architecture StudyAvionics System Architecture Study
Generic Avionics System Definition: The integrated group of all Lunar Lander Vehicle
flight electrical, electronic, and electro-mechanical components, flight wiring harnesses connected to those components,
and flight software loaded into those components.
Major Avionics Subsystems:• Command & Data Handling (C&DH)• Communications & Tracking (C&T) • Electrical Power Avionics • Guidance Nav & Control (GN&C) Avionics• Crew I/F, Controls, Displays & A/V• Flight Software (FSW)
Minor Avionics Subsystems:• Thermal Control & Monitoring Avionics• Mechanism Control & Monitoring• Reaction Control System Avionics• Cryogenic Control & Monitoring Avionics• Thrust Vector Control & Monitoring Avionics• Descent Main Engine Control & Monitoring• Ascent Main Engine Control & Monitoring• Life Support System Control & Monitoring
LevelTitle Level Description This
• Vehicle Functions and Performance Levels Defined.• Vehicle Treated as “Black-Box”. No Internal Implementation biases.• Interfaces to other Major Exploration System Elements Defined.
• Module Functions and Performance Levels Defined.• Modules Treated as “Black-Boxes”. No Internal Implementation biases.• Inter-Module Interfaces Defined.• Stage Separation Interfaces Defined.
& Components Level
• Components include Electronic Boxes, Antennas, Sensors, etc.• Component Functions and Performance Levels Defined.• Components Treated as “Black-Boxes”. No Internal Implementation biases.• Component Interfaces Defined: Power, C&T, Data, etc.• Power Distribution, Data Networks, and Packaging Approaches Defined.
• Hardware Sub-Assemblies include Cards, Backplanes, Chasses, etc.• Sub-Assembly Functions and Performance Levels Defined.• Cards Treated as “Black-Boxes”, but assumed part technologies defined.• Card Interfaces Defined: Box-External and Box-Internal.• Box-Internal Power Distribution, Data Networks, and Packaging Defined.
4-SW Software Level
• Flight Software Architecture Topology Showing Distributed Elements• Flight Software Communication Architecture w/ OSI Reference Model Layers• Flight Software Layered Architecture Models • Potential Implementations of Op Systems, I/O Drivers, Application Tasks, etc
Creation of the Common Services Assembly (CSA): All of the Common Avionics Functions that are required for all 3 Design
Reference Missions (DRMs) were identified and grouped together in a new Level-2 Configuration Item called the “Common Services Assembly” (CSA).
Rationale/Benefits: Centralization/Consolidation of Common Items: The CSAs eliminate any DRM-Unique
implementations of common functions, and any unnecessary duplication of functions/implementations in different modules within a particular DRM, thereby minimizing the avionics system size, mass, power, and cost.
Economies of Scale: The CSAs can be “mass-produced” for use in every mission (9), regardless of the particular DRM, resulting in major cost savings, significant schedule reduction, common verification & test, and operational simplification. Even greater benefits can be achieved if the CSA is also used for other Lunar Surface Systems.
CSA Top-Level Physical Packaging Configuration: Each DRM Type may have a unique CSA top-level packaging configuration and harness,
however, their CSA Hardware Components will be identical. The CSAs may have to be split into separate physical entities, such as a CSA Electronic
Box Bay and a CSA Sensor/Antenna Ring.
6.22 m1 1
Sortie Cargo Size Unknown
Orion “Keep Out” z
Position Pros Cons
1 • Easily integrated into all 3 DRM’s• Ring Concept
• Engine radiative heating problems• Potential interference with AM adapter during separation
2 • Still ring concept, that is integratable into all 3 DRM’s
• Visibility out of top windows• Orion “keep out” zone
3 • Not much interference with other systems• Additional truss structure for mounting• Potential cabling issues
4 • Only available uncluttered real estate left that is close to AM press. vessel • May encroach on sortie cargo space
Level 3Level 3Avionics System Data Processing Avionics System Data Processing and Data Architecture Descriptionand Data Architecture Description
Avionics – Data Processing & Data Architecture Description
• Driven by requirement of minimum mass and power and high reliability of maintaining vehicle control and crew safety
• Composed of two Architectural Elements optimized to perform:Vehicle Flight Control– Centralized General Purpose Processor – Distributed vehicle control effectors and sensors– Crew Controls and Displays– Interconnected by “low speed” highly deterministic data network Communications and Data Management– RF Communications units– Video imaging and processing units– Data Routers– Interconnected by “high speed” data network and C3I protocols
Vehicle Control Element -Central Processing
• Central Processor Performs– Vehicle level closed loop control processing – Vehicle monitoring & configuration mgmt processing– Redundancy management processing– User Display and Controls (C&D) processing (Flt Crew and Ground)– Subsystems processing suited for “general purpose processors”
• Central Processor Precepts and Attributes– “Low/Medium” performance general purpose processor– Focused on high reliability, low power “bullet proof” proven hardware– High performance special purpose processing needs are offloaded to sensors,
effectors, and special processors where necessary– Allows a low speed, highly reliable and low power vehicle control network solution
Vehicle Control Element -Sensor and Effectors
• Sensor and control effectors interface with central processor via two methods depending on complexity/functionality of the unit
“Electronic and processing intense” Units (“Type A”)– Units interface directly with the low speed - Vehicle Control Data Network (VCDN) – Processing intense sensor and effector units also contain special purpose processors (SW
and/or Firmware) for pre-processing and data formatting– Offloads the central processor and reduces network traffic required– Units consist of:
– IMU - Descent Main Engine (DME) Controller– Star Tracker - S-Band SDR*, Router*, & CIU– Lidar* - D&C Controller*– Landing Radar - PDU– Hazard Detection Sensor* - RPC– Video Processor (VPU)* - Fuel Cell Electronics– EVA Servicing Unit and Battery Charger
*Note: Units also have port to High Rate Data Network (HRDN) for video and C&T data
Vehicle Control Element -Sensors and Effectors (cont’d)
• “Small, Highly Distributed” Sensors and Effectors (Type “B”)– “Type B” are of the category of distributed and remote temperature sensors, pressure
sensors, position indicators, discrete commands of valve actuation, S&M deploy, and analog drive commands which are of standard type discrete and analogs.
– And, which do not naturally contain sufficient electronic sophistication to interface directly with the vehicle control data network (VCDN)
– “Type B” sensors and effectors interface with central processor via a general purpose data collector/distributor unit dubbed RMUX (remote multiplexer/de-multiplexer)
– Contains a general purpose microcontroller for local processing and control– Atleast 1 in each module and can have significant commonality
– Provides central process interface for subsystems control and Monitoring:– TCS– Life Support– RCS Prop Storage– Cryo Prop Storage – Pyro Events Control (PEC)– Ascent Main Engine Control– RCS Engine Control– Mechanisms Control– Thrust Vector Control (TVC)
Crew and Ground UserCommand & Control (C&C) Interface
• Crew C&C Interface provided by Displays and Controls (D&C) Controller interfacing directly with the Vehicle Control Data Network (VCDN). Hardware consists of:– D&C Controller – Provides local display formatting, display drive and D&C data
routing with Central Processor. High Rate Data Network (HRDN) I/F for video data.
– Flat Screen text and graphic Displays with “Edge Panel Switches”– Keyboards– Vehicle Flight Control Hand Controls – With Rotational, Translational, and Throttle
Control functionality– Caution & Warning Indicators and control Panel
• CEV Flight Crew C&C provided by hard-line interface using D&C equivalent commands and display feedbacks to CEV (also used by preflight checkout users)
• CTN ground access users provided C&C interface via RF communications links using D&C equivalent commanding and/or special applications implement command codes.
Communication and Data Management Element
• Communication and Data Management Element Provides function of:– RF Communications between Lander, CTN, CEV and Surface Sys– Data formatting and encoding– High Speed Data Routing– Video imaging and processing
• Hardware Consists of:– RF Communications units– Video Cameras (landing and Rndz/docking)– Interfaces with LIDAR and Hazard Detection Sensor for any video type image
data provided– Video processing units (VPU)– D&C “Flat screen” display interfaces for Video– Interconnected by “high rate” data network and C3I protocols– C3I Data Routers
– Interfaces to all external CxP Systems– Provides communication security to Vehicle Control Data Network (VCDN) and Altair– Interface to crew portable networked equipment– Partitions critical function protocols
Ø Highly-Reliable Low/Medium Rate Data Network for all Critical Communication, Control, and Monitoring
Ø Deterministic Time-Synchronized Protocol
Ø ~300 kbps Throughput Requirement:· Housekeeping Data · Bi-Directional Digital Audio· 20% Packet Overhead
High-Rate Data Network (>100 Mbps) HRDN
Ø High-Rate Data Network for Supplemental Data Communication such as Video Signals, etc.
Ø Event-Driven Protocol
Ø ~300 Mbps Throughput Capability:· Supplemental Control & Monitoring· 2 Bi-Directional Uncompressed Digital Video with
640 x 480 pixel resolution & 30 frames/sec
RF Communications Network
Ø The data network diagram above shows logical connections only. No Network Topology is implied (such as point-to-point, ring, etc.)
Ø Estimated Data Network Connections:o Primary Data Network: ~30o Auxiliary Data Network: ~ 12
Color-Coding By Type
Analog RF point-to-point connectionsBridged to flight networks via C3I router
C3I Hard-Line Network
Direct Hard-Line interface to connected spacecraftFeatures adaptable spacecraft bus for interfaceCould be same bus as HRDN
Power Dist Unit
Avionics SystemAvionics SystemSubsystem SpecificSubsystem Specific
Design DriversDesign Drivers
Electrical Power Subsystem & Components
Accommodate All External Power Sources: Ares-V Launch Tower via Umbilical Cable and EDS Earth Departure Stage Crew Exploration Vehicle Lunar Outpost
Accommodate LLV Power Sys - Internal Power Generation B/L Approach: Fuel Cells & Assoc Electronics located in Descent Module
Accommodate LLV Power Sys - Internal Power Storage B/L Approach: Batteries located in Ascent Module
Power Switching & Distribution Simple Power Distribution Bus between Modules (sometimes bi-directional) Each Module contains a Power Unit (RPC or PDU) with a Primary Power Bus Input,
Power Distribution Outputs to all required components within that module, and a Vehicle Control Data Network (VCDN) I/F that controls the power switching/distribution within that module.
Support an EDS or insitu Flight Crew initiated startup with an “always-active” power source for "cold start" of Altair - Nominal mission and contingencies.
Power Component Modularity & Commonality RPC and PSDU components in different modules can have significant commonality Avionic Component Power Supply Cards may be able to use common designs.
Communication & Tracking (C&T) Subsystem & Components
Software Defined Radio (SDR) and supporting antennas and electronics Configurable for S-Band, 802.xx, EVA Interfaces to both data networks (VCDN & HSDN) Encoding/decoding (LDPC,etc..) One radio needed for each concurrent link
Video Processing Unit (VPU) ALHAT,LIDAR, & GN&C (Landing\Docking) Video data processing Accepts raw or encoded streams Limited to 2 video streams in each mission phase Processes and distributes camera commands
CIU & Speaker Mic Provides voice communications for astronauts Located in Ascent Module and Air Lock
EVA Checkout Antenna Located in Air Lock for Sortie and Ascent Module for Crew Checkout for EVA
Guidance, Navigation, & Control (GN&C) Subsystem & Components
All GN&C sensors assumed to be Type A “SMART” boxes with direct interface to the Vehicle Control Data Network (VCDN).
Star Tracker – Inertial attitudes Inertial Measurement Unit (IMU) – Rates and Acceleration LIDAR
• Provides range & relative orientation to support docking• Sensor is critical for auto docking
Currently not known exactly what functionality will be included Using as a placeholder to provide “HOOKS” for inclusion into design Interfaces directly to the Vehicle Control Data Network (VCDN) for processed data, and to the
High Rate Data Network (HRDN) for video processing Study includes looking at sharing of Altair resources such as cameras and IMU’s Where possible sharing of Altair resources such as cameras and IMU’s is recommended
Propulsion Subsystem & Components
Descent Main Engine Controller (DME)
Controller performs critical function of safe pre-start, start, throttling, monitoring and shutdown of Descent Engine.
Requires critical time sequencing and monitoring performed at 50 HZ• Based on meeting with Kendall Brown while at LaRC
High rates and precision sequencing requirement led to concluding a DME local Controller would be necessary.
Interfaces directly with Flight Computer over Vehicle Control Data Network (VCDN).
Closed-loop control of engine to be performed locally within DME Controller based on high level commands from Central Processor.