e-Informatica Software Engineering Journal, Volume 5, Issue 1, 2011, pages: 39–49, DOI 10.2478/v10233-011-0029-x

ARINC Specification 653 Based Real-TimeSoftware Engineering

Sławomir Samolej∗∗Faculty of Electrical and Computer Engineering, Rzeszow University of Technology

ssamolej@prz.edu.pl

AbstractThis paper reports successive steps of a real-time avionic pitch control application creation. Theapplication structure follows a new real-time systems development profile published in ARINCspecification 653. The paper mentions some main ARINC specification 653 features and showsthe subsequent application creation levels: control system units distribution, timing requirementsdefinition, application implementation and tests. It describes the author’s experience gained duringan avionic hard real-time system development and focuses on real-time software engineering detailsof the application creation.

1. Introduction

Real-time applications gradually evolve formsimple one-task embedded programs to largemulti-task and distributed systems. Modernlarge real-time applications are usually based onreal-time operating systems (such as VxWorks[1], PikeOS [2], LynksOS [3], WindowsCE [4],and Linux RTAI [5]), or are written in real-timelanguages (Ada 2005 [6] or Spakr [7]). Theseapplications should be developed according towell defined practical rules expressed e.g. in [8, 9].Real-time tasks are given priorities according toa predictable policy (such as Rate Monotonicor Deadline Monotonic Policies). Inter-task com-munication protocols prevent the system fromdeadlocks and unpredictable delays during exe-cution (by Priority Inheritance or, if possible, byPriority Ceiling Resource Access Protocol appli-cation). The data exchange between distributedapplications should be predictable. Naturally,such rules can be applied in modern real-time op-erating systems APIs or in Ada language, but lessadvanced developers often encounter problems,especially in case of complex software.

To make the real-time system developmentless cumbersome, several groups of experts havedeveloped some practically applicable real-timedesign patterns. Among the set of well de-fined code-generation oriented design patternsthe POSIX standard [10], HOOD [11] andHRT-HOOD [12] methods and Ada Raven-scar Profile [13] can be indicated. They definegood real-time system programming techniquesand are partly supported by some automaticreal-time software code generators. Subsequently,the real-time design patterns have been inte-grated with dedicated software toolkits such asMatlab-Simulink [14], SCADE SUITE [15] orIBM Rational Rose RealTime [16]. These toolsallow to design graphically the real-time software,giving as the output a real-time system structure(IBM Rational Rose), both structure and selectedalgorithms implementation (SCADE SUITE),or complete real-time application code and en-vironment generated for a specific hardware(Matlab-Simulink). Moreover, SCADE SUITEenables to develop a complete hard real-time sys-tem source code that conforms to internationalsafety standards DO-178B (up to level A for

c© Copyright by Wrocław University of Technology, Wrocław 2011

40 Sławomir Samolej

Military and Aerospace Industries), IEC 61508(at SIL 3 by TÜV for Heavy Equipment, andEnergy), EN 50128 (at SIL 3/4 by TÜV for RailTransportation), and IEC 60880 (for NuclearEnergy).

It is also worth noting that internationalstandardization organizations have recently pub-lished some new standards or specifications re-garding modern real-time systems development.The ARINC (AERONAUTICAL RADIO, INC)specification 653 [17] or the SAE (Society of Au-tomotive Engineers) Standard AS5506 [18] areexamples of such documents. To the author’sopinion the new documents bring a new qualityin real-time systems development. They providea new abstraction layer in the real-time soft-ware design process which makes possible to cre-ate complete large distributed real-time systems.This paper deals with the ARINC specification653 (ARINC 653) based hard real-time systemsdevelopment.

The ARINC 653 was developed by aviationexperts to provide “the baseline environmentfor application software used within IntegratedModular Avionics (IMA) and traditional ARINC700-series avionics”. It is closely connected withthe Integrated Modular Avionics (IMA) concept[19, 20, 21]. Primary objective is to define a gen-eral purpose APEX (APplication/EXecutive) in-terface between Operating System (O/S) of theavionics computer and application software.Thespecification includes interface requirements be-tween application software and O/S and list ofservices which allow the application software tocontrol scheduling, communication, and status ofinternal processing elements. Over a period of 6years from the specification announcement:– the ARINC 653 based software has been imple-

