Brigitte Bauer

Keywords: ARINC653, IMA, Avionics Software, Avionics Standards, Certification

The paper covers the definition of Integrated Modular Avionics (IMA), the associated avionics standards and the impact on the Avionics Software. ARINC and RTCA/EUROCAE committees, in which all Avionic stakeholders are involved, developed these standards. 2005 is a key year for standardization: ARINC653 part1 supplement2 and part3 are ready for publishing, RTCA-SC200 / EUROCAE-WG60 is under ballot. The concepts of IMA, the new architecture in Avionics, were defined in the late Eighties and published for the first time in the ARINC651 standard in 1991. The IMA concepts were firstly applied on Boeing 777, extended and used on Airbus A380 and now selected for the future Boeing 787. These concepts divide the avionic embedded domain into Platform (Hardware+Core Software) and Applications instead of Hardware and Software. Several applications of different criticality levels could reside on the same platform.

The consequences were the development of new standards and guidelines for supporting these concepts, e.g.: -ARINC653 defines the API and the behavior of the Core Software services.

-DO-255/ED-96 contains the description of an Avionic Computing Resource (a platform separated from its hosted applications).

-DO-248B/ED-94B clarifies DO-178B/ED-12B and defines concepts like robust partitioning.

-SC200/WG60 (future ED-124) contains the IMA Development Guidance and Certification. -SC205/WG71 has started. It reviews and extends DO-178B/ED-12B and DO-248B/ED-94B in regard of new technologies The paper describes the objectives and the results of these standardization committees. It focuses on ARINC653 and ED-124 standards and presents shortly the associated standards.

Introduction

This paper tries to describe in an objective way the IMA standards. Therefore extracts of them are given in extenso to respect their spirit.

Standardization committees

RTCA Organized in 1935 as the Radio Technical Commission for Aeronautics, RTCA [11] today includes roughly 250 government, industry and academic organizations from the United States and around the world. Member organizations represent all facets of the aviation community, including government organizations, airlines, airspace user and airport associations, labor unions, plus aviation service and equipment supplier. RTCA, Incorporated is a not-for-profit organization formed to advance the art and science of aviation and aviation electronic systems for the benefit of the public. The organization functions as a Federal Advisory Committee and develops consensus-based recommendations on contemporary aviation issues. The organizations recommendations are often used as the basis for government and private sector decisions as well as the foundation for many Federal Aviation Administration (FAA) Technical Standard Orders (TSO). EUROCAE The European Organisation for Civil Aviation Equipment, EUROCAE, [12] was formed in1963. At that time, there was no regular forum in Europe where administrations, airlines and industry could meet to discuss technical problems. EUROCAE was created to fill this gap. The main European administrations, aircraft manufacturers, equipment manufacturers and service providers are members of EUROCAE, and they actively participate in the Working Groups. EUROCAE is an international non-profit making organization. Membership is open to manufacturers and users in Europe of equipment for aeronautics, national civil aviation administrations, trade association and, under certain conditions, non-European members. Its work program is principally directed to the preparation of performance specifications and guidance documents for civil aviation equipment, for adoption and use at European and worldwide levels. EUROCAE documents are considered by Joint Aviation Authorities (JAA) as means of compliance to Joint Technical Standard Orders (JTSO) and other regulatory documents.

Joint RTCA and EUROCAE committees have developed their guidance documents related to Software and IMA. ARINC/AEEC Aeronautical Radio Inc / Airlines Electronic Engineering Committee (ARINC/AEEC) [10] is a group of interest, funded by airlines. It is in charge of the definition of Aeronautical standards that ensure interchangeability and interoperability. AEEC leads the development of avionics architectures and form, fit, function, and interface technical standards. The avionics installed in more than 10,000 aircraft around the world are based on these standards, known as ARINC Standards. The use of ARINC standards results in substantial benefits to airlines by allowing avionics interchangeability and commonality and reducing avionics cost by promoting competition. Furthermore, for new aircraft and avionics installations, ARINC standards provide the starting point for avionics development and allow aircraft manufacturers to pre-wire aircraft, thus ensuring that cost-effective avionics for air transport aircraft are ready when needed. AEEC is organized in committees, sub-committees and working groups.

IMA

Overview

ARINC651 "Design Guidance for IMA [1] introduces and defines the IMA concepts. It's first publishing occurred in 1991: "IMA is formed around the concept of powerful computer (s) with an Operating System that allows independent processing of application software, while maintaining robust partitioning between software modules for even the most critical functions…."

A revised version with a few updates was published in 1997. -The Application Software, which performs the avionics functions.

Objectives

-The Core Software, which provides a standard and common environment in which applications software executes.

-APEX (APplication EXecutive) and COEX (COre EXecutive) interfaces. -Coordination with SC205/WG71.

ARINC653

APEX Working Group

ARINC 653 Specification

In the ARINC653 document, its primary objective is to define a general-purpose Application/Executive interface (APEX) between the Operating System (O/S) of an avionics computer resource and the application software. Included within this specification, are the interface requirements between the application software and the O/S and the list of services, which allow the application software to control the scheduling, communication, and status information of its internal processing elements. This Specification defines the data exchanged statically (via configuration) or dynamically (via services) as well as the behavior of services provided by the O/S and used by the application. The bulk of this document describes the runtime environment for embedded avionics software. This list of services identifies the minimum functionality provided to the application software, and is therefore the industry standard interface. It is intended for this interface to be as generic as possible, since an interface with too much complexity or too many system-specific features is normally not accepted over a variety of systems. The ARINC653 document is intended for use in a partitioned environment.

The document describes also the software that resides on the hardware platform. It consists of:

-ARINC 653 Application partitions that are subject to robust space and time partitioning and are restricted to using only ARINC calls to interface to the system.

-An O/S kernel that provides the API and behaviors defined within this specification, and supports a standard and common environment in which application software runs. This may include hardware interfaces such as device drivers and builtin-test functions.

-System partitions, partitions that require interfaces outside the scope of APEX services, yet constrained by robust spatial and temporal partitioning. These partitions may perform functions such as managing communication from hardware devices or fault management schemes. System partitions are optional and are specific to the core module implementation.

!" #

ARINC653 characteristics

Partition management -A partition is a program unit of the application designed to satisfy the partitioning constraints. It contains multiple processes.

-O/S provides robust partitioning for time and space.

-Partitions of different criticality levels reside in the same core module.

-Partition scheduling is predetermined, repetitive, with fixed periodicity (no priority for a partition).

-Partition memory is in predetermined areas (no memory allocation services in APEX).

Process management -A process is a software task, which executes concurrently with other processes of the same partition.

-Process scheduling is Prioirty Preemptive.

-Periodic and aperiodic processes are scheduled.

-Each process has a priority.

-Common O/S services like Suspend/Resume, Start/Stop, Lock preemption are provided.

Inter-partition communication -The communication between partitions on the same or between different modules is generic and is not depending on the underlying media.

-A message is sent from a single source to one or more destinations. Sender and receivers do not know each other.

-Ports/channels/messages are the means for supporting queuing mode (no lost message) and sampling mode.

