MKROPPdXESORS AND

MICROSYSTEMS

ELSEVIER Microprocessors and Microsystems 20 (1997) 479-483

ARINC 653 - Achieving software re-use

A. Cook”, K.J.R. Huntb aFormerIy with British Aerospace Airbus Ltd. Airframe Avionics, 867-02. Cl New Technical Centre. PO Box 77, Filion. Bristol, Avon, 8599 7AR, UK

‘British Aerospace Airbus Ltd, Airframe Avionics, 867-02, Cl New Technical Centre, PO Box 77, F&on. Bristol, Avon, B599 7AR, UK

Abstract

A key goal of the ARINC 653 (APEX) specification is the achievement of software re-use through provision of a standard operating environment for applications software. Reuse of software can be achieved in two ways: (i) by re-using operating systems, which provide common functions across the application spectrum, eg. health monitoring, process management, communications mechanisms; and (ii) by re-using the applications software which provides avionics applications functions. By provision of a stan- dardised interface between applications and operating system, ARINC 653 facilitates both forms of re-use.

Operating systems are by nature tightly coupled to the underlying hardware platform, re-use of operating systems is therefore limited to modules employing the same hardware unless a new standard such as COEX (Core Executive Interface) can be tightly defined.

Applications software is often dependent on the actual aircraft implementation. Direct re-use of applications will not always be possible; however, by use of ARINC 653, it will be possible to re-use individual partitions of an application in other applications.

ARINC 653 is language-dependent and within languages such as Ada there is scope for functionally identical implementations which are syntactically different. Unless definitive language implementations of ARINC 653 are adhered to, language issues will become a major hurdle to re-use.

A large cost of avionics development (particularly software) is the cost of certification. Currently, avionics functions are certified at the ‘system’ level. In order to maximise the benefits of software re-use, means must be found to claim credit for previously-developed software components of a system. EUROCAE WG48 and RTCA SC182 are currently investigating this issue in their definition of an Avionics Computing Resource. It is hoped that these groups, working in co-operation with ARINC 653, will provide the means to achieve the benefits of re-use.

Keywords: Software m-use; Integrated Modular Electronics; ARINC 653

1. Introduction

A key goal of Integrated Modular Avionics (IMA) is achievement of cost benefits through the re-use of com- ponents. Software re-use will be facilitated through the Application Executive interface (APEX) defined in the ARINC 653 [l] working paper.

Compliance with the APEX interface will allow soft- ware to be used on another platform without changes to the source code. However, the maximum benefits of soft- ware re-use will not be obtained unless the software is written in a modular manner in response to a functional, rather than aircraft application specific, set of require- ments. This re-use of software will enable development and through-life cost benefits to be achieved when compared to the incremental design approach often used when migrating designs between aircraft variants.

0141-9331/97/$17.00 c 1997 Published by Elsevier Science B.V. PII s0141-9331(97)01113-1

This paper discusses the issues of software re-use and describes the means of achieving the cost benefits of re-use through the ARINC 653 interface. The objectives of the EUROCAE WG-48 and RTCA SC- 182, which are defining a Minimum Operational Performance Standard (MOPS) for an Avionics Computing Resource (ACR), are also described. The impact of the ACR MOPS, in conjunction with ARINC 653, on the certification of re-usable software is discussed.

2. Why r-e-use software?

Currently, the procurement of avionics software is very expensive. In an avionics system, software often accounts for a high percentage of the development

480 A. Cook, K.J.R. Hunt/Microprocessors and Microsystems 20 (1997) 479-483

cost, particularly if industry standard hardware modules are used. A large proportion of this development cost is incurred in meeting certification requirements in particular complying with the verification and validation pro-cesses. While safety and certification requirements must remain paramount there is obvious potential for cost benefit if software can be re-used in new imple- mentations and credit taken for previous certification effort.

Re-use of applications is appropriate in the following circumstances:

i) the application is to be implemented in a different airframe type, but where the software requirements are unchanged.

ii) although the software requirements have not changed, it is thought beneficial to upgrade or modify the hardware platform.

iii) new options or functions are identified for existing software. Additional software can be added while the remainder is re-used.

3. Current barriers to cost effective re-use of software