mented in A380, A400M and B787 airliners,– at least three commercial real-time op-

erating systems (WxWorks 653, PikeOS,LynksOS-178 RTOS) have been updated tooffer the APEX,

– four European-founded and focused on theARINC 653 – based software developmentresearch projects (PAMELA, NEVADA, VIC-TORIA and SCARLETT) have been created.

This paper describes some details concerningreal-time programming rules included in AR-INC 653. A Pitch Control Application createdwithin SCARLETT [22] project by ResearchGroup from Rzeszów University of Technology(RGRUT) illustrates the ARINC 653 based de-velopment process. The following sections areorganized as follows. At first, the ARINC 653is introduced. Secondly, the Pitch Control Ap-plication development is presented. The finalpart describes the future RGRUT’s research andimplementation plans.

2. ARINC specification 653

Airborne real-time systems have been evolvingfrom the so-called “federated” structure to Inte-grated Module Avionics (IMA) [19, 20, 21]. TheIMA concept has been introduced in Europeanfunded research projects, PAMELA, NEVADAand VICTORIA. The result of the projects wasthe first generation of IMA (IMA1G), currentlyon-board of A380, A400M and B787 aircraft.Following the IMA concept, modern on-boardavionic subsystems (software applications) aregrouped in a limited set of standard micropro-cessor units. The units and other electronic de-vices communicate via standard network inter-face – Avionics Full Duplex Switched Ether-net (AFDX) [23, 24]. The group of federatedapplications executed until now on separatemicroprocessor units (and communicating bymeans of ARINC standard 429 based devices[25], for example) must become a set of real-timeprocesses executed on one hardware module.This module will be managed by a dedicatedreal-time operating system. Provided that theoperating system offers a standard API and ful-fills safety requirements, such solution signifi-cantly broadens portability of avionic applica-tions and allows to develop and certify hard-ware and software independently. Current im-plementation of IMA covers limited range ofaircraft functions but shows some significantbenefits, i.e. aircraft weight reduction and lowermaintenance costs.

ARINC Specification 653 Based Real-Time Software Engineering 41

2.1. Partitions

The IMA assumes that a set of time-criticaland safety-critical real-time applications (avion-ics units) may be executed on one microprocessormodule. To cope with this level of criticality, newreal-time operating system architecture has beensuggested. ARINC 653 [17] defines generic struc-ture of the system. Figure 1 shows the logicalstructure of RTOS suggested in it.

The key concept introduced in the specifica-tion is the partition. It creates a kind of con-tainer for an application and guarantees thatexecution of the application is both spatially andtemporally isolated. The partitions are dividedinto two categories, application partition and sys-tem partition. The application partitions executeavionics applications. They exchange data withthe environment by means of specific interface– APEX (APplication/EXecutive). The systempartitions are optional and their main role is toprovide services not available in APEX, such asdevice drivers or fault management.

2.2. Hardware-Software ModuleArchitecture

The ARINC 653 also includes some recommenda-tions on microprocessor module architecture forthe dedicated real-time operating system. Gen-eral diagram of the architecture is presented infigure 2. Each module includes one or more mi-croprocessors. The hardware structure may re-quire some modification of core operating systembut not the APEX interface. All processes thatbelong to one application partition (real-timetasks) must be executed on one microproces-sor. It is forbidden to allocate them to differ-ent microprocessors within the module or splitthem between modules. The application programshould be portable between processors withinthe module and between modules without anymodifications of the interface to operating sys-tem core. Processes that belong to one parti-tion may be executed concurrently. A separatepartition-level scheduling algorithm is responsi-ble for this. Inter-application (partition) commu-nication is based on the concept of ports and

channels. The applications do not have the infor-mation at which partition the receiver of data isexecuted. They send and receive data via ports.The ports are virtually connected by channelsdefined at separate level of system development.

