1 / 61

Common Avionics Approach

Common Avionics Approach. SpaceAGE Bus & cFE /CFS: Software & Hardware Component Based Architecture Presenters: Jonathan Wilmot & Glenn Rakow NASA-GSFC. Background: Avionics Current Practice.

sharis
Télécharger la présentation

Common Avionics Approach

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Common Avionics Approach SpaceAGEBus & cFE/CFS: Software & Hardware Component Based Architecture Presenters: Jonathan Wilmot & Glenn Rakow NASA-GSFC

  2. Background: Avionics Current Practice • Each organization that builds space systems has their own approach to implementation, so within organizations there are de facto standards • Necessary to save money • Or make profit • However among space builders there is little interoperability • Mechanical approach differences • Electrical interfaces differences • Software architecture differences • Even though the implementation methods used are very similar • Procured Single Board Computer – BAE Rad750, Leon 3 • Bus protocols – Mil-Std-1553, SpaceWire • Mechanical approach – Backplane in mechanical chassis • etc.

  3. Basic Tenets – Common Avionics • Standards – Interfaces, protocols, electronic data sheets, examples: • CCSDS AOS, Internet Protocol (IP), xTEDS • Software architectures, examples: • Frameworks, design patterns, Application Programmer Interfaces (API), • Hardware – Interfaces, form factors, protocols, examples: • SpaceWire, Mil 1553b, RMAP, USB PnP, 6U • Each of these can stand alone and be applied to a wide variety of missions • Missions may use 1553, or CCSDS AOS but can not interoperate • Current approach for many organizations • Common Avionics are defined by the intersection • Each organization can define it’s own intersection, common only to that organization • Example: AFRL Space Plug-and-play Avionics (SPA) Hardware Software Standards Common Avionics

  4. Common Avionics Goal • Reduce Non Recurring Engineering cost of space avionics through reuse • Be applicable to majority of space missions both robotics and crew rated vehicles • Compatibility of avionics between vendors • Necessary for Human Exploration Programs • Develop different vehicles/systems from same components • Increase pool of compatible products • Focus limited resources to create synergy in space industry • Technology independent – focus on interfaces not implementations • Protocols not defined • Few possibilities - allows space community to converge based upon demand • Provides system engineer flexibility • Stream-line integration of avionics components (hardware & software) similar to commercial “plug-n-play”

  5. Common Avionics Business Model • Encourage exchange of designs in open market that may be integrated to implement system • Designs may have different levels of compatibility but market forces should force convergence to small group of options • Government agencies use tech transfer offices to make designs available to industry that can then be purchased on open market • Current example: • GSFC developed the SpaceWire Test Set (SWTS) hardware and software. • Via Tech Transfer office, SWTS designs provided to support contractor, who markets and sells the SWTS product. • Effort involves procuring the Printed Wiring Board (PWB), outsource the PWB assembly, and test with software. • To date 150 SWTS have been built for multiple agencies and projects • Currently, GSFC cFE/CFS and SpaceWire IP core (both software products) are widely distributed and used on non-GSFC missions • Help is needed in developing a governance model for maintaining/updating code

  6. Potential New Budget Model Avionics cost savings Development cost => Build-to-Print Hardware cost approaches a reduction of 80-90% Based upon LCRD HSE budget Reduction of quality assurance and system engineering due to COTS component Reduction of risks Reduction of documentation Reduction of schedule and manpower Time is money => delay requires funding to carry manpower longer Less development Cost Build-to-Print Reuse

  7. Building Block Elements Definition: • Building block element is a software or hardware functional standalone unit of implementation with completely defined interfaces, so that they can be integrated together to form increasingly complex systems. Examples: • Hardware • Printed Wiring Boards (PWBs) built to a standard mechanical form factor with defined electrical interfaces • Modules – comprised of a single or multiple PWBs integrated together into a mechanical card frame to form a increasingly complex function • Software • Software component that has interface to a defined software bus so that a publish/subscribe messaging service • Hypervisor – supports low level time-space partitioning to protect the operating system from crashing

  8. NASA/GSFC’s Flight Software Architecture:Core Flight Executive and Core Flight System Jonathan Wilmot Software Engineering Division NASA/Goddard Space Flight Center Jonathan.J.Wilmot@nasa.gov 301-286-2623

  9. cFE/CFS Introduction Core Flight System (CFS) • Core Flight System (CFS) • A Flight Software Architecture consisting of the cFE Core, CFS Libraries, and CFS Applications • core Flight Executive (cFE) • A framework of mission independent, re-usable, core flight software services and operating environment • For cFE/CFS, each element is a separate loadable file CFS App CFS App CFS App core Flight Executive (cFE) CFS App CFS App CFS App CFS Library CFS Library

  10. CFS Flight Software Layers CFS App 1 CFS App 2 CFS App N Mission App 1 Mission App 2 Mission App N Mission and CFS Application Layer CFS Library Mission Library Mission and CFS Library Layer cFE Core CFE Core Layer http://sourceforge.net/projects/coreflightexec OS Abstraction Layer cFE Platform Support Package http://sourceforge.net/projects/osal Abstraction Library Layer Real Time OS Real Time OS Board Support Package RTOS / BOOT Layer RTEMS, VxWorks, Linux Mission Developed PROM Boot FSW GSFC Developed 3rd Party

  11. cFE Core - Overview • A set of mission independent, re-usable, core flight software services and operating environment • Provides standardized Application Programmer Interfaces (API) • Supports and hosts flight software applications • Applications can be added and removed at run-time (eases system integration and FSW maintenance) • Supports software development for on-board FSW, desktop FSW development and simulators • Supports a variety of hardware platforms • Contains platform and mission configuration parameters that are used to tailor the cFE for a specific platform and mission. Executive Services (ES) Event Services (EVS) Software Bus (SB) Table Services (TBL) Time Services (TIME)

  12. Solar Array High-Gain Antenna Orbit Models Attitude Determination & Control Sensor/actuator I/O handlers Exemplar GSFC Flight Software Architecture Sensors & Actuators Instruments Mass Storage File System Software Hardware I/Fs Limit Checker Memory Space Wire Stored Commanding Scheduler Hardware I/Fs Instrument Managers CFDP File Transfer Manager Data Device adapters Storage File Manager Local Storage EDAC Housekeeping Inter-task Message Router (SW Bus) Memory Scrubber Manager Software Bus Table Time Executive Event 1553 Bus Support Telemetry Output Command Ingest Services Services Services Services C&DH Components Commands Communication Interfaces GN&C Components 1553 Hardware Real-time Telemetry cFE Components File downlink (CFDP) via SpaceWire Note - Some connection omitted for simplicity

  13. Facets of Common Avionics • Software • NASA cFE/CFS example of a component software architecture • Hardware • SpaceAGE bus (intra-box interface definition) • Modular • Standalone • Scalable • Interface Control Document definition • Maintain reasonable flexibility with these area Examples: • Software – allow different operation systems • Hardware – allow different protocols • Electronic Data Sheet (EDS) – work with different software architecture

  14. Electronic Data Sheet (EDS)

  15. SpaceAGE busIntra-Box Interface Definition • SpaceAGE bus defines how to integrate Hardware modules together – analogous to cFE/CFS software bus • Hardware modules analogous to cFE/CFS software components • 2 module types defined – Hub and Node – every box has 1 Hub and one or more Nodes • Serial interfaces; Protocol agnostic • Electrical interfaces- Power; Comm; Analog; Clock; Reset; Converter Sync; Module Detect • Mechanical interface – Card frame • No backplane nor chassis • X&Y dimensions defined – Z (height) not defined (flexible) • FOMs: • Minimize NRE (cost and schedule) • Broad mission applicability – supports all reliability schemes (cross-strapped, etc.) • Incremental Design

  16. SpaceAGE Bus Architecture Node Module Node Module Node Module Hub Module Node Module Node Module Node Module Node Module Legend • SpaceAGE Bus Interface • power • comm. • analog • miscellaneous signals • typically used for avionics systems

  17. RIU Example using Integrated Modular Avionics (IMA) Approach Heater Card Pyro Card Prop Card Epoch Epoch Time TTP/C Switch External I/F to Higher Controller Time Slot External Vehicle Control Bus Hub Module Hypervisor implementing “skinny” version of time-space partitioning Synchronized to Time-triggered data bus Legend Time Triggered TTP/C (~10 MHz), with Bus Guardian Processing, implementation not specified (could be embedded in FPGA)

  18. Distributed IMA (DIMA) Approach Function 1 Control Application Function 2 Control Application Function 3 Control Application Operating System Operating System Operating System CPU 1 CPU 2 CPU 3 CPU 1 sleep sleep sleep sleep TTP/C Switch CPU 2 sleep sleep CPU 1 CPU 2 CPU 3 External Vehicle Control Bus External Vehicle Control Bus External Vehicle Control Bus CPU 3 sleep sleep Hub Module Multiple Timelines Illustrating Distributed Processing Concurrently Hub Module Hub Module Node Node Node Node Node Node Legend Time Triggered TTP/C (~10 MHz), with Bus Guardian Processing, implementation not specified (could be embedded in FPGA)

  19. Application of SpaceAge Bus

  20. Implementation Example - Altair

  21. Altair Avionics Design Approach (Distribution Process) • Break vehicle up into sectors • AM and AL into quadrants • DM into upper and lower quadrants • Gather the MEL components (sensors and actuators) into the various sectors per subsystem function • From ProE vehicle layout drawing • Select module functions to perform requirement • Estimate board and box sizes and locate Distributed Avionics Units based upon data to minimize harness mass • Rule of thumb – keep sensors and efforts within 10 feet of Remote Interface Unit (RIU) – point where harness mass dominates box mass • Otherwise consider adding additional RIU in area • Reliability analysis • Iterate

  22. Location on Vehicle (Example: AM Functions per Quadrant)

  23. Propulsion Functions per Module/Sector

  24. Distributed Avionics Unit Configuration Cabled Interfaces (just Power & Comm. Shown)

  25. Example RIU - AM Monitor 1 Functional Description: C&T RF Switches ECLSS Vent valves LGC system Potable water Suit loop Swing bed control Cabin air supply Cabin air return Cabin Waste venting ATCS Pumps Accumulator Propylene Glycol Loop Power Switching Location: AM Pressurized Size: 10” x 7.5” x 6.5”(L x W x H) L x W = mounting surface (includes 0.75” flange) W x H = connector face ATCS C&DH ATCS C&T End Cap End Cap Power Supply & Controller E-A-CH18D4H32DA P-A-CH16H E-A-CH18D4H32DA T-A-CH16V6H32DA P-A-CH16H ECLSS Power GN&C Mech Prop Structure

  26. Example RIU - AM Prop Monitor Functional Description: Prop He Tanks Status He Tanks Iso Valves MMH Tanks Status MMH Tanks Iso Valves NTO Tanks Status NTO Tanks Iso Valves Power Switching Location: AM Unpressurized Size: 10” x 5.5” x 6.5”(L x W x H) L x W = mounting surface (includes 0.75” flange) W x H = connector face ATCS C&DH ATCS C&T End Cap End Cap P-A-CH16H P-A-CH11T32DA P-A-CH11T32DA Power Supply & Controller ECLSS Power GN&C Mech Prop Structure

  27. Avionics Totals

  28. Portion of Altair C&DH MEL

  29. LCRD Example

  30. Building Blocks Used on LCRD • Three building block elements initially developed • Reprogrammable Digital board • Analog board • Memory board • Schematics developed initially under constellation funding • Layout and reviews done under LCRD funding • Boards can be interconnected within modules to form different functional modules • HUB – Digital board and Analog board • Data Processing Storage Unit (DPSU) – Digital board and Memory board • Channel Coding Output Buffer (CCOB) – 2 Digital boards • Approach allowed different combinations of boards and modules to be traded to match performance requirements • Allowed board development to continue as system changed

  31. LCRD Application of Building Blocks • Data Processing and Storage Unit (DPSU) • Stores high rate data for Payload operational modes • Supports store and forward function • Provides T&C interfaces to CEs through SpaceWire • Channel Coding and Output Buffer (CCOB) (2) • Multi-rate gigabit non-blocking, crossbar switch to internal/external functional elements (DPSU, CCOB and Integrated Modems) • Performs Forward Error Correction (FEC) decode/encode based on Integrated Modem operational mode • Provides translation of frame format and data link buffering to switch • Performs channel data interleave/de-interleave function HSE CE1 CE2 SpW1 SpW1 DPSU SpW2 SpW2 CCOB 2 CCOB 1 Integrated Modem 1 Integrated Modem 2

  32. Digital Board Layout

  33. Layout of Memory Module

  34. LCRD High Speed Electronics (HSE) Mechanical

  35. End – Thank you

  36. C&DH – Single String • (LRO Mapping using LCRD elements) External Analog Tlm Module Comm Module SSR Module Instrument A I/F Instrument B I/F Instrument C I/F Hub Module Comm Module: 2 Digital boards SSR Module: 1 Digital board & 1 Memory board Hub Module: 1 Digital board & 1 Analog board External Analog Tlm Module: New design External Vehicle Control Bus Mil-Std 1553b Legend SpaceWire Low rate SpaceWire using Manchester encoding over intra-box interface Gigabit SpaceWire 2 (SpaceFiber protocol) over intra-box interface UART I/F Embedded processor in FPGA Mil-Std 1553b

  37. C&DH – Redundant Processor • (LRO Mapping using LCRD elements) External Analog Tlm Comm Module SSR Module Instrument A I/F Instrument B I/F Instrument C I/F Hub Module Hub Module Comm Module: 2 Digital boards SSR Module: 1 Digital board & 1 Memory board Hub Module: 1 Digital board & 1 Analog board External Analog Tlm Module: New design External Vehicle Control Bus External Vehicle Control Bus Mil-Std 1553b Legend SpaceWire Low rate SpaceWire using Manchester encoding over intra-box interface Gigabit SpaceWire 2 (SpaceFiber protocol) over intra-box interface UART I/F Embedded Self Checking Pairs (SCP); One BC other Monitor on 1553 Mil-Std 1553b; one Hub module BC, other Hub Module Monitor, switchable through backdoor control over SpaceWire

  38. Backup

  39. SpaceAge Bus – Electrical

  40. Power - Single Voltage Distribution Node Module Node Module Node Module *EMI Filter Node Module Node Module Power In Hub Module Node Module Node Module Legend Non-Digital Power and Return, Redundant Pair (LCRD implementation used primary power) Power Switch * Power conversion could also be done here (LCRD does not)

  41. Communications - Serial Full Duplex Node Module Node Module Node Module *X-Bar Switch Node Module Node Module External Vehicle Control Bus Hub Module Node Module Node Module Legend 2 uni-directional differential pairs, i.e., need to encode data & clock on same pair Non-Blocking, protocol agnostic – multiple different protocols may be bridged via switch (LCRD uses SpaceWire 2 – new multi-Gigabit version of SpaceWire) *

  42. Processing Node Module Node Module Node Module Node Module Node Module External Vehicle Control Bus Hub Module Node Module Node Module Legend 2 uni-directional differential pairs, used for communicating with Nodes Processing, implementation not specified (could be embedded in FPGA)

  43. Analog Telemetry Gathering Node Module Node Module Node Module Node Module Node Module I0 HUB Internal Analog Tlm Out Ana Mux I1 Hub Module In ADC Out Sel Node Module Node Module Legend 1 Analog signal and ground pair

  44. Clock Distribution Node Module Node Module Node Module Clock Gen Node Module Node Module Hub Module Node Module Node Module Legend Differential pair, Node defined, may be different between nodes. Multiple uses - could be 1 Hz pulse, etc.

  45. Reset Distribution Node Module Node Module Node Module Reset Gen Node Module Node Module Hub Module Node Module Node Module Legend Signal and Return (Return shared with “Sense” signal), Node defined electrical and protocol

  46. Node Presence “Sense” Node Module Node Module Node Module Sense Detect Node Module Node Module Hub Module Node Module Node Module Legend Signal and Return (Return shared with “Sense” signal), Allows hot-plugability of Node

  47. Nodes “Converter Sync” Signal Node Module Node Module Node Module Converter Sync Node Module Node Module Hub Module Node Module Node Module Legend Signal and Return same as Power Return, Used to reduce EMI by synchronizing switching converters on each Node

  48. SpaceAge Bus – Mechanical

  49. Assembled System View (Modules with EMI Shields)

  50. Transparent View (Modules without EMI Shields)

More Related