Michael Beine

Michael Jungmann

Michael Jungmann Code

Code Generation for Safety-Critical Systems

teaching and research institutions in France or abroad, or from public or private research centers.

Introduction

The number of safety-critical systems in vehicles is rapidly increasing. A few years ago, the failure of a computer system in a vehicle would in the worst case mean the loss of a function, but in the systems of the future, the wrong reaction to a fault may be a safety hazard for the vehicle's occupants and other road users.

To cope with rising demands, such as the growing number of electronic systems in a vehicle, increasing complexity and shorter time-to-market, the automotive industry is increasingly adopting model-based design methods and using automatic code generators for software development.

In contrast, automatic code generators are hardly ever used for the development of safety-critical systems. Firstly, very special requirements are imposed on the code for safety-critical systems. Secondly, many software suppliers are only just beginning to apply appropriate development standards, and so they cannot tackle the introduction of automatic code generation at the same time.

However especially the high complexity and functional requirements of safety-critical systems demand the use of modern tools for developing, designing, implementing, verifying and validating such systems.

It is natural to rely on experiences from the aviation industry when developing safety-critical systems for automotive applications. In the aviation industry for several decades programmable systems have been used for flight control, aircraft engine control, landing gear control etc.. The safety and reliability requirements of these systems are comparable with steer-by-wire or brake-by-wire systems which are currently under development in the automotive industry.

Safety Standards for Safety-Critical Systems

To minimize the dangers of safety-critical systems, special development standards and processes have been designed for use in such applications.

All safety standards define a set of activities that have to be carried out in order to achieve a desired safety level. Those activities can be generally grouped into three categories: selecting development methods and tools, implementing the system, and verifying and validating the system.

The standards differ regarding their perspective on the system to be developed. Some standards cover the development of the overall system. Among them are IEC 61508 and ARINC 653. Other standards like RTCA DO-178B and DoD-2167A only deal with the development of the software, but are more detailed.

The established standard in automotive electronics is IEC 61508 [START_REF]Functional Safety of electrical/electronic/programmable electronic safety related systems[END_REF]. This is a generic safety standard that requires the definition of more detailed standards for specific industries and projects. Software engineering studies have shown that the RTCA DO-178B [START_REF]B Software Considerations in Airborne Systems and Equipment Certification[END_REF] software development standard, originally defined for the aviation industry, is also a suitable detailed standard that corresponds to the IEC 61508 safety standard [3 et al].

Michael Jungmann

MTU Aero Engines GmbH, Munich, Germany

A Suitable Software Development Process

Most of these standards follow the well-known V-cycle, since the number of listed requirements barely leaves room for choice. Figure 1 shows the software development process for safety-critical systems organized according to the V-cycle. The left side of this V-cycle describes the implementation path. It starts out from high-level requirements and becomes more detailed at every step through to the creation of actual production code. The right side represents the verification path, in which each verification phase is shown opposite its corresponding implementation phase.

Model-Based Design

Using model-based design methods and tools for implementation has tangible benefits. System requirements analysis is the first step on the implementation path. All functional and non-functional requirements for the system are expressed. Using model-based design methods and tools for implementation results in an executable specification, which has many advantages over a purely textual specification. A model-based specification meets the requirement of IEC 61508 to use a semi-formal method for specification, which is required because it leaves less room for interpretation than a textual one, thus reducing the possibility of misinterpretation and error. It allows a seamless continuation of the implementation path and naturally connects its different phases. With model-based design the system behaviour can be assessed and tested in every phase of the implementation, allowing to find and fix undesired behaviour and errors early on.

Verification Activities

The first phase of the verification path is the unit or module test phase to verify the production code and the smallest functional blocks in the executable software. The activities in this phase include static analysis and dynamic testing of functionality. Software integration testing, acceptance testing and system integration testing complete the verification path.

The activities to be performed in each phase differ only slightly in the individual standards. However, all standards have one thing in common: The objective of safety can be achieved only by systematically performing all the activities. Taken on its own, no individual step within this process allows the quality of the developed software to be assessed.

Role and Benefits of Automatic Code Generation

In any study of automatic code generation the focus is on the coding and the unit testing phase. Coding marks a cornerstone in the software development process; automatic code generation is the key technology in this devel opment phase. There are several reasons for using an automatic code generator in the development of safetycritical systems.

Using automatic code generation is natural once the software design is already available as an executable specification. A code generator can convert this executable specification with a lower implementation error rate than a human programmer. Every manual translation step is prone to errors and is time consuming. The potential for introducing errors is high, especially when going through iterations and making successive changes, and consistency between the software design specification and the code is often lost. This is not the case when using automatic code generation. A code generator translates the model and changes made to the model to code reliably, reproducibly, and constantly day after day. It ensures that the generated code is always consistent with the software design. Furthermore, since the documentation can typically also be generated along with the code, it is easily kept up to date as well. Thus with automatic code generation the software design, the implementation and the documentation are automatically kept in sync.

Using a code generator is no guarantee for getting error-free software. There is no formal proof that there will never be a coding error, since there is an infinite number of combinations of modeling constructs and parameters. On the other hand, a well designed and tested code generator produces significantly less programming errors than human software programmers do. While software programmers might have good and bad days, the automatic code generator performs its task with the same level of quality every day. The code generator learns with every improvement made and from every bug that has been fixed and never forgets.

Quality and Reliability Aspects

The quality and reliability of any tools used for the development of safety-critical systems are of special importance.

Pros and Cons of Tool Certification

IEC 61508 requires that any tools used must be either certified, or proven in use, or that a justification for their use must be given. Certification involves undergoing a procedure under a national or international standard, which is not specified in greater detail. One applicable standard is the above mentioned RTCA DO-178B. This gives users two alternatives. One is to have the code generator itself certified according to RTCA DO-178B, which might enable developers to cut down on the volume of verification activities. However, such cuts would apply only to individual activities in the unit or module testing phase and are project-specific. General omission of a verification phase is not normally possible. Certifying the code generator presupposes that a certifiable code generator exists, i.e., the development documentation for the code generator must have been created and supplied by the tool vendor according to RTCA DO-178B at the same level that is applicable for the application software. Moreover, the code generator requires a system-specific certification, in which the interaction between the code generator, compilation system and target processor is tested. SEQARABE This all involves an enormous workload, which is reflected in the cost of a certifiable code generator and of projectspecific certification. The price of a certifiable code generator is between five and ten times higher than that of an uncertified one. Project-specific certification involves extra costs, which can be between € 50,000 and € 100,000. Moreover, the certification procedure for a code generator is also very time-consuming, and the maintenance cycle for such a generator is currently around two years, while approximately three months are sufficient to produce a corrected version for an uncertified code generator.

The alternative way is to subject the application software to all the prescribed verification activities as if no code generator had been used in its creation. The verification process used for this can also find errors that might be introduced by an automatic code generator. This approach does not involve the disadvantages described above, and is also more cost effective for most projects.

Conformance to Software Quality Standards Systematic development and system testing of ECU software is of paramount importance. The "Hersteller Initiative Software" (HIS), a German automotive OEM initiative consisting of Audi, BMW, DaimlerChrysler, Porsche, and Volkswagen, demands that ECU development and the development of major software tools comply with ISO/IEC 15504, also known as SPICE ("Software Process Improvement Capability Determination") [START_REF]Information Technology -Software Process Assessment[END_REF], [START_REF] Wagner | Hersteller Initiative Software[END_REF]. SPICE has been defined by a working group of ISO/IEC on the basis of existing quality standards and combines ideas from ISO 9001 and CMM. SPICE requires that formal process assessments be performed by an independent organization on a regular basis. The assessment results are then used to derive process improvement activities. When the standard is followed and a high level of compliance is achieved there is a good chance that the software produced will be of high quality.

Since a code generation tool is a complex piece of software and has a substantial impact on ECU code, this demand is valid also for a code generator.

Code Generator Requirements

Using automatic code generation for the development of safety-related software imposes several requirements on the code generator.

Code Requirements

For example multiple and very special requirements are imposed on the source code for safety-critical systems. Among them are