Intra-partition communication -Synchronization between processes inside the same partition is done via semaphores and events.

-Communication between processes inside the same partition is done via buffers and blackboards.

Time management

The Time is managed by services and means controlling periodic and aperiodic processes and also controlling the duration of potential blocking services like timeouts, deadlines, timed and periodic waits, delayed start, replenishment.

Fault management -The Health monitoring is responsible for monitoring and reporting faults and failures.

-The faults are managed at application, partition and module levels -Configuration tables contain recovery action to respond to pre-defined faults of the partitions and the module.

-The error handler process, a specific process provided by the application, manages the application level errors. The application base for ARINC 653 has increased substantially, and there is a recognized need to refine and augment the specification. In addition various organizations, including the Open Group [13] and military systems have shown an interest in ARINC 653 as the basis for a "secure" operating system. Therefore the Working Group will continue to meet on a regular basis to review and to adapt ARINC653.

Conclusion

Future ED-124

This document, jointly prepared by EUROCAE Working Group 60 and RTCA Special Committee 200, [3] was officialy approved by RTCA in November 2005, the approval from EUROCAE should occur before the end of 2005 and the document should become ED-124. The RTCA reference is not yet known.

Objectives

The SC200/WG60 document named IMA Development Guidance and Certification Considerations contains guidance for Integrated Modular Avionics (IMA) developers, application developers, integrators, certification applicants, and those involved in the approval and continued airworthiness of IMA systems in civil certification projects. The guidance describes the objectives, processes and activities for those involved in the development and integration of IMA modules, applications, and systems to incrementally accumulate design assurance toward the installation and approval of an IMA system on an approved aviation product as differentiated from traditional federated aviation system architectures.

In the document, IMA system concepts are described, including the platform and modules, and their relationships to the hosted applications and avionics functions used in an aircraft installation.

The six tasks defining the incremental acceptance of IMA systems in the certification process are presented.

IMA is defined as a shared set of flexible, reusable, and interoperable hardware and software resources that, when integrated, form a platform that provides services, designed and verified to a defined set of requirements, to host applications performing aircraft functions.

The IMA platform should be capable of providing robust partitioning and other protection means that allow multiple applications to share a platform and its resources, or to support functions distributed across a fault-tolerant network.

The development of an IMA system is based on an IMA platform containing hardware and software that are common and can be shared by the hosted applications.

An important aspect of the certification process for IMA systems is to obtain incremental acceptance of and certification credit for IMA platforms, modules, and/or hosted applications, cumulating in IMA system installation approval on an aircraft product, and resulting in issuance of the product certificate.

Terminology

A set of terms is defined in the document to assure understanding among all parties involved.

Application -Software and/or application-specific hardware with a defined set of interfaces that, when integrated with a platform, performs a function.

Component

Key characteristics

Platforms and hosted applications key characteristics are: -Platform resources are shared by multiple applications.

-An IMA platform provides robust partitioning of shared resources.

-An IMA platform only allows hosted applications to interact with the platform and other hosted applications through well-defined interfaces.

-Shared IMA platform resources are configurable.

-An application may be designed independent of other applications and obtain incremental acceptance on the IMA platform independently of other applications.

-Applications can be integrated onto a platform without unintended interactions with other hosted applications.

-Applications may be reusable.

-Applications are independently modifiable.

Shared resources :IMA systems may host several applications that share resources.

Robust partitioning is a means for assuring the intended isolation and independence in all circumstances (including hardware failures, hardware and software design errors, or anomalous behavior) of aircraft functions and hosted applications using shared resources. The objective of robust partitioning is to provide an equivalent level of functional isolation and independence as a federated system implementation (i.e., applications individually residing on separate Line Replaceable Units (LRU)). The platform robust partitioning protection mechanisms are independent of any hosted applications, that is, applications cannot alter the partitioning protection provided by the platform.

An Application Programming Interface (API) defines the standard interfaces between the platform and the hosted applications and provides the means to communicate between applications and to use I/O capabilities. ARINC653 provides an avionics standard for an application programming interface and the related services.

IMA systems manage platform faults, hardware failures, partitioning violations, errors and anomalous behavior of hosted applications, including common mode faults and cascading failures.

The assignment of roles and responsibilities is necessary, and should address the entire IMA system life cycle from conceptual design to retirement. The identified stakeholders are Certification Authority, Certification Applicant, IMA System Integrator, Platform and Module Suppliers, Application Supplier, Maintenance organization.

Certification tasks

Typical development processes are divided into six tasks that define the incremental acceptance activities for the certification process for IMA systems:

-Task 1 (Module and/or Platform Acceptance): Integrate components and/or modules to form a platform -Task 2Application acceptance (software and/or hardware)): Integrate a single application with the platform-Task 3IMA system acceptance): Integrate multiple applications with the platform and one another-Task 4 (Aircraft integration)Integrate IMA system(s) with aircraft and its systems -Task 5(Change)Identify changes and their impacts, and need for re-verification -Task 6Reuse): Identify and use IMA components.

Integral processes

Integral processes for IMA development are described: -For Safety Assessment, due to the high level of integration inherent in IMA systems, it is recommended that applicants use ARP 4754/ED-79 [8] and ARP 4761 [9] or acceptable alternatives. The process should consider a minimum list of activities described in the document.

-For System Development Assurance, a section describes key areas of system development assurance, which include software guidance, hardware design assurance, shared design assurance, IMA system configuration management, and environmental qualification.

-The verification process should ensure that the implementations of specified requirements for the IMA system have been met. -For Configuration management, a section addresses configuration management (CM) of the IMA system life cycle data and life cycle environment.

-A Quality Assurance process in accordance with ARP-4754/ED-79 should be implemented for both the IMA system and the modules within the system.

-The certification liaison process establishes communication and understanding between the applicant and the certification authority throughout the IMA system life cycle to assist in the acceptance and certification process.

Objectives tables

The objectives are used to plan and ensure that the installed IMA system complies with the guidance of this document. Objectives should be addressed during the planning process of the aircraft certification program (e.g., Aircraft and/or IMA System Certification Plans, Platform Acceptance Plan, Module Acceptance Plan, Hosted Application Acceptance Plans). Since multiple stakeholders will typically be involved in the acceptance and certification efforts, the plans should clearly delineate who is responsible for achieving each objective. Plans should also indicate roles and responsibilities.

IMA system design examples

This annex contains examples of various system designs. Each example shows how some subset of the IMA characteristics may be implemented in a typical design. Single LRU platform, distributed IMA platform, distributed complex IMA System, Software designed radio are the examples described in the document.

Other Associated Standards

DO-255/ED-96

DO-255/ED-96, Requirement specifications for an avionics computer resource (ACR) [4], defines the Avionic Computing Resource, identifies the characteristics of a platform separated from its hosted applications and identifies the first features of incremental certification. This document contains the Minimum Operational Performance Standards (MOPS) for an ACR. The ACR provides shared computation resources, core software and signal conditioning necessary to interface with a variety of aircraft systems. By complying with the requirements specified by the MOPS, the ACR and the software applications may be independently developed. Together the ACR and installed software applications perform one or more aircraft functions. The aircraft functions can be hosted on multiple ACR platforms that can be provided by multiple vendors.

