ArticlePDF Available

ARINC 653 API and its application – An insight into Avionics System Case Study

Authors:

Abstract and Figures

Traditionally automated systems in aircraft were realised using well defined functions that are implemented as federated functional units. Each functional units possesses its own resources with fault containment compared to multiple functions in single processing node. Integrated architectures are structured over the avionics cabinets or processing cabinets which house the hardware modules and software application partitions along with system software. These integrated modular avionics (IMA) applications supports distributed multiprocessor architecture. Both time and memory is shared among multiple avionics functionalities across the same platform with good protection mechanisms provided by ARINC 653. ARINC 653 is an additional layer of protection being embedded as part of real time operating systems supporting the partitioning protections using well defined application executive, and application programming interfaces (API). IMA uses set of partitions, which are scheduled across a major frame M consisting set of partitions Ptn and each partition having set of task/process τn/Psn. The number of partitions and number of processes in each partition is a trade-off between the real time requirements and the resource. The paper also presents in brief, the API functionalities, its components, implementation, required interfaces, restrictions based on criticality of the avionics application. Error detection, control mechanisms for data integrity and validity for reconfiguration is also addressed. The experimental and simulation studies related to the API utilization as part of case study is addressed with four partitioned case study demonstrating the normal and failure scenario.
Content may be subject to copyright.
Received 30 October 2012, revised 08 February 2013, online published 23 March 2013
Defence Science Journal, Vol. 63, No. 2, March 2013, pp. 223-229
2013, DESIDOC
1. INTRODUCTION
The avionics architecture consisting of modules,
sub-systems and systems in aerospace domain is complex
hardware and software centric. Such architecture of
federated era was no doubt very good in terms of
fault containment, fault tolerance and was fool proof
architecture. However, it has many disadvantages of
having resources duplicated in each system in terms of
processing, memory and peripheral systems. Advantages
being excellent fault tolerant capabilities against the
disadvantage of duplication of resources and complexity.
Also such systems have disadvantages like increased weight,
redundant computer resources in each line replaceable
unit (LRU), higher looming volume, electrical interface
complexity and physical maintenance.
Growth in the aerospace industry encouraged the
avionics systems to utilise the increased processing
power, communication bandwidth and hosting of multiple
federated applications into a single integrated platform.
This has been realized as integrated modular avionics
(IMA). The IMA emerged as a platform for integrating
multiple avionics severity applications on a common shared
integrated computing environment1,2. Such system platform
is realizable with well integrated ARINC 653 based real
time operating system with time and memory partitioning
with application executive (APEX) libraries3.
IMA integration has the advantage of affordable
low recurring expenses for software updates or upgrades
without impacting the rest of the partitioned applications.
Application partitions are well protected with time and
memory protection mechanism provided by the underlying
real time operating system (RTOS) ARINC 653 standard
application executive.
In this paper it is attempted to bring a review of
the APEX APIs and their usage. Also addresses the
four partitioned application with data flow across all
the four partitions.
2 ARINC 653 BASED RTOS APEX
2.1 Importance of Time and Memory Partitioning
for Avionics Architectures
The ARINC 653 is one of the most critical specifications
for the integrated modular avionicss definition4, where
protection and functional separation between applications are
ensured with the use of partitions. This aims at enforcing
fault containment, preventing fault propagation from one
partition to another which eases the application’s life cycle
verification, validation and certification procedures. Also
this enables to host multiple applications with varying
DO 178B/C severity levels in different partitions.
Partitioning in IMA platform is quite critical and has
strong impact on the avionics architectures like federated
ARINC 653 API and its application – An insight into Avionics System Case Study
Ananda C.M.*, Sabitha Nair, and Mainak G.H.
CSIR-National Aerospace Laboratories, Bangalore–560 017, India
*E-mail: ananda_cm@nal.res.in
ABSTRACT
Traditionally automated systems in aircraft were realised using well dened functions that are implemented
as federated functional units. Each functional units possesses its own resources with fault containment compared
to multiple functions in single processing node. Integrated architectures are structured over the avionics cabinets
or processing cabinets which house the hardware modules and software application partitions along with system
software. These integrated modular avionics (IMA) applications supports distributed multiprocessor architecture. Both
time and memory is shared among multiple avionics functionalities across the same platform with good protection
mechanisms provided by ARINC 653. ARINC 653 is an additional layer of protection being embedded as part of
real time operating systems supporting the partitioning protections using well dened application executive, and
application programming interfaces (API). IMA uses set of partitions, which are scheduled across a major frame
M consisting set of partitions Ptn and each partition having set of task/process τn/Psn. The number of partitions and
number of processes in each partition is a trade-off between the real time requirements and the resource. The paper
also presents in brief, the API functionalities, its components, implementation, required interfaces, restrictions based
on criticality of the avionics application. Error detection, control mechanisms for data integrity and validity for
reconguration is also addressed. The experimental and simulation studies related to the API utilization as part of
case study is addressed with four partitioned case study demonstrating the normal and failure scenario.
Keywords: Integrated modular avionics, application programming interfaces, memory partition, application
executive
REVIEW PAPER
223
DEF. SCI. J., VOL. 63, NO. 2, MARCH 2013
224
and integrated. Traditionally avionics systems are more
functionality centric with dedicated algorithmic and
architectural methods for performance enhancement5. Avionics
architectures are classified as two major sectors
(a) Federated architectures
(b) Integrated architectures.
Transiting from federated architecture to integrated
architecture demands enormous effort with well defined
domain understanding and platform support6. ARINC 653
time and memory partitioning mechanism as provided
by supporting RTOS is very essential and mandatory.
Partitioning uses appropriate hardware and software
mechanism to restore strong fault containment to the
maximum extent in such integrated architecture7. Partition
can contain one or more application processes and each
process having attributes like
Period: Processes can be periodic or aperiodic.
Periodic process has fixed period defined between
successive releases of the process. Aperiodic processes
are set with a unique value to indicate that they
are not periodic and hence they do not have fixed
period.
Time capacity: Each process has fixed time for
execution and has a deadline by which time the
process should complete execution, which is a
constant value.
Priority: Each process has fixed priorities. This is
the base and current priority of the process, based
on the selection. The priority of the processes is
pre-fixed as part of static scheduling.
State: Process state can be dormant, ready, waiting or
running based on the actual execution condition.
Process state can be dormant, ready, waiting or running
based on the actual execution condition. With the above
discussions, it is mandatory that the partitioning in IMA
is critical and hence there is a guideline for partitioning
if not a contract rule. Jon Rushby7,8 ddefines and details
spatial and temporal partition as;
Spatial partitioning must ensure that software in one
partition cannot change the software or private data
of another partition (either in memory or in transit),
nor command the private devices or actuators of
other partitions.
Temporal partitioning must ensure that the service
received from shared resources by the software in
one partition cannot be affected by the software in
another partition. This includes the performance of
the resource concerned, as well as the rate, latency,
jitter, and duration of scheduled access to it.
With this partitioning system, the architectural difference
in terms of complexity, modularity, inter operability
and most important the recurring reduced efforts for
certification is highly motivating factor for aerospace
avionics system design and development.
Typical avionics architectures with and without
partitioning if realized looks like as shown in Figs. 1
and 2 for federated and Integrated respectively. Hence,
the partitioning system has tremendous potential in
realization of efficient and cost effective avionics suite
for civil aircraft requirements and in particular to gain
advantage of recurring efforts for application design,
and development.
The avionics application software is designed, developed
and certified to DO 178B9 with varying severity in each
partition as required based on the failure hazard analysis
(FHA), failure mode effect analysis (FMEA), and system
safety analysis (SSA)10.
Figure 1. Typical avionics federated architecture.
REDDY: APPROACHES TOWARDS IMPLEMENTATION OF MULTI-BIT DIGITAL RECEIVER USING FFT
225
3. ARINC 653 PLATFORM
Typical avionics systems are scheduled with major
frames. Each major frame has set of partition. Each
partition is grouped in to a set of processes, each having
modular sub-functionalities. As software components, each
process consists of set of low level functions called the
tasks as depicted in Fig. 3 and as in Eqn (1).
Figure 3 shows the set of partitions P, which are
scheduled across a major frame M consisting of a set of
partitions and each partition having a set of tasks/process.
In some applications, task and process are interchangeably
used, but it is better to use them separately under the
multi-process operating system.
Each task (Ps) =
{ }
1234 n
, , , ..........ττττ τ
is
single task)
Figure 4 shows the ARINC 653 multiple partitioned
block diagram showing the typical blocks with layered
interfaces from hardware up to the application. Application
software hosted on each partition has one or more
processes and these use the services provided by APEX
using set of ARINC653 primitives. Apart from application
partition, system partition also uses the services provided
by the core software layer and may or may not use the
Figure 2. Typical Integrated architecture based avionics suite.
Figure 3. Typical IMA partitioned schedule table with frames,
process and tasks.
Consider a major frame M having a set of partitions
Pti..Ptn based on functionalities as in Eqn (1). Each
partition Pti consists of a set of process Psi..Psn based on
the applications sub-functionalities. Each Psi consists set
of tasks 1.. τ2). The number of partitions and number
of processes in each partition is a trade-off to get the
real time response based on capabilities of the hardware
and software together. Normally the memory is statically
allocated for each partition.
Each major frame (M)=
{ }
123
4
, , , ........ n
ttttt
PPPPP
(1)
Each partition (Pt) =
{ }
123
4
, , , ........ n
sssss
PPPPP
Figure 4. Typical Multi partitioned ARINC 653 APEX
platform.
DEF. SCI. J., VOL. 63, NO. 2, MARCH 2013
226
APEX interface11. Operating system Kernel handles the
major services like process scheduling and management,
time and clock management as well as inter-process
synchronization and communication. Avionics functionality
in a given partition is strictly governed by the time and
memory partitioning mechanism and hence any faults
in that partition is contained inside the partition. This
is the strength and integrity of the ARINC 653 based
platform for fault containment.
The application executive (APEX) interface services
are mapped12 into
• TheRTOSkernelserviceslikeprocessmanagement,time
and clock management, inter-process synchronization
and communication.
• Thesystemspecificoperatingsystemandprocessor/
platform functions are like hardware interfacing,
device driver functions, facilities for application
downloading and support for BIT.
• ARINC 653 functions like partition management
and inter-partition communication.
3.1. Critical API’s for Reconfiguration of Task or a
Process
The APEX-Interface aims to provide services
for: Partition management, process management, time
management, intra-partition communication, inter-partition
communication, and health monitoring. The complete list
of APEX interfaces are detailed in the standard13.
Intra-partition communication and Inter-partition
communication in ARINC 653 platform is very critical
and enables the secured data flow inside and across the
partitions. Inter-partition communication uses sampling
port services and queuing port services via messages.
Intra-partition communication is for those communications
and synchronization across processes present inside the
partition. Intra-partition communication uses buffer services,
blackboard services. The processes can be of aperiodic
or periodic processes and is managed by APEX.
4. CASE STUDY WITH FOUR PARTITIONS
Attempt was made to experiment the time and memory
partitioned mechanism for four partitioned system using
VxWorks ARINC 653 environment.
The applications were implemented with task
reconfiguration capability in the event of limited failure
scenarios using reconfiguration algorithm14,15. Four partition
systems have been implemented with sixteen tasks in
each partition as shown in Fig. 5. These partitions are
scheduled to execute at a frame time of 25 ms and are
fixed priority static table driven schedule with time loading
of approximately 50%. The execution time of each task
in all four partitions was measured and is tabulated as
shown in Table 3. Process attribute table is created for
sixteen processes, and then processes are created with
CREATE_PROCESS service and started with START
service. Each partition is activated with NORMAL mode
using SET_PARTITION_MODE service. Later these
sixteen processes are called; time of execution of each
The CREATE_PROCESS service is used to create a
process with defined attributes and allocate resources for
it. Each process is created only once during the life of
the partition. Also, all the processes in a partition must be
defined in such a way that the necessary memory resources
for each process can be determined at system build time.
The field names in a PROCESS_ATTRIBUTE_TYPE
structure are very critical and are an argument to the
CREATE_PROCESS service. Field names are specified in
Table 1. The current priority of a process can by changed
dynamically through the SET_PRIORITY service.
Figure 5. Four partitioned avionics function.
Table 1. Attributes of PROCESS_ATTRIBUTE_TYPE
structure
NAME Stringidentierfortheprocess.It
must be unique within the partition.
ENTRY_POINT Starting address of the process.
STACK_SIZE Size (in bytes) of the stack allocated
to the process.
BASE_PRIORITY Process initial priority.
PERIOD Delay between two activations
TIME_CAPACITY The elapsed time within which the
process should complete its execution.
DEADLINE Type of deadline (SOFT, HARD, or
no deadline).
APEX partitions within an ARINC 653 module
communicate with each other using messages with the help
of ports and channels. Communication was established
in queuing mode with name, message size, message
range, port direction, queuing discipline and port id using
CREATE_QUEUING_PORT routine. Subsequently the
messages were sent in this specified queuing port using
SEND_QUEUING_MESSAGE service. When a partition
is created corresponding partition XML configuration file,
the application module and Core OS XML configuration
file are created. Memory for each application is specified
in application xml file which also consists of Entry Point,
Initialization time and period. Here, the port should
also be specified by the developer implicitly. The port
element in the configuration file will specify whether
the port is queuing or sampling along with the name,
process is captured using GET_TIME service.
REDDY: APPROACHES TOWARDS IMPLEMENTATION OF MULTI-BIT DIGITAL RECEIVER USING FFT
227
size, queuing length and protocol. Xml files for coreOS,
Applications, system partitions, schedules, connections
and health monitor tables are referred in the module xml
configuration file along with scheduling of partitions,
in short it deals with the entire configuration of the
project. It is possible to assign major and minor frame
for all partitions. In order to send messages through a
port, the source partition and the destination partition
are to be mentioned along with the respective port name.
This is in correspondence with the channel ID of module
configuration file.
Deadline time is the absolute time by which the
process should be complete. It starts as the return value
of the GET_TIME service (current system time) plus the
TIME_CAPACITY that is specified when the process is
created. Threads periodically evaluates deadline time to
determine whether the process is satisfactorily completing
its processing within the allotted time (time capacity).
Deadline time can be increased by issuing the REPLENISH
service. Various services for monitoring are
Status of the process is monitored using GET_
PROCESS_STATUS service
Process ID of calling process is read using GET_
MY_ID service.
Process ID any process with specified process name
is read using GET_PROCESS_ID service.
Process is started using START service and this
service will cause process to enter the READY
state.
In case study experimentation, each of the four
partitions with processes were enabled and started with
START service. The sequence of startup and execution
is captured and is shown in Fig. 6 for partition 1.
Similarly startup sequence has been verified for partition
2, partition 3, and partition 4, respectively.
The scaled time loading measurements carried out
using the System Time Viewer of VxWorks Workbench
is listed below for each partition. The real-time data for
each of the tasks in all four partitions were captured using
the debug ports of the real-time System-Viewer16.
Figure 6. Partition 1 startup.
Table 3. Time loading for each partition of schedule 1 and
schedule 2
Schedule Partitions Allotted time
(ms) Used time
(ms)
0
Partition 1 25 14.006
Partition 2 25 10.033
Partition 3 25 12.422
Partition 4 25 11.692
1
Partition 1 25 14.204
Partition 2 25 11.853
Partition 3 25 12.239
Partition 4 25 11.383
The time loading of each partition are 14.006 ms,
10.033 ms, 12.422 ms, and 11.692 ms respectively for
partition 1, partition 2, partition 3, and partition 4 as
shown in Table 3.
Figure 7. Time loading of partitions for two schedules.
Figure 7 shows the pictorial representation of the
four partitions as case study with each partition’s time
loading measurements and hence the total time for each
schedule. Consider a four partitioned system which
executes in two scheduled times. Each partition consists
of sixteen processes. In schedule 0 first four partitions
will execute and in schedule 1 next four partitions will
execute. Each partition is assigned with a partition
window of 25 ms as shown in Table 3 and hence major
frame time is 100 ms.
There are two types of inter partition communication
services: Sampling port services and queuing port services.
In queuing mode each message contains different data.
Table 2. Execution time of all tasks in each of the four
partitions
343.0675.0801.0111.0
907.0526.0700.0089.0
078.0395.2773.0995.0
745.0284.3318.0266.1
343.0675.0801.0111.0
907.0526.0700.0089.0
078.0395.2773.0995.0
745.0284.3318.0266.1
Partition 1 Partition 2
409.0105.0094.0760.0
468.0482.4068.1549.0
106.0850.0950.0093.0
050.2119.0636.0324.1
Partition 3 Partition 4
DEF. SCI. J., VOL. 63, NO. 2, MARCH 2013
228
Messages are queued and overwriting is not allowed so
no data’s are lost.
Messages will be there in source port until they
are send, and will be stored in destination port until
its read. Consider a two partitioned system with one
process each. Queuing ports are created in each partition
with CREATE_QUEUING_PORT service. Process1 in
partition1 will send data to queuing port using SEND_
QUEUING_MESSAGE service. Process 1 of Partition 2
will receive the data from queuing port using RECEIVE_
QUEUING_MESSAGE service. GET_QUEUING_PORT_ID
and GET_QUEUING_PORT_STATUS will return ID and
Status of the ports respectively. Fig. 8 shows the capture
of queuing port interfaces using the IDE toolset.
Figure 8. Queuing port implementation in the case study.
Figure 9. Typical partition execution with a task failure
(Test Case 2).
Figure 10. Typical failure scenarios considered in the case study
for various failure.
The System-Viewer is configured to display and
capture the required execution parameters on the terminal
window for real time monitoring. The result of time
loading for each of the four partitions proposed algorithm
functionality for different test cases is also captured
using system viewer. The case study also addresses the
failure test cases based on FHA/FMEA analysis.
Following is one sequence of failure test cases
experimented and the results were captured using system
viewer tool of VxWorks workbench.
Test Case 1: All four partitions functioning normally
with no fault
Test Case 2: Failure of task 12 in partition1 and
successful reconfiguration
Test Case 3: Failure of task 02 in partition2 and
successful reconfiguration
Test Case 4: Failure of task 09 in partition3 and
unsuccessful reconfiguration
Test Case 5: Failure of task 14 in partition4 and
successful reconfiguration
Fig. 9 shows the Test Case 2 failure simulation and
hence the reconfiguration of the task captured using real
time system viewer. More details on the control metrics,
their validation and reconfiguration scheme along with
the control metrics are available in Ananda17.
4.1 Control Metrics for Reconfiguration
The safety feature of the above implementation is
based on four control metrics for efficient functioning
of the applications in each partition. They are
a. Reconfigurability information factor (RI)
b. Schedulability test/TL/UF (TL)
c. Context adaptability and suitability (CAS)
d. Context flight safety (CFS)
These control metrics helps the application for
proper functioning in the event of any failure and its
reversionary action if applicable for continued availability
of the applications.
However, the data handled by these control metrics
need to be clear from errors and hence error detection,
correction and validation is the critical task for such
implementation17,18. Case study also takes into account
the various failure scenario of the system as shown
Fig. 10.
REDDY: APPROACHES TOWARDS IMPLEMENTATION OF MULTI-BIT DIGITAL RECEIVER USING FFT
229
5. CONCLUSION AND FUTURE WORK
Integrated modular avionics is well integrated with the
ARINC 653 compliant RTOS including APEX Libraries.
The APEX libraries play a very critical role in the safety
and reliability issues of the system particularly for multi
partitioned and multiple application requirements. ARINC
653 platform is the technology based for civil aircraft
avionics and other systems for hosting multiple applications
of different DO 178 severity levels on the same hardware
resource. The set of APEX APIs provide handy and easy
interface across the application and the underlying RTOS
enabling quick implementation of applications with all
the included capabilities of ARINC 653.
CSIR NAL is working on programs with ARINC 653
for avionics suite implementation for typical transport
category FAR 25 class of aircraft. The result of this
implementation is yet to be collected and is in the
process of integration tests.
ACKNOWLEDGMENT
Authors thanks Mr Shyam Chetty, Director NAL, Dr
MK Sridhar, Adv (M&A) and Mr KG Venkatanarayana,
Head ALD for their moral and management support.
Authors acknowledge the interactive support from ALD
Avionics and Wind River technical support teams.
REFERENCES
1. ARINC Specification 653-1. Avionics application
standard interface. Aeronautical Radio Inc Software,
October 2003.
2. ARINC Specification 651: Design guidance for
integrated modular avionics. Aeronautical Radio,
Inc, Annapolis, MD, November 1991. Prepared by
the Airlines Electronic Engineering Committee.
3. Audsley, Neil & Wellings, Andy. Analyzing APEX
applications. In the Proceedings of IEEE Real Time
Systems Symposium RTSS, 1052-8725/96 1996 IEEE,
pp 39-44.
4. D0 297: Integrated Modular Avionics (IMA) Development
Guidance and Certification Considerations.
5. Russell W. Duren, Waco, Algorithmic and architectural
methods for performance enhancement of avionics
systems. In the 28th Digital Avionics Systems Conference,
DASC 2009, pp. 1.D.4-1 – 1.D.1-6.
6. Watkins, C. & Walter, R. Transitioning from federated
avionics architectures to integrated modular avionics.
In the Proceedings of the 26th IEEE/AIAA Digital
Avionics Systems Conference (DASC 2007), Dallas,
TX, USA, Oct. 2007. pp. 2.A.1–1–2.A.1–10.
7. Rushby, John. Partitioning in avionics architectures:
Requirements, mechanisms and assurance. Computer
Science Laboratory, SRI International, FAA Technical
Center and NASA Langley Research Center through
contract NAS1-20334, and by DARPA and NSA
through Air Force Rome Laboratory Contract F30602-
96-C-0204. March 1999, pp. 1-68.
8. Rushby, John. Partitioning in avionics architectures:
Requirements, mechanisms and assurance. SRI
International, Menlo Park, California, NASA/CR-
1999-209347, June 1999. pp-1-68.
9. Software considerations in airborne systems and
equipment certification. RTCA/DO178B, RTCA Inc.,
Washington, DC, Dec 1992.
10. Analysis techniques for system reliability - Procedure
for failure mode and effects analysis (FMEA). IEC
60812, 1985.
11. Rufino, José & Filipe, Sérgio. AIR Project Final
Report, DI-FCUL, Report No.TR–07–35, Skysoft
Portugal & FCUL, Portugal, December 2007.
12. VxWorks 653 programmers Guide 2.3. www.windriver.
com/products/product.../PN_VE_653_Platform2_3_0410.
pdf. (Accessed on 12/08/2012)
13. ARINC. ARINC Specification 653-2: Avionics application
software standard interface, Part 1 - Required Services.
Aeronautical Radio INC, Maryland, US. 2005.
14. Ananda, C.M. Re-configurable avionics architecture
algorithm for embedded applications. In the IADIS
International Conference on Intelligent System and
Agents 2007, Lisbon Portugal, 2007, pp. 154-160.
15. Ananda, C.M. Improved availability and reliability
using reconfiguration algorithm for task or process
in a flight critical software. Edited by F.Saglietti and
N Oster. Spriner LNCS publication, Springer-Verlag
Berlin Heidelberg 2007, 2007, pp. 532-545.
16. Wind River Systems Inc, Wind River System Viewer
user’s guide, ver 4.7, 2005. http://www.windriver.com/
products/product-notes/PN_WB_1110.pdf (Accessed
on 12/08/2012)
17. Ananda, C.M. Reconfiguration of task in flight
critical system - Error detection and control. In the
28th Digital Avionics Systems Conference (DASC) on
Modernization of Avionics and ATM — Perspectives
from the Air and Ground. The Florida Conference
Center, Orlando, FL October 25 - 29, 2009, USA,
@IEEE, pp. 1.A.4-1–1.A.4.-10.
18. Ananda, C.M. Validation of control parameters
for a reconfigurable algorithm in a flight critical
avionics application. In the International Conference
on Aerospace Science and Technology (INCAST),
INCAST-013, Bangalore India, 26-28 June 2008.
pp. 310.1–310.6.
Contributor Shri C.M. Ananda obtained his Masters
degree in software systems from BITS,
Pilani in 2003. He is currently pursuing his
PhD in avionics. He is working at National
Aerospace Laboratories on embedded systems,
digital autopilot, engine instruments crew
alerting systems, and stall warning system
for SARAS aircraft. His areas of interest
are: Integrated modular avionics, flight
critical system, embedded distributed system, re-configurable
avionics architectures and safety critical software.
... Note that the MAF is a per-thread property; it is quite similar to the ARINC 653 standard used in industrial civil airplane[GNC13] designs, except that the ARINC 653 is a per-CPU property. ...
Preprint
The next generation of space systems will have to achieve more and more complex missions. In order to master the development cost and duration of such systems, an alternative to a manual design is to automatically synthesize the main parameters of the system. In this paper, we present an approach for the specific case of the scheduling of the flight control of a space launcher. The approach requires two successive steps: (1) the formalization of the problem to be solved in a parametric formal model and (2) the synthesis of the model parameters with a tool. We first describe the problem of the scheduling of a launcher flight control, then we show how this problem can be formalized with parametric stopwatch automata; we then present the results computed by the parametric timed model checker IMITATOR. We enhance our model by taking into consideration the time for switching context, and we compare the results to those obtained by other tools classically used in scheduling.
... In [1] requirements were formulated for a real-time operating system (RTOS) designed to work with integrated modular avionics. In particular, the RTOS should comply with the ARINC 653 standard [2]. The software used in aircraft must be certified in accordance to strict rules. ...
Article
The paper discusses details of the pilot display visualization that uses the hardware acceleration capabilities of the Vivante graphics processor in the JetOS aviation operating system. Previously the OpenGL Safety Critical library was implemented without hardware acceleration. This was done in such a way because software library is easier to certify in accordance with the avionics requirements. But usage of the software OpenGL does not provide acceptable visualization speed for modern Flight Display and 3D relief applications. So more complex visualization approach utilized the GPU acceleration capabilities was elaborated. Although the OpenGL library was implemented for a specific GPU and took into account its specificity, the described approach to adapt the MESA open source library can be used for other GPUs. An effective algorithm for multi-window visualization using the implemented library with hardware acceleration is present. The described approach allows you to achieve the visualization speed acceptable for the pilot display of the aircraft.
... Host real-time operating system is called Baget [1]. It provides different standards for developers: POSIX 1003.1 [2], ARINC 653 [3], C++11. All programs must be statically compiled in order to run. ...
... [Problem statement] Assigning tasks to partitions to enforce schedulability and security is an NP-hard combinatorial problem with 2 conflicting objective functions. Even with few partitions and tasks, it raises a combinatorial explosion as illustrated in [3], with only 4 partitions, each containing 16 tasks. It leads to numerous partitioning options which may have an impact on the schedulability. ...
Conference Paper
ARINC 653 introduces the concept of partition that allows time and space isolation in real-time avionic systems. Tasks are assigned to partitions according to various objective functions or constraints such as safety, performance, and security. Some of these objective functions may be conflicting as an improvement of one objective leads to a decrease of another. For example, improving safety by active redundancy may decrease performance. In this paper, we investigate the conflicting aspect between schedulability and security in Time and Space Partitioning (TSP) systems. Many researches have shown that enforcing the security of a system results in an overhead affecting its schedulability. We formulate a design space exploration (DSE) process with a meta-heuristic to explore solutions defined by the tasks to partitions assignment according to security requirements and timing constraints. Experiments are conducted with the Cheddar scheduling analyzer to characterize applications that are concerned by this conflicting issue and to evaluate the trade-offs between schedulability and security.
... In all current IMA research, however, the complexity of faulttolerated system functions remains in the development of application software. The IMA-platform itself provides RTOS-specific management units -such as partition, process, time, partition communication management and health [1,25,26], but safety-critical system function (e.g. according DAL A 3 ) requires redundant system peripherals (sensor, actuator, etc.) and partitions. Redundancy implies a complex management for the application software [46]. ...
Conference Paper
Full-text available
This article presents a demonstrator built to prove the operability of the selective integration of the Flexible Platform approach into Distributed Integrated Modular Avionics (DIMA). Safety-critical system functions rely on a complex system management. System management comprises of fault detection, redundancy management, and isolation of platform modules. Commonly, the system management causes the majority of the development and certification efforts. The currently established Integrated Modular Avionics and its succession Distributed Integrated Modular Avionics (DIMA) reduced the number of computers and the weight of the avionics system. Standardized OS and API provide independence between applications and underlying platform. Hence, multiple aircraft systems with different design assurance levels are hosted on a single IMA platform. However, it is currently mandatory to realize the system management individually in each system application. This significantly increases the development, test and certification effort, even if the basic system function is just a simple one. The Flexible Platform developed at the Institute of Aircraft Systems at the University of Stuttgart provides comprehensive system management mechanisms as generic software. With an additional abstraction layer, safety-critical applications are developed as simplex-minded system functions. A knowledge-based toolchain automatically derives the instance of the Flexible Platform. With model transformations, most artefacts of the system development process are generated up to auto-verification and documentation. However, the current Flexible Platform requires the full control on hardware and operating system. Considering IMA, a selective use of the Flexible Platform features on IMA is under development, which integrates seamlessly into the IMA development process. IMA applications that want to benefit from the Flexible Platform, comprise of the simplex-minded function and a fully generated safety-critical platform management middleware (PLAMA). Both are combined in one partition. A Service Provisioning Layer (SPL) facilitates ARINC 653 compatibility. In addition, Interfaces Control Documents (ICDs) to configure the IMA-modules are generated automatically via ICD-Generators from the Flexible Platform high-level specification model. For the verification of the Flexible IMA Platform, a demonstrator with industrial IMA modules, OS and tools as well as significant demonstration scenarios are required. Therefore, a lab demonstrator of a small redundant DIMA architecture was built with multiple Common Remote Data Concentrators (CRDC), Core Processing Modules (CPM), Actuator Control Modules (ACM), and AFDX networks. A test system is configured and connected to the demonstrator. It emulates all peripheral devices, such as redundant sensors or actuators and flight mechanical models. Manipulating and monitoring tools are inserted to make the inside of Flexible Platform applications visible and traceable. The demonstrator is thereby capable to run legacy IMA-applications and applications that are using the Flexible IMA Platform in form of a hardware-in-the-loop (HiL) simulation. The overall demonstration scope consists of the integration of two system functions. The first function is a High Lift System (HLS) function similar to the A320-HLS developed with the new Flexible IMA Platform approach. The second system function is an existing legacy application consisting of traditional A653-partitions and configuration files. In addition, nine demonstration scenarios are defined that verify, for instance, full compatibility to the IMA API; a safe operation with IMA partitions and the asynchronous AFDX; simplex-minded function development; and a seamless integration into the IMA process and tool workflow. As a results we have a lab demonstrator, supporting equipment, and precise demonstration scenarios that can fully verify the Flexible IMA Platform approach.
Chapter
With the development of embedded technology, more and more security critical tasks appeared in embedded application fields, which requires higher real-time and reliability of the system. ARINC 653 standard proposed the concept of partition, and improves the security and reliability of the system in the system kernel aspect. Time-window and priority strategy are the primary methods in task scheduling, but there are many shortcomings in the traditional partition window time zoning. The smaller window requires higher switch frequency, the larger window will result unexpected time segments. In order to solve the problems above, this paper proposes a dynamic cycle execution time (DCET) scheduling algorithm. The algorithm can prevent task in low level key partition preempting the task in high level key partition. Make use of free time segments to execute the task, thus improve the efficiency of the system. At last, a partition environment was built by μC/OS-II on the ML507 development board, and the experimental result confirms the effectiveness of the algorithm.
Conference Paper
The safety and security of kernel is the key to the security of the embedded system and we even have to formal verification the kernel in the field of safety-critical embedded applications. In this paper we introduce a design and implementation of the modeling of micro kernel based on spatial-temporal isolation in Haskell which is a functional language. This not only could significantly improve the security of micro kernel, but also facilitate the formal verification of micro kernel in the later.
Article
Full-text available
The paper presents a new method for re-configuration of tasks or a process in an embedded avionics application. The13; proposed algorithm works based on four control parameters: re-configurability Information factor, Schedulability13; Test/TL/UF, Context Adaptability/suitability and Context Flight Safety. The algorithm is data centric and interfaces13; system health as control input and initiation of the re-configuration is only after successful evaluation of the parameter metrics. It enhances the availability and reliability of the system under failed conditions by efficient selection and procedural re-configuration with safe state exit. The advantage of the new approach over the non-configurable systems is the increased availability of flight critical applications under failed conditions. It also preserves the advantages of non-Reconfigurable systems over federated architecture. Invalid failure of control parameter brings the system to safe state. The scheme, algorithm and the control parameters metrics and their validation approach are described. The algorithm is13; novel in terms of dynamic re-configuration compared to existing static avionics architecture
Conference Paper
Many studies on managing obsolescence and refreshing technology concentrate on replacing hardware to improve the performance of legacy systems. In contrast, the author's research has concentrated on the development of methods that can significantly enhance the performance of legacy systems while requiring few or no hardware modifications. If hardware replacement is allowed, these methods can be leveraged to further improve the upgraded systems. The methods can be characterized either as algorithmic or architectural methods. Algorithmic methods include techniques such as new data compression routines. A previous paper by the author and a fellow researcher has presented data compression routines that are suitable for implementation on legacy MIL-STD-1553 data buses. As expected, these routines where shown to increase the communication throughput. What may be less obvious is that they also increased the time available to perform computation. Architectural techniques include repartitioning of software functions and/or communications to free system resources. This paper presents these and other methods for increasing the performance of legacy avionics systems. The same techniques can also be applied to improve the design of new systems.
Conference Paper
Traditionally in avionics, Federated Architecture (FA) is used where each function has its own independent, dedicated fault-tolerant computing resources. FA though has the advantage of inherent fault containment but envelops a potential risk of massive use of resources resulting in increase in weight, increase in looming, cost and maintenance. Integrated Modular Avionics architecture (IMA) is successful, as it has an efficient and effective management of hardware and software computing. Most of the applications designed on IMA currently do not have dynamic reconfiguration. The paper presents a new method for re-configuration of tasks or a process in an embedded avionics application. The proposed algorithm works based on four control parameters: re-configurability Information factor, Schedulability Test/TL/UF, Context Adaptability/suitability and Context Flight Safety. The algorithm is data centric and interfaces system health as control input and initiation of the re-configuration is only after successful evaluation of the parameter metrics. It enhances the availability and reliability of the system under failed conditions by efficient selection and procedural reconfiguration with safe state exit. The advantage of the new approach over the nonconfigurable systems is the increased availability of flight critical applications under failed conditions. It also preserves the advantages of non-Reconfigurable systems over federated architecture. Invalid failure of control parameter brings the system to safe state. The scheme, algorithm and the control parameters metrics and their validation approach are described. The algorithm provides very good availability of the system even under failures.
Conference Paper
Traditionally in avionics, Federated Architecture (FA) is used where each function has its own independent, dedicated fault-tolerant computing resources. FA though has the advantage of inherent fault containment but envelops a potential risk of massive use of resources resulting in increase in weight, increase in looming, cost and maintenance. Integrated Modular Avionics architecture (IMA) is successful, as it has an efficient and effective management of hardware and software computing. Most of the applications designed on IMA currently do not have dynamic reconfiguration. The paper presents a new method for re-configuration of tasks or a process in an embedded avionics application. The proposed algorithm works based on four control parameters: re-configurability Information factor, Schedulability Test/TL/UF, Context Adaptability/suitability and Context Flight Safety. The algorithm is data centric and interfaces system health as control input and initiation of the re-configuration is only after successful evaluation of the parameter metrics. It enhances the availability and reliability of the system under failed conditions by efficient selection and procedural re-configuration with safe state exit. The advantage of the new approach over the non-configurable systems is the increased availability of flight critical applications under failed conditions. It also preserves the advantages of non-Reconfigurable systems over federated architecture. Invalid failure of control parameter brings the system to safe state. The scheme, algorithm and the control parameters metrics and their validation approach are described. The algorithm provides very good availability of the system even under failures.
Conference Paper
This paper identifies considerations for transitioning from a federated avionics architecture to an integrated modular avionics (IMA) architecture. Federated avionics architectures make use of distributed avionics functions that are packaged as self-contained units (LRUs and LRMs). IMA architectures employ a high-integrity, partitioned environment that hosts multiple avionics functions of different criticalities on a shared computing platform. This provides for weight and power savings since computing resources can be used more efficiently. This paper establishes the benefits of transitioning to IMA. To aid in the planning process, the paper also identifies factors to consider before transitioning to IMA. The approach to resource management (computing, communication, and I/O) is identified as the fundamental architectural difference between federated and IMA systems. The paper describes how this difference changes the development process and benefits the systems integrator. This paper also addresses misconceptions about the resource management mechanisms that can occur during a transition to IMA and concludes that resources are not inherently constrained by IMA architectures. Guidance is provided for transitioning to both "open" and "closed" IMA architectures. Open IMA architectures utilize open interface standards that are available in the public domain. Closed IMA architectures utilize proprietary interfaces that can be customized. The analysis of these avionics architectures is based upon the authors' experience in developing platform computing systems at GE Aviation. GE Aviation has developed open system IMA architectures for commercial aircraft (Boeing 787 Dreamliner), as well as military aircraft (Boeing C-130 combat aircraft, and Boeing KC-767 Tanker).
Conference Paper
The next generation of civil aircraft may be produced using Integrated Modular Avionics (IMA). A component of IMA is APEX, a standard operating system interface. This supports a two-level scheduling scheme consisting of fixed priority scheduling within a statically generated cyclic schedule. This paper illustrates how APEX applications can be analysed for their response times and shows that there is potential for a large amount of release jitter
Article
This report examines the requirements for partitioning, mechanisms for their realization, and issues in providing
Partitioning in avionics architectures: Requirements, mechanisms and assurance Computer Science Laboratory, SRI International, FAA Technical Center and NASA Langley Research Center through contract NAS1-20334, and by DARPA and NSA through Air Force Rome Laboratory Contract F30602- 96-C-0204
  • John Rushby
Rushby, John. Partitioning in avionics architectures: Requirements, mechanisms and assurance. Computer Science Laboratory, SRI International, FAA Technical Center and NASA Langley Research Center through contract NAS1-20334, and by DARPA and NSA through Air Force Rome Laboratory Contract F30602- 96-C-0204. March 1999, pp. 1-68.
Reconfiguration of task in flight critical system-Error detection and control
  • C M Ananda
Ananda, C.M. Reconfiguration of task in flight critical system-Error detection and control. In the 28 th Digital Avionics Systems Conference (DASC) on Modernization of Avionics and ATM-Perspectives from the Air and Ground. The Florida Conference Center, Orlando, FL October 25-29, 2009, USA, @IEEE, pp. 1.A.4-1-1.A.4.-10.
Validation of control parameters for a reconfigurable algorithm in a flight critical avionics application
  • C M Ananda
Ananda, C.M. Validation of control parameters for a reconfigurable algorithm in a flight critical avionics application. In the International Conference on Aerospace Science and Technology (INCAST), INCAST-013, Bangalore India, 26-28 June 2008. pp. 310.1-310.6.