Presently, avionics software is procured by the air- frame manufacturer as part of a system providing an aircraft function. The computing platform is purpose built to an architecture which meets the availability and integrity requirements of the aircraft function. Hard- ware and software are thus tightly coupled, both to each other and to the actual aircraft implementation. Any changes to the aircraft functionality will require changes to the existing software code. The full verification and validation process must therefore be repeated to ensure that the changes do not prevent existing software from meeting its requirements. Similarly the re-use of an entire application in a new airframe type is often not possible. Components of software from previous implementations may be re-used in new implementations. Such com- ponents must execute in conjunction with components which have been specifically developed for the new implementation, and all software components of the new implementation are therefore subject to the com- plete verification and validation process.

Cost effective re-use will only be achievable when com- ponents of software can be added to a system, with the assurance that the new components do not affect the integrity of existing software.

4. Achieving re-use with integrated modular avionics

IMA, as described in ARINC 651 [2], proposes an approach to avionics design which places emphasis firmly on component re-use. IMA components conform

to an open standard allowing manufacturers to produce equipment which is decoupled from an actual imple- mentation. These components are configured into an architecture which meets the availability and integrity requirements of the aircraft functions to be implemented.

5. IMA software and ARINC 653

Within IMA, applications software will provide each system’s functionality. The applications software runs under the control of an executive, with one or more applications running on a core processing module. The executive provides a set of system services to the appli- cations, eg. memory allocation, process management, communications services and health monitoring, thus decoupling the applications from the hardware environ- ment. Using an executive enables applications to become relocatable across core modules. However, re-use of applications across dissimilar executives will only be achieved if the interface, through which the executive services are accessed, is the same for all possible execu- tives. This requirement is the main driver for the ARINC 653 working paper ‘Avionics Applications Software Standard Interface’. ARINC 653 defines the Application Executive (APEX) interface. A set of services required by an avionics executive are described and a set of pro- cedure declarations by which they are accessed are defined, these declarations being the APEX interface. By the nature of the services they provide, executives are tightly coupled to the underlying architecture of the hardware.

The executive itself is a re-usable component of soft- ware, providing functionality which would otherwise be a requirement of the application software. However, because of the coupling to hardware, executives are not easily portable across different platforms. To enable the re-use of executives across different platforms, a further interface known as the Core Executive (COEX) inter- face is described in ARINC 651 [2], which is a logical interface between an executive and the underlying hardware. As yet, no ARINC working group has been set up to define the COEX. Currently, it is expected that the executive will be supplied as an integral part of the core module which, itself, will be the re-usable component.

6. Partitioning for safety

From the discussion in the previous paragraph it can be seen that ARINC 653 is the key standard for facilitat- ing re-use of avionics applications software in IMA. ARINC 653 provides a common logical environment for applications software, allowing software to be ported

A. Cook, K.J.R. Hunt/Microprocessors and Microsystems 20 (1997) 479-483 481

from one platform to another. However, from earlier discussion, it is clear that to maximise the cost-benefits of re-use, it is necessary to reduce the verification and validation effort required when software is re-used. ARINC 653 addresses this issue through the concept of partitioning. Applications software executes within a number of partitions, each of which is isolated in time and space from other partitions. The software within a particular partition can only address a pre-allocated area of memory, and can only execute within pre-determined timeslices.

The partitioning mechanism ensures that software errors in one partition do not propagate into other par- titions. There are three main advantages for re-use, gained by implementation of the partitioning mechan- ism; software of different DO- 178B [3] levels can execute on the same module, malfunction of software in one partition cannot affect execution of software in other partitions, new software can be added to or removed from a partition without affecting the execution of soft- ware in other partitions.

By employing the partitioning mechanism appli- cations can be partitioned into loosely coupled com- ponents. Where it can be shown that failure of a particular component does not adversely affect the critical functions of the application, the component’s software can be assigned a lower DO-178B [3] level, something that obviously has advantages both during initial design and when the component is re-used. Modi- fied software can be added to partitions while re-using software in other partitions without repeating the verifi- cation and validation process. As long as it is demon- strated that software can be located in a partition, meeting its time and space requirements, software can therefore also be ported to a different module without repeating the verification and validation processes.