Temporal isolation of each partition has beendefined as follows. A major time frame, activatedperiodically, is defined for each module. Eachpartition receives one or more time partitionwindows to be executed within this major timeframe. Generally, time partition windows consti-tute a static cyclic executive [9]. Real-time tasksexecuted within the partition can be scheduledlocally according to priority-based policy. Theorder of the partition windows is defined in aseparate configuration record of the system.

Health Monitor (HM) is an important ele-ment of the module. HM is an operating systemcomponent that monitors hardware, operatingsystem and application faults and failures. Itsmain task is to isolate faults and prevent failurepropagation. For example, the HM can restart apartition when detects application fault.

By assumption, the applications (or parti-tions) may be developed by different providers.Therefore an integrator of the IMA system de-velopment process is necessary. This person col-lects data regarding resources, timing constraints,communication ports and exceptions defined ineach partition. The collected data are transferredinto configuration records. The configurationrecord for each module is an XML documentinterpreted during compilation and consolidationof software.

2.3. APEX Interface

APEX (APplication/EXecutive) interface defini-tion is the main part of ARINC 653. The APEXspecifies how to create platform-independent soft-ware that fulfills ARINC 653 requirements. Maincomponents of the interface are:– partition management,– process management,– time management,– memory management,– interpartition communication,– intrapartition communication,

42 Sławomir Samolej

Figure 1. Logical real-time operating system structure created according to ARINC specification 653 ([17],pp. 4).

– health monitoring.The APEX interface provides separate set of

functions enabling the user to determine actualpartition mode and change it. The applicationmay start the partition after creation of all appli-cation components. It is also able to obtain thecurrent partition execution status. Interpartitionhealth monitoring procedures can stop or restartthe partition.

The application may be constructed as a setof (soft or hard) real-time processes, scheduledaccording to priorities. APEX process manage-ment services can:– create process and collect process status or

ID,– start, stop, suspend or resume process,– prevent from process preemption,– change the process priority.

The APEX manages both aperiodic and pe-riodic processes. Periodic processes are activatedregularly. Additionally, a separate parametercalled “time capacity” is attached to each ofthem. It defines time frame (deadline) withinwhich single instance of task must finish compu-tations. When a process is started the deadline

is set to current time plus time capacity. Theoperating system periodically checks whether theprocess completes processing within the allottedtime. Each process has a priority. During anyrescheduling event the O/S always selects for theexecution the highest priority process in “ready”state.

There are no memory management servicesin APEX because partitions and associated mem-ory spaces are defined during system configura-tion. The ARINC 653 assumes, for safety reasons,that the whole memory is statically allocated topartitions and processes before the partition orapplication starts. It is expected that memoryspace is checked either at build time or beforerunning the first application.

Interpartition (inter-application) communi-cation is based on queuing port and samplingport communication units. The queuing portprovides interpartition message queue, whereasthe sampling port shares variables between theports. During system integration, the ports areconnected by means of channels defined in sys-tem configuration tables. The ports communicatewith other partitions or device drivers within the

ARINC Specification 653 Based Real-Time Software Engineering 43

Figure 2. Hardware-software architecture of typical module according to ARINC 653 specification ([17], pp.11).

module, or exchange data between modules (bymeans of AFDX network interfaces).

The synchronization of processes belonging toone partition may be achieved by appropriate ap-plication of counting semaphores and events. Theinter-process communication within the partition(intrapartition communication) is implementedby means of APEX buffers (shared messagequeues) and APEX blackboards (shared vari-ables). It is possible to define a time-out withinwhich process waits for the data, if not availableimmediately. The process may be blocked for thespecified time only.

The ARINC 653 Health Monitor is an ad-vanced exception handing engine. Three errorlevels are defined:– Process Level which affects one or more pro-

cesses in the partition,– Partition Level with only one partition af-

fected,– Module Level which affects all partitions

within the module.Both Partition Level and Module Level errorsare handled by a set of procedures installed by