Compliance with the MOPS ensures a complete specification of the Application Programming Interface (API) provided by the ACR, its capacity and capability, and its performance. Based on this ACR specification, application software may be independently developed. This document is intended to assist manufacturers, software application developers and installers, in achieving an ACR and installed software applications, which will perform their intended functions satisfactorily under all conditions normally, encountered in routine aeronautical operations. This document stipulates that the ACR manufacturer provides a suite of tests and analyses to assure the operation, performance and capacity of the ACR. Although specific test procedures are not included, assurance objectives are established for each ACR attribute.

In developing an ACR as specified by the requirements in these MOPS, the ACR manufacturer is required to specify the development environment required only to develop the ACR. The ACR manufacturer is also obligated to specify the integration and configuration tools and environment necessary such that requirements for the addition or deletion of applications to the ACR will be adhered to at the time they are integrated.

Approval of the ACR ensures that the defined API services, partitioning and health monitoring perform correctly over the full range of environmental conditions encountered in aeronautical operations. The DO-255/ED-96 document contains the ARINC 653 API as an example.

The IMA concepts are introduced in this document that was published in June 2000. DO-255/ED-96 was a major input of the Joint SC200/WG60 committee, which defines guidance for IMA systems.

DO-248B/ED-94B

The purpose of DO-248B/ED-94B, Final Report for Clarification of DO-178B/ED-12B [5], is to provide clarification to the guidance material in DO-178B/ED-12B.

It contains Errata, Frequently Asked Questions, (FAQ) and Discussion Papers (DP).

-The purpose of Errata is to provide a means of correcting errors in clarify DO-178B/ED-12B.

-The purpose of a FAQ is to provide short and concise responses that are frequently asked by the industry concerning the material of DO-178B/ED-12B. These questions are frequently asked to certification authorities or others who provide interpretation of DO-178B/ED-12B.

-The purpose of a Discussion Paper is to provide clarification for certain sections of DO-178B/ED-12B when clarification requires more than a short answer to a question. The document contains 12 Errata, 75 FAQ and 15 DP.

One of the Discussion Paper, DP14 concerns partitioning in DO-178B/ED-12. Partitioning rigor and guidelines for robust partitioning mechanisms are described. Robust partitioning definition was reused in ARINC653 and SC200/WG60 documents. The DO-248B/ED-94B document is the third and final report of a Joint RTCA/EUROCAE committee. It was published in October 2001.

SC205/WG71

Joint RTCA Special Committee 205 and EUROCAE Working Group 71, Software Considerations in Aeronautical Systems, was formed to work on potential updates and improvements to DO-178B/ED-12B [6], and associated guidelines and clarification, DO-248B/ED-94B and DO-278/ED-109 [7]. These documents provide guidance and guidelines for the production of software for airborne, CNS/ATM systems and equipment with a level of confidence in safety, which complies with airworthiness requirements. DO-178B/ED-12B was released in 1992. The document is seen as reasonably complete in its guidance and remains effective. However it does not efficiently address all current and emerging software technology issues (e.g. the use of a model-based development process, the application of formal mathematical methods etc.). The issues raised by a set of experts, need additional or revised guidance for industry and the certification authorities.

The Objectives of the Joint Committee are: -To promote safe implementation of aeronautical software.

-To provide clear and consistent ties with the systems and safety processes.

-To address emerging software trends and technologies.

-To implement an approach that can change with the technology. Revision C will be provided for DO-178B/ED-12B, and DO-248B/ED-94B. The technology independent nature of the DO-178B/ED-12B and the associated DO248B/ED94B will be maintained. Supplements to document technology-specific or method-specific guidance and guidelines will be developed if necessary.

The kick-off meeting of the Joint Committee occurred in January 2005. 2 plenary meetings are planned per year. The third one will occur in April 2006. The goal is that in end of 2008, the material produced should be ready for approval by EUROCAE and RTCA. Additional ad hoc meetings are planned depending on the sub group activities. A large number of persons participated to each meeting. Therefore the committee is split in 7 sub groups dedicated to editorial, management and technical aspects. 5 technology or method oriented SG will clarify the use of formal methods, tools, model based design, Object Oriented techniques, other safety issues and CNS/ATM.

Conclusion

Thanks to IMA, today Avionics Software contains Application Software dedicated to the avionics functions and Core Software dedicated to the management of the platform resources. The independence between Application Software and Avionic Platform is achieved.

Hardware isolation and standard interfaces are provided with the IMA platform to the function suppliers and ARINC653 is confirmed as the avionics standard Application Programming Interface. Furthermore technical standards and guidance material are available to the IMA stakeholders. Some IMA concepts were applied in the B777, which flew for the first time in 1995, but the full application was done in A380, which flew for the first time in 2005. During 15 years a succession of programs and studies on the both sides of Atlantic Ocean improved the IMA concepts and demonstrated their maturity.

To definitively confirm this new way of Applications development is to port them, from one IMA platform to another or from one aircraft to another.