Partitioning, however, is only a means of ensuring that errors do not propagate between components. Partition- ing cannot guarantee that common mode or combina- tional failures cannot occur, nor does it provide a means of fault recovery. For example, if two partitions each contain software performing a function whose individual loss is major but whose combined loss is catastrophic, and they execute on the same module, then the processor is a single point of failure which would lead to a cata- strophic failure condition. The configuration of par- titions onto core modules must therefore satisfy the normal safety assessments, assurance must be provided that functional availability and integrity requirements are met, and that common mode failures are eliminated.

In order to implement the ARINC 653 partitioning mechanism, the timing requirements of each application must be known, and a partition execution schedule derived for each module. The schedule must be periodic to allow deterministic execution, although applications may need to respond to aperiodic events. Aperiodic

processes must therefore be allocated timeslices within the partition execution cycle; if the aperiodic event does not occur, processing will not take place within the allocated timeslice. Similarly, a partition’s software may occasionally complete its execution before the end of the partition timeslice, in which case all processing is suspended until the end of the timeslice. Nothing can be done to recover the under-utilised processor time, as the partitions must execute with fixed periodicity.

7. Challenges of the IMA approach

A major disadvantage of the IMA approach is the level of work required by the system integrator. The sys- tem integrator must determine how applications will be partitioned in terms of functionality and predict the memory and time requirements of each partition. The integrator is responsible for allocating functions to modules and defining the partition execution cycle for each module. The definition of the time schedule is a task whose complexity is likely to rise exponentially with the number of partitions to be configured onto a core module. It is unlikely that a schedule of even moderate complexity can be determined manually and therefore the assistance of sophisticated software tools will be required. Because of the relocatable nature of applications, any particular partition may need to pass messages to partitions located either on the same module, on a different module in the same cabinet or outside the host cabinet. The integrator is responsible for ensuring that the communications paths are set up for each partition, by generating configuration tables for each module which provide routing information for all messages sent and received by each partition resident on the module. The generation of configuration tables is another high-complexity task which will require sophis- ticated tools to assist successful implementation.

The successful achievement of IMA objectives is highly dependent on being able to control the complexity of implementations and the development of tools which can alleviate the work load of the system integrator.

8. Software re-use outside the IMA environment

The problems described in the previous paragraph are essentially caused by attempts to integrate aircraft func- tions into a common system environment. Functional integration is not, however, essential for achieving cost- effective re-use. The APEX interface is independent of any physical implementation and is equally applicable to Line Replaceable Units (LRUs) and to IMA Line Replaceable Modules (LRMs).

EUROCAE WG-48 and RTCA SC-l 82 were established to define a Minimum Operational Performance Standard

