Common Avionics Building Blocks

wistfultitleΗλεκτρονική - Συσκευές

24 Νοε 2013 (πριν από 4 χρόνια και 1 μήνα)

91 εμφανίσεις

Common Avionics Building Blocks

Glenn.P.Rakow@nasa.gov

Jonathan.J.Wilmot@nasa.gov

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?


D
istributed


Resources (both hardware and software) are physically distributed


Reduce harness mass


Provide for local control of local functions


Lowers flight computer load


I
ntegrated


Multiple functions of different criticalities running on separate, high integrity, partitions


Re
-
locatable functions not limited to a single line replaceable unit (LRU) boundary


M
odular


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


A
vionics


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

11

GSFC Flight Software Architecture


Project cFE/CFS


Platform
-
independent, mission
-
independent PnP flight software framework


Reusable
c
ore
F
light
E
xecutive (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


Status


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





12


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 platform
-
independence.


Files, Tables

Typical Flight Components

13

Mission

Specific Apps

cFE Core Services

CFS
Configurable Applications

Mission Specific I/O Apps

Scheduler

Inter
-
task Message Router (SW
Bus


Publish/Subscribe)

Event

Services

Health &

Safety

Manager

Executive

Services

Time

Services

Software

Bus

Command

Ingest

Telemetry

Output

Data

Storage

Mass

Storage

System

SSR

Table

Services

GNC
-
C

Application

House
-

keeping


Limit

Checker

Digital IO

Analog I/O

GNC
-
G

Application

Prop

Application

LN200 IMU

GPS/SIGI

Altimeter

Javad

GPS

Automated

Flight

Manager

(AFM)

EPS

Application

Prop HW

232

422

C&T

Application

1553

Nav Fast


Propagate

Nav

UPP

Nav



KF
(
Kalman

Filter)

Nav

-

IMU

Preprocessor

EPS HW

GPS IO

Alt IO

LN200 IO

SIGI,

1553

IO

232

GNC Sensors

GNC
-
N Apps

C&T
Hardware,

Radio

(Framed CCSDS)

100 Hz

100 Hz

100 Hz

50 Hz

25Hz


1 Hz

100 Hz

10 Hz

10 Hz

10 Hz

50Hz

5 Hz

5 Hz

50 Hz

50 Hz

50 Hz

5 Hz

5 Hz

10 Hz


1 Hz

Bkground


1 Hz


5 Hz

Software Support for

Distributed IMA

14


Virtual partitioning:


Single CPU:


CPU failure takes down everything


Partitioned into multiple virtual CPUs:


Space and time partitioning ARINC
-
653


Requires a high
-
performance processor


Distributed partitioning:


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:


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

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…




ECLSS

ATCS

C&DH

C&T

Power

GN&C

Mech

Prop

Unknown

ATCS

Address
Time
0
RIU maintains

system
c
omposability

Hypervisor
Hardware


Glenn.P.Rakow@nasa.gov

Alex.Kisin@nasa.gov

Eric.T.Gorman@nasa.gov

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



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


Signal Buses Traditional Approach

21


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


Eliminate mechanical tolerances between backplane connectors and boards


Increase system reliability by reducing number of signals


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


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

Design Goals

22


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


Major System Requirements

23


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





Proposed System Functions

24


Ease of implementation


Simple electrical interface


Only 16 physical copper wires per link which are capable to satisfy requirements for 90% or more missions


Simple mechanical interface


Only connectors position is defined


No restrictions for module width


Much easier compatibility between various vendors


No custom user functions for standardized back connectors


Increased data throughput on subsystem level


Serial links will provide higher data rates


Double processing/communication rate when 2 HUB modules are plugged in


User expandability


Front and Top surfaces are reserved for User connectors


Multiple cards per module


Lower mass and volume over parallel bus design


Superior heat transfer


Elimination of wedge locks: direct contact between cards and module’s frame


Larger contact surfaces between module body and chassis


EMI/EMC issues


100% EMI shielded


Lower emitted noise due to a possible total synchronization of all units


System reliability


Single string, or


Dual independent redundancy, or


System cross
-
redundancy


Wide range of applications


Can be used for human or robotic missions


Proposed System Highlights

25

One of Possible System Architectures

26

27


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







Connector’s Desired Requirements

Rugged D
-
Sub miniature from Sabritec Inc
.

with Quadraxial pin assembly inserts

Suggested Connector Type

28

4 (shown) and 16 position shells are suggested

Proposed Signal Assignments

29

Group
Sub
Group
Function
Pin
Node Bus
Connector
Flow
Direction
Hub Bus
Connector
Flow
Direction
Redundant Hub
Notes
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−
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
Hub to Node Bus (28 inserts out of 32 for 7 Nodes)
Digital
Serial
Communication
Full Duplex link.
Diagonal pins 1-3 and 2-4
provide 100Ω impedance
Tick and Reset
Distribution
Sync - for power supplies;
Tick - for Hub/Node events
Node can be reset
individually by Hub
Power
and
Analog
Power and
Supply Sync
Up to 2A@28V of derated
Node current;
DC/DC Sync is 500-625KHZ
free running 5V clock;
Hub generated Power Fail
Hub to Hub Crossover Bus (4 inserts for an extra Hub)
Digital
Cross
Communication
Full Duplex link.
Diagonal pins 1-3 and 2-4
provide 100Ω impedance
Tick and Sync
Cross
Connection
Allows both Hubs to share
common clock and sync
Reset
and
Config
Cross Reset
X_Reset allows each Hub
to reset its peer Hub either
by command, or by lack of
communications for the
TBD time period
Configuration
and Peer Hub
Plug-in
Tells each Hub that its
Peer Hub is plugged-in
Hub 1 has no jumper,
Hub 2 has external jumper
Analog
Telemetry and
Node Sense
Each Node may have 4-8
analog telemetry slots
or
just 1 passive thermsitor;
"Sense" tells Hub if Node is
plugged in and secured
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)



