Using Proven Aircraft Avionics Principles to Support a Responsive Space Infrastructure

Randy Black Honeywell Space Applications

4th Responsive Space Conference April 24-27, 2006 Los Angeles, CA

Practical Aspects of Responsive Aviation Space

//////////////////////////

Tactical deployment of aviation assets

Rapid reconfiguration of hardware and software in response to variable mission scenarios Maintain high mission success through reliable system architecture Decrease cost and schedule associated with development, integration, test/qualification, and operations

Integrated Modular Avionics (IMA) architectural principles support Responsive Space goals
Common plug-and-play hardware modules and software time and space partitioning support rapid reconfiguration IMA is required to fly for 15 days following first fault condition; reliability of 10-9 chance of undetected failure Acquisition cost of AIMS2 IMA was 75% less than previous federated architecture with >20% shorter development schedule

Proven Architecture with >40 Million Hours of Flight

Copyright by Honeywell International Inc. Published by AIAA 4th Responsive Space Conference 2006 with permission.

Goal: Minimize Impacts of System Changes

Off-Line

Modeling Tool(s)

Common System Manager

Application

Run-Time

Application

Data Base, Tables, etc.

Application

Copyright by Honeywell International Inc. Published by AIAA 4th Responsive Space Conference 2006 with permission.

Integrated Modular Avionics History

2nd Generation DAIS 3rd Generation PAVE PILLAR
RADAR CNI EW

4th Generation PAVE PACE / ISS

Integrated RF

5th Generation Low Cost Integrated Avionics

Federated, LRU based systems

Open architecture, common modules for RF Technology drives core processing performance

Integrated, LRM based system Open architecture, common modules for core processing

Technology drives system performance Architecture drives schedule / risk / affordability