the system integrator. The Process Level errorscan be handled by the programmer. Separatesporadic task called “error handler” can be regis-tered for each of the partitions. When the HealthMonitor detects an error at the process level itcalls the error handler. The handler recognizesthe error and, depending on the error, can:– log it,– stop or restart the failed process,– stop or restart the entire partition,– invoke the registered error handler process

for the specific error code.To the author’s knowledge four real-time op-

erating systems meet ARINC 653 requirements,i.e. Wind River VxWorks 653 [1], Sysgo PikeOS[2], LynuxWorks LynxOS-178 RTOS, and Lynux-Works LynxOS-SE RTOS [3].

3. ARINC 653 based Pitch ControlSystem Development

This section describes an ARINC 653 based sam-ple avionics subsystem development. The objec-

44 Sławomir Samolej

tive is to create a distributed hard real-timeapplication to control a pitch angle of typicalairliner (Pitch Control Application – PCA). Sub-sequent development steps are: control systemdefinition, control procedures allocation to hard-ware units, timing requirements assessment, ap-plication structure design, system programming,testing. Preliminary version of the PCA has beenproposed in [26]. Papers [27] and [28] report onstages of PCA development and some extensionsto detect control system malfunctions.

3.1. Control System Definition

The system controls two actuators (brushlessmotors) connected to a load (elevator). Eachactuator is controlled by separate cascade of con-trollers shown in figure 3. The single actuatorcontrol system includes internal current controlloop, velocity control loop (PID2, PID4), and po-sition control loop (PID1, PID3). The Flight Con-trol Algorithm (FCA) is a supervisory modulethat generates position demand signal for bothactuator control subsystems. It collects signalsfrom the pilot, aircraft, and actuators. The refer-ence signal is a force or shift of control side-stickmoved by the pilot. The FCA module correctsthe reference signal using the actual aircraft pitchangle. The PCA includes also Error Estimatorthat collects some control signals and estimatesquality of control system during runtime. It alsoproduces separate output for system operator.The entire Pitch Control Application has beenmodeled in Matlab-Simulink [14] software toolkit.All control procedures and settings have beendesigned following control engineering rules.

3.2. Distribution of Control Procedures

The Pitch Control Application has been devel-oped according to a set of restrictions formulatedby the system integrator. One of the restrictionsrequires selected control procedures to be allo-cated on different hardware modules. Figure 4illustrates the desired PCA control modules allo-cation. Hardware Module 1 (HM1) includes theFCA, Error Estimator and position controllers(PID1 and PID3, compare fig. 3). Hardware Mod-

ules 2 and 3 (HM2 and HM3) include velocitycontrollers (PID2 and PID4, compare fig. 3). Thenext restriction is that the FCA, Error Estimatorand all the PID controllers should be softwaremodules whereas the current controllers must beincluded into motor drives hardware. The hard-ware modules are connected via AFDX network.The network structure has also been imposed bythe system integrator.

According to the requirements thehardware-software environment follows the IMAphilosophy. Therefore the FCA and Error Es-timator control blocks belong to one ARINC653 based application partition, as two separatereal-time tasks. All PID controllers are separatereal-time tasks each of which belongs to separateapplication partition. The partition structurephysically and temporally isolates the maincontrol application subsystems. It also enablesreallocation of PID control procedures betweenhardware modules, what is another applicationrequirement.

3.3. Timing Requirements

The Pitch Control Application has been devel-oped to fulfil the ARINC 653 real-time param-eters shown in figure 5 and table 1. The timecapacity (deadlines) and task periods have beenchosen taking into account both actuator dynam-ics and computing power of hardware units. Thepartition including the FCA and Error Estima-tor periodic real-time task acquires 6 [ms] timeslot and 20 [ms] deadline. It is executed in two3-millisecond time frames (fig. 5). The partitionswith PID1 and PID3 control procedures are ac-tivated every 5 [ms] and executed within 1 [ms]time frame. Similarly, PID2 and PID4 real-timetasks are activated every 5 [ms], but their dead-lines are extended to 2[ms] since Hardware Mod-ules 2 and 3 provide lower computing power thanHardware Module 1. The major time frames infigure 5 include some “System” slots. These slotsmay be used by other software modules loadedon hardware. The HARD attribute attached toeach of the real-time tasks instructs the HealthMonitor (built into the operating system) thatif any task misses its deadline, the core operat-

