Application migration using ARINC 653 and Open GL

137 downloads 140455 Views 122KB Size Report
Application migration from Linux ... Desktop platforms plentiful in most organizations ... Linux prototype has application functionality that falls into 3 main.
Application migration from Linux prototype to deployable IMA platform using ARINC 653 and Open GL

1

Why a Linux Prototype • Low (no) cost development environment – Stable kernels available for download – Commercial vendors also available providing support – Familiar environment to most

• Availability of additional open source libraries – Open GL – GLUT

• PC based platforms – Low cost, high performance graphics hardware availability – Desktop platforms plentiful in most organizations

• GNU based tools 2

Deployable IMA Environment using VxWorks 653 • To support multiple applications a partitioned environment is needed – Allows each application to be tested and certified separately – Reduces cost of change for updates – Reduces SWaP (Space, Weight and Power)

• Linux prototype has application functionality that falls into 3 main categories – Graphical display – Analog IO data – Terrain database

3

VxWorks 653 Partitioned Environment Logical View • The partitioned environment is based on a virtual target computer concept that: – Provides dedicated processing capability that is robustly partitioned – Provides a DO-178B “target computer” (6.4.1). The virtual target provides: • Dedicated time on the processor • Dedicated memory • Dedicated OS and Services (Partition Operating System or POS) • An ARINC 653 compliant API providing access to the POS and underlying Platform Services when needed

4

Processing resource (CPU)

Leveraging Open Standards Application API and behavior • ARINC 653 APEX Services – Partition management • Start and restart control

– Process management • Periodic and aperiodic

– Time management • Process execution control

– Inter-partition, Inter-module communications • Sampling, Queuing Ports

– Inter-process communications • Buffer, Blackboard, Semaphore, Event

– Error management • Process, Partition, Module

5

ARINC 653 Partition Scheduler

Major frame

Activation2 Activation 1

Partition 1

Partition 2 t1

t0 Minor frame

duration 1

= Partition Idle

6

Partition 1

Partition 3 t2

t3

Partition 2 t4

t5 duration 2

Partition 1 t6

Partition 2 time

ARINC 653 APEX Priority-Preemptive Inside Partitions

T1 T1

T1 T1

T1 T1 T2 T2

T2 T2

T3 T3

APEX API

T2 T2

T2 T2 T3 T3

T4 T4

APEX API

T1 T1

APEX API

T3 T3

APEX API

Partition #1 Partition #2 Partition #3 Partition #1 7

Time

ARINC 653 Example Data Flows Partition 1

Source Queuing Port

App 1

Buffer

Module OS Destination Queuing Port

App 3

Blackboard

Event

App 2

Partition 2

Destination Sampling Pseudo-Port

Source Sampling Port

Event

App 4

I/O Driver External I/O Device (Such as AFDX)

8

I/O Driver External I/O Device (Polled Only)

Leverage Open Standards Graphics • Open GL – – – – – – –

Matrix-based 2D and 3D geometry Viewport and clipping regions Texturing Graphics pipeline support Display lists Vertex arrays Wide driver support for graphics hardware • 3D Labs • ATI

– No font support though • Fonts are provided by GLUT or other higher level libraries

9

Migration Challenges • Linux not suitable for embedded, DO-178B certified environments – Large SLOC (Source lines of code) – Assumes unconstrained memory resource availability • Allocation/deallocation of memory can occur without developer’s direct control

– Updated/changed frequently at the kernel level – Applications can be monolithic in nature

• The VxWorks 653 environment is ready for DO-178B certification – Memory allocations occur during initialization and then disabled by OS during run time to prevent fragmentation and resource depletion – All resources are specified at initialization time – System configuration is statically defined and set at initialization time – API subsetting is common to reduce SLOC to ease certification testing and structural coverage – Drivers require special attention to be safe in a partitioned environment 10

Migration Challenges • Subsetting can mean loss of functionality – Open GL subset does not provide GLUT • Developer must create similar functionality from Open GL primitives • Font support must be supplied – Typically available from open source for use – Typically a restricted set

• Process models initialize differently in ARINC 653 – Developer must specify resources used for a process • Time • Stack (memory) • Deadlines

• Development environment is typically quite different – Use of GNU tools eases this somewhat – Development process must follow DO-178B guidelines 11

Migration Challenges • Overall system architecture must be well thought out before migration begins – – – –

Without a solid architecture, excessive rework results Insures a full understanding of resources needed Allows application to be partitioned by functionality Allows thoughtful selection of development language • C, C++, assembly, etc.

• Takes the multi-threaded Linux application into a partitioned environment – Partitioning also involves data and their sources as well • APEX input/output quite different than Linux

12

System Architecture using VxWorks 653

13

Low Level Drivers for Graphics Hardware • Low level drivers that interact with graphics hardware can be problematic in the certifiable environment – High performance requirements drives use of DMA and shared memory for graphics data transfer – DMA can be problematic in a time partitioned system – Special care must be taken in the design to insure partitioning is not violated – Drivers typically need time partitioning awareness added or must be completely analyzed to insure robustness in the ARINC environment – Are always certified to the highest level of the platform which is typically DO-178B, Level A along with the rest of the Board Support Package

14

Summary • Developers using desktop development environments such as Linux must adapt to the more rigid and rigorous embedded environment – The two environments and development methodologies are quite different – Not all desktop developers can make the transition to the embedded development environment

• Linux based applications can be migrated to the embedded environment to support reuse of rapid prototyping using the desktop – System architecture design will be key in making this successful – Use of open standards such as Open GL and ARINC 653 can assist in this effort but also may lengthen the migration cycle without a complete understanding of the differences 15

Thank you Larry Kinnan Senior Engineering Specialist Aerospace and Defense

[email protected]

16