02 VxWorks653

Integrated Modular Avionics
and ARINC 653 using

VxWorks 653
Larry Kinnan
Principal Technologist, Avionics and Safety Critical Systems
April 2012
2/53
What is Integrated Modular Avionics ?
Integrated
Multiple Application executed on the same computer
Data communications multiplexed

Modular
Usage of non-system specific computers
Configurable computers to provide resources to different
applications

Avionics
Initially used in Avionics (Honeywell, Boeing, Thales, Airbus,
etc.). Now used outside the Avionics domain
| 2012 Wind River. All Rights Reserved.
| 2012 Wind River. All Rights Reserved. 3/53
Federated IMA
Federated vs. Integrated Modular Avionics
Advantages
Independence of design and
certification
Well-understood methodology
Established supply chain

Challenges
Greater space, weight, and power
(SWaP) requirements
Each function is a separate LRU
Less software reuse
Less portability
Less modularity
Advantages
Lower SWaP requirements
Multiple functions on single LRU
Better software reuse
Better portability
Better modularity

Challenges
Greater complexity of system
integration
Greater complexity of design and
certification
Inexperienced supply chain

Flight
Control

Graphics

ARINC 429

Radar

Flight
Control

Radar

Graphics

Time and Space Partitioning
ARINC 653 Operating System
4/53
IMA Expected Benefits
Minimize the cost of changes
Minimize dependencies between elements of the system
Avoid or limit the need to rebuild and revalidate the entire system
if a change is required or a new application added

Allow flexible organization
Build and Validate different elements of the system separately
Reduce the level of information shared between elements of a
system (also bring IP protection)
Facilitate independent development of different components by
different groups of developers (distributed development)

Allow re-usability (Application, IMA Platform)
5/53
Classical Mistakes
ARINC 653 is an IMA System standard
Wrong: This is an Avionics Application Software Standard Interface

Using ARINC 653 compliant COTS OS is sufficient to
implement an IMA approach
Wrong: You need to define an IMA Platform
It must not be construed that compliance to ARINC 653 assures robust
partitioning. (ARINC 653-2 Part1)

The ARINC 653 compliant COTS OS is only a part of the
IMA Platform
6/53
Classical Mistakes (cont.)
Independency of Applications is assumed but not
demonstrated
Roles and Responsibility are not clearly defined
The usage domain of the IMA Platform was not defined
Debug and Test capabilities are not taken into account
Assumed that one can take multiple federated applications
and place them on an IMA Platform without modification

7/53

Consider RTCA DO-297 / ED-124
DO-297 (2005) Integrated Modular Avionics (IMA)
Development, Guidance and Certification Considerations
Defines Roles and Responsibilities
Defines IMA Platform characteristics
Resource Management (for Shared Resources in particular)
Robust Partitioning Protection Mechanism
Provide an API to Applications. ARINC 653 Parts 1 and 2 are
suggested for portability but not required
Health Monitoring and Fault Management
Operating System (part of a Core Software)
Defines an IMA Development Process
8/53

Robust Partitioning
Robust Partitioning is the key of the IMA Platform
Its demonstration allows:
Applications to be developed, tested and verified separately
System fault to be contained
Allow Application modifications

If specific additional provision have been taken:
Applications can be added or removed to the system
Applications can be distributed on multiple IMA Platform

VxWorks 653 Runtime
Compliance to ARINC Specification 653, Part 1


VxWorks 653 Runtime
Implements a two-level OS architecture model
Module OS performs partition scheduling
Partitions perform their own task scheduling
Standards-based virtualization approach
"Virtual machine" approach as described in DOT/FAA/AR-99/58,
Partitioning in Avionics Architectures: Requirements, Mechanisms and
Assurance, by J ohn Rushby
Corresponds to virtual machine concept described in DO-178B, section
6.4.1
Virtualization enables applications to run on partition OSs
Enables high performance
Ability to run dozens of partitions with minimal RTOS partition switch
overhead even at high clock rates
Scales to a maximum of 255 partitions without performance degradation

VxWorks 653 IMA Architecture
XML Configuration Data
VxWorks 653 Application Executive
Board Support Package (BSP)
User
Mode
Kernel
Mode
ARINC 653
Partition OS
Flight
Control (FC)
Application

Level A
POSIX
Partition OS
VxWorks
Partition OS
Ada/J ava
Partition OS
Radar
Application

Level B
Graphics
Generator
Application

Level C
Display
Application

Level D
Hardware