ARINC Specification 653 Based Real-Time Software Engineering 45

Figure 3. Pitch control system architecture

Figure 4. Allocation of Pitch Control System procedures on the Hardware Units

ing system must be informed. In consequence,this forces the operating system to take appro-priate action. The Health Monitor proceduresmay even reload the whole partition that missestiming constraints. It has been assumed that themaximum communication delay in the AFDXnetwork should not exceed 7 [ms].

All of the algorithms applied in the PCA areeither controllers or simplified numerical proce-dures which solve some differential equations.During the development the worst case comput-

ing time for each of the algorithm has been eval-uated. Experimental checks have proved that thealgorithms meet their timing constraints.

As mentioned before, the PCA timing restric-tions have been provided by control engineers whospecified the system. P2 and P3 partitions acquire1 [ms] time frames for computations and are ac-tivated every 5 [ms]. This guarantees sufficientfrequency (200Hz) of PID algorithm repetition,so sufficient quality of control. P1 partition is 4times “slower” than others without adverse effect

46 Sławomir Samolej

Figure 5. PCA timing requirements

Table 1. PCA real-time tasks parameters

Control Procedure Stack Size Base Priority Period Time Capacity DeadlineFCA 4096 18 20 20 HARD

Error Estimator 4096 17 20 20 HARDPID1 4096 20 5 1 HARDPID3 4096 20 5 1 HARDPID2 4096 20 5 2 HARDPID4 4096 20 5 2 HARD

on quality of control. This preserves some com-putational time for other applications installedon the same hardware module.

3.4. Application Structure

The Pith Control Application structure is shownin figure 6. Apart from control procedures allo-cation strategy of figure 4, figure 6 shows thepartitions and the intra- and interpartition com-munication structure. The first (P1) partitionloaded into the Hardware Module 1 includes tworeal-time tasks, the Flight Control Algorithm(FCA) and Error Estimator. The FCA task col-lects signals from Pilot, Aircraft and actuator

modules and produces the desired pitch anglesignals for position controllers (PID1, PID3).The Error Estimator monitors both communi-cation channels and quality of control duringruntime. The algorithms applied in the ErrorEstimator have been presented in [27, 28]. Thesecond (P2) partition includes the first posi-tion controller algorithm (PID1), running asseparate real-time task. Identically, the third(P3) partition includes the second position con-trol algorithm (PID3). The fourth (System Par-tition) collects all signals exchanged betweenhardware modules and transfers them to theAFDX network. The Hardware modules 2 and3 have the same hardware-software structure.

ARINC Specification 653 Based Real-Time Software Engineering 47

They include one system partition and one ap-plication partition. The application partitions(P4 and P5) involve single real-time tasks withspeed control PID algorithm. The system parti-tions provide inter-hardware module communi-cation.

For the intrapartition communication, AR-INC 653 blackboards have been applied, whereasthe interpartition communication is based onARINC 653 sampling ports and channels. Black-boards and sampling ports seem most suitablecommunication units for the system, since theyare in fact shared and protected data regions.They always provide the latest acquired data.It is possible to set their properties in such amanner that they do not block the real-timetasks, even if they are empty. It is assumed thatsome of data packages produced by “fast” controlblocks may be lost due to the “slow” ones. Fromreal-time software engineering point of view allcommunication mechanisms applied in the PCAare shared variables and monitors [9]. This solvesthe mutual exclusion problem. The shared vari-ables are accessed (at the operating system level)according to Priority Inheritance Protocol [8, 9].One can check that the PCA communicationstructure does not include deadlocks.

Due to “external” partition scheduling andsimple application structure, the priorities of lo-cal task are used mostly for the precedence con-straints definition. The tasks priorities (definedwithin the partitions – compare tab. 1) reflectthe order of the computations, the tasks shouldfollow. This approach is essential especially in P1partition. It is expected that the FCA real-timetask is terminated before the Error Estimatortask begins.

4. System Programming and Testing

The PCA has been finally implemented in C lan-guage for VxWorks 653 [29, 30, 31] and PikeOS[32, 33, 34] operating systems, with APEX inter-face applied for PCA structure generation. Fromthe programmer’s point of view, each partitiondefined during the application development isa separate program. The program consists of a

set of real-time tasks. The tasks exchange databy means of APEX blackboards or send and re-ceive data via sampling ports. Timing constraintsare attached to the tasks. Each task involvesmain function which collects data from the inputcommunication objects (blackboards or samplingports), calls appropriate control block algorithm,sends computed data to output objects, and fi-nally suspends execution. The function is peri-odically activated by core operating system.

The PCA is a distributed real-time control ap-plication, so implementation tests have involvedthree main areas, i.e. communication, timingconstraints and control algorithms. Firstly, thecommunication structure of the application hasbeen assessed and all channels and data struc-tures checked. Secondly, Worst Case ExecutionTime (WCET) for each of the real-time taskhas been measured and the meeting of timingconstraints both at the process and the partitionlevel evaluated. The measured time has beencompared with partition time slots defined atthe beginning. Thirdly, the control proceduresapplied in the application have been tested, bothas separate function blocks and as complete setof cooperating software modules.

To the author’s experience, good practicefor the ARINC 653 programmer is to prepareworking document that explains:– ports introduced in the application,– channels’ description (how to connect the

ports with other ports),– time budget (partition window) allocated to

the partition,– time period within which the application (par-

tition) should run again,– memory requirements.

Some extra records with internal structureof the application will also help. Typically theapplication developer should provide:– parameters of real-time tasks (IDs, stacks,

priorities, deadlines, periods, criticalness<HARD/SOFT>),

– internal communication structure (black-boards and buffers, their IDs, capacities, tasksattached),

48 Sławomir Samolej

Figure 6. PCA structure

– communication timeouts (attached to APEXfunction calls to read data from blackboardsor buffers),

– internal error handler procedure actions.According to IMA philosophy the prepared ap-plications (partitions) in a form of binary filesequipped with such documents are sent to thesystem integrator.

5. Conclusions and Future Research

The paper reports emerging trends and designpatterns in real-time systems development. It isfocused on ARINC 653, where a new standard forreal-time systems design is introduced. Successivesteps of a typical ARINC 653 based application(Pitch Control Application PCA) developmentare described. The application has been designedas contribution of Rzeszów University of Technol-ogy to European SCARLETT [22] project. In thecurrent state of the PCA development, the appli-cation is being integrated with other hardwareand software modules delivered by SCARLETT

partners. It is expected that the final PCA ap-plication test will reveal whether the currenthardware-software environment conforming withARINC 653 is able to execute some distributedhard real-time applications successfully.

6. Acknowledgments

Research reported in the paper is fundedby SCARLETT 7th European Frame-work Project, Grant Agreement No.FP7-AAT-2007-RTD-1-211439. Some of hard-ware components used in the research pub-lished within this paper were financed bythe European Union Operational Program –Development of Eastern Poland, Project No.POPW.01.03.00-18-012/09.

References

[1] Wind River WWW Site. [Online]. Available:http://www.windriver.com/

[2] SYSGO WWW Site. [Online]. Available:http://www.sysgo.com/

ARINC Specification 653 Based Real-Time Software Engineering 49

[3] Lynux Works WWW Site. [Online]. Available:http://www.lynuxworks.com/

[4] WindowsCE WWW Site. [Online]. Available:http://www.microsoft.com/

[5] Linux RTAI WWW Site. [Online]. Available:https://www.rtai.org/

[6] J. Barnes, Programming in Ada 2005.Addison-Wesley, 2006.

[7] ——, High Integrity Software, The SPARK Ap-proach to Safety and Security. Addison-Wesley,2003.

[8] G. C. Buttazzo, Hard Real-Time Computing Sys-tems: Predictable Scheduling Algorithms and Ap-plications. Kluwer Academic Publishers, 1997.

[9] A. Burns and A. Wellings, Real-Time Systemsand Programming Languages. Pearson Educa-tion Limited, 2001.

[10] “IEEE Std 1003.1, 2004 Edition,” IEEE, Tech.Rep., 2004.

[11] J.-P. Rosen, HOOD an Industial Approach forSoftware Design. Elsevier, 1997.

[12] A. Burns and A. Wellings, HRT-HOOD: A struc-tured design Method for hard Real-Time AdaSystems. Elsevier, 1995.

[13] A. Burns, B. Dobbing, and T. Vardanega, “Guidefor the use of the ada ravenscar profile in highintegrity systems,” University of York, TechnicalReport YCS-2003-348, Jan 2003.

[14] Matlab-Simulink WWW Site. [Online]. Available:http://www.mathworks.com/

[15] Scade Suite WWW Site. [Online].Available: http://www.esterel-technologies.com/products/scade-suite/

[16] IBM Rational Rose RealTime WWW Site.[Online]. Available: http://www-01.ibm.com/software/awdtools/developer/technical/

[17] Avionics Application Software Standard Inter-face Part 1-2, ARINC Specification 653P1-2,2005.

[18] SAE AS5506 Standard: Architecture Analysisand Design Language (AADL), 2006.

[19] P. Bieber, E. Noulard, C. Pagetti, T. Planche,and F. Vialard, “Preliminary design of futurereconfigurable ima platforms,” in ACM SIGBEDReview - Special Issue on the 2nd InternationalWorkshop on Adaptive and Reconfigurable Em-bedded Systems. ACM, Oct 2009.

[20] P. Parkinson and L. Kinnan, “Safety-critical

software development for integrated modularavionics,” Wind River, Wind River White Paper,2007.

[21] J. W. Ramsey, “Integrated Modular Avionics:Less is More Approaches to IMA will saveweight, improve reliability of A380 and B787avionics,” Avionics Magazine, 2007. [Online].Available: http://www.aviationtoday.com/av/categories/commercial/8420.html

[22] SCARLETT Project WWW Site. [Online].Available: http://www.scarlettproject.eu

[23] “AFDX: The Next Generation Interconnect forAvionics Subsystems,” Avionics Magazine Tech.Report, Tech. Rep., 2008.

[24] Aircraft Data Network Part 7 - Avionics FullDuplex Switched Ethernet (AFDX) Network, AR-INC Specification 664 P7, 2005.

[25] ARINC 429: Mark 33 Digital Information Trans-fer Systems (DITS), 1996.

[26] S. Samolej, A. Tomczyk, J. Pieniążek,G. Kopecki, T.Rogalski, and T. Rolka,“VxWorks 653 based Pitch Control SystemPrototype,” in Development Methods andApplications of Real-Time Systems, L. Trybusand S. Samolej, Eds. WKL, 2010, ch. Chapter36, pp. 411–420, (in Polish).

[27] T. Rogalski, S. Samolej, and A. Tomczyk, “AR-INC 653 Based Time-Critical Application forEuropean SCARLETT Project,” Aug 2011, ac-cepted for presentation at the AIAA Guidance,Navigation, and Control Conference, 8-11 Aug2011 Portland, Oregon, USA.

[28] S. Samolej, A. Tomczyk, and T. Rogalski, “FaultDetection in a ARINC 653 and ARINC 644 PitchControl Prototype System,” Sep 2011, acceptedfor publication in: Development, Analysis andImplementation of Real-Time Systems, L. Try-bus and S. Samolej eds., WKL, 2011, (in Polish).

[29] VxWorks 653 Configuration and Build Guide 2.2,Wind River, 2007.

[30] VxWorks 653 Configuration and Build Reference,2.2, Wind River, 2007.

[31] VxWorks 653 Progmer’s Guide 2.2, Wind River,2007.

[32] PikeOS Fundamentals, Sysgo AG, 2009.[33] PikeOS Tutorials, Sysgo AG, 2009.[34] PikeOS Personality Manual: APEX, Sysgo AG,

2009.