• the restriction to a subset of the programming language used which is deemed safe, • restricting control and dataflow structures to precisely specified variants,

• following accurately specified rules regarding the scope of functions and data,

• following predefined complexity measures, and • the readability, maintainability, and testability of the source code.

Such demands on the code quality are defined in the MISRA C guidelines [START_REF]MISRA Guidelines for the Use of the C Language in Vehicle Based Systems[END_REF]. This is a generally accessible standard for the use of C in ECU projects up to SIL 3 produced by the British "Motor Industry Software Reliability Association". Its title is "Guidelines for the Use of the C Language in Vehicle-Based Software" but it is commonly referred to as "MISRA C". Depending on the certification process chosen, these requirements also have to be met by the automatically generated code.

Furthermore there is the demand that the generated code must not use significantly more memory and execution time than hand code. Missing efficiency for a long time has been the reason why automatic code generation has not been applied in production.

Process Integration

To fully enjoy the benefits of automatic code generation, the code generator has to be optimally integrated into the development process and tool chain in use. Seamless integration and interaction with the model-based design tool is self-explanatory. Furthermore open interfaces and the possibility for tool automation are useful to connect with other tools, automate work steps, and to prepare and support later development phases, e.g. the succeeding unit and module test.

The Production Code Generator TargetLink

In the following the production code generator TargetLink is used as an example.

TargetLink for Safety-Critical Systems Development

The design and simulation tools most widely used in the automotive industry are MATLAB ® , Simulink ® and Stateflow ® . Data flow models are described in Simulink, while Stateflow is used for the control flow parts. Simulink and Stateflow are integrated, and allow a mix of both types in one model. TargetLink, the production code generator from dSPACE, is seamlessly integrated into MATLAB and allows reliable conversion into C code of software designs that are available as Simulink/Stateflow models.

A major advantage of using model-based design methods and tools is the capability of early verification by means of simulation. TargetLink supports different simulation modes which allow the correctness of the implementation, i.e. the code generated by TargetLink, to be tested directly. This is done by comparing simulation results with results from reference simulations, frequently referred to as model-in-the-loop simulations (MIL). This verification can be performed stepwise:

• First, the generated code is compiled with a host compiler and executed on the host PC; this is also known as software-in-the-loop simulation (SIL). • Then simulation is performed on an evaluation board equipped with the target processor. Therefore the generated code is compiled with the actual target compiler; this simulation mode is called processor-in-the-loop simulation (PIL).

In all simulation modes TargetLink allows signal traces of block outputs to be logged. These signal traces can be saved and plotted on top of each other, thus providing direct visual feedback and allowing further analysis. 21 -22 -23 January 2004 The user has full control over file and function partitioning. This allows code for specific model parts to be generated in separate C functions and files. These model parts can also be implemented and tested incrementally. This has the advantage that when changes are made, it is not necessary to regenerate and test the code for model parts and software modules that have not changed.

SIL and PIL simulation are complemented by code coverage analysis. The coverage types currently supported are statement and decision coverage. All this means that extensive support is given to the unit or module testing phase, including model parts that are generated incrementally.

The code generated by TargetLink can well match human programmers efficiency in terms of memory consumption and execution speed since TargetLink has been specifically designed for production coding. Numerous benchmarks and user experience reports show that in most cases TargetLink is within a narrow range of what the human programmers produce. Furthermore it complies with most of the 127 MISRA rules. MISRA expressly permits deviations from the standard if they are technically justified and documented. Such a compliance document that describes deviations from the MISRA standard is published by dSPACE [START_REF] Thomsen | Integration of International Standards for Production Code Generation[END_REF].

A comprehensive and fully documented API grants access to all TargetLink properties and settings. It allows all processes to be automated, while at the same time providing options for intervention in the individual process phases. For example, so called "hook functions" allow user tasks to be performed at all stages of the build process.

Software Quality Assurance for TargetLink

Special attention is paid to quality assurance during TargetLink product development. For maximum reliability and quality, comprehensive tests are performed before each release of a TargetLink version.

• Automatic test engine run: Several hundred thousand code patterns are tested and several million test points are run through. These tests are repeated for every processor that is supported separately. • Automatic test suite run: This test is run on several thousand models. Different input values are used and parameters are varied to produce more than a hundred thousand test cases, whose results are compared with expected values. • Semiautomatic system test: This is to check the installation and correct functioning in different PC configurations and in interaction with different MATLAB and compiler versions.

• Manual testing with customer models: Tests are performed using large, real ECU models and evaluated manually. A beta test phase is carried out with selected customers before official product release. When TargetLink is delivered to customers, it is already to a certain extent 'proven in use'.

Particular emphasis is placed on a mature development process for developing TargetLink. To secure, improve and certify systematic development TargetLink is developed according to SPICE, as required by HIS, the German manufacturers' initiative for software. Compliance is monitored by an independent auditor. The scope of auditing is also specified by HIS.

Additionally, both the development process and the release tests are supervised by an independent in-house software quality management team.

User Experiences

TargetLink has been used for many control applications worldwide. TargetLink code is in production in many applications, some of which are safety-related. For example TargetLink has been used to develop a cabin pressure control system. Therefore TargetLink generated code was certified according to RTCA DO-178B Level A, the highest safety level, meaning that a failure would have catastrophic consequences for the aircraft [START_REF] Aloui | C Code Reaches New Heights at Nord-Micro[END_REF].

In the following the use of TargetLink at ATENA Engineering for the development of safety-critical software is described.

Experiences with Safety-Critical Systems and Automatic Code Generation at ATENA Through close cooperation with its parent company, MTU Aero Engines GmbH, ATENA Engineering has decades of experience in developing safety-critical systems in the aviation sector to fall back on. For example, MTU Aero Engines GmbH has developed and produced the engine controllers for a number of European aviation projects, and is still actively involved in such work. The aircraft engine controllers are multi-channel electronic control units (ECUs) with between 4 and 10 processors. The response times needed for control are in a range of 2 ms. RTCA DO-178A [START_REF]DO-178A Software Considerations in Airborne Systems and Equipment Certification[END_REF], along with its predecessors and project-specific derivations, has been the standard for developing such systems for many years. ATENA as a subsidiary of MTU Aero Engines offers engineering services both to the aviation industry and to automobile manufacturers and their suppliers. This constellation means that ATENA is in a position to apply software development standards comprehensively to safety-critical systems in automobiles. SEQARABEMTU Aero Engines as well as ATENA have had comprehensive experiences with automatic code generation. Both have performed detailed evaluations of different code generators in the past. The focus was on the applicability for the development of safety-critical systems according to RTCA DO-178B Level A and IEC 61508 SIL3 respectively. Central points of the evaluations were:

• Integration into the overall development process • Quality and efficiency of the generated code • Flexible and comprehensive configuration options of the code generator Application of TargetLink at ATENA Because of the disadvantages described earlier, ATENA decided not to use certified code generators for safetycritical systems. Instead, complete verification of the application software is performed, and the verification process itself is automated as much as possible. Nevertheless, great importance is placed on the quality and reliability of the code generator used. Quality characteristics that do not involve the disadvantages described above, such as a development process that complies with ISO/IEC15504 (SPiCE), are regarded as important.

At ATENA model-based design using the MathWorks tools MATLAB, Simulink, Stateflow was already established. Therefore a search has been made for a code generator that integrates well with this modeling tool suite.

A thorough evaluation of the available code generation tools led to the decision to use TargetLink for the software implementation of a safety-critical system according to IEC 61508 SIL3. It is an automotive application related to alternative fuel concepts. The volume of the related Simulink model is approximately 120,000 subsystems. The software components are up to 25,000 code lines in size. The main reasons for this decision were TargetLink's technical features as well as its high product quality.

In order to integrate TargetLink into the software development process, ATENA made several adaptations to the code generation process. These were aimed at further automating the generation process and achieving the necessary software quality for safety-critical applications. The adaptations included the greatly reduced use of pointers and interrupts, compliance with various complexity criteria and replacement of "function-like" macros and functions from the standard libraries by user-defined functions. Work was also performed on enabling such complex systems to be broken down into subsystems and translated separately, and on allowing generation of standardized description files for calibration tools for the subsystems. The test frame software for testing the individual modules was also automatically generated for preparing the unit testing phase. The adaptations were supported by the Tar-getLink API. It allows all the processes to be automated, while at the same time provides options for intervention in the individual process phases and access to all TargetLink properties and settings.

