Download Distributed Integrated Modular Architecture_update - CWE

Common Avionics Building Blocks
[email protected]
[email protected]
Background
• Common avionics is a term used here to describe
how to design space electronics and software for
reuse between different space avionics makers
• This work stems from work on Constellation,
specifically the former Altair project (Lunar
Lander); NASA/GSFC software component based
architecture, core Flight Executive (cFE); and
Consultative Committee for Space Data Systems
(CCSDS) Spacecraft Onboard Interface Services
(SOIS) Working Group (WG)
• DIMA is another term used to describe this work
What is DIMA?
• Distributed
– Resources (both hardware and software) are physically distributed
• Reduce harness mass
• Provide for local control of local functions
– Lowers flight computer load
• Integrated
– Multiple functions of different criticalities running on separate, high integrity, partitions
– Re-locatable functions not limited to a single line replaceable unit (LRU) boundary
• Modular
– Standard interfaces/Virtual Backplane
– Avionics boxes built up of hub card(s), power supply(s) and subsystem slices
• Provides for composability
• Allows for hardware reuse
– Software constructed of re-locatable modules
• Allows for software reuse
• Avionics
– Board level building blocks used to assemble boxes into systems
DIMA Rationale
• Significantly reduce Non Recurring Engineering (NRE) for
the development, testing and integration of avionics
systems
– Design systems from software & hardware building block
modules
– Seamless integration of modules to form units and systems
• Vendors can build building block products, e.g., electronic
boards and software applications that can be rapidly
integrated to form avionics boxes and systems
– Everyone designing to the same interfaces for compatibility and
interoperability
• AFRL estimates 80-90% of mission costs are NRE
Key Technical Aspects of DIMA
• Partition based software – time/space software partitioning (allows
applications with different criticality levels to be hosted on same
processor)
• Component based software – modular software tasks integrated to
software bus (supports easy development and integration of software due
to independence of tasks and is the basis for distribution of software
across different processors)
• Data Exchange Message (DEM) format – provides message definition for
parsing data across system. Allows packet wrapping and passing data
across different layers
• Time Triggered data bus (virtual backplane)
– 10-20 x faster than current command & control bus (Mil-Std 1553)
– fault tolerant Time Division Multiple Access (TDMA) data bus (no single component can
take down bus)
– Provides synchronization for data for software distribution and byzantine architecture
• Board level building block elements
– Enables random boards to be built into a variable length box with little/no NRE
Current Efforts for Space Common
Avionics*
• Air Force Research Lab (AFRL) Operational
Responsive Space (ORS) Space Plug-n-Play Avionics
(SPA)
• Consultative Committee for Space Data Systems
(CCSDS) Spacecraft Onboard Interface Services (SOIS)
Working Group (WG)
• European Space Agency (ESA) Space Avionics Open
Interface aRchitecture (SAVOIR)
* May be other efforts
A Past Effort
•
•
•
•
•
NASA HQ Standard Component Office –
developed by GSFC
Defined complete Spacecraft bus
Flown on:
• Solar Max
• LandSat 4
• LandSat 5
• UARS
• EUVE
• TOPEX
• GRO (electronics only)
• HST (basic C&DH)
Government is the architect
Questions:
• What should standardize and why?
What should we standardize and why?
• Focus here is on avionics
• Electronics will evolve and need to accommodate this trend
– Currently designs are becoming IO bound
– Density increases but power density is becoming issue
– Believe electronics form factor can be selected
• Standardize on interfaces and not on implementation
• Layered architecture – easier to design, implement and test.
Also easier to change a layer while minimizing affect on other
layers
• Protocol flexibility – across the communication stack
• Standardize on lowest level of modularity
– Software component
– Hardward -board level
Figures of Merit (FOM)
• Mass
• Power (power relates to mass)
• *ilities
– Extensibility – allows for future growth – additions of new
functionality or evolvolution/modification of existing
functionality
– Composability – ability to select and recombine elements
in various combinations to meet specific requirements
(modular and stateless)
– Testability
• Vendor specific independence – government is architecture –
definition of interfaces at low level (software component and
board level) so products can be seamlessly integrated
Software
• What we need
– Modular – tasks need to be developed independently
– Tasks need to be protected from one another
– Task need to be integrated seamlessly within the same
processor or on another processor
• Permits
–
–
–
–
Quicker development
Fault tolerance
Quicker integration
System wide processor load balancing
• Benefit
– Saves NRE, i.e., money
GSFC Flight Software Architecture
•
Project cFE/CFS
– Platform-independent, mission-independent PnP flight software framework
•
•
•
•
•
Status
–
–
–
–
–
•
Reusable core Flight Executive (cFE) and cFE-compliant applications
Goal: Significantly reduce cost and schedule for flight software systems
Goal: Increase reuse of flight and ground software components
Goal: Enable technology infusion and evolution
cFE complete and in maintenance
Component applications developed as needed
Flown on Lunar Reconnaissance Orbiter (LRO)
Based-lined for all GSFC in-house spacecraft developments
In use or being evaluated at several other NASA centers, JSC, ARC, LaRC, KSC, MSFC, and APL
Collaborations
– AFRL Space Plug-and-play Avionics (SPA)
•
•
•
Architecture has been discussed with James Lyke, Frederick Slane, Raymond Krosley
GPS and SpaceWire PnP discovery and Electronic Data Sheets(EDS) prototyping and demonstration
Reviewing AIAA SPA standards
– CCSDS/ESTEC
•
Standardization of Spacecraft Onboard Interface Services SOIS
11
cFE Layered Component
Architecture
•
Each layer and service has a standard API
•
Each layer “hides” its implementation and
technology details.
•
Internals of a layer can be changed -- without
affecting other layers’ internals and
components.
•
Small-footprint, light-weight architecture and
implementation minimizes overhead.
•
Enables technology infusion and evolution.
•
Provides Middleware, OS and HW platformindependence.
Files, Tables
12
Typical Flight Components
EPS HW
Prop HW
Analog I/O
Digital IO
C&T
Application
EPS
Application
100 Hz
100 Hz
1 Hz
1 Hz
Automated
Flight
Manager
(AFM)
GNC-G
Application
GNC-C
Application
Prop
Application
25Hz
100 Hz
50Hz
5 Hz
GNC Sensors
1553
GPS/SIGI
SIGI,
1553
IO
Mass
Storage
System
SSR
50 Hz
GNC-N Apps
Javad
GPS
232
GPS IO
5 Hz
Nav – KF
(Kalman
Filter)
Nav - IMU
Preprocessor
50 Hz
Altimeter
LN200 IMU
Nav Fast
Propagate
Nav
UPP
50 Hz
10 Hz
Data
Storage
5 Hz
Bkground
5 Hz
232
Alt IO
422
Health &
Safety
Manager
Inter-task Message Router (SW Bus – Publish/Subscribe)
50 Hz
LN200 IO
1 Hz
C&T
Hardware,
Radio
Telemetry
Output
Command
Ingest
Housekeeping
Scheduler
10 Hz
10 Hz
10 Hz
100 Hz
Software
Bus
Time
Services
Executive
Services
Event
Services
Table
Services
Limit
Checker
5 Hz
(Framed CCSDS)
cFE Core Services
CFS Configurable Applications
Mission Specific I/O Apps
Mission Specific Apps
13
•
Virtual partitioning:
–
Single CPU:
•
–
Multiple CPUs:
•
–
–
CPU failure has limited affectivity
Real partitioning:
•
•
Space - geographical separation
Time - TDMA system bus behavior
Machines can be scaled to requirements:
•
Low-power, rad-hard
Multi-core partitioning:
–
–
–
•
Space and time partitioning ARINC-653
Requires a high-performance processor
Distributed partitioning:
–
•
CPU failure takes down everything
Partitioned into multiple virtual CPUs:
•
•
•
Software Support for
Distributed IMA
A form of distributed processing
Use case: Image processing for landing and docking
Multi-core scenario
Systems can be built from a combination of these
approaches
–
Proper interface definition allows software and hardware
components to be minimally affected by these partitioning trades
14
DIMA Enabled RIU Controller
•
Partitioned run-time hypervisor on a microcontroller
– Time slice via configuration table on interrupt driven minor cycles
– MMU isolation of component memory, I/O access, and Interrupt Service Routines (ISR)
– Components only have access to their memory and I/O space
• Run-time and I/O schedules are Time-Triggered to bound latency
– Hypervisor controls bus interfaces and ISRs
• Application initiated processor exceptions are masked, but counted for diagnostics
• Hypervisor can interrupt components only as configured
– Hypervisor supports common load, initialization, controller diagnostics, configuration…
ATCS
Address
C&DH
ATCS
C&T
ECLSS
Power
GN&C
Mech
Prop
Unknown
0
Hypervisor
RIU maintains system composability
Time
Hardware
[email protected]
[email protected]
[email protected]
Problem
• This presentation address how to build avionics
boxes from modular board level elements
– Intra-box only
– To significantly reduce NRE of development, test and
integration and through eventual reuse
• It does not address the box-to-box
communication physical interface or protocol,
i.e., does not address Inter-box
– This approach can support different data link layer
protocols
17
Focus
• Need to be applicably to wide range of requirements (90%
rule)
– Robotic and Human rated
– Centralized and Distributed
– Support different redundancy schemes
• Single string, Block Redundant, Cross-Strapped Redundant
– Implementation agnostic (vendor agnostic)
• Need to focus on interface definitions and be protocol
agnostic.
– Interface definitions need to be defined along the computer
communication stack so that different layers may be substituted
without effecting layers above and below, e.g., 1553 can be replace by
TTP/C or TTGbE, etc.
– Define Intra-box physical interfaces only and not protocol or voltage
levels – let community sort this out and converge
18
Approach
• Dominate FOMS – mass and power
• Eliminate NRE of backplane and mechanical chassis
– Quickly accommodate boxes of varying module count
19
Goal
• Multiple vendors can build and qualify their board
level building block (including software because
time-space partitioned) without knowing what other
boards in box will be or how many
20
Signal Buses Traditional Approach
• Electrical
– Custom and/or Euro Card form factor (typically 6U or 3U)
• Single sided or double sided boards
– Parallel Printed Wiring Board backplane (derived from commercial world)
– Some custom signals added to standard signal set (PCI, VME, etc.) making
interchangeability difficult
• Mechanical
– Custom Enclosure design with card faceplate integrated with card
– Wedge locks for card locking and heat dissipation path:
• From board to wedge lock
• From wedge lock to overall enclosure
• From enclosure to chassis
• Qualification
– Modules are integrated into enclosure are only functionally tested
– Environmental testing (EMI/EMC, thermal, vibration) is done on box level
21
Design Goals
•
•
Create architecture suitable for 90% of space missions
Reduce costs avionics system development
–
–
•
Through significant reduction of NRE and
Through standardization of avionic internal electrical interfaces and mechanical interfaces
Simplify electrical interfaces by adopting:
–
Serial communications interface
•
•
–
Single voltage power distribution
•
–
–
Higher voltages to reduce current and eliminate voltage margin concerns
Minimal set of commonly used signals
Interconnection through a star architecture
•
•
•
Eliminate mechanical tolerances between backplane connectors and boards
Increase system reliability by reducing number of signals
Common or Central module – HUB
Peripheral or User module – NODE
Simplify mechanical interfaces by adopting:
–
Modular and variable length slot mechanical enclosure concept using card frames (slices) where:
•
•
•
•
Each Printed Wiring Board (PWB) includes its own portion of the mechanical chassis
Improvement of thermal design – eliminates wedge locks as thermal path
Qualifies modules (slices) for EMI/EMC and thermal requirements
Significantly reduces tolerance of mechanical design
22
Major System Requirements
• High speed communication links
– Compatibility with high speed (gigabit) serial protocol
• Power distribution
• Reliability
– module-to-module isolation
– Support Redundancy schemes
• Ease of implementation
– Minimal compatibility requirements
– Simple predefined interfaces
• Ease of expansion
– Up to 7 NODE modules in same chassis (8 or 9 modules total including
HUB module(s))
– At least 1 surface reserved for user connectors
23
Proposed System Functions
•
Data
– Serial communications from HUB to each NODE
•
•
•
•
•
•
Data rates per link: from 1Mbps to up to 3.125Gbps (user configurable and programmable)
Differential pairs for Full duplex operations
Multiple streams: HUB can talk simultaneously to more than one NODE
Flexible data transfer protocols such as SpaceWire, SpaceFibre, PCI Express, etc: all can co-exist in 1 system
AC coupling for better CMV protection
Power
– 28V bus switched power distribution from HUB
•
•
•
•
•
Up to 20-30W RMS power per NODE
Electrical isolation between Hub(s) and Nodes
True “hot” plugging/unplugging for all NODEs and HUBs without disturbing other system components
Capability to work directly with 120V power bus voltages
Clock
– Individually distributed from HUB to each NODE
•
•
•
User programmable clock distribution for S/C events synchronization
Single frequency power supplies synchronization
Analog telemetry
– HUB will process all Node telemetry (with 0.1% accuracy); Node requires to have:
•
•
•
Either differential multiplexer and signal scale conditioner for NODE analog signals (0.1% accurate) , or
Single thermistor, if any NODE analog circuitry is undesirable
Auxiliary
•
•
Complete all in-system functions programming and debugging
Visual indication to show activity of any HUB or NODE modules
24
Proposed System Highlights
•
Ease of implementation
–
Simple electrical interface
•
–
Simple mechanical interface
•
•
•
100% EMI shielded
Lower emitted noise due to a possible total synchronization of all units
System reliability
–
–
–
•
Elimination of wedge locks: direct contact between cards and module’s frame
Larger contact surfaces between module body and chassis
EMI/EMC issues
–
–
•
Front and Top surfaces are reserved for User connectors
Multiple cards per module
Lower mass and volume over parallel bus design
Superior heat transfer
–
–
•
Serial links will provide higher data rates
Double processing/communication rate when 2 HUB modules are plugged in
User expandability
–
–
•
•
No custom user functions for standardized back connectors
Increased data throughput on subsystem level
–
–
•
Only connectors position is defined
No restrictions for module width
Much easier compatibility between various vendors
–
•
Only 16 physical copper wires per link which are capable to satisfy requirements for 90% or more missions
Single string, or
Dual independent redundancy, or
System cross-redundancy
Wide range of applications
–
Can be used for human or robotic missions
25
One of Possible System Architectures
26
Connector’s Desired Requirements
•
Minimum number of conductors
– 16, with capability of expansion
•
Wires
– Up to AWG#24 wires for power transfer
•
Impedance
– 100 ohms differential
•
Termination
– Customer controlled
•
Shielding
– 100% EMI shielded
•
Connectivity
– Blind mateable
– Scoop proofed
•
Material
– No outgassing and wiskering
•
Shape
– Rectangular for small real estate use
27
Suggested Connector Type
Rugged D-Sub miniature from Sabritec Inc.
with Quadraxial pin assembly inserts
4 (shown) and 16 position shells are suggested
28
Proposed Signal Assignments
Sub
Group
Hub to Hub
Function
Serial
Communication
Digital
Tick and Reset
Distribution
Power and
Supply Sync
Power
and
Analog
Analog
Telemetry and
Node Sense
Cross
Communication
Digital
Tick and Sync
Cross
Connection
Crossover Bus
(4 inserts for an extra Hub)
Hub to Node Bus (28 inserts out of 32 for 7 Nodes)
Group
Cross Reset
Reset
and
Config
Configuration
and Peer Hub
Plug-in
Pin
Node Bus
Connector
Flow
Direction
Hub Bus
Connector
1
RX+
←
TX+
2
TX+
→
RX+
3
RX−
←
TX−
4
TX−
→
RX−
1
Sync/Tick_in+
←
Sync/Tick_out+
2
Reset_in+
←
Reset_out+
3
Sync/Tick_in−
←
Sync/Tick_out−
4
Reset_in−
←
Reset_out−
1
Node Power
←
Node Power
2
Power Return
←
Power Return
3
DC/DC_Sync_in
←
DC/DC_Sync_out
4
Power Fail
←
Power Fail
1
Analog_out+
→
Analog_in+
2
Analog_out−
→
Analog_in−
3
Sense_out+
→
Sense_in+
4
Sense_out−
→
Sense_in−
Flow
Direction
Redundant Hub
Notes
Full Duplex link.
Diagonal pins 1-3 and 2-4
provide 100Ω impedance
Sync - for power supplies;
Tick - for Hub/Node events
Node can be reset
individually by Hub
Up to 2A@28V of derated
Node current;
DC/DC Sync is 500-625KHZ
free running 5V clock;
Hub generated Power Fail
Each Node may have 4-8
analog telemetry slots or
just 1 passive thermsitor;
"Sense" tells Hub if Node is
plugged in and secured
1
TX+
TX+
2
RX+
RX+
3
TX−
TX−
4
RX−
RX−
1
Sync/Tick_out+
Sync/Tick_out+
2
Sync/Tick_in+
Sync/Tick_in+
3
Sync/Tick_out-
Sync/Tick_out-
4
Sync/Tick_in-
Sync/Tick_in-
1
X_Reset_out+
X_Reset_out+
2
X_Reset_in+
X_Reset_in+
3
X_Reset_out−
X_Reset_out−
4
X_Reset_in−
X_Reset_in−
1
Peer_Hub out
Peer_Hub out
2
Peer_Hub in
Peer_Hub in
3
Config_out
Config_out
4
Digital GND
Digital GND
Full Duplex link.
Diagonal pins 1-3 and 2-4
provide 100Ω impedance
Allows both Hubs to share
common clock and sync
X_Reset allows each Hub
to reset its peer Hub either
by command, or by lack of
communications for the
TBD time period
Tells each Hub that its
Peer Hub is plugged-in
Hub 1 has no jumper,
Hub 2 has external jumper
29
One of Proposed Routings
30
Suggested Hub Architecture (Digital)
Section)
31
Suggested Hub Architecture (Analog)
32
Suggested Node Architecture
33
Dual Cards Assembly for HUB Module
(with EMI shield)
34
Dual Cards Assembly for HUB Module
(without EMI shield)
Single Cards Assembly for Node Module
(without EMI shield)
Single Cards Assembly for Node Module
(with EMI shield)
Cross Section View
38
Assembled System View
(with EMI shield)
39
Assembled System View
(without EMI shield)
Transparent View
41
Assembled System View with End Plates
(without EMI shield)
Assembled System View with Fastening
Hardware
Assembled Top View with Intra-box
Harness
Assembled Side View with Intra-box
Harness
L-Bracket Front
46
L-Bracket Back
47
Component
Single Node
Double Node
Hub
EMI Shield
End Cover
L Bracket
EMI Bracket, Small
EMI Bracket, Large
PCBs (est)
Total Mass
Total Electronics Mass
Total Chassis Mass
Mass (lbs)
1.084
1.5
1.476
0.568
0.925
1.209
0.036
0.058
1.5
Qty
6
1
2
2
2
1
8
2
12
Total Mass (lbs) Total Mass (kg)
6.50
2.96
1.50
0.68
2.95
1.34
1.14
0.52
1.85
0.84
1.21
0.55
0.29
0.13
0.12
0.05
18.00
8.18
33.56
18.00
15.56
15.25
8.18
7.07
Hub Sense
and LED
Suggested Layout for Hub
Analog Conversion Area with MUXes
Buffers
Buffers
0.05W
0.05W
Comp
Comp
Buffers
0.05W
Comp
Comp
0.1W ALL
0.2W
Comp
+/-5V
DC/DC
Converter
0.3W
Prime Bus
EMI filter
Prime Power
Electronics Area
4W
0.25W
+/-5V
DC/DC
Converter
0.3W
+3.3V
/ 20-50W
+3.3V
/ 50W
DC/DC
DC/DC Converter
Converter
5W
50
7W2
Dual Opto
FET SSR
Dual Opto
FET SSR
0.2W
Comp
Buffers
Dual Opto
FET SSR
0.2W
Comp
5W
0.2W
Dual Opto
FET SSR
Sabritec-16
Nodes Power and Analog
Comp
0.25W
Input Power
Buffers
0.05W
Overall Buses Comparison Chart
Function
Data Interface
Data Exchange
Data Exchange Method
Impedance Matching
Bus Utilization
Redundancy
Power Distribution
Bus Current
Common Voltage Tolerance
Card-to-Card Isolation
Hot Plugging/Unplugging
System Telemetry
EM Interference
Clock Distribution
Clock Skew Requirements
Connector Pins per Card
Bus Interconnect
User Connectors Areas
PCB Assembly
Card Insertion Force
Blind Mating
Scoop Proofing
Cards or Modules Distance
Traditional Buses
Parallel
Half-duplex
Synchronous
Mismatched
Single flow
Single
Multiple bus voltages
Medium to very high
Low (100's of mV)
Very complex/Impossible
Complex/Impossible
Not Specified
Leaking
Single high frequency
Very tight
Several hundreds
PCB
Front surface only
Single side w/limited back
Medium to high
Yes, stress on conn. pins
Yes
20-25mm
Suggested SpaceAGE Bus
Serial
Full-duplex
Asynchronous
Matched
Multiple independent flows
Single, Double, Cross
Single voltage
Low to very low
High (several volts)
Possible and very simple
Possible and very simple
Standard: Analog & Digital
Fully shielded
Multiple low freq. for Sync
Low: not very important
16 per Node plus Chassis
Harness
Front and top surfaces
Dual sided, w/unlimited tier cards
Low
Yes, stress on conn. metal body
Yes
Limited by communication rates
51