38

Cross Section View



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
Mass (lbs)
Qty
Total Mass (lbs)
Total Mass (kg)
Single Node
1.084
6
6.50
2.96
Double Node
1.5
1
1.50
0.68
Hub
1.476
2
2.95
1.34
EMI Shield
0.568
2
1.14
0.52
End Cover
0.925
2
1.85
0.84
L Bracket
1.209
1
1.21
0.55
EMI Bracket, Small
0.036
8
0.29
0.13
EMI Bracket, Large
0.058
2
0.12
0.05
PCBs (est)
1.5
12
18.00
8.18
Total Mass
33.56
15.25
Total Electronics Mass
18.00
8.18
Total Chassis Mass
15.56
7.07
Suggested
Layout for Hub


50

Dual Opto
FET SSR
Dual Opto
FET SSR
Analog Conversion Area with MUXes
Buffers
Hub Sense
and LED
Sabritec
-
16
Nodes Power and Analog
Buffers
Buffers
Buffers
Buffers
Comp
Comp
Comp
Comp
Comp
Comp
Comp
Comp
0
.
2
W
0
.
2
W
0
.
05
W
0
.
05
W
0
.
05
W
0
.
05
W
0
.
1
W ALL
0
.
25
W
Dual Opto
FET SSR
Dual Opto
FET SSR
0
.
2
W
0
.
2
W
Prime Power
Electronics Area
0
.
25
W
7
W
2
Input Power
+/
-
5
V
DC
/
DC
Converter
0
.
3
W
+/
-
5
V
DC
/
DC
Converter
0
.
3
W
Prime Bus
EMI filter
4
W
+
3
.
3
V
/
20
-
50
W
DC
/
DC Converter
5
W
+
3
.
3
V
/
50
W
DC
/
DC Converter
5
W
Overall Buses Comparison Chart


51

Function
Traditional Buses
Suggested SpaceAGE Bus
Data Interface
Parallel
Serial
Data Exchange
Half-duplex
Full-duplex
Data Exchange Method
Synchronous
Asynchronous
Impedance Matching
Mismatched
Matched
Bus Utilization
Single flow
Multiple independent flows
Redundancy
Single
Single, Double, Cross
Power Distribution
Multiple bus voltages
Single voltage
Bus Current
Medium to very high
Low to very low
Common Voltage Tolerance
Low (100's of mV)
High (several volts)
Card-to-Card Isolation
Very complex/Impossible
Possible and very simple
Hot Plugging/Unplugging
Complex/Impossible
Possible and very simple
System Telemetry
Not Specified
Standard: Analog & Digital
EM Interference
Leaking
Fully shielded
Clock Distribution
Single high frequency
Multiple low freq. for Sync
Clock Skew Requirements
Very tight
Low: not very important
Connector Pins per Card
Several hundreds
16 per Node plus Chassis
Bus Interconnect
PCB
Harness
User Connectors Areas
Front surface only
Front and top surfaces
PCB Assembly
Single side w/limited back
Dual sided, w/unlimited tier cards
Card Insertion Force
Medium to high
Low
Blind Mating
Yes, stress on conn. pins
Yes, stress on conn. metal body
Scoop Proofing
Yes
Yes
Cards or Modules Distance
20-25mm
Limited by communication rates