The software development process, whose implementation phase is being given decisive support by dSPACE's TargetLink, has now been in use at ATENA since November 2002. Automatic code generation plays a major role, as the company has succeeded in generating up to 80% of the entire production code from Simulink models. The code generator is embedded in a project-specific tool chain. This guarantees compliance with the quality criteria for safety-critical applications.

Recently, ATENA delivered the final product for the first development phase for integration tests at the OEM's facilities. From this first development phase the following experience was gained:

• The model-based requirement analysis and design phase led to an executable specification which allowed early system verification. This resulted in a mature specification. Later software tests revealed only few errors that originated from the specification. • The automatic code generation allowed the implementation of the software design with a low error rate and with high efficiency especially for minor modifications. • The source code generated by ATENA's software development process with dSPACE's TargetLink as a key item is of acceptable quality for safety-critical applications.

Based on the evaluation results also made at MTU Aero Engines and the project experiences made at ATENA, it is planned to use TargetLink also for future avionics projects at MTU Aero Engines.

Summary

Automatic code generation complementing model-based design provides many benefits for the user and can be applied for the development of safety-critical systems. It is suitable for software that has to comply with safety standards when embedded into an adequate development process. There are several requirements imposed on the code generator relating to quality and technical features that have to be met.

TargetLink, the production code generator from dSPACE, meets these requirements and therefore is also a suitable code generator for the development of safety-critical systems.

ATENA Engineering opted for TargetLink due to its technical features and quality level. At the same time ATENA decided to use a code generator with fewer qualification options, but to perform complete qualification on applica

Figure 1 :

 1 Figure 1: The V-Model for software development

Figure 3 :

 3 Figure 3: Work reduction potential when using a certified code generator

Figure 4 :

 4 Figure 4: Model-, Software-and Processor-in-the-Loop simulation for software verification

Figure 5 :

 5 Figure 5: Customer benchmark comparing TargetLink code with handwritten code on different target processors In addition TargetLink code is easily readable and has many comments, enabling the user to go back from the code to the model. Unnecessary macros, function calls, cryptic naming etc. are avoided. Comprehensive configuration options give the user full control over variable, function and file naming, as well as the flexibility of partitioning the code into functions and files to keep the structure logical and manageable. Thus TargetLink code can be subjected to code inspections and reviews.

-22 -23 January 2004

21 -22 -23 January 2004 tion software. This alternative is considered to be more cost effective than using a code generator which is fully qualified.

Authors


Günter Gromeier
email: guenter.gromeier@etas.fr

come

Session 3: Business Models Business models for software components in the automotive industry

Introduction

Electronic control units (ECUs) are today the standard solutions to manage and control highly complex control tasks in modern vehicles for applications like powertrain, security, comfort and car-multimedia. The increasing complexity of these applications generates continuously increasing requirements and demands regarding the performance and quality of these ECUs. One of the consequences is that the part of the requested embedded control software will increase at an over proportional rate. According to recent studies the relative part of software compared with the total value of a vehicle in 2010 will achieve 13% (HypoVereinsbank / Mercer Study, 2001).

Today the development and business processes for ECU hardware, sensors and actuators (or more generally for all material parts of this control system) are managed relatively well. On the other side the handling of the new and evolving processes for the development and especially the commercialization of embedded software are one of the major challenges for the automotive industry. The definition and implementation of adapted business models for "embedded software" is of interest for all companies that are involved in this business processes. The possible business models must not only cover the corresponding cost issues (e.g. for development, patents, production) but have to deal as well with a rather unclear legal situation and with the automotive specific warranty and liability aspects.

How shall in such an environment a manufacturer of software components earn enough money to run a profitable business: by directly selling this products, by giving this products away for free and earning money with associated services, by the exploitation of associated rights and patents or a with combination of all of this possibilities.

The most important European car manufacturers, suppliers and tool providers in this area (in total 23 partners from 4 European countries) have faced some of these technical and economical challenges in a common European project. This common project is the ITEA 1 -project: "EAST 2 -EEA 3 Embedded Electronic Architecture". The major objectives of this project are the definition of a common middleware and of a software architecture description language. A further workgroup in this project analyzed "Intellectual 1 Information Technology for European Advancement 2 Electronics Architecture and Software Technologies 3 Embedded Electronic Architecture Property Rights and Commercial Issues" related to the introduction of this new technologies. The knowledge acquired and the data collected in the context of this subproject had a high impact on the considerations presented in this paper.

These findings together with some general reflections about business models will lead to an evaluation of strengths and weaknesses of various commercial and financing models. This evaluation could become a guideline for establishing and improving ones own business models. This paper will give in a first part an overview about the general structuring of an ECUs software and of a network of ECUs, as it is currently used in modern vehicles. The following part will present the needs of the European automotive industry concerning the new upcoming business models for exchanging and trading embedded software. Afterwards some general considerations about business models will be shown followed by an evaluation of different types of commercial models. The final part of this paper will present some aspects related to the dynamics of business models and give some recommendations as well as an outlook.

Embedded software in the automotive industry

Modern vehicles integrate today a high number of features and functionalities. The operation and control of this various subsystems is mainly ensured by electronic control units. Even if some applications are still operated by a single, independent ECU, the major part of a vehicles functionality is controlled by a network of ECUs (Figure 1). A good example for a networked operation is the TCS/ASR 4 system -a functionality ensured by the engine and the break control systems. The ECUs themselves have to ensure a complex interaction between electronics and software. A major part of control system innovations is realized today directly with a more and more complex software functionality. This ever increasing complexity requests a good structuring and organization of an ECUs software. Conventional programming techniques are replaced my modern approaches based on defined software architecture concepts.

When taking a deeper look into the embedded automotive software, one can identify blocks for basic functions like communication drivers or peripheral access routines as well as blocks for actual controlalgorithms. Some other programs are ensuring the scheduling of functions end the exchange of data between the various software blocks. These different types of software components are shown in a typical representation for 2 networked ECUs in Figure 2. The technical management of this software related aspects is quite complex and is requesting a close cooperation between all involved participants. Their objective is to establish a common software technology which is supported by corresponding processes and powerful development tools. One of the results of these activities is an increasing share of software components between applications, ECUs but as well between the different project participants. The first two mentioned software sharing aspects are of a rather technical nature and addressed by the previously mentioned activities. The share of software components between business participants is mainly driven by economic factors and asks therefore for a clarification and definition of the upcoming business processes.

When concentrating on the details of this upcoming business processes it has to be mentioned that currently the business processes for ECU hardware, sensors and actuators (or more generally for all material parts of this control system) in the automotive industry are managed relatively well. On the other side the handling of the new and evolving processes for the development and especially the commercialization of embedded software are one of the major challenges this industry is facing.

The today's most common business model for selling embedded software in the automotive industry is to sell the software in combination with hardware, where the main value is attributed to the hardware components. Software is seen as a more or less necessary add-on. However things are changing and the value of software is being recognized more and more. But what is the appropriated value of such software components and Appl. 8

• • •

Appl. 5

ECU B

Appl. 6

what kind of price model should be applied? Approaches based either on directly applying the software development costs to the final control unit price or using royalty price models have not shown the expected success in the automotive industry. Furthermore the software business models have to take into account that costs are mainly related to the development of the software whereas the corresponding production costs are very low and warranty costs could be quite significant.

Before further concentrating of the details of the various business model possibilities, a basic aspect has to be analyzed more in detail: the general architecture of the embedded software of an ECU (or of a group of ECUs) from an economic perspective. The structuring into different parts of this software will eventually determine which of the components could be traded independently of the ECU hardware. Figure 3 shows a possibility for structuring software components in an economic context based on the possible technical solutions presented previously in this paper.

Figure 3 Categories of software Componentsan economic / business perspective

The different software categories according to this classification are:

• Hardware specific components (which will be provided mainly by the ECU or hardware suppliers, e.g.

hardware abstraction layer -HAL, device drivers, I/O drivers) • Standardized components (commodity like components which are available on the free market, e.g. operating system -OS, communication layer) • Application software components (components that contain functionality and business differentiating elements and will be provided by vehicle manufacturers, ECU suppliers as well as third party suppliers) • Middleware (a special type of software structure that enables the previously mentioned separation and by this the models in question, will not be considered for the business aspects -is rather an enabler for this) These categories of software components will serve as a basis for the following considerations in this paper. embedded software as a standalone product in the automotive industry is rather low. Some first experience was gathered in the context of the introduction of standardized OSEK5 operating systems. The applied business model concepts, that were adapted from other industries did not show the expected success and put the software suppliers in a rather complicated situation.

Needs of the European automotive industry

As already mentioned the most important European participants in the automotive software business came together in the context of the ITEA-EAST project and analyzed the business requirements in a subproject called "Intellectual Property Rights and Commercial Issues". The main approaches applied in this subproject were surveys performed within the participating companies in order to evaluate their corresponding needs for the upcoming business models. The involved companies participated in the definition of the surveys (and by this in the identification of the most important issues) as well as in the following realization of these surveys.

The companies that are mainly driving the conditions and requirements in this business context are the vehicle manufacturers. The major findings regarding their needs and expectations will be presented in the following. In order to get a representative assessment of their needs various members of these companies were involved in the survey including technical persons but as well management and business representatives.

Considering the main objectives of the survey the various questions had to follow a certain logical flow. Firstly, it was important to clarify the motivation of and the value for a vehicle manufacturer to be involved in the development and trade of embedded software. Secondly the corresponding business position of the vehicle manufacturer had to be identified. E.g. whether he is interested in producing himself embedded software. Will he be involved in the trade of embedded software or is he considering that this is rather the task of the various suppliers? Depending on the result of these basic questions, further details had to be clarified. These are related to technical, organizational, financial, intellectual property, process and cooperation aspects. The basic structuring of the vehicle manufacturers survey was as follows:

• Motivation -reason why -value creator In the following some top findings of this survey will be presented. Starting with the motivation of vehicle manufacturers, they confirmed that they will participate themselves in all important activities regarding software components or would like at least to acquire the competences for specification, test and creation for embedded control systems processes. Their objective is to be able to take buy or make decisions according to their internal strategies.

Figure 4 shows one of the findings concerning the business position vehicle manufacturers will adapt. Of very high importance are some forms of reglementations in their relations with their suppliers.

How do you rate your prescriptions for your suppliers regarding the integration aspects of embedded software?

0 2 0 4 0 6 0 8 0 1 0 0
No reglementations regarding the use of a predefined embedded software architecture for suppliers.

Prescribe and enforce (only) the use of a defined embedded software architecture per control unit. Suppliers are free to write their own software and/or choose their software vendors.

Enforce the use of a standardized software architecture and provide the basic embedded software modules to the suppliers.

% of participants

agree not sure disagree

Figure 4 Prescription models for suppliers

When looking more precisely at the technical aspects vehicle manufactures will mainly build software components in the application category but would like to be active as well in some further areas. Figure 5 shows the opinion of vehicle manufacturers concerning the responsibilities for providing different software component categories by the various business participants.

Which type of software components will be provided by which business participants according to your estimation? Organizational aspects were considered as rather confidential and can not be presented in the context of this paper. Figure 6 gives some important indications about the interests of vehicle manufactures concerning commercial and purchasing aspects. The figures show that most companies are rather neutral concerning these issues. However buyouts seem to tend in the direction of preferred models. According to the survey open source based business concepts seem to have little impact as possible business cases in the automotive industry.

Possible commercial / purchasing models for the acquisition of software components 0 2 0 4 0 6 0 8 0 1 0 0 Pay per use -costs are due only if the corresponding software component will be used for a certain time (possible uses cases in car-multimedia applications or remote diagnostics).

Subcontracting to external companies -your company subcontracts in this model the development of software and acquires all rights in the further use of this software.

Linked to yearly ECU budgets -the acquisition price depends on the yearly planned budgets for ECU projects (mixture of buyout and royalty approach).

Royalties -the price is directly related to the amount of ECUs that will be produced per year / per project / per time unit to be defined.

Buyout -your company pays once for the software licence and is then allowed to perform unlimited copies of this software in the corresponding project context.

% of participants likely neutral unlikely

Figure 6 Commercial models for trading software components

In the area of intellectual property related aspects vehicle manufacturers tend to patent protections and copyrights. Certification of software components and compliance with current and upcoming standards as well as standardized processes are the main issues concerning process aspects. Finally partnerships with clear responsibilities in business relationships are of very high importance for European vehicle manufacturers.

Business models in general

The meteoric rise and fall of dot-com businesses during the past few years left markets reeling, analysts scratching their heads, and CEOs searching for answers. The most obvious candidate: bad business models. But what exactly is a "business model," anyway? No one ever defined the term precisely -it seemed to mean either "what we do" or "how we hope to make money someday" -but it always got tossed into conversations about new economy businesses (The HBR List, 2001).

The theory and literature about business models and pricing strategies is very generic. In order to apply them to the embedded software business in the automotive industry, a better understanding of some key concepts should be found. The term business model is very large. Several authors confirm this aspect in their work.

Michael Porter mentions in an article about "Strategy and the Internet": the definition of a business model is murky at best. Most often, it seems to refer to a loose conception of how a company does business and generates revenue. Yet simply having a business model is an exceedingly low bar to set for building a company. Generating revenue is a far cry from creating economic value, and no business model can be evaluated independently of industry structure. The business model approach to management becomes an invitation for faulty thinking and self-delusion (Porter, 2001).

Often confused are as well the terms "business model" and "strategy". People use them interchangeably to refer to everything -so they mean nothing. But no organization can afford fuzzy thinking about these fundamental concepts. A business model and a strategy are two different animals. One explains who your customers are and how you plan to make money by providing them with value; the other, how you'll beat competitors by being different (Magretta, 2002).

So what is now an appropriate definition of business models in this context? In general it can be said, that business models are the outline of all transactions needed to make a profitable business. Therefore they should be developed with all the stakeholders: shareholders, customers, suppliers, employees, financial institutions, government agencies, etc., regarding the most important business aspects. This most important business aspects concentrate on the following questions:

• Who are the customers • What is going to be sold to them • How to make a profit • How do the customers decide to buy the product or service and to come back • Why do customers buy and why they do not buy • How to keep employees Considering this various dimensions of business models it is quite difficult to find appropriate answers to all this issues. In the following considerations the focus will be on one important aspect of business modelsthe different commercial and trading models. However it has to be emphasized that the commercial and trading models are just one part of the general business models, even if in the day to day reflections the two aspects are often used (and confused) in the same context.

Types of commercial models for trading software components

As mentioned in the previous part of this paper, commercial models are one important aspect of business models. Some further expressions are often used in the same context and have more or less the same meaning: licensing models, pricing models, purchasing models, trading models and quite often the term business models in its reduced meaning.

In the past most often companies that used embedded software components have licensed technology on a project-by-project basis and for those vendors with a run-time royalty, negotiated royalty fees by project.

Viewed as an industry over spanning problem, such commercial models have been described as complicated, full of restrictions and time-consuming.

Recently several providers of software components proposed new models with the intent of simplifying the way products are licensed. The trends to follow are standardization for embedded technologies, the leverage of technology investments corporate-wide, an increase of efficiency and cost reduction. As a result today users have more options when selecting embedded software solutions.

The today's available most important commercial models that can be applied for trading embedded software components can be structured as follows (non exhaustive list):

• Product packaging • Classical software licensing • Royalties • Buyouts • Development subcontracting • Pay-per-use • Subscription • Time-limited (leasing)
• With indirect financing (free licenses, open source concepts)

In addition to this models -that are actually related to the acquisition of an initial right to use the corresponding software -special service agreements and update / upgrade possibilities are offered. One can easily imagine the variety of combination possibilities that result in the final business proposals.

The different commercial models will be described briefly in the following. The description will be accompanied by a short analysis of strengths and weaknesses of this various models.