ARINC 653 APEX
ARINC 653 specification
defines a general purpose
APEX (APplication /
EXecutive) interface
Between the OS and the
application software
VxWorks 653 provides a full
ARINC 653, Supplement 2,
Part 1 APEX
Fully supports robust time
and space partitioning as
defined by ARINC 653

APEX Interface
Core Module Interface Relationships
Source: ARINC Specification 653 Part 1, Supplement 2, Figure 1.2

ARINC 653 Advantages
Portability
APEX (APplication/EXecutive) interface facilitates portability of
software applications
Reusability
APEX interface enables reusable application code for IMA
systems
Modularity
By removing hardware and software dependencies, the APEX
interface reduces the impact on application software from
modifications to the overall system
Integration of Software of Multiple Criticalities
Each application uses a virtual target (DO-178B, Section 6.4.1)
Supports DO-178B Levels A-E on the same processor

ARINC 653 APEX API provides the following services:

Includes APIs for C, C++, and Ada
Ada APIs are provided by partners
A certifiable and safe C++ subset is available
No delete operator or garbage collection
No pure virtual functions
No runtime type information (RTTI)
No C++ exceptions
Process management
Time management
Partition management
Sampling port management
Queuing port management
Buffer management
Blackboard management
Semaphore management
Event management
Error management

ARINC 653 APEX API
Partition Management
The schedule in the XML configuration defines the major frame
A major frame is simply a collection of partition windows executed in a repeating
sequence
The sum of all the partition windows durations is the major frames duration
Each partitions time is referred to as a partition window
Partitions do not have a priority
Partitions can be scheduled in any order and multiple times within a major frame
Health Monitor typically checks for any temporal violations (jitter and deadlines)
Partition
1
Partition
1
Partition
1
Partition
2
Partition
2
Partition
2
Partition
3
Major Time Frame
Activation 2
Activation 1
Duration 1 Duration 2
IDLE

Process Management API
These are the ARINC process APIs:
GET_PROCESS_ID GET_PROCESS_STATUS
CREATE_PROCESS SET_PRIORITY
SUSPEND SUSPEND_SELF
STOP STOP_SELF
START * DELAYED_START
LOCK_PREEMPTION UNLOCK_PREEMPTION
RESUME GET_MY_ID
ARINC 653 provides for either a hard or soft deadline
for a process
A hard deadline forces remedial action such as WARM_START
A soft deadline typically records failure and continues
Deadline actions are performed by Health Management framework