All commercial or military aircrafts as well as the Airbus and Boeing pioneers will then follow these standards.

  APEX (APplication EXecutive Interface) is one of the AEEC working groups. The APEX working group started as an ad hoc for ARINC 651 (definition of IMA). It is in charge of the specification of the Avionics Application Software Standard Interface.

		-To specify the baseline operating environment for
		application software used within IMA and traditional
		ARINC 700-series avionics.
		-To define a general interface (APEX) between the
		Application Software and the O/S of an Avionics
		Computer Resource (i.e. IMA).-To support one or
		more avionics applications of different levels of
		criticality per core module,
		independent execution of those applications in
		predetermined time slots (partitioning).
		The result of the Working Group:
		-Will improve the overall cost of avionics software
		development, modification and maintenance.
		-Is a key part of Integrated Modular Avionics
		strategy.
		-Allows independent development, modification, and
		deployment of software applications.
		-Is supported by several development programs,
		including A380 and B787.
		When the Working Group restarted in 2002,
		improvement of the existing standard and extensions
		were planned in 2 steps:
		-Step 1: for Improvement, clarification,correction,
		required services only.
		-Step 2:new services definition, which are optional
		services, and conformity test plan for the required
	The document that hold this specification has	services.
	received the number "653".	Now the status of the working Group is:
	The working group started in 1991, and the first	-Supplement 1 (October 16, 2003) and Part1
	document named ARINC Specification 653 "Avionics	supplement 2 (adopted in October 2005) improve
	Application Software Standard Interface" [2] was	Application Software portability and concern only
	firstly published in January 1997. The working group	required services. The first implementation was
	was reopen in 2002, and Supplement 1 was	made in A380.
	published in October 2003.	-Part 2 -Extended Services adoption is planned for
	Supplement 2 (named Part1) should be published	mid 2006; certain services like logbooks are also
	before the end of 2005.	implemented in A380.
	Part3 corresponding to a Conformity Test Plan for	-Part 3 -Conformity Test Plan was adopted October
	the required services (Part1) should be published in	2005. The first draft came from the VICTORIA FP5
	early 2006. Part2 containing optional extensions is	European Project.
	still under discussion and should be approved in mid
	2006.	2006 work program consists in:
		-Completion of Part 2 (653 extensions) development
	The scope of the Working Group is defined as:	of Part 1 Supplement 3.
	-Assure the products of this working group meet the	-Starting Part3 Supplement 1 and Part2
	needs of safety critical, real-time applications.	Supplement1.
	-Ensure application portability.
	-Ensure the means of communications between
	partitions is independent of physical transport
	mechanism.
	-Maintain upward compatibility with the previous
	APEX.
	-Ensure sufficient APEX services are provided to
	meet the needs of the using community.
	-Assure consistency with the related activities.
	The purpose of the Working Group is:

  -A self-contained hardware part, software part, database, or combination thereof that is configuration controlled. A component does not provide an aircraft function by itself.

			Application 1			Application N
	Core Software -The operating system and support software that manage resources to provide an	Component (Software)	Component (Application Specific Hardware)		Component (Software)
	environment in which applications can execute. Core
	software is a necessary component of a platform
	and is typically comprised of one or more modules. Module -A component or collection of components	Avionics Function Specific
	that may be accepted by themselves or in the context of IMA. A module may also comprise other	General Purpose			(Module) Platform
	modules. A module may be software, hardware, or a
	combination of hardware and software, which
	provides resources to the IMA-hosted applications. Modules may be distributed across the aircraft or	Core Software			Module		Shared Resources
	may be co-located.
	Partitioning -An architectural technique to provide	Module	Module	Module
	the necessary separation and independence of
	functions or applications to ensure that only intended
	coupling occurs. The mechanisms for providing the protection in an IMA platform are specified to a	Component (Software)	Component (Software)	Component (Hardware and/or	Component (Hardware and/or	Component (Hardware and/or	Component (Hardware and/or
	required level of integrity.			Software)	Software)	Software)	Software)
	Platform -Module or group of modules, including
	core software that manages resources in a manner
	sufficient to support at least one application. IMA
	hardware resources and core software are designed
	and managed in a way to provide computational,
	communication, and interface capabilities for hosting
	at least one application. Platforms, by themselves,
	do not provide any aircraft functionality. The platform
	establishes a computing environment, support
	services, and platform-related capabilities, such as
	health monitoring and fault management. The IMA
	platform may be accepted independently of hosted
	applications.
	Resource -Any object (processor, memory,
	software, data, etc.) or component used by an IMA
	platform or application. A resource may be shared
	by multiple applications or dedicated to a specific
	application. A resource may be physical (a hardware
	device) or logical (a piece of information).
	The figure below shows the relationships between
	many of these terms.

  [1] ARINC 651: Design Guidance for Integrated Modular Avionics 7 November 1997 [2] ARINC 653: Avionics Application Software Standard Interface, supplement 1, 16 Oct 2003, drafts August 2005 [3] RTCA-SC200 / EUROCAE-WG60: IMA Development Guidance and Certification Considerations, final document 14 October 2005 [4] EUROCAE ED-96 / RTCA DO-255: Requirements Specification for Avionics Computer Resources 20 June 2000 [5] RTCA DO-248B / EUROCAE ED-94B: Final Report for clarification of DO-178B Software Considerations in Airborne Systems and Equipment Certification. 12 October 2001 [6] RTCA DO-178B / EUROCAE ED-92B: Software Considerations in Airborne Systems and Equipment Certification. 1 December 1992 [7] RTCA DO-278 / EUROCAE ED-109: Guidelines For Communication, Navigation, Surveillance, and Air Traffic Management (CNS/ATM) Systems Software Integrity Assurance 5 March 2002 [8] SAE ARP4754 / EUROCAE ED-79: Certification Considerations for Highly Integrated or Complex Aircraft Systems. [9] SAE ARP4761: Guidelines and Methods for Conducting the Safety Assessment Process on Civil

	Airborne Systems and Equipment
	[10] Arinc.com
	[11] RTCA.com
	[12] EUROCAE.org
	[13] opengroup.org
	7. Glossary
	ACR: Avionic Computer Resource
	AEEC: Airlines Electronic Engineering Committee
	APEX: Application Executive Interface
	API: Application Programming interface
	ARINC: Aeronautical Radio Incorporated
	CNS/ATM: Communication Navigation Surveillance /
	Air Traffic Management
	EUROCAE: European Organisation for Civil Aviation
	Equipment
	FAA: Federal Aviation Administration
	IMA: Integrated Modular Avionics
	JAA: Joint Aviation Authorities
	RTCA: Radio Technical Commission for Aeronautics


A Thomas Soulier

Software business models for AUTOSAR automotive world standard (V1.00)

Keywords: Business Models, AUTOSAR, Open Source

AUTOSAR

(AUTomotive Open Standard ARchitecture) as a promising initiative, will establish an open standard for automotive E/E architecture. AUTOSAR compliant Basic software will ensure independency of the application software from the underlying hardware while allowing modularity as well as reusability. From existing black box electronic control module business, three distinct layers, hardware, basic software and application software supported by robust toolkit may develop different kinds of business activities. From the drawing of established business models landscape, we will determine the strategic options that could be offered for a Tier 1 supplier. And this will finally end up to innovative business model proposals and a migration plan in accordance with customer needs and supplying value through systems engineering activities, software products and professional services.

Introduction

Siemens VDO is currently selling embedded electronic systems and using the traditional HW business model. But tomorrow hardware will be clearly separated from software (SW) with the arrival of the AUTOSAR standard. So what can be learned from mature industries which have faced this kind of situation for decades and have continuously adopted a new business model in a rapid evolving environment. Moreover they have recently been confronted with the swell of revolution coming from Open Source software companies. We will confront existing business models and associated strategic options to the upcoming situation in the automotive E/E architecture business to evaluate innovative business model proposals.

Business Models landscape :

Best practices and experiences outside of automotive

Business model definition

Through the landscape of business model definitions, we can distinguish some common points and general characteristics. A business model is a method or approach towards a defined market aiming at company survival. Defining a business model can be summarized to the answer to two basic questions :

-How to develop a sustainable and profitable turnover? -Where to position the company in the value chain?

Company's objectives consist in getting benefits from sales of product and/or service in ever evolving environment. In order to fulfil this goal companies try to gain market share and extend their potential market which becomes more and more difficult to achieve.

Clearly automotive actors will not accept radical changes in the traditional business model. That is why looking at other comparable business activities and especially software industry could facilitate business model definition. Thus this should drive a better market acceptance when proposing software products and services as a Tier one supplier.

2.2

Commercial software definition [START_REF]Business Models That Last: Balancing Products and Services in Software and Other Industries Paper 197[END_REF] With commercial software customers do not have access to the source code which is closed and most likely protected by copyrights and/or patents. Moreover commercial software companies do not grant the user any other rights beyond the use of the software package. We can consider three main business models in the commercial software industry:

-Software product company -Software service company -Hybrid solutions company.

Software product companies

In this category, products are highly standardized and companies excel in acquiring and leveraging generic product knowledge. Therefore architecture level technology integration is important as well as product complementarity. Moreover digital replication ensures minimal costs to mass-produce. As a consequence companies can benefit from large economies of scale and other efficiencies such as automation in design.