Product packaging -the main characteristic of this commercial model is to group different products to one package, e.g. bundle the ECU hardware with some or all software components. It could of course be applied as well in the area of software only, e.g. bundle software development tools and software components. Major advantage of this approach is that it allows to respond to customer requests with a more or less complete solution. The biggest disadvantage is on the seller side, as it does not ensure a profitability tracking for the single products.

Classical software licensing -in this case a buyer acquires typically the right to use a software but not the actual product itself. There are various forms of use-case possibilities for software in question, e.g. for one product, for one person, etc., which have to be defined more in detail in corresponding contracts. Main advantage of this model is that the legal context is quite clear and it is widely used in the industry. The disadvantage is that this model is quite general and leaves some aspects (like the limitations in the use of software) unsolved.

Royalties -are actually a subtype of the classical software licensing model and refer to the financial parts of this approach. The rights for the use of the software are transferred as in the above presented model, the financing part itself is related to the amount of copies produced from the delivered original software. This model was used quite often in the past, especially outside of the automotive industry. Its disadvantage is the long negotiation needed to find a corresponding counting system, without putting the customers in the situation of a possible illegal use of software copies.

Buyout -the buyout model is as well a subtype of the classical software licensing model. In this case the right to produce copies from the acquired original software is not directly related to the amount of copies, but rather limited to a specific product group, department or eventually available for the whole company.

The major advantage of this model is on the customer side as it is very flexible in its application. The problems are rather with the companies offering this approach as the price finding process is rather complicated. A special type of buyouts are site licenses.

Development subcontracting -in this case the development of a software component is financed by a customer in the context of an engineering contract. The customer typically acquires in this case as well all rights for the software in question. Relatively high costs are the disadvantage of this approach as the customer does not participate in the sharing of development costs that apply for the other models. On the other side he will get an absolutely customized solution that should perfectly fit his needs.

Pay-per-use -this model is rather unusual in the automotive industry, except for some cases in carmultimedia applications. The use can be applied to the actual activation of some software functions or to service functions that are enabled with the software in question. The biggest potential of this approach lies in its flexibility concerning the integration of various services -as done today in the telecommunication industry.

Subscription -the subscription model differs slightly form the models presented before as in takes into consideration as well software maintenance issues and future updates / upgrades. Customers pay a subscription fee every year and get access to all services and new versions of the software in question. The advantage of this method is that customers have at all the time the newest versions and bug fixes available.

The disadvantage in the context of the automotive industry is with the financing possibilities that automotive customers currently have.

Time-limited (leasing) -this model is applied to some classical software licensing or buyouts models that are limited in time. Total cost reduction is the major advantage of this model -e.g. it could fit quite well in a time limited project context. The disadvantage is clearly the time limitation.

With indirect financing (free licenses, open source concepts) -in this case the actual software is offered for free -in source or object code form. The financing of development efforts has to be done via services or other related products. One disadvantage of this approach is the rather unclear responsibility in the use of this software.

Dynamics of business models

Even if one of the previously presented models should fit quite well to a specific business context or the current need of ones company, an important aspect of business models should never be neglected -most business models are not static. The technology on which they rest and the environments in which they operate continually change. The firms and competitors who design them, initiate or react to change. In responding to or initiating change to sustain or attain a competitive advantage, it is important to understand the nature of change so as to better take advantage of it in crafting and executing a business model.

Where that change is from a new technology, one of the first things to remember is that profiting from the new technology will take more than mastering the new technology. It also takes complementary assets. Imitable or not, being able to develop the new technology is important since many firms that fail to profit from a new technology, despite having complementary assets, do so because they do not know how to develop the new technology (Afuah,Tucci, 2003).

Conclusion and outlook

As a first conclusion it can be mentioned that for the automotive industry embedded software trading aspects are rather new and unusual. The typical business models in this rather conservative industry are based on the long-term experience in the classical automotive supply chain which relies mainly on the trade with material goods. The typical drivers in the automotive industry like the management of safety and environmental aspects, rather high production volumes, the high cost sensitivity and the ever increasing complexity of technical systems will finally determine which business models will be the most appropriate.

A further aspect that will have a major influence for the upcoming business models is the evolution of the today's rather unclear legal environment. Several important decisions were take recently in the context of the general trade with software and intellectual propriety. This decisions together with the introduction of some new regulations (some already existing in the US market) will certainly change important parameters of current business models. The participants in the embedded software market are asking for some clarification in order to facilitate their business transactions.

Finally it can be mentioned that the increasing competition within the embedded software market and introduction of various business models have educated the users in the automotive industry in determining not only the most appropriate technology to acquire but also how much they will pay and how they want to pay for it. Whether on of the models presented previously will be successful in achieving standardization across the industry is yet to be seen as different groups wrestle with a "ones size fits all" mentality in satisfying their technology needs.