Process Attributes
Period defines time when each activation of process is to occur
ARINC periodic processes are based on absolute or wall clock time
If the period is zero (aperiodic), then normal priority based pre-emptive
scheduling will occur as soon as the process is started and the partition is in
NORMAL mode
Time capacity is elapsed time allowed for process to complete its
execution before invoking deadline action or needs to be replenished
Both periodic and aperiodic processes can have a capacity (deadline time)
PROCESS_ATTRIBUTE_TYPE processTable[]=
{
/* NAME ENTRY_POINT STACK_SIZE BASE_PRIORITY PERIOD TIME_CAPACITY DEADLINE */

/* name, entry, stack, prio, period, t capacity,deadline */
{"apexMinimalTest", apexMinimalTestRun, 4000, 100, TIME_4sec, TIME_2sec, SOFT},
{"apexListener", apexListener, 4000, 110, ZERO_TIME_VALUE, TIME_6sec, SOFT},
{"forwarder", apexForward, 4000, 110, ZERO_TIME_VALUE, ZERO_TIME_VALUE,SOFT}

Process Management
After NORMAL mode is set, processes can be made
ineligible for execution by calling STOP or STOP_SELF
Calling START or DELAYED_START resets the process
back to its initial state including its stack.
SUSPEND (SUSPEND_SELF) and RESUME are used
to place a process into a WAITING state and the have it
continue from the point it was suspended
Process IDs are used in most Process Management calls
except those that request the ID (these use the ASCII
process name)
Processes cannot affect the Process level Health Monitor
if one exists

Time Management API
Support for periodic and aperiodic processes
TIMED_WAIT PERIODIC_WAIT
GET_TIME REPLENISH
Periodic process are scheduled using wall clock(absolute)
time
Underlying partition scheduling is transparent to application
Deadlines can be adjusted programmatically using
REPLENISH
REPLENISH has bounded constraints to its operation to prevent
inappropriate behavior. You cannot replenish beyond the periodic
processs next activation time
Calling REPLENISH with an INFINITE_TIME makes the periodic
process an aperiodic process

Partition 1
App 1
App 2
Event
Partition 2
App 3
App 4
Blackboard
Event
Source
Queuing Port
Destination
Queuing Port
Module OS
I/O Driver
Destination
Sampling
Pseudo-Port
Source
Sampling Port
External
I/O Device
(Such as AFDX)
I/O Driver
External
I/O Device
(Polled Only)
Buffer
ARINC 653 Example Data Flows

Buffers
Buffers consist of queued messages
CREATE_BUFFER SEND_BUFFER
RECEIVE_BUFFER GET_BUFFER_ID
GET_BUFFER_STATUS

SEND _BUFFER
Process
2
Process
3
Process
1
GET_BUFFER_STATUS
Process
4
GET_BUFFER_ID
RECEIVE_BUFFER
SEND PROC
QUEUE
RCV PROC
QUEUE
Buffer
FIFO
Q

On a blackboard, a message is overwritten by the next message, or it can be cleared
Processes can queue for a message but process reads latest
version of data on blackboard
API
CREATE_BLACKBOARD CLEAR_ BLACKBOARD
GET_BLACKBOARD_STATUS READ_BLACKBOARD
GET_BLACKBOARD_ID DISPLAY_BLACKBOARD
Blackboards
Process
1
message
Blackboard
Process Queue
Process
2
Process
3
Process
4
DISPLAY
CLEAR
READ
GET STATUS

Semaphores and Events
Counting semaphores are used for synchronization
CREATE_SEMAPHORE WAIT_SEMAPHORE
SIGNAL_SEMAPHORE GET_SEMPAHORE_ID
GET_SEMAPHORE_STATUS

NOTE: ARINC semaphores DO NOT provide for priority inversion
protection

Events are used for notification of occurrence of
a condition
CREATE_EVENT SET_EVENT
RESET_EVENT WAIT_EVENT
GET_EVENT_ID GET_EVENT_STATUS


Inter Partition Communication API
Sampling ports
Overwrites previous message, fixed length, time stamped
Messages have a defined validity time after which the data is
considered stale
Example air data being supplied at a specified interval
After the validity of the data has expired, the
READ_SAMPLING_PORT will return the last data value but the
validity flag will be FALSE

API
CREATE_SAMPLING_PORT WRITE_SAMPLING_MESSAGE
READ_SAMPLING_MESSAGE GET_SAMPLING_PORT_ID
GET_SAMPLING_PORT_STATUS


Queuing Ports API
Queuing ports properties
Stored messages, variable length, FIFO or PRIORITY queuing.
API
CREATE_QUEUING_PORT
SEND_ QUEUING _MESSAGE
RECEIVE_ QUEUING _MESSAGE
GET_ QUEUING _PORT_ID
GET_ QUEUING _PORT_STATUS
CLEAR_QUEUING_PORT (Supplement 3)


Advanced ARINC Port Capability
VxWorks 653 provides fully compliant ARINC ports
Inter-partition (local) ports
Inter-module through use of pseudo-ports and VxWorks device drivers
All connections described in XML
Basic SAP (Part 2, Service Access Point) port capability
VxWorks 653 also provides enhanced port capabilities
Partition-level Pseudo-Ports
Completely resident within a partition
Transparent operation to applications
Connections described via XML
Direct Access Ports
Hard-coded connection to device driver
No message buffering
Typically faster but at the expense of portability and ARINC conformance
APEX Local Ports
Enable communication
between partitions
Connections are buffered
Connections configured via
XML
Connection can be one-to-
many; comprises:
One source
At least one destination
A channel
Slower than direct access
ports
Module OS
Configuration
Data
Partition OS Partition OS
Application Application
Port Port

Pseudo-Ports
Allow communication with other
targets over a physical
transport mechanism
E.g., AFDX network
Connections are buffered
Connections configured via
XML
Connections are one-to-many
Only one destination allowed
to be a pseudo port
Slower than direct access ports
Use standard VxWorks device
driver model
Module OS
Configuration
Data
Application
Partition OS
Port
Partition OS
Application
Port
Driver
Port

Direct Access Ports
Allow communication with other
targets over a physical
transport
No message buffering in the
Module OS
Faster than pseudo ports
Communication must be one-
to-one
Communication must be hard-
coded
Module OS
Configuration
Data
Partition OS
Application
Partition OS
Application
Port
Driver

Partition Pseudo-Ports
Partition pseudo ports are
direct access ports with a user-
mode driver
There is no message buffering
Faster than pseudo ports
Communication must be one-
to-one
Communication must be hard-
coded
Polling-mode only
Module OS
Configuration
Data
Partition OS Partition OS
Application Application
Port
Driver Driver
Port

Partition OS
Source Application
Sampling
Port API
Message
Queuing
Port API
Source Partition
Message
APEX Channels Memory Pool
Sampling Channel
Module OS
Queuing
Channel
Module 1
Partition OS
Destination Application
Queuing
Port API
Message
Sampling
Port API
Destination Partition
Message
APEX Local Ports - details

Partition OS
Source Application
Sampling
Port API
Message
Queuing
Port API
Source Partition
Message
Sampling
Channel
Module OS
Driver 1
Queuing
Channel
Device 1
Device 2
Driver 2
Module 1
Hardware
Device 2
Hardware
Device 1
Partition OS
Queuing
Port API
Message
Sampling
Port API
Message
Sampling
Channel
Module OS
Driver 1
Queuing
Channel
Device 2
Device 1
Driver 2
Module 2
Hardware
Device 2
Hardware
Device 1
Pseudo Port details, multiple drivers

Partition OS
Sampling
Port API
Message
Queuing
Port API
Message

Zero-Copy Mode
Virtual Channels
Module OS
Device Driver
Device 1 Device 2

Device

Module 2
Partition OS
Source Application
Sampling
Port API
Message
Queuing
Port API
Source Partition
Message

Device


Zero-Copy Mode
Virtual Channels
Module OS
Device Driver
Device 1 Device 2
Module 1
Pseudo Port details, common driver


Hierarchical Health Management
HM Framework supports ARINC 653 model
Process level controlled by the Application Suppliers
Partition level controlled by the System Integrator
Module level controlled by the Platform Supplier
HM framework provided with VxWorks 653 allows
developers to get started with minimal effort
Debug handlers provided to facilitate initial bring up and ease of use
Support for cold and warm restarts
Partition level
Module level
Partition and Module Health Management configured
using XML
Developers can easily add their own custom HM handlers
Health Monitoring API
CREATE_ERROR_HANDLER
Creates an error handler for the current partition
GET_ERROR_STATUS
Gets the error status of the first process in the error list
Used by the handler to get the current error information
RAISE_APPLICATION_ERROR
Invokes the error handler process for a specific error
Can be invoked to have the handler just report a message
Can only be called with the error APPLICATION_ERROR.
REPORT_APPLICATION_MESSAGE
Transmits a message to the HM function, typically to log maintenance
information

Health Monitoring Error Codes
These error codes are standard for ARINC 653:

DEADLINE_MISSED APPLICATION_ERROR
NUMERIC_ERROR ILLEGAL_REQUEST
STACK_OVERFLOW MEMORY_VIOLATION
HARDWARE_FAULT POWER_FAIL

XML Configuration of
VxWorks 653 Systems
DO-178B Qualified Development Tools

Wind River DO-178B Qualified
Development Tool Suite
XML schema
Heritage in ARINC 653 Supplement 1, re-organized for DO-297 role-based separation
Proposed for ARINC 653 Supplement 3
XML File Checker
Performs consistency checks to verify consistency of configuration
Qualified as a DO-178B verification tool
XML Compiler
Qualified as a DO-178B Level A development tool
No further test of binary configuration data or qualification required
XML Table Generator
Translates XML to human-readable tables, organized by role
Qualified as a DO-178B verification tool
Role-based build procedures
Result: Develop, configure, build, debug, test, re-test, and certify each
independent application independently, incrementally, and asynchronously


FMS
DO-297 Role Separation
Hardware Platform
XML Compiler/Checker
DO-178B Qualified Development Tool
Platform
Supplier
System
Integrator
XML Config
File
Binary Configuration Data
XML Config
File
XML
Config File
XML
Config File
XML Tables
XML
Config File
Application
Suppliers
XML Tables
XML Tables XML Tables
Nav
Display
XML Tables
XML Business
Rules

XML Configuration Key Benefits
For large, multi-application systems, saves millions of
dollars over the life of an IMA project
Process is scalable
Even small systems can benefit without excessive costs or
overhead
Immediately improves configuration quality
Certification requirements easier to state and review
Table-based, instead of C, complex database, or XML
Reduces reconfiguration / update time
Reduces time to market
DO-178B Qualified
Verification Tools


ACE: Agent for the Certification Environment
Provides host-to-target communication
For debug, test setup, and monitor data capture

Configurable in/out of target with no impact to
certification
Discrete signal assertion enables loading (BSP function)

Qualified as DO-178B verification tool per FAA 8110.49
Chapter 9
Both host and target sides

ACE: Agent for the Certification Environment
Platform with ACE loaded
Kernel
Mode
User
Mode
Module OS Memory Space
Hardware Board
ARINC 653
Partition OS
Flight Control
(FC)
Application

Level A
POSIX
Partition OS
VxWorks
Partition OS
Ada/J ava
Partition OS
Radar
Application

Level B
Graphics
Generator
Application

Level C
Display
Application

Level D
ACE
Module OS Memory Space
Hardware Board
ARINC 653
Partition OS
Flight Control
(FC)
Application

Level A
POSIX
Partition OS
VxWorks
Partition OS
Ada/J ava
Partition OS
Radar
Application

Level B
Graphics
Generator
Application

Level C
Display
Application

Level D
Platform without ACE loaded
Platform are identical, except for presence / absence of ACE

VxWorks 653 Monitoring Tools
Designed for providing support for debugging and test-
for-credit in the certification environment
Three monitors
CPU time
Memory utilization
ARINC ports
Key attributes
The tools fly: either enabled or disabled, but always present
Low overhead
Disabled tools burn the same time as enabled

VxWorks 653 Monitors
CPU time monitor
Module OS: Idle time, interrupt service time
Partition OS: Thread time: execution, idle; pseudo interrupt time;
partition time
Memory utilization monitor
Use of heap, stack, port memory, health monitoring log memory
ARINC port monitor
Like a bus monitor in a federated system
Start / stop, enable /disable each port
Actual port data can be streamed to the host

VxWorks 653 Target Monitors
Target-side monitors fly in deployed system
Requires ACE (Agent for the Certification Environment)
Allows retrieval of tool logs and information by the host
Partition-safe
DO-178B Level A Certification Evidence available
As software components of OS
Small number of instructions at each partition switch and
port operation
~10 instructions, << 1% overhead
Always executed
Monitor enabled: data collected in buffer
Monitor disabled: same instructions executed but data discarded

Summary: VxWorks 653 Platform
Industry-dominant ARINC 653 solution
Complete implementation of ARINC 653 specification
Powerful, multipartition debug / test / certification tools
Currently used in 180+ sub-systems, by 100+ customers,
for 40+ airframes
Portable, complete DO-178B Certification Evidence
2.9GB sealed DVD with DO-178B Level A certification evidence
Most complete Certification Evidence in the industry
Solves tough ARINC 653 IMA development
challenges
Performance, supplier independence, health management, certification,
middleware, debugging, more
DO-178B Network Stack for
VxWorks 653 Platform
Optional, add-on product for VxWorks 653 Platform


DO-178B Network Stack for VxWorks 653
Developed based on DO-178B Level A guidelines
DO-178B Level A Certification Evidence for DO-178B Network
Stack available for VxWorks 653 Platform releases
Check on Wind River Online Support (OLS) for the latest
information

Resides in the Module OS
Available in all partitions

Optional, add-on product for VxWorks 653 Platform

DO-178B Network Stack for VxWorks 653
Resides in the Module OS
Available in all partitions
Configuration support for combination of IPv4 with UDP and TCP
BSD-style sockets in IPv4 communications domain (AF_INET)
Broadcasting and subnetting support
RFC919, RFC922, RFC950
Architecture for IP Address Allocation with CIDR
RFC1518, RFC1519
TFTPv1 Remote access support: server and client
RFC783, RFC1350
Simple Network Time Protocol (SNTP) Version 2
For IPv4 RFC2030

Port Channel Mapping and the Stack
Example:
Using port channel mapping to
connect an ARINC port to a
socket
Uses pseudo ports and driver
to connect application to
network stack
Stack operates in polling
mode for determinism

Partition
Module OS
APEX
Application
ARINC Ports
Port
Driver
sendto() / recvfrom()
DO-178B Network Stack
SEND_QUEUING_MESSAGE()
RECEIVE_QUEUING_MESSAGE()
writeRtn() / readRtn()
Questions
For more information, contact:

Your Wind River local account team

Larry Kinnan
Principal Technologist, Avionics and Safety Critical Systems
Larry.Kinnan@WindRiver.com

02 VxWorks653

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

02 VxWorks653

Enviado por

Direitos autorais:

Formatos disponíveis

Integrated Modular Avionics

and ARINC 653 using

Você também pode gostar