To support and target a large customer base, companies have large marketing, support and maintenance departments.

The main problem for product company remains in high fluctuation effect. Indeed if the economy turns bad, the product does not fit any more the customers needs or become commodities by value dilution.

To face this problem, companies are progressively starting to sell more and more maintenance services (special product enhancements, regular upgrades sold under long-term contracts).

Key: Need to understand general customers need

Pros & Cons

(+)Potential for higher profitability (gross margins up to 99%) (+)Low production costs (-)Require higher investments (-)Highly influenced by business fluctuations (-)Hard to write successful applications (killer apps) (-)SW can become commodities (-)Subject to discretionary IT spending

Software service companies

In this company category, all their revenues come from project-driven relationships with custom-built systems even if they rely heavily on reusing partial products for different types of applications. High service revenues are often linked to the degree of complexity of the products. IT companies have adopted service-based offerings with their products because they are often too complex to package as "off-the-shelf" offerings.

Key: Need to understand specific customers need

Pros & Cons

(+)Sustainable recurring revenues even in "bad" economic times (+)More room for growth (-)Higher marginal costs (-)Slower growth potential (-)Lower profit margin potential (-)More labor intensive than products (-)Hard to scale without adding people 2.2.3 Hybrid solution companies : the ideal solution?

The main advantages of those companies remains in both generating scale economies from sales of standardized products and more predictable recurring revenues like service companies.

Figure : Business models of hybrid solution companies

Strategic decisions will have to be taken considering:

to be either more product or more service oriented because it is too difficult to be equally good at both the degree of generic and customized software parts. Platform approaches are obviously to be preferred. These decisions will impact the organizational capabilities and financial investments.

2.3 Open Source software [START_REF] Feller | [END_REF] Even if the objective of this paper is not to define deeply the Open Source from its origine, it is worthwhile to provide the context. Originally the movement came from the Free Software Foundation (FSF), established in 1985. The FSF is dedicated to promoting computer users' rights to use, study, copy, modify, and redistribute computer programs.

Microsoft business model

The objective of Microsoft is to become and remain as the market leader through high volume sales and de facto technical standards settings that "lock in" customers. Their software applications and databases only work on a particular operating system or hardware platform which ensures long-term relationships and a monopoly situation difficult to overturn. In 1997 the term "Open Source" was decided upon in a strategy session held in reaction to Netscape's announcement of a source code release called Mozilla. The term was used to clarify a potential confusion caused by the ambiguity of the word "free" in the English language. Later that year the Open Source Initiative formed and began using the term Open Source to describe software which refers to:

-Use, modify, redistribute -Community -License Supporters of the Open Source claim that Open Source is NOT [START_REF]Perspectives on free and Open Source software[END_REF] : Please refer to Appendix and references to get more detail on those licenses.

-new -a set

Community

The producers of Open Source products are typically a diverse group of developers who are salaries of companies involved in Open Source activities or talented developers working to gain visibility from their peers. The role of the community consists in controlling what happens with the product by making one crucial choice: the license.

Companies can take great benefit from projects sponsorship and partnership [5] :

-Greater market exposure -Expanded business opportunities -Joint strategic sales and marketing initiatives -Access to a broad and growing customer base

An innovative business models

Open Source initiatives have given birth to innovative business models often based on commercial software business models as shown by IT industry adoption in their portfolio and expertise.

Even though there are still some innovative examples:

-Subscription business model

-Dual licensing model
This overview of innovative business model being done, it is necessary to highlight that a number of companies pioneering those business models failed driving a number of them out of business in the years 2000. It shows that it is vital in such business models to be able to monetarize the services provided in order to survive.

Comparison between Open Source & commercial SW Business Models

Open Source business models have mainly been inspired by commercial ones. Some initiatives have been taken concerning license agreements and service offers. But we also observe that Open Source companies are mainly IT companies that decided to give away software development and open their code to focus on customized development and services. Some commercial companies are considering Open Source like Borland which will participate to Eclipse project for generic software Some Open Source companies own copyrights for their code and the software they develop is available under both an Open Source license such as GPL and a commercial license. Open source developers can choose the Open Source license. But any companies that wish to incorporate the code in a proprietary product must pay for it under the commercial license. This business model is used by Trolltech AS, MySQL AB [7] and Sleepycat software. [8] Another's business model is a Software as a Subscription one whereby customers receive a certified build of Open Source software that comes bundled with technical support and maintenance as an annual contract.

Customers will purchase subscriptions with different options (degree and way of support, delay to deliver bug fixing).

One good example is Covalent. [6] modules and develop internally customized and differentiating SW modules [9] . If Open Source is not necessarily chosen, we can summarize by saying that software companies decide sooner or later:

not to compete on generic SW modules but on customized ones not to compete on SW modules but on their integration When a company delivers a software product, customers will require bug fixing and rapid problem solving which is not provided by Open Source communities. Todate, the growth rate of the main companies selling commercial and proprietary software is indeed the best proof that Open Source software will not replace commercial software soon [START_REF]Open Source Versus Commercial Software: Why Proprietary Software is Here to Stay by Shawn Shell Oct 14 2005[END_REF] . We will describe common issues faced by all software companies.

Commercial software

Open

2.5.1 Ownership of rights [START_REF] Välimäki | Evaluation of Open Source licensing models for a company developing mass market software[END_REF] Ownership of rights is fundamental and influences the company in pricing its software, in changing its licensing policy and in distributing software with different licenses. The risk when using Open Source licenses is that the license may involve conflict by diluting the perceived added-value and even by creating lock-in situation with the impossibility to re-license.

When software protection is covered by copyright two ways exists to clear rights:

-Rewrite an orginal version for the SW based on the non protected basic ideas.

-Obtain rights with a license contract specifying such rights. The latter is certainly the most pragmatic way to access to the software functionality

Certification

Certification and quality assurance are fundamental issues, difficult to solve but important to gain recognition from customers and even to raise barriers to entry. Many Open Source companies have built a branding image and developed certification programs to validate a company involvement in the community, the level of competencies of its developers, its code mastering and integration capabilities. (ex. Apache Software Foundation [12] , MySQL AB) Commercial companies are also delivering services to increase the value of their technology and control its image. SAP delivers training sessions and different sort of certificate grades, such as an interface certification program, consulting, and access to test systems [13] .

What are the common points with the upcoming AUTOSAR standard considering the different business model described earlier ?

3

The automotive industry : from traditional black box business to innovative business models 3.1 AUTOSAR : managing the complexity [14] The AUTOSAR partnership is an alliance of OEM and Tier 1 automotive suppliers working together to develop and establish an open industry standard for automotive E/E architecture. It will serve as a basic infrastructure for the management of functions within both future applications and standard software modules.

Figure : AUTOSAR Membership (June 2005)

The objective of the AUTOSAR consortium is to cooperate on standards and compete on implementation. This architecture presents a lot of points in common with the Personal Computer from IBM. And we can also see some common points with Open Source.

The main difference here is that all actors exist but no one can say how deeply their role will be affected.