482 A. Cook, K.J.R. Hum/Microprocessors and Microsysiems 20 (19973 479-483

(MOPS) for an Avionics Computing Resource (ACR). The ACR will be a generic computing module which can host unspecified applications software, and the MOPS will define a set of characteristics which will establish if the ACR is capable of hosting a certain class of appli- cation. An IMA core processing module may achieve the classification of an ACT but an ACR is not neces- sarily an IMA core processing module. EUROCAE WG-48 has made the reduction of certification costs when re-using applications software one of its primary objectives. This cost reduction will be achieved through pre-qualification of the ACR, and an ACR developed to comply with the MOPS will be qualified to host certain types of application software. It is anticipated that there will be a number of ACR classes. The ACR MOPS will describe a logical environment for the execution of appli- cations software, rather than focusing on the physical hardware characteristics. The ACR will therefore consist of a processor and operating system with a standard Applications Programming Interface (API); the APEX will hopefully be adopted as the API. The ARINC 653 working group and RTCA SC-182 have met to discuss common issues of ARINC 653 and the ACR. The agreement and participation of the air- worthiness authorities is essential to the success of the ACR MOPS. The concept of component pre- qualification, for an unspecified application, is a radical one. Precisely what credit can be taken when porting software from one ACR to another needs to be defined and agreed with the authorities. Currently, the FAA actively participates in RTCA SC-182, and EUROCAE WG-48 has made the European Authorities aware of its objectives and intentions.

September 1997. Subject to their approval of the MOPS, the FAA has agreed to produce a Technical Standard Order based on the MOPS by September 1998.

10. Conclusions

Software re-use is potentially of great benefit to the avionics industry and the biggest benefit will be in the area of certification. The benefit will only be achieved if mechanisms can be established to enable the carrying over of previous verification and validation work, when software components are re-used.

To facilitate re-use, a move away from hardware and software which are both tightly coupled to specific func- tions is required. Avionics computers should instead be based on processing modules which feature an executive allowing relocatable applications. IMA and the more recent ACR concept propose this type of solution.

ARINC 653 describes the required functionality of an Avionics Executive and defines the APEX interface through which applications access the services. By devel- oping executives which comply to the APEX interface, applications can be ported across modules. ARINC 653 is a key standard for avionics software re-use.

9. Timescales for applicable standards

One of the main features of ARINC 653 is the defini- tion of partitioning. Partitioning ensures that the exe- cution of software within a particular partition cannot be adversely affected by software executing in another partition. The implementation of this concept enables software of different criticalities to execute on the same processing module and to allow changes to software within one partition while guaranteeing that other par- titions are not affected. Partitioning is therefore a crucial concept to enable certification credit to be taken when re-using software.

ARINC 653 is approaching completion of Phase 1. All the services have been defined and the service call procedures specified. However a final review meeting will be held towards the end of 1995. The major topic at this meeting will be to agree two appendices giving a definitive specification of the APEX in Ada and C. The appendices are necessary because although Sec- tion 3.0 of ARINC 653 specifies the service calls as a set of pseudo-code procedure declarations, there remains a possibility of producing functionally identi- cal implementations which have syntactic differences. This could arise, for example, where Ada generic packages are used. Syntactic differences would affect the portability of software across different APEX implementations, and it is therefore proposed to include comprehensive language definitions as gui- dance to developers,

ARINC 653 and the ACR MOPS provide a mech- anism for re-use of applications software, although the means of gaining certification credit is dependent on a process of pre-qualification of components. Pre- qualification is a radical concept for certification and will only be achieved in co-operation with the certifica- tion authorities.

ARINC 653 is applicable both to IMA and future LRU implementations. Early adoption by industry will ensure that future avionics software will be upwardly compatible with later IMA solutions, and the benefits of successful re-use will be felt in the near term as well as the more distant future.

References

RTCA SC-182 and EUROCAE WG-48 intend [I] Avionics applications software standard interface, ARINC Project to complete the specification of the MOPS for ACR by Paper 653, Draft 13, June 1995.

A. Cook, K.J.R. Hunt/Microprocessors and Microsystems 20 (1997) 479-483 483

[2] Design guidelines for integrated modular avionics, ARINC Report 651, November 1991.

[3] Software considerations in airborne systems and equipment certifi- cation, EUROCAE/RTCA DO-178B/ED12B, December 1992

Alan Cook graduated with a BSc (Eng) degree in Materials Science from Imperial College London in 1983. Having developed an interest in computing while at college. he decided to pursue a career in the software industry, initially taking employment as a programmer with Ferranti Computer Systems Ltd in October 1983. He subsequently workedfor Plessey Avionics and GEC, his work areas were develop- ment of real-time systems and performance assessment models. He joined British Aerospace Airbus in 1991 to work on the Control Tech- nology Programme, looking at the certt$cation and software aspects of integrated modular avionics. He has been a member of the ARINC 653 working group since 1993, and is currently secretary of EVRO- CAE WG48 (Avionics Computing Resource).

i

Ken Hunt completed an MSc in Electronics System Design at Cran- field Institute of Technology in 1974, then took up a post at GEC’s Central Research Laboratory at Wembley. During this time, he worked on commercial and military semiconductor- and phosphor- based displays and infrared imaging systems. Moving to BAe Dynamics in 1985, he took on responsibility for the electro-mechan- ical design and manufacturing of many of the companys defence products; latterly with responsibility for the EMC design, perfor- mance and testing of avionic and shipborne equipments. During this time, he worked on several modular avionic programmes, including the Advanced Avionic Architecture and Packaging (A’P) study and chaired the ASSC (Avionic Systems Standardisation Committee) Packaging Working Group. Since transferring to the Airbus division in 1991, he has workedon avionic equipmentsfitted to aircraft rangingfrom Concorde to the A330. Whilst in his present role as Manager, Systems Technology, he has been consortium manager for the Control Tech- nology Programme Phase 2.