From a presentation by Ron Szkody on 29 May 1996 to the Integrated Sensor System (ISS) Open System Architecture (OSA) Joint Task Force (sponsored by United States Air Force Wright Laboratory /AAST-30

AIMS

VIA

Primus EpicTM

AIMS-2
2002

AIMS-787 Current

Space Exp

2004

1980s

5 Generations of 5th Generation Avionics

Architectural principles are more important than specific implementations

Key IMA Architectural Principles

1. Modular hardware architecture
Shared resources Lock-step processors Virtual Backplane

2. Full time and space partitioning

Partitioned (e.g. ARINC-653) operating system Shared software resources Hardware enforcement of partitioning

3. Table-driven coordinated operations and memorymapped interfaces

Coordination of processor, memory, I/O, and bus/backplane resources System control of data movement

4. System-level coordination tools Key IMA architectural principles may be included or excluded to meet program needs

Shared Resources

Integrated Modular Avionics benefits

Reduces size, weight, power Reduces NRE cost and schedule Reduces parts, part types, and spares
Hardware Resources Software Resources Application Software Application BITE Shared I/O Memory System Operating System & API Hardware BITE Common Software Middleware

Unique Input/Output

Reduces software development, certification, and modification costs

Processor Power Supply Chassis

Two Examples of a Shared Hardware Architecture

Power Power GG I/O Board Generic I/O Board a

Copyright by Honeywell International Inc. Published by AIAA 4th Responsive Space Conference 2006 with permission.

cPCI Backplane cPCI Backplane cPCI Backplane

...

Generic I/O Board a cPCI Backplane Generic I/O Board a Processor Board Network I/F Board

GG I/O Board Generic I/O Board

Cabinet Bus

Processor Board

System Data Bus (IEEE 1394b, MIL-STD-1553, AFDX, etc.)

cPCI Backplane

Power Comm I/O Board Generic I/O Board a Generic I/O Board a Generic I/O Board a Processor Board Network I/F Board

Processor Board Comm I/O Board Generic I/O Board Power

System Data Bus (IEEE 1394b, MIL-STD-1553, AFDX, etc.)

Network Centric

Cabinet Centric

Power

Power Generic I/O Board Generic I/O Board a Generic I/O Board a Generic I/O Board a Processor Board Network I/F Board

...
cPCI Backplane cPCI Backplane GG I/O Board Generic I/O Board a
Cabinet Bus

Processor Board

Processor Board Comm I/O Board Generic I/O Board Power

Other Modules

Lock-Step Processors
Each side duplicates all processing, memory accesses, and I/O functions Compare logic determines when there is a fault on one side Each side enables external communication of the opposite side Upon fault detection, the processor pulls itself offline If a fault is recoverable (e.g. an SEU in one memory can be detected and the correct value loaded from its counterpart on the opposite side), the processor re-inserts itself into operation

DRAM

Support Chip / Compare Logic

Support Chip / Compare Logic

DRAM

System Memory

System Memory

Processor

Processor

Copyright by Honeywell International Inc. Published by AIAA 4th Responsive Space Conference 2006 with permission.

Lock Step Processing Reduces Redundancy Requirements

Combined with robust BIT/BITE, lockstep processors provide 100% fault coverage Does not require a cross-channel voting mechanism, providing cross channel trust Minimizes processing modules required to handle Byzantine failure conditions Provides a degree of self-healing

Lock-step processing enables minimal number of required channels to compensate for fault conditions
9 Copyright by Honeywell International Inc. Published by AIAA 4th Responsive Space Conference 2006 with permission.

Time and Space Partitioning

Memory Key implementation concepts Processor Input/Output
High Throughput Computer Memory Management Unit High Integrity Time Base Table Driven Communication Memory Mapped I/O High integrity Operating System

ROBUST PARTITIONING SYSTEM

Partitioning Domains
1. 2. 3. 4. Memory Space Computation Time Input/Output Access Backplane Access

Memory Processor Input/Output

Memory Processor Input/Output

Shared I/O Resources

Memory Processor Input/Output

Multiple Virtual Computers

Each partition operates as if it were hosted on a dedicated computer

10

Copyright by Honeywell International Inc. Published by AIAA 4th Responsive Space Conference 2006 with permission.

Characteristics of a Fully Partitioned Systems

No partition can: 1. Contaminate anothers code, I/O, or data storage areas (Space Partitioning) 2. Consume shared processor resources to the exclusion of any other partition (Time Partitioning) 3. Consume I/O resources to the exclusion of any other partition (I/O space and time partitioning) 4. Cause adverse effects to any other partition as a result of a hardware failure unique to that partition

11

Copyright by Honeywell International Inc. Published by AIAA 4th Responsive Space Conference 2006 with permission.

Partitioning and Table-Driven Operations

BITE
Continuous BITE Status Generation Maintenance I/F Non-Volatile Memory Mgmt Loader Entry Detection Fault Server

I/O
1394 1553 Ethernet Analog I/O Discrete I/O RS-422

Application A Critical Functions

Application B Essential Functions

Application N Non-Essential Functions

OS API

OS API

OS API

OS API

OS API

OS API Memory Management

Partitioned Operating System Non-Resident Boot

Application Fault Response Time Management Software Loader Platform Load Verification Module Load Verification Cabinet Initialization

Hardware Abstraction Layer (HAL2) Non-Resident Boot Initialization Power-Up BITE (POST) Platform Fault Response

Resident Boot
Boot Initialization

Common Monitor Common Monitor Tools Interface

Hardware Abstraction Layer (HAL1) System Monitor/Debug Interface

Partition Monitor/Debug Interface

Partitioning allows software running on 1 processor to be treated as if applications were physically separated Table-Driven operations removes system responsibility from the software developers and transfers it to the system integrator
12

I/O and inter-application communication is table-driven and managed by the system software Many system modifications only impact tables values no impact to applications software

Copyright by Honeywell International Inc. Published by AIAA 4th Responsive Space Conference 2006 with permission.

Benefits of Partitioning

Allows software applications to be developed and tested independent of other developers Software changes do not require recertification of unmodified applications
Allows each applications verification level to be based on its criticality. Supports coexistence of applications of differing criticality levels on the same hardware Supports coexistence of applications with differing tendencies to change Significantly reduces integration, test, and V&V activities

13

Copyright by Honeywell International Inc. Published by AIAA 4th Responsive Space Conference 2006 with permission.

Offline Table Generation Simplifies System Modifications

1 per High-Speed Bus Interface Bus Bus Access Bus Access Bus Schedule Access Schedule Access Schedule Schedule Bus Scheduler 1 per Application System Interactions Redundancy Schemes Database Bus Bus Access Bus Access Schedule Access Memory Schedule Schedule Map

es rc ou es R fic ng af si Tr es oc ng us Pr i B d im & re T O ui red I/ eq i ed R equ ir R equ R

Applications Developers

Resource Manager

System Engineers
Physical Implementation
tem s Sy ch Ar

Memory Mapper

ctu e t i

re

Application Scheduler

1 per Processor Bus Bus Access Bus Access Schedule Access Application Schedule Schedule Schedule

System and partitioning tools are required in addition to traditional development tools
14 Copyright by Honeywell International Inc. Published by AIAA 4th Responsive Space Conference 2006 with permission.

Table-Driven, Memory-Mapped Interfaces

Partition B
Memory

Partition A
Memory Code
System Tables System Tables
Middleware

Code
Virtual Backplane
Middleware

I/O Partition
Memory Drivers

Test Script
Inter-Application Comm, I/O

Test Equipment / Validation Facility / Maintenance Facility

Copyright by Honeywell International Inc. Published by AIAA 4th Responsive Space Conference 2006 with permission.

I/O

15

Benefits of Table-Driven, Memory-Mapped Control

Applications may not require modification if underlying I/O, processor, or backplane/data bus hardware changes Applications are not required to handle interfaces with other applications or I/O resources Simplifies independent development and testing of applications Moving applications from one processor to another does not require changes to the application, the placement of I/O handlers, etc. Applications do not need to account for redundancy Many system changes can be accomplished simply by re-running the offline tools and generating new tables to control the modified operations Responsibility for accommodating system architectural changes transitions from software to the system integrator
16 Copyright by Honeywell International Inc. Published by AIAA 4th Responsive Space Conference 2006 with permission.

Designing for Modifiability Computing Platforms

Off-Line

Run-Time

Data Base, Tables, etc.

17

Copyright by Honeywell International Inc. Published by AIAA 4th Responsive Space Conference 2006 with permission.