Customer needs

Today the automotive actors are pushing forward the standardization through AUTOSAR in order to:

-Improve quality and reliability of the E/E systems -Manage the increasing E/E complexity associated with growth in the functional scope -Improve their competitiveness, by easing the implementation of innovative functions, developed by themselves or by third parties -Decrease the development costs, via software components reuse. -Optimize and master the scalable E/E solutions Tools for vehicle validation, for system modelization, for simulation and supporting the function partitioning with data exchange will become more complex.

3.3

Predictable impacts

On relationships

The current automotive embedded software landscape is composed of three major players: the OEMs, the Tiers 1 automotive suppliers and in some extent the software houses (software development companies). Today's relationships between these three actors are changing. Within an AUTOSAR framework, this representation could be impacted. The former bilateral relationship between OEMs and Tiers 1 is changing to a triangle including the Software Suppliers.

The OEMs and the Tier 1 are assessing the role that the software companies could play. It is thinkable to give them a major role to define the software architecture and the required tools for the implementation, configuration and validation. This is thinkable, but is it the unique solution?

The issue is to master a combination of expertise and it is crucial for the first years: automotive systems and electric/electronic architecture, automotive project management and real time embedded software engineering have to be mastered at once to insure the success of the first implementations.

In addition to the technical issues, the liability and the required initial investments seem to be a handicap for the software houses. Taking this situation into consideration, what could be the best scenario to supply value to customers.

Figure : Relationships of actors within AUTOSAR environment

The above figure points out the need to define the level of responsibility for all the involved parties.

It is today obvious that the level of responsibility is not the same among all these involved parties, whereas this aspect remains crucial within the evolving landscape. On one hand, the software suppliers will handle the responsibility only for their component delivery (and not to an extended scope).

On the other hand, if the Tiers 1 act as system integrators (implementing the TPS modules), they will handle the responsibility for the whole system and for the complete software platform delivery.

In addition, the role of each party for investigation in case of technical issue still to be precisely defined.

On Business Models

Consequently, a new business model has to be set up in parallel with the platform business. As this standard will enable developing and offering software Components Off The Shelf (COTS), AUTOSAR will split the current automotive business. Today's ECU business that consists of selling "black boxes" may evolve into a market of different stand alone products like:

-ECU and Hardware components -Software modules (basic layers and Application / Functions) -System integration -Associated Services (via dedicated Tools Chains and specialized methodology) -Project management

The additional services (like System Integration, Software Calibration or functional partionning at vehicle level) will increase in importance, as they are essential for a modular environment. Some of the OEMs are willing to delegate some parts of the system development due to the increasing complexity, the time to market reduction and the growing need of innovation Of course, the investment and risk sharing with the suppliers is still also a good motivation for the car makers. Consequently, only the suppliers offering strong cooperation during the entire development phases (including pre-development and co-design) with OEMs will be successful in the future. That's why the Siemens VDO AG platform strategy integrates a partnership development plan aspect with our customers in order to best fit with the impacts on the value chain. Siemens VDO AG has initiated such project. It targets on paving the way to offer our customers solutions to make a real step forward into new business models, legal aspect considerations as well as adapted technical processes.

Certification

The AUTOSAR consortium is working on the issue of an independent Conformance Test Agency (CTA). But with software each time minor modifications are realized conformance tests have to be done to validate the entire system.

To face those constraints different option are still open such as self certification or third parties certification.

Comparison between AUTOSAR & Open Source

AUTOSAR environment may seem, in a first insight, some common points with Open Source ecosystem explored earlier:

-Governance and decision process -Work packages organization -Search of innovative business model However a further analysis show that significant difference can be raised.

Firstly the Automotive industry being very concentrated can not be compared with Open Source adopter in Information Technology industry. As a consequence the community effect will not be leveraged and we know this is a key point in the success of Open source mechanism.

Secondly the AUTOSAR Consortium rules today does not allow Open source mechanism due to the restriction of some IP in the area of the members.

3.5 My "Open Source car", an utopia or a possible future ?

In any case Siemens VDO AG has to consider the different potential scenario to adapt the best to its customer needs.

Also in a longer basis the basic software may follow Open Source trends but this is only one of the possible scenario. This process of change of business models is defined with close relationships with customers to determine their needs and propose them suitable answers.

Liability

Concerning software products ownership of rights and liability are important issue:

-Responsibility and liability shall be defined by appropriate process, when a system supplier integrates third-party software or when software supplier provides third-party software to a system supplier

Migration plan

Given all these inputs, Siemens VDO is currently defining its migration plan internally and revising and adapting it to each customers according to the method described below.

Figure : Migration plan method

Conclusion

The AUTOSAR motto is: "cooperate on standard, compete on implementation". As we have seen in this paper, some analogies could be done with the fondations, mechanisms of Open Source initiatives. In a first insight the model could look like applicable in the automotive industries and even attractive. This paper developped the different restrictions could be raised.

The first requiremement is: the basis of sound business models need to be clearly established in a win-win approach with cultural changes in Tiers 1 but also with the OEMs.

Siemens VDO is exploring those different scenarios in order to propose to its customer the most innovative business models and to anticipate any changes in the industry. Siemens VDO AG intend to play a lead role in the definition of those business models to be always close to its customers needs in order to satisfy them.

Glossary

Commercial-Off-the-Self (COTS) Commercially available generic SWasP. Usually for a given function or infrastructure layer that can be purchased and integrated with low customization or no customisation, thus facilitating customer infrastructure expansion and reducing costs.

GNU General Public License (GNU GPL)

The first version was published Richard Stallman, a former staff member at MIT computer lab, in 1989 as part of the GNU project and it has since become the flagship of the so called free software movement. It allows free distribution and modifying but all bundled and derivative works must be under GNU GPL.

IP (rights)

Legal framework for protecting new technical solutions or software using patents, trademarks and/or copyrights.

Liability

Responsibility for defects caused by the software used in third party hardware.

License

A license is a contract that authorizes the right of use, or manufacture, or trade (exclusive or not) of an intellectual property title, without becoming the owner of the licensed product.

LF/RF

Long Frequency / Radio Frequency.

SWasP

SoftWare as a Product (SWasP) is a software product that is designed, developped, tested and marketed as a standalone product in the product portfolio of a company.

TPS:

Third party software , Software to be integrated in a System.

Warranty

Guarantee obligations specified into the Software License Agreement, by which one of the two parties guarantees the other one the enjoyment of the good or the right.

Figure :

 : Figure : Impacts on Business Model

Acknowledgement Many thanks to my colleagues for their support:* Expertise Support: Sébastien Calvez Bernard Sanchez Stéphane Fregosi Pierre Baroghel Reader : Florent Bonetto


D Breton

A Rossignol

Eurostar E3000 Satellite On-Board Software Development of a product line towards multiple system needs

Keywords: Reusability, Evolvability, Product line

The present paper describes how the on-board software for the telecommunication satellites family Eurostar E3000 contributes to the successful story of the product line. It encompasses a synthetic description of the platform and the on-board software functions and major requirements to support the different options and variants, how this generic software was efficiently developed and verified, how each instantiation for each new satellite program could benefit from the overall industrialization process.

Introduction

On one side main space programs are considered for avionics and on-board software as a new prototype every time. On the other side the commercial market pressure has forced satellite manufacturers to improve drastically their cost and their time to market. These market constraints are particularly true for the commercial telecommunication satellite market. To achieve such goals EADS ASTRIUM has decide to develop a very generic telecommunication satellite platform named Eurostar E3000 able to be customised for all major telecommunication application domains and missions. A new powerful and modular avionics was developed to be compatible with the performance range and the functional set of variants and options. The on board software running in the main computer was defined, developed and validated as a generic product line with a major objective to reduce as far as possible cost and schedule for each program instantiation and qualification.

Eurostar 3000 Telecommunication Platform

From Eurostar 1000 to Eurostar 3000

The latest version Eurostar E3000 inherits from the large development and in-flight experiences of the two first versions Eurostar E1000 and E2000 with 21 operational in-orbit satellites.

All the family was developed with a very modular design for efficient customised solutions covering a broad range from medium size (3 KW to 6 KW payload power) for E1000/2000 platform to large size (up to 12 kW) for E3000 platform. -This extra code is identified, made neutral and without side effects on board The E3000 Software product catalogue has been prepared as an input to the E3000 platform product catalogue: the structure is derived from the structure of the E3000 platform product catalogue to allow an easy mapping of information between these two documents. This SW catalogue is also a reference document for the "E3000 On-Board Software Alternatives Implementation" document which provides a detailed cartography of alternatives impacts in the E3000 SW and especially how the non selected alternatives are managed inside the SW (i.e. unused SW if any and in this case how its safety is ensured). The Figure 2.3 summarises the position of the different documents.

Scalable power system

Single or dual PSR concept range of 4 to 2x16 power modules Battery highly efficient Li-Ion cells or conventional NiH2 (4.5" or 5.5" cells)

Solar array :

3 to 5 panels per wing 2 panel sizes Propulsion all chemical (CPS tank size : 2450kg to 2900kg) or chemical plus plasma propulsion

Figure 2.2 -E3000 Platform modularity

Each alternative is described with the same structure:

Description: a summary of the functionality introducing the configurability provided by the alternative Categorisation: whether it is linked with a platform option or it is a functional alternative.

When it is a system option, its relevant name is provided.

Justification: an explanation of the reasons that caused that feature to be optional.

Reference: a list of the User Requirements Documents referring to this alternative.

Compatibility: a description of the compatibility issues associated with the alternative (i.e. compatibility with other OBSW alternatives).

Alternative selection: a description of what has to be done to select the alternative in terms of software (i.e. Database, numerical data, requirements documents …) after the alternative has been elected (i.e. all the system analyses has been carried out). In the process for recurrent E3000 OBSW, all the alternatives will be selected at user level through the "Alternative Inputs Nevertheless, some OBSW alternatives are linked together and some configurations are not recommended or even not allowed. In order to provide to proposal managers a quick overview of all sets of alternatives which have already been designed and validated together in the frame of programs, the document includes table presenting a mapping of selected OBSW alternatives in existing Satellite configurations: sets of alternatives that have proven their compatibility and preferred configurations (i.e. already developed).

Eurostar 3000 On Board Software product line

From an On Board Software (OBSW) production view point, Eurostar E3000 Spacecraft family represents a particular challenge:

• The development approach shall live for more than 15 years and support the production of On Board software versions for tenths of satellites involving various alternatives combinations.

(Software versions have already been produced for more than ten different Satellites. Satellite integration and avionic validation activities may typically involve four satellites in parallel)

•

The Eurostar E3000 family OBS production shall cope with evolution needs (for correction or enhancement purpose).

• EADS Astrium shall provide operational satellite customers with a maintenance/expertise capability.

Eurostar E3000 On board Software product line was settled to achieve these objectives. E3000 OBSW product line encompasses source code objects, data, tests scripts, tools and processes that allow maintenance, production and validation of OBSW versions for E3000 family satellites in an optimized way. The next chapters develop how each of these components contributes to achieve this goal through the basement of E3000 OBSW product line: architecture, source code and data management. • Program team

• Software team Another interesting feature is the existence of Interpreted Program (IP) allowing late or even inflight evolution with a large capacity to adapt code or data to a specific alternative need.

OBSW source code management

Alternative management in source code mostly relies on two methods: use of distinct objects or conditional compilation in a shared object. These two methods avoid the presence of unused software parts in the on board software. In some cases however, option management may lead to unused OBSW parts in the final on board software binary file. Dedicated analyses are then performed to make sure that such unused part of OBSW (that have anyway been validated at component level) cannot nominally be reached and that they do not include any action that could interact with hardware. More generally, for each alternative in the E3000 catalogue, a dedicated so-called Alternative Implementation Document describes how alternative is managed in source code and justifies the innocuousness of any unused validated Software part.

OBSW data management

Data management is an important part of the industrial process that had to be settled in the frame of Eurostar E3000. Various kinds of data are used for the production of On Board Software: numerical values, 1553 acquisitions and commands lists, Telemetry format definition… In the frame of E3000 OBSW product line, a data engineering activity was conducted. This activity first consisted in data categorisation. Several categories can be defined to sort out data: mission dependent data that do not depend on a software alternative (e.g. Attitude Control gains, sensor wedging), alternative dependent data that may or may not be mission dependent (typically the use of Proton launcher may require dedicated OBSW functions activated during Proton coast phase that require dedicated parameters), and other data that are not expected to be mission dependent (for example queue size parameters).

For each satellite application program, data are imported from system database or files into the source code at software generation by a dedicated tool called Production Program. Many OBSW functions do consume data that are expected to be mission dependent.

In the frame of E3000 OBSW product line that encompasses tenths of spacecrafts, the validation strategy for such functions is crucial. The industrial process that was settled for data management aims at fulfilling the following objective: data import into OBSW source code shall not question, to a The validation strategy at OBSW level for EUROSTAR 3000 recurrent programs consists in performing a fixed subset of the SVB tests defined in E3000 product line validation plan. The corresponding test campaign is called "acceptance test campaign". The acceptance test subset encompasses about one third of the complete EUROSTAR 3000 product line validation plan. (Note that the SVB procedures have been previously automated in the frame of the E3000 OBSW product development and that the validation on SVB is in fact a regression testing activity)

The validation of most data to be validated at OBSW level is ensured by the acceptance test subset. OBSW validation level Data not covered by acceptance campaign are clearly identified. An analysis that consists in checking the value of such data against the values already validated in the frame of E3000 product line is conducted in the frame of each recurrent program. Should an unprecedented value be encountered, the dedicated tests to be run in order to validate this new value are identified in advance in the Data Verification Control document. (That latter document identifies the tests that contribute to the validation of each OBSW data)

The acceptance test subset provides a large coverage of the OBSW functions for non regression / good health verification purpose. In particular these tests exercise as many functional level data as possible (though the responsibility of the validation of these data belongs to functional validation).The development plan for a recurrent program (that may involve unprecedented combination of alternatives and specific data) includes a unique OBSW version delivery. The production, the validation and documentation of this version is achieved in less than 1500 hours of manpower.

Data types

Type

Acknowledgement

The authors acknowledge the contribution of Mrs Dehaynain, Mr Gaullier and Mr Palous to this work.

Glossary

AOCS

E2000+ characteristicsoo

  Figure 2.1 -Eurostar satellite series

  Figure 3.1: E3000 OBSW architecture

1 -Eurostar satellite series

	2.2 The latest generation Eurostar E3000
	The latest Eurostar version, the E3000, already
	chosen by satellite operators Eutelsat, Hispasat,
	Inmarsat, Intelsat, SES Astra, Paradigm and Telesat
	and successfully introduced in orbit in 2004, is
	setting new standards.
	The following improvements have been introduced in
	the EUROSTAR 3000 platform:
	o Increase launch mass, by designing a scale -up
	structure of the heritage design, which is
	capable of up to 6 tons launch mass with
	conservative design margins.
	o Improve critical platform performance such as
	pointing by implementing a 2 DOF AOCS
	system,	propulsion	performance	by
	implementing the flight proven plasmic
	propulsion technology.
	o Improve operability and autonomy by using
	additional computer capacity to implement user
	friendly system interface and a complete and
	comprehensive FDIR approach.
	o A design for manufacture and test approach has
	been followed with extensive participation of
	manufacturing and AIT during all phases of the
	design.
	The E3000 platform is characterised by its
	modularity:
	• A common Service Module design
	• A large level of modularity with generic elements
	o Communication module with one, two or
	three floors
	o Propulsion : chemical only or chemical +
	electric (Plasma), several tank capacities
	from 2.4 to 2.9 tons
	o Power :

scalable solar array, NiH2 or Li-Ion batteries • Satellite power up to 16 kW : solar array span up

	2.3 The Eurostar E3000 software product catalogue
	and alternatives
	The E3000 new product development policy was
	established to meet various telecommunication
	program requirements:
	• It leads to a Platform product catalogue with
	options,
	• At Software level (definition and implementation)
	the driver was to make a generic product to the
	maximum extent and to customize this product
	through data (database to the maximal extent) in
	the frame of a dedicated program,
	• This approach is the most effective in terms of
	planning and cost and enables strong heritage
	between programs
	• The counterpart is:
	-The SW is not exactly tailored to a
	specific program needs but to a family of
	needs fulfilled by a set of SW
	alternatives
	to 45 m

-At SW generation, the generic product is customized to fit a program's needs (alternatives selection)

-Customisation may lead to extra code (in the frame of a dedicated program)

  Table" in the program specific GURD.

	TM/TC options (Sub-carrier, bit rate, protocols,
	authentication or not)
	Payload Configuration
	Power system configuration (Solar arrays,
	Battery, Number of modules, Single or Dual)
	Actuators configuration (Chemical and Plasmic
	propulsion, thrusters, CPS tank size, number of
	wheels)
	GNC modes ( Inverted attitude, Transfer orbit,
	Orbit inclination )
	Thermal	loops	configuration	(Number,
	frequency, monitoring, thresholds)
	This OBSW catalogue allows many spacecraft
	configurations.
	Improvement : a list of proposed improvement
	dealing with the alternative management
	(specification, design, selection …)
	Development status: the level of the
	definition/development of the alternative. A
	description of the work to be performed to
	finalise the production of the software.
	Maturity: the level of verification / validation of
	the alternative. A description of the work to be
	performed to finalise the verification.
	About twenty platform options are defined and
	available at system level spread over all sub-
	systems:

2 -OBSW data types and associated validation 5. Conclusion

  Automatised production of source product for each program, o Suite of integration and validation tests with minimised effort for "rerun" on a specific program instantiation.

	definition These data do not depend on any alternative but their value, provided by subsystem architects, may depend on the mission. These data are the parameters used in software to define which alternative are involved in the mission. These data depends on an alternative and are provided by functional subsystem architects for each mission. This category gathers data such as Telemetry format definition. Data imported in software that correspond to an alternative that is not used for the mission. Alternative dependent data that are derived from software design (not functional data). E3000 Software data Software non functional data that are E3000 Study data TYPE 2A ALTERNATIVE TYPE 1 Definition data TYPE 2B ALTERNATIVE Study data TYPE 2C ALTERNATIVE Operation data TYPE 2D ALTERNATIVE Unused data TYPE 2E ALTERNATIVE Software data TYPE 3 derived from software design and may change between missions. TYPE 4 E3000 Software constant Software non functional constants that are derived from software design. TYPE 5 ALTERNATIVE Database interface Commands or acquisition definition that depend on alternatives or mission (e.g. list of command to be sent to configure equipments). efficiency and the in-flight successful operations are essentially due to: a well managed process starting from the system level to the avionics and software development level including definition, design, production and validation activities, a completely structured set of options and variants (so called alternatives) defined at system level in a catalogue and at software level by design, source and data management types definition with associated validation and verification objectives, a complete and powerful set of means at software level: o Source code and data configuration management, o Complete and modular documentation, Figure 4.The on board software "recurrent" development o	Test level functional software functional functional software software software software functional

:

  Attitude and Orbit Control System DOF: Degree Of Freedom E3000: Eurostar 3000 FDIR: Failure Detection, Isolation and Recovery IP: Interpreted Program MDM: Mission Data Management OBSW: On Board Software SVB: Software Validation Bench

maximum extent, the OBSW validation of the concerned function.

To achieve this goal, the process impacts data population methods, code architecture, and validation. Mission dependent data are provided by the application program project team. Data population tools based on Excel file templates called Numerical Input Documents (NID). Macros have been designed in order to ensure that data are populated in a consistent way for all spacecrafts. These tools enable typically automatic population of alternative dependent data. The populated information is then automatically transferred to the system database (data of that category are called "data lists").

From a validation view point, the objective of the software validation for objects including data lists is to demonstrate the ability of importing and handling such data lists whatever their content is so that data list content evolution does not require the function OBSW re-validation. Data validation will be developed further in the next sections. A dedicated document, called Mission Data Management documents (MDM), depicts the NID structure, population constraints, and the way to deal with data population for alternative dependent data. Anytime a software modification is performed (for product evolution or correction purpose), all impacted component and integration tests are updated and run before making the OBSW modification available for any application program.

OBSW validation for a "Recurrent" Program

Once the software product line is validated, the following spacecrafts OBSW validation strategy follows a so-called "recurrent" approach. Since source code has been validated in the frame of the available product line, the validation for recurrent programs shall mostly concern data validation.

The recurrent data validation strategy elaboration first consisted in reviewing all data and sorting them into several categories according to their origin, their functional meaning and at which level they shall be validated (OBSW or functional). OBSW level validation shall be covered by OBSW Validation Bench (SVB) tests, functional level validation may be performed on Avionic test bench or functional simulators as part of the satellite avionic test campaign. Figure 4.2 summarizes the data categories.

Data to be validated at functional level shall nevertheless be preferably exercised on SVB. It means that the SVB validation is performed with the data inputs which are contained in the SW image to be delivered (i.e. same data for SVB validation and for functional validation).