• Consultancy document ( 2001

Figure 1

 1 Figure 1 ECUs and network of ECUs in a today's vehicle

Figure 2

 2 Figure 2 Types of software components in an ECU (network)

  Before presenting different possibilities of business concepts and business models one should know what the needs and requests of the participants in the corresponding market are. The experience with trading Operating System (i.e. OSEK) Device Driver (CAN, LIN, ..

Figure 5

 5 Figure 5 Categories of software components offered by the various business participants

  ) "Automobiltechnologie 2010", HypoVereinsbank / Mercer Study • Thurner, T. et al. (2003) "The EAST-EEA project -a middleware based software architecture for networked electronic control units in vehicles" in: "Electronic Systems for Vehicles" (VDI Berichte 1789), Düsseldorf, VDI-Verlag, p 545 ff. • Schäuffele, J. and Zurawka, T. (2003) Automotive Software Engineering, Wiesbaden, Vieweg Verlag • The 2001 HBR List (2002) "Even a Great Business Model Is Not Enough ", Harvard Business Review, April 2002 • Porter, Michael E. (2001) "Strategy and the Internet", Harvard Business Review, March 2001 • Magretta, J. (2002) "Why Business Models Matter", Harvard Business Review, May 2002 • Afuah, A. and Tucci, C. L. (2003) Internet Business Models and Strategies (2nd edn), New York, McGraw-Hill Higher Education

-22 -23 January 2004

OSEK is an abbreviation for the German term "Offene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug" (English "Open Systems and the Corresponding Interfaces for Automotive Electronics").


Fabien Paganelli
email: fabien.paganelli@renault.com

Luc Bourgeois
email: luc.l.bourgeois@renault.com

Session 3: Business Models Context, issues and solutions for automotive embedded software products

Keywords: Re-use, embedded software, architecture, software product line

published or not. The documents may come

Introduction

Shorter time to market

Competition in the automotive industry has led car manufacturers like Renault to increase their competitiveness through a defined business strategy including :

• Reducing time to market for new vehicle projects.

• Increasing the number of vehicle product families and types in the expectation of larger production volumes leading to purchasing cost reductions and sale increasing. • Developing strong in-vehicle customer benefit policies to make cars more attractive.

Such an accelerating context put even more pressure on quality aspects. Making cars quicker does not mean putting away quality of products. Putting even more the emphasis on quality is the best way to avoid large and costly car recall campaigns and high guarantee costs impacting business results and public image. Furthermore, quality and reliability are leverage for customer trust and business improvement. The evolution of the automotive context in this way affects all engineering fields involved in car design and production, among which in-vehicle software product development. In this way, it represents a challenge for both car manufacturers and suppliers to address the following issue regarding software development : how deploying quicker in-vehicle software products while improving in quality.

Innovation protection and subcontracting

Today Renault model of working on ECU (Electronic Control Unit) and embedded software is mainly based on sub-contracting. Renault makes totally, partially or sub-contracts functional specifications on the basis of customer benefits and functionality requirements, and achieves functional and system validation testing. Suppliers are in charged of the whole software product development and testing. Therefore, Renault provides all specifications and know-how to external companies, among which are functional requirements implementing innovative customer benefits. This means that innovation protection for Renault is quite poor while it is a territory of intensive competition between car manufacturers. This brings about the issue of protecting innovation more efficiently.

In the following chapters, based on the state of our current investigations on software product and management, and in an attempt to identify solutions to address the issues mentioned above, we introduce our point of view on the notion of software product line and architecture based development for automotive products, and the opportunity to build car manufacturer software components.

2 Software product line for in-vehicle embedded products

A point of view on SPL

Starting from scratch for every application, or making too many modifications in existing software is time consuming and error-prone. This puts a lot of pressure on suppliers and the car manufacturer teams while introducing risks in the car design and test process. On the current evolution trend of automotive business as exposed earlier, such a software development model is no longer acceptable.

The software engineering institute has developed an approach to build software product lines. A software product line is defined in [cle02] as a set of softwareintensive systems sharing a common, managed and set of features that satisfy the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way.

Core assets are defined as software artifact that are used in the production of more than one product in a software product line. A core asset may be an architecture, a software component, a process model, a plan, a document, or any other useful result of building a system.

According to what is exposed in [cle02], there are no more places for opportunistic fine-grain re-use in a software product line. Re-use becomes a plan, enabled and organized activity.

The reason why Renault is interested in product lines is that the latter is a systematic and engineered way to develop well fitting software products based on large and mastered re-use. Thus, it is a good mean to develop solutions faster as a solution to tackle the shrinking of vehicle development time while improving quality since it re-uses well known core assets. As such, we consider that it is potentially a good approach to address our first issue. On the supplier side, the creation of software product lines may lead to the following advantages :

• It is a mean to be more competitive as software product lines have proven payback as exposed in [cle02] through many examples in different industrial sectors.

• It allows suppliers to better fit to customer expectations in terms of quality and development schedule constraints. Therefore it is a good point for suppliers to be more eligible on request for quotations at the beginning of a car project for developing a software product supporting a number of vehicle functionalities.

Therefore, a well established software product line approach through the implementation of required practices and organization as exposed in [cle02], may represent a positive evolution factor on software product development in a win-win approach between car manufacturers and suppliers.

Among keys in the in the development of a software product line are management and analysis of variability and the design of an adequate software architecture framework. Through the notion of adequate software architecture, we mean the development of a software architecture addressing the qualities that must be extracted from stakeholders' requirements and providing mechanisms to implement points of variability.

Variability analysis as a key success factor

Since one of the main objective of a software product line is deploying more quickly customer solutions on a common software architecture basis, variability between target customer products must be identified and taken into account in the SPL architecture design. In this respect, it is required to consider variability at an early stage in the software product line built exercise with a view to allow design decisions on specific customer product development to be made later on. Too late consideration of variability is risky as it may result in too many modifications in the target software architecture to fit to target customer needs, undermining in this way the product line approach.

Among the research efforts on variability and analysis of variability, we can mention for instance [gur01] that proposes to address variability through feature analysis, [sva01] that offers a taxonomy on variability realization techniques and factors relevant to determine how to implement variability, [bac01] that proposes an analysis on the cause of variation, types of variation, a way to represent them as put into context, and implementation mechanism into software.

[thi02] describes a practical case of variability analysis and management in the aim of building a SPL for a type of automotive product.

Software architecture at the heart of SPL

Software architecture is defined in [bas02] as "The software architecture of a program or computing system is the structure or structures of the system, which comprise the software elements, the externally visible properties of those elements, and the relationships among them".

Central to a product line is the software architecture it relies on. In this respect, the software architecture must be designed in a way as dealing with variability of target products. Some work has been achieved in the automotive industry in an attempt to implement a software product line through variability formalization based on target product features [thi02].

In this context, as stated earlier, the software architecture aiming to support a product line for an invehicle software must be designed for modifiability. However, design for modifiability must be achieved in balancing with design for performance as target products are embedded software with real-time constraints, limited resources, and characterized by tight cost constraints making the adding of more resources very expensive. Therefore, trade-off must be achieved between these qualities depending on the target product feature and without jeopardizing the product line. Furthermore, other qualities must be required (security, availability, reliability, …) depending on the product type and its level of criticality (e.g., engine control, braking, multimedia systems, dashboard, light control have all different set of constraints).

Success in designing the right architecture with a view to support a software product line is paramount to keep the later operational over time. As described in [bas03], the SEI has developed an interesting approach and a set of methodological tool aiming to help entities involved in that sensitive job.

Among the main items developed in that methodology, we would like to mention as success or facilitating factors :

• The identification of the stakeholders of the target architecture with a view to capture from them and through business and technical scenarios the requirements from which the main qualities of the target architecture will be extracted, and with whom the trade-offs will be achieved.

While not pretending to be exhaustive, and in the context of automotive products, we can mention as stakeholders the developing organization (supplier), the customer, the end-user, the purchaser. Note that the three later are all represented by individuals working for the car manufacturer.

• The design of the target architecture through patterns. The pattern approach has been largely introduced in [bus96]. An example of the patternapproach benefit in the design of a software architecture aiming to become a software product line has been described in [pet03] in the field of radar systems.

Let us mention some of the advantages of patterns we have captured : Going faster in the design of an architecture through the usage and combination of patterns that represent proven solutions in essence.

Patterns do not apply constraints on detailed design solutions as they can be implemented in different ways fitting to target application requirements and properties. Pattern represent a medium for setting-up a better communication between customer and suppliers as it represents some kind of high level while concrete design language that can be understood on supplier and customer side.

Patterns dot not limit the scope of thinking but represent a way to extend it by building new patterns if none are fitting to the target problem. As such, they represent a way for knowledge management on architecture design.

• The documentation of architecture using different views fitting to stakeholders rationality as a way to communicate the architectural choices and discuss trade-offs on a common shared basis.

Among automotive target product able to carry on the way to a software product line approach, body control management and engine control are heavy strategic embedded software products as they support large customer related benefits, perceived quality, performance and global customer feeling.

Car manufacturer made components

As stated earlier, car maker know-how is mainly concentrated in functional requirements and applicative component source code. Applicative components contain the code resulting from the implementation of new functions and benefits resulting from research activities on every aspect of car control such as in-vehicle energy management, body control, chassis control, engine control, and so on. In that context, keeping confidential function content may be required. To this end, other means than providing specification or C source code to external entities must be found.

Currently, one way for innovation protection is to make software components designed and built by the car manufacturer. The targeted components are the applicative components implementing protected functionalities. Such components would be provided for instance to suppliers in object or binary code for integration. However, such a solution bears a certain number of issues either business or technical.

On the business side, issues raised by such an approach are about responsibility sharing between car manufacturer and supplier in case of failure of the target product.

On the technical side, a certain number of issues must be addressed, as exposed in [aee00] regarding the integration of components from different sources on one target platform. Among the items to be considered are :

• Component features What is the level of coupling between the target component and the others ? What links are there to the hardware ? What are the component real-time constraints ? Etc.

• Interfacing with the environment

What are the inputs, outputs and calibrations of the component if applicable ?

• Data implementation As portability is one of the main features to be considered, should some specific facilities provided by the target hardware be avoided ? Ex : bit addressing, etc.

• Format of the component files at delivery Should the component be delivered in object code or binary code ? This raises an issue regarding the usage of a same or different compilation chain compared with the compilation chain used for the built of the whole target product.

All these items call for trade-off depending on the strategy defined for the target product… Furthermore, a process of interaction between the car manufacturer and the supplier(s) involved in such an exercise must be defined with a view to know who does what, when and how.

Also, software standards are required to facilitate such an approach. Some initiatives aiming to standardize software materials such as middleware, I/O control, and low level software either have been running for a while (e.g. specifications of the OSEK consortium on operating system and communication components), or are more recent (e.g. the HIS interest group, Autosar).

Renault is keeping up to date on the results of such working groups that may be transformed into software product requirements in a close future. Further investigation on business and technical issues must be performed (e.g. through collaborative projects) to define solutions that can be applicable in the automotive business context.

Conclusion

As exposed in this paper, software product lines applied to automotive software represent an interesting approach to tackle the issue of making better software product in a quicker way and in a winwin approach between car manufacturer and supplier. Nevertheless, setting-up an SPL approach is not a trivial task as it is a combination of business, organizational and technical decisions that are structuring at the company level and its competitiveness. [bir03] describes an interesting feedback on current industrial practices in the attempt to build SPL in different industrial sectors.

On the technical point of view, care must be taken to variability analysis as the result of the latter represents a strong architectural driver. Indeed, it will lead the design team to identify the mechanisms that will enable the SPL to be more or less efficient in its ability to be a common basis for making different target customer products.

Furthermore, while variability implies design for modifiability, the software architecture of the SPL must be built in balancing with performance and other qualities depending on the product mission and type and the business scenarios captured from stakeholders' requirements and needs. Since software architecture is a key parameter in the elaboration of automotive systems, it is essential for the car manufacturer as a major stakeholder to obtain a deep regard on the architectural design decision made by suppliers with a view to check the fitness between expectations and target product reality. To this end, it must have access to detailed architectural documentation. Beyond the good design approach it represents, a pattern-based language may help in this effort of communication between stakeholders.

On the reinforcement of innovation protection through component built by car maker, a lot must be done to define a solution around subjects such as working model between car maker and suppliers and technical mechanisms allowing integration at no dissuasive hardware costs. Work is under way to address these issues. Furthermore, Renault is very keen to stay in contact or participate on relevant areas in the effort of standardization, paramount to apply such a strategy.

  Evaluating Software Architectures: Methods and Case Studies". L.Bass, P.Clements, R.Kazman, Boston, MA: Addison-Wesley, 2002 [bas03] "Software architecture in practice, 2 nd edition", L.Bass, P.Clements, R.Kazman, SEI series in software engineering, Addison-Wesley, 2003

	[Aee00] "Supplier code portage process, an
	experiment	on	embedded	software
	portability", AEE project working group 4.2,
	2000
	[bac01] "Managing	variability	in	software
	architectures",		F.Bachmann,	L.Bass,
	Proceedings of the ACM SIGSOFT
	Symposium	on	Software	Reusability
	(SSR'01), pp. 126-132, May 2001
	[bas02] "

-22 -23 January 2004


Dr Franco Gasperoni
email: gasperon@act-europe.com

The Business Model of Free Software: Legal Myths and Real Benefits

Keywords: Free Software, Business Models, GNAT Pro

the French Economics Nobel prize, on the fundamental instability of the international banking system.

Principles of Copyright

Copyright is the exclusive legal right to copy, distribute, modify, display, perform, rent or more generally exploit a work by its copyright holder. The creator of the work automatically owns the copyright unless one of these holds:

• Work-made-for-hire implied by employment;

• A specific work-made-for-hire agreement was put in place;

• A specific contractual assignment occurs.

Not everything can be copyrighted. An idea, for instance, cannot be copyrighted. Copyright protects the way the idea is expressed in a piece of work, such as a book, but it does not protect the idea itself.

In the 19 th and first half of the 20 th century copyright concerned mostly literary, musical, or artistic works. Today copyright equally concerns software works. In the context of software both source code and binaries are protected by copyright. Loading a copy of the software onto a computer is considered copying.

Only the copyright holder of a software program is allowed to copy, modify, make derivative works, and distribute the software. Anybody else needs permission from the copyright holder. In the software industry this permission is called a software license.

Nothing requires the copyright holder of a software work to give a license, or to give the same license to everyone. Copyright holders can, at their discretion, charge a fee in exchange for a copy of the software work and its attached license. In this case what the recipient is buying is not the software work per se but a copy of it. Virtually all software products are sold this way.

The software license specifies the conditions under which the recipient can (and most often cannot) copy, distribute, modify, the copy of the software received. Software licenses have a great degree of freedom in the conditions or restrictions that they can contain. Not every condition is legal. In the European Union, for instance, software users are allowed to decompile a software work distributed in binary form for the purpose of interoperability with other systems.

Free Software

In the 60s and 70s software was bundled with the computer hardware sold to a customer and came with full source code. In those days the computer itself was the added value and software a mere technological necessity to operate valuable hardware. Twenty years later the situation reversed. Computer hardware had become a commodity and the added or differentiating value was the software application. In the course of this transition software went from being a giveaway to being ferociously protected with copyright (and patents). In the process software developers went from being an open community where collaboration was the rule to a multitude of closed shops protecting their software works in hope to become the next millionaire.

To rekindle the spirit of cooperation and openness that existed in the software community Richard Stallman created the GNU project in 1983 to create a free software system upwardly compatible with Unix ("GNU is Not Unix" goes the recursive acronym). In doing so Richard Stallman created the Free Software movement and the Free Software Foundation (FSF). In addition to being the organizational sponsor of the GNU project, the FSF mission is to "preserve, protect and promote the freedom to use, study, copy, modify, and redistribute computer software, and to defend the rights of Free Software users" [1].

But what is Free Software exactly? The free in Free Software refers to the following four types of freedom:

1. The freedom to run the software for any purpose; 2. The freedom to redistribute copies of the software; 3. The freedom to study how the software functions and adapt it; 4. The freedom to improve the software and release the improvements.

Access to the software source code is a necessary pre-condition for the last two items.

Free Software and Public Domain

When Richard Stallman created the GNU project and the notion of Free Software he created a special software license to protect Free Software. Why? Isn't public domain what Free Software is all about? Public domain software is software that is not copyrighted. This can happen if the copyright holder has explicitly put the software work in the public domain or if "enough time" has passed from the creation of the software work. Under the American Copyright Term Extension Act of 1998, for instance, "enough time" means life of the author plus seventy years.

It is perfectly possible that the binaries of a software work be in the public domain without availability of the corresponding source code. If the source code is in the public domain as well it is possible for anyone to take those sources modify them, assert the copyright on the new derived work and redistribute the modified software under very restrictive conditions violating the four basic freedoms of Free Software.

Thus, had Richard Stallman decided to release the GNU project as public domain software with sources, anyone could have taken that work, modified it and redistributed it under non Free Software terms, thereby defeating the very nature of Stallman's objective.

The GNU GPL (General Public License)

To protect the four freedoms of Free Software, Richard Stallman created the GPL (General Public License) [2], the main, but not the only software license under which Free Software is distributed.

In this respect Free Software is no different from proprietary software that closed software companies like Microsoft sell. A Free Software program comes with a license (the GPL), just like the software work from closed software vendors. If a user of Free Software violates the GPL the copyright holder can take legal action, just like closed software vendors can if their software license is violated.

The big difference between the GPL and closed software licenses is that the GPL is written to favor the users of Free Software, while the license of closed software vendors is written to allow the bare minimum and to favor the closed software vendor. Specifically, the GPL allows:

• Copying with no restrictions of any kind;

• Redistribution of original software with sources;

• Redistribution of derived works with full sources.

When a user redistributes a Free Software program that person must make available to the recipients all the program sources. If the user modifies a Free Software program and distributes it, the user must make available to the recipients the sources of these modifications.

Free Software distribution is a transitive process: you must confer to others the same rights that were conferred to you. The idea behind Free Software is to encourage secondary distribution, derived works, general use, and create the notion of ownership of ideas by the community interested in the software work.

Free Software and Internet Downloads

It is not because something can be downloaded with sources from the Internet that it is necessarily Free Software. In fact it is the user's responsibility to check the license of the software downloaded. If the originator of the software is not willing to make any license claims the user cannot make any assumptions on whether what he is doing is legal or is infringing somebody's copyright. This is typically not a problem if students, academics or hobbyists use the software. It can, however, be a major liability for somebody using the downloaded software to implement a commercial product.

When a user receives a software product from its authors, Free Software or otherwise, by paying a fee or gratis, the user receives the software license allowing to load the software on a computer under certain conditions. This license, explicitly obtained from the authors or included in a shrink-wrapped box, protects the user against third party copyright infringement claims. It is the safe way that a software product can be used, Free Software or otherwise, without having to worry about legal implications.

In the case of Free Software, strong of the rights that the GPL confers recipients, users of a Free Software program can in turn redistribute the program and make the legal claim that the software is Free Software. There are two things that re-distributors of Free Software cannot do and that is (a) change its license (b) take legal action against somebody that violates that license. Both (a) and (b) can be done only by the original software copyright holder(s).

Free Software and Public Availability

The only obligation that Free Software licenses, such as the GPL, impose on its users is that any work derived from a Free Software program must itself be Free Software. This means that if one distributes a Free Software program, then that person must make its sources available and allow its recipients to do likewise. However, there is nothing that requires that anyone distributes or redistributes a Free Software program.

Free as in Freedom

There is some confusion over what can be charged for a Free Software program. This confusion has arisen from the sentence in the GPL that says "...for a charge no more than your cost of physically performing source distribution" This sentence only applies to the charge of distributing the sources a posteriori if the sources are not distributed with the product itself. This statement does not apply to the distribution of the product. As Richard Stallman puts it: "Free Software" is a matter of liberty, not price. [...] you should think of "free speech", not "free beer." Thus, like any software product, there are no specific restrictions on the price that can be charged for software that is licensed as Free Software.

Business Models of Free Software

Several business models can be built around the notion of Free Software. We enumerate below the key ones which can be mixed in any number of ways to give rise to hybrid business models.

1. Pure Free Software Product. In this model the software vendor limits itself to selling a stand-alone, self-contained set of Free Software programs with perhaps some minimal installation help. Because recipients of Free Software have the freedom to redistribute copies of the software product (and charge for it) this limits the amount that the initial vendor can charge to pretty much commodity costs, unless the Free Software work is a one-of sold in low volume to address specialized business needs. Most commercial GNU/Linux distributions up until recently were based on the pure product commodity price model.

Dual License Free Software Product.

In this model the Free Software work is distributed at no cost under the terms of the GPL while it is sold under a different license to customers who do not want to be bound by the terms of the GPL. This model is available only to the copyright holders of the software. In addition it only makes sense when the software sold is included, in whole or in part, in another application that is sold by the customer under terms different from the GPL. If the customers were to include in their own work Free Software licensed according to the GPL, the customer application would be considered a derivative work of the Free Software thereby forbidding redistribution or requiring that the application be licensed under the GPL. MySQL, a database, and Cygwin a UNIX-like environment for Windows are sold this way. This is an interesting illustration of the fact that the copyright holder can distribute the same version of a software work with different licensing conditions.

3. Pure Service. In this model a service company builds expertise around a number of Free Software works and helps its clients in the installation, use, maintenance, upgrade and any adjustments or customizations that the clients require.

4. Leveraged Service. A leveraged service is an expertise-based service that leverages on a Free Software product. This product/service combination is typically sold as a yearly subscription consisting of the Free Software product with upgrades and high-quality product support and online consulting from the product specialists. GNAT Pro, the Free Software development environment for the Ada programming language is one such example. This business model will be described in more detail in the following section.

5. Free Software Co-op. This business model stimulated by the work of the Network for Dependability Engineering [START_REF]Logiciel libre et sûreté de fonctionnement[END_REF] is described in a forthcoming paper [START_REF]Free Software Co-ops[END_REF].

GNAT Pro

In the early 1990s work was underway to revise the original Ada 1983 standard (known as Ada 83). Ada 83 is the programming language designed for safety and mission critical applications, especially embedded applications. Over the years it has built an impressive track record in this field. The revision of Ada 83, known as the Ada 9X project, gave rise in 1995 to Ada 95, the upwardly compatible version of Ada 83 that incorporates object-oriented and real-time programming features for native and embedded systems.

As a result of the Ada 9X effort the Ada group founded in 1980 at New York University received a grant to develop an Ada 95 compiler to be made available as Free Software. This effort led to the birth of the GNAT technology and subsequently gave rise to two sister companies: Ada Core Technologies in the United States and ACT Europe in Europe which will be referred to as AdaCore in the remainder of this paper.

Today AdaCore provides native, embedded, and safety-critical Ada and mixed-language software development solutions for a large variety of systems. Our offering is based on GNAT Pro, which has become over the last decade the leading Ada development environment.

Developing, maintaining, and marketing GNAT Pro for ten years have provided significant experience with both technical and non-technical aspects of Free Software. In the previous sections we have reviewed several key legal aspects. We summarize below some of the business lessons learned.

• On Free Software and university projects. When the GNAT project was funded at New York University there was a specific clause that required New York University to make the resulting software work available as Free Software. Had that provision not being there, GNAT would probably be sitting on some university shelf in New York.

• On public releases. Although it does not have to, AdaCore makes public releases of its GNAT technology. Making the GNAT technology publicly available was important in gaining mind-share and has fostered a user community around it. Furthermore this has allowed AdaCore to attract a pool of talented engineers on both sides of the Atlantic, the vast majority of whom knew GNAT before joining.

• On the GPL. Free Software compilers represent an interesting situation for developers of non Free Software. On the one hand a compiler is a standard development tool that is not meant to be included in the final application, while on the other hand a compiler comes with libraries and runtimes that are linked, and hence included in the final executable. To ensure that programs generated by GNAT Pro can be made proprietary, or classified as secret, or be subject to any other restrictions that customers deem appropriate, AdaCore is licensing the GNAT Pro libraries and runtimes with a special version of the GPL, called the GNAT Modified GPL (GMGPL) that explicitly allows links with non Free Software code.

• On selling GNAT Pro. GNAT Pro is sold as a yearly subscription. A subscription provides customers with: 1. The GPL license for GNAT Pro and the GMGPL license for the runtime and libraries to guarantee that programs generated by GNAT Pro can be distributed under customer-specific terms and conditions; 2. The GNAT Pro development environment for the selected application domains and platforms; 3. GNAT Pro tool support directly from the GNAT Pro developers; 4. Online consulting directly from the GNAT Pro and Ada experts.

• On aligning with customer interests. The subscription-based model of GNAT Pro aligns the customer interests with our own. The customer is interested in receiving a high-quality product with a high quality service to develop its application, often a safety, mission, or business critical one. We are interested in making sure that our customer succeeds. Not only does this bring us engineering pride it also ensures that the customer renews its subscription year after year and keeps using our technology and services on the projects to come. As a result the engineering and financial interests of our customers are aligned with our own.

• On subscriptions and recurrent revenue. It is gratifying to see that many players in the software industry are discovering the benefits of subscription-based models (as opposed to pay-up-front). When properly implemented subscription-based models generate a predictable and recurrent revenue stream. For companies traded on the stock exchange this means predictable earnings per share, quarter after quarter.

• On the benefits of a leveraged service. GNAT Pro customers receive a high-quality Free Software product with a high-quality service from the Ada experts and the GNAT Pro developers. This allows customers to develop sophisticated systems where they can leverage on GNAT Pro and its software components as if they had developed it themselves since they have direct access to the sources and the GNAT Pro developers. The GNAT Pro experts serve as partners to the customer development team. They work closely with the customer team to help them make optimal use of our products and to assist them with all aspects of software development. As part of that dialogue our engineers regularly address issues such as code optimization, programming language semantics, multi-language systems, and code organization. The net result for the project is reduced risk, higher productivity, and shorter time to delivery.

• On trusting customers. The price of the yearly GNAT Pro subscriptions is based on the number of developers in the teams using GNAT Pro. To select the appropriate GNAT Pro subscription level AdaCore offers several predefined team sizes based on the maximum number of developers covered by the GNAT Pro subscription: up to 5, 15, 25, 35, 50, 100, 200, and 500 developers overall. These different team sizes allow for easy personnel adjustments during the course of a GNAT Pro subscription year. How do we check that users do not exceed the subscription level they purchased? We don't, we trust our customers. Trust builds trust.

-22 -23 January 2004

Conclusion: Free Software and Sustainable Development

Beyond the legal and business aspects of this paper, I would like to conclude on the benefits that the freedom of Free Software licensing provides in the realm of sustainable development.

Firstly, support and maintenance of Free Software can be bone by organizations other than its copyright holder. This means that if, for some reason, the latter no longer provides satisfactory service the customer can select a different provider or train an internal team to achieve this task. This is especially relevant in industries where long-term projects may outlive the maintenance lifetime or even the provider of the target operating system, libraries, and development tools.

Finally, Free Software allows the creation of a local pool of software expertise and enables every region or country whether in Africa, North or South America, Asia, Australia, and Europe to forgo electronic colonization.