Keywords:

dramatically decreasing the spin-in process efficiency….

IMA for space : status and considerations At first, a status will be made on the current of the on-board data-handling system for the space applications, in particular the way CNES pushed the concept of platform and the way it has been spread by industry for non-CNES programs (under ESA contract, commercial market, international cooperation) : from SPOT earth observation to telecom satellites including scientific missions based on PROTEUS and MYRIADE platforms will be described. Then it will demonstrated to which extend the IMA concept is not yet directly applicable in the context of the space domain : technical (constraints/limitations on rad-hard processors, limited volume of embedded applications, mission-criticality of all on-board applications…), organisational constraints (ESA, national agencies and the various industry actors) and specific other space domain (market and associated investment budgets) will be detailed.

In the last part, it will presented how and which of the concepts inherited from IMA are however considered relevant for space. In particular the various technical fields have been explored and will be presented in various area such as ARINC 653 standards (system partitioning and segregation), software standardisation of architectures and associated building blocks (isolation of applications and independent development and validation), engineering methods, associated tools. The organisational problems and associated business model will also be considered (need for architecture and design authority funding the investment, responsible for technical requirements and maintenance). Preliminary studies and a roundtable have been held within the space domain and a work plan established in order to gain from the IMA experience and fill the technology gaps. However the lack of visibility on the real issues behind the IMA and still missing answers to some questions (lessons learnt from aeronautic world are partly hidden from the external) are

Introduction

The IMA concept has been created and deployed in the aeronautic domain in order to optimise the development and validation effort of the on-board functions by offering a common standard core (made of on-board computer hardware -CPIOM-, bus -AFDX-and on-board software middleware including ARINC 653 compliant operating system and standard APIs). Space domain agencies and industry are facing the same constraints and needs as the aeronautic ones in particular in terms of :

• Cost and efficiency optimisation, • Schedule reduction, • Increasing on-board complexity and autonomy, • Evolution and concentration of organisations, • Reliability and criticality. There is a need for changing the way (technical and organisational) to design and develop satellites and space systems : standardisation is a key issue already identified ten years ago.

Standardisation tentative

Concept of platform

In order to standardise or at least develop once common avionics for several missions, in the eighties, appeared the concept of satellite platforms : the idea consisted in physical and functional decoupling of the basic avionics and housekeeping functions (power, AOCS, thermal, TM/TC) constituting the platform from the mission functions (payload instruments). This concept enabled already mutualisation of engineering, design and validation effort between several mission of the same types : The concept has been made available to the prime contractors for their own applications (e.g. ASTRIUM has based the ALSAT satellite on this platform for a commercial earth observation export program). This concept has been considered also very attractive for military cheap missions. The lessons learnt from those platforms investments show a real and effective cost reduction. However, and except in the telecom world, the number of missions for each platform remains very low (up to 10-15 at most).

Satellite avionics architecture and platform concept limitations

Despite the real gains obtained thanks to platforms, a survey shows that 80% non-recurring costs of the satellites are mission dependant and not only on instruments/payloads. This means that for each mission the impact of the specific requirements on the platform are quite high, in particular in the software development and validation. The reasons for such major impact of each mission on the platform design are partly hidden and industry confidential. This is due mainly to the competition between prime contractors, but also to the customersupplier relationship between agencies and primes. It is therefore very difficult to access the real internal cost data. Out of the in-house CNES experience gained on MYRIADE, but also to the PROTEUS CNES funded platform, it was made possible to outline a first list of those reasons. The platform was supposed to implement all and only generic and standard features. However :

• There is a strong coupling between the mission and the platform : the performance of the final system links the instrument capabilities with the platform ones (e.g in earth observation and most scientific mission satellite pointing is directly defining the mission performances), • The interfaces (space to ground protocols, operations) are specific to the final customer (ESA, CNES, commercial export…), • Some constraints are also coming from the launcher leading to satellite/platform design impacts, • There is a strong dependency between hardware and software (processors, I/O management, on-board protocols). Obsolescence of components is very difficult to master from the software side (e.g. on MYRIADE platform migration from T805 processor to ERC32/LEON imply a major software redesign).

• The processor resources are very limited (European rad-hard product lines : ERC32 offers only up to 20 MIPS). This leads to software optimisation, degrading the reusability (modularity, parameterised functions, ...),

• The reliability has to be kept very high and the projects prefer to run a complete software validation and qualification for their mission rather than relying on a generic validation performed once. All those aspects lead for each mission to major consequences on the platform software, and very often a complete redesign and qualification are necessary.

Improvement needs

In order to reduce significantly the software cost, the following have to be explored : • How to maximise generic features,

• How to increase decoupling between the various functions, • How to improve reuse process and architecture, and provide the evidence of gains in terms of validation effort, • How to decrease cost of specific functions ?

Expected benefits from the IMA concept

Given the limitations outlined §2.2 and the improvement needs on the platform concept §2.3, space agencies are looking to what has been invested in the others domains for the development of embedded real-time software in order solve the same kind of questions.

It is to be noted that this paper focuses on the IMA concept rather than other initiatives such as AUTOSAR in the automotive world, because :

• the constraints in terms of criticality aspects and associated rules have been seen very close from each other : DO178B software engineering and quality standard corresponds nearly one to one to space ECSS E40/Q80, • the notion of avionics and some associated functions are similar between an aircraft and a spacecraft, • the IMA concept has been seen as more mature because effectively implemented and flying today whereas AUTOSAR is still under development.

It is not the objective of this paper to describe in details the IMA concept. However, an analysis of the main IMA offered features conducts to isolate the fundamental following aspects :

• standard on-board computer resources including full CPU boards : processor, I/O, bus,… • standard certified RTOS and common API for all software functions (ARINC 653), • standard common software validation means.

Both standard hardware and software implement time and space partitioning capabilities in order to guarantee the independency of the functions running on the same computer. The effectively observed benefits from this approach are :

• develop once the standard features,

• increase of reliability of the common complex generic software (and hardware) achieved throughout extensive testing, • embed software functions on the same computer having different criticality levels without risk of error propagation between functions, • embed software functions within the same computer without risk of error propagation between functions, • develop and validate functions incrementally and independently from the others, • optimise use of computer resources by late allocation of software functions to computers, As a matter of fact, in terms of organisational aspects, IMA concentrates the various competences on appropriate suppliers leading to an increase of the efficiency of the corresponding teams :

• the function supplier can concentrate on the functional aspects without any particular knowledge of the hard-real time kernel, resource management, I/O, etc…

• a change of function supplier would not affect the system level, • the IMA supplier can focus on the tricky real time concurrency problems (shared resources, tasking, scheduling) and develop those very critical software with dedicated process effort (including robustness).

Why not IMA for space ?

Without having full access today to the data and the convergence process that took place years ago inside the aeronautic community, it is very difficult to assess the validity of the IMA concept for the space needs.

Nevertheless, the contacts initiated in the scope of preliminary studies and the help provided gently by the aeronautic people in order to explain the context and provide first answer to the raised questions, enabled to better characterise the differences between the two worlds and assess the validity of the approach step by step.

A workshop was held in ESA on the topic beg. October 2007. It provided additional inputs in order to assess the IMA approach in space context to the preliminary already conducted studies on the subject. It was the forum for open discussions within the space community together with invited aeronautic people.

The main differences between space and aeronautic have been isolated and classified into five categories:

• technique • market • organisation • strategy • culture 4.1 Technique
Obviously the technical needs are not completely shared by the two domains :

• time and space partitioning : it appears that aircrafts have to mix-up very critical functions (Cat A : flight control commands, braking, …) together with none critical ones (Cat E : flight entertainment). Satellites only on-board medium critical functions and almost of the same criticality level (Cat B-C). Another way saying all functions on-board the satellite are at-least mission-critical and therefore all developed according the subsequent engineering and quality rules. • Standardisation : it is a clear objective shared by the two communities but there is still need for specific aspects. IMA is today "standard" within the same aircraft family (space platforms ?), but not compatible from an IMA supplier to an other. This means that it is not obvious whether it is affordable to standardise the envelope of needs in order to share the same computer resources and associated basic software for all satellites types. Moreover the consequences of such a concept would preclude the following :

• Processors and computers : due to environmental constraints for space applications, it is not possible to fully reuse the hardware boards and processors developed by the aeronautic people. Dedicated and still very limited series of rad-hard processors are needed.

• CPU and memory resources : today an ERC32 is providing only 20 MIPS associated with a few Mbytes of memory. As a consequence the tendency in terms of avionics is more to decentralise and spread the processing into dedicated computers rather than concentrating within single units. The IMA would imply to have powerful processors enabling to support the IMA features (memory footprint, CPU overhead) and concentrate software functions. This problem will progressively disappear with the new generations of powerful european rad-hard processors (LEON, GINA, …).

• Computer and bus architecture : the IMA concept has not only impact on software architectures. It relies also on a physical segregation of I/Os and memory not existing today in space avionics. • On-board software architecture : implementation of full ARINC 653 operating system induce a major impact on the current existing on-board software architectures and off-the-shelf building blocks. Applying such a design would mean a complete redesign and validation of them. • On-board software reliability : implementation of full ARINC 653 operating system induce a increased complexity : time and space partitioning features in the RTOS were difficult to develop, debug and maintain. Furthermore, the experience shows that validation of RTOS (ref. [START_REF] Cantenot | RTEMS Operating System Qualification is completed[END_REF]) is very difficult, and today mainly rely on the validation achieved on the full software for the satellite software. This aspect has been properly tackled by the aeronautic people but remain a key issue where exchange of experience will be necessary.

Technically, both developed IMA off-the-shelf hardware and software can not be directly reused without complete re-assessment of needs (possibly less stringent) and redesign in order to suit to technical existing rad-hard processors, computers, … 4.2 Market -return on investment : Given the technical implication on the spacecraft avionics, it appears that the cost of IMA for space in terms of level of investment would be very high. This point is not disputed today by the aeronautic people. By lack of access to the confidential real figures, it is very difficult for the space community to estimate the cost of such an investment. Even if those figures were made available, transposition within the space context, 10 years later, would not be fully valid anyway. Macroscopic evaluation of both markets is however providing the following information :

• Current aircrafts contain roughly one hundred computers and four hundred functions whereas satellites count at most twenty computers and a maximum of thirty functions. • In terms of series, an aircraft is supposed to be designed for more than one hundred items, whereas satellite platform count at most 10. In that context, it is not obvious that the gain on each computer development (hardware + software) would be sufficient except if maybe if the standardisation is achieved at the complete community level (between all agencies and all prime contractors). But as a matter of fact, is it technically realistic (and really desirable in particular in terms of risk) to achieve this harmonisation at the level of the space community, whereas the aeronautic people have one "IMA" per product line (which corresponds approximately to satellite platforms). In any case, redevelopment from scratch of an IMAlike concept for space would not be affordable.

Organisation

In the aeronautic world, the IMA is supported by the aircraft manufacturer and contracted to one or several suppliers. Given the market constraints outlined §3.2, it would not be profitable for the satellite prime contractors to do the same (and already looking at the current situation achieved at platform level). Therefore IMA for space would imply to create an IMA design authority, and select supplier(s) at a consortium level (including agencies + prime contractors) based on a common investment. For the function supplier, the implication of IMA is also very important. The risk of such a rationalisation at their level is to loose completely low level expertise on board computers and basic software. Furthermore, each function supplier need then to acquire IMA architecture background in order to provide software functions fully meeting the IMA constraints and development rules. The cost and impact in this area has to be properly mastered and challenged : the gain provided by IMA on the supplier has to be compared with the training effort and support from IMA supplier. The function supplier is also no longer providing fully integrated and validated packaged solutions (hardware + software). In terms of responsibility, the concept creates strong interactions between IMA, function suppliers and the system level :

• In terms of schedule : IMA framework has to be made available to the function supplier, • In terms technical responsibilities, when an anomaly occurs in a function, the question may arise of whom is responsible and supposed to investigate, • Same question may appear at system integration level. Out the visibility we have today, the IMA aeronautic experience does not reveal problems in this area. But it seems that the IMA was much anticipated, and the level of accompanying effort was very high in order to prevent any schedule conflict : the technical segregation concept was fully validated before having made available to the suppliers. This is one of the major lessons learnt from their experience : it can not be implemented incrementally on projects and should be mature enough before being applied.

Strategy

The space community in Europe is organised very differently than in the aeronautic domain. The customers are mainly institutional, national agencies (CNES, DLR, ASI, BNSC…) and the ESA. All those actors have a strong interest in decreasing the cost of space missions, but without endangering their own national interests (which aim at maximising the implication of their industry on space programs). An harmonisation process is in place in order to make technical consistent decisions. But this process is very long and heavy even at least to converge and fund technical studies. One could imagine how long it could take to converge on a such a major issue. In the context of the aeronautic world, the IMA was pushed the airliners, which common interest was to decrease the cost of aircrafts. It was then declined by the aircraft manufacturers, and imposed to the suppliers. The decision making was somehow easier because it was a top-down process driven by economical interests regardless the implication on the suppliers (which market part remain quite comfortable at the end). In the space domain, they are few actors and it would be very dangerous to decide such a change without any preceding assessment of impact on all of them : it would be very dangerous (and not at all desirable) to stress any of the fragile suppliers with their associated know-how… 3.5 Culture With this very complex network of actors, and possible reluctance of some of them for short term economical interests, and technical risks, the space community has to face also its history and culture. Space has been during tenth of years one of the leading engine producing brilliant and competing solutions at the time only technical objectives were assigned to projects without stress on economical constraints. Today, under more and more economical pressure, this community is reluctant to change things that have been investing stone after stone and which efficiency have been flight proven. It is clear also that again for economical short term constraints, both industry and agencies are not in favour of taking high risk and therefore do not push very hard for experiencing any major breakthrough. Last, and not specific to the space domain, engineers prefers slight innovations on what they know and master, rather than reusing existing concepts they have not invented nor experienced themselves : this "not-invented-here" syndrome is really preventing a proper cross-domain fertilisation and rationalisation. Was it easier in the aeronautic world to provoke such an earthquake ? Probably not, but the reality of the market and the very hard competition between aircraft manufacturers was a matter of survival. Today in the space business, at least for what concerns the institutional market in Europe, deciding IMA for space is not -at short term at least-a matter of life or death.

IMA for space or something else ?

For all the reasons depicted §3, IMA as such will not be applied and reused in the space domain. However something looking like IMA should emerge based on similar concepts but on an adapted technical rationale associated with a dedicated organisation and funding. In particular due to the culture and decision making process, a step by step approach will be preferred to any other violent breakthrough.

consolidation of needs

There is a need for future missions :

• to reuse software and invest on common core rather than developing several times the same pieces of software (IO, services, middleware…) • to on-board autonomy functions, less critical, and very difficult to validate. • within payload / instrument computers, the high critical FDIR shall coexist within the same computer with low critical data processing : the need is to develop the low critical functions with adapted engineering standards (and therefore accept less reliability). This approach is acceptable only if this does not endanger the high critical functions through segregation capabilities.

• for maintenance in flight, to ease reloading of functions without reloading (and stopping) the full software. • for geo-return on European projects, it is needed to split the on-board software development on several function suppliers. The independence of the software development process between functions is necessary such a context. This preliminary list of needs should be properly refined, and classified from top basic mandatory needs down to optional desirable ones : this would drive the roadmap for incremental step by step implementation and deployment of the concept.

challenge of technical solutions and impacts

• As a prerequisite focus first on standardisation of software engineering (E40, Q80) architectures and interfaces (SOIS, PUS). • Impact on hardware side (including resources aspects) shall be assessed carefully because it seems that the expected benefits will be very limited if MMU as well I/O are not physically segregated. Cache/registers flushing at each partition switch will cost on the software performance. Injection of constraints in the hardware roadmap. • Definition of the appropriate robustness level : select the capabilities to be implemented in the RTOS (dynamical checks, physical barriers), in the associated tools (static software checks at compilation step). • Definition of the appropriate genericity level : It is to better to customise optimised solutions according to family of applications instead of fully generic inducing complexity in particular in the configuration process. • Compare with other experienced approaches providing also segregation capabilities such as ASSERT, CORDET, DISCO, CNES TMSCM… Many studies have been initiated already in order to consolidate the implications and prototype solutions to be experienced on the space use cases :

• Impact on RTEMS will be assessed (CNES + ESA studies), because RTEMS is spread on the space applications and per essence, the impact on the existing reused software would be minimised and possibly smoother than with other RTOS. Nevertheless the other RTOS will be evaluated in the scope of the CNES study. • Real implementation is to be evaluated for SYMBOL-X payload function. CNES, in charge of this software will inject dedicated requirements in this area. Those studies have to be structured and complemented by others in order to secure all the technical issues before any decisions. A dedicated roadmap has to be written in order to address all of them.

organisational

In parallel to the technical studies, some analysis shall be conducted in order to identify by whom and how IMA for space should be managed and decisions taken. The business model has to be carefully assessed and defined by all the actors, in a wider context where an organisational model is already under discussion on the way to develop and share software building blocks.

• The agencies should clearly identify the targeted needs and found a funding scheme of all the preliminary assessment studies. • The technical design authority board should be created in order to define and agree on targeted "reasonable" and "incremental" level of specifications (to be standardised within the appropriate ECSS place-holder). • Both agencies, prime contractors and software suppliers should identify the investment they are ready to perform. This should be consolidated in order to show how the resulting project costs would decrease.

Key dates and short term roadmap

Trying to draw where IMA for space stands today, lead to the following key dates and events already held :

• 2006 : preliminary tentative studies initiated by ESA (TRP + GSTP). Only technical activities started on ARINC 653 and on-board software impacts. • June 2007 : CNES presents the paper "IMA for space : status and perspectives" [START_REF] Arberet -Cnes | IMA for space : status and perspectives[END_REF] in the scope of CISEC day on IMA. The status was difficult to depict due to a very large number of questions and lack of knowledge on the concept and the way it was implemented. • End September : IMA day in the scope of ADCSS workshop in ESTEC/ESA the Nederland where the results of preliminary studies were presented. After the roundtable, a preliminary roadmap was established and reflected here in this paper. And at very short term :

• January 2008 : key meeting to be held between ESA, CNES and prime contractors (TAS, ASTRIUM) in order to define the scope of a structuring study involving all the parties and covering all major issues. • End 2008 (hopefully) : the roadmap will be consolidated together will risk, cost and organisational analysis. Would the consortium be then in position to create the IMA for space project ?

Conclusion

IMA concept will not be reused as such by the space community because it does suit to the needs, the constraints (technical, organisational, costs, risks…). Nevertheless most of the ideas behind the IMA concept are valid and the experience gained in the aeronautic field is very profitable in order to capitalise the lessons learnt and decline for space the key drivers of what would be or should be invested instead (and as a consequence save time and money). Already preliminary activities have been conducted and will be structured efficiently with an associated roadmap in 2008.

A clear and unambiguous signal has still to be given by all the contributing actors of the space domain in order to confirm the future of IMA for space. Would OpenSpace project be launched in 2008 ?

Acknowledgement

Many thanks to all the contributors to this article, in particular to ESA partners, together with ASTRIUM and TAS, believing that there is a common interest and a future for "IMA for space" whatever it would imply.

Special thanks to AIRBUS (cross-reading from Mr. Dario Louarduzzi) and THALES (Mr. Derville, Chenevier, Fumey, Clement) for the hours spent with us, accepting to answer to the never-ending questions, including our provocative, sometimes nasty or just doubtful comments…

  P.Arberet 1 , J.Miro 2 1: CNES, 18 avenue Edouard Belin, 31401 TOULOUSE Cedex 9, France 2: ESA/ESTEC, Postbus 2999, 2200 AG Noordwijk, the Nederlands Abstract: This article aims at giving an overview the current status and potential perspectives, including the open points, for space applications of the Integrated Modular Avionics (IMA) concept defined and developed by the aeronautic industry.


P H Dezaux

Migration Strategy of In-House Automotive Real-Time Applicative Software in AUTOSAR Standard

Keywords:

PSA PEUGEOT CITROEN automotive electronic architecture consists of several electronic control units (ECUs), distributed on various networks that are interconnected by a central ECU. The legacy software of this unit is built on in-house generic applicative software components that support functions required for the whole range of our vehicles. This software is based on a proprietary architecture with specific basic software components. AUTOSAR stands for AUtomotive Open System Architecture and is a standard used to design ECUs based on standardized interfaces and basic software components. This paper gives an overview of the strategy used for migration of these in-house applicative software components to the AUTOSAR architecture.

Introduction

Electronics and software represent an ever increasing share of the added value within the automotive industry. This trend is driven by safety, assistance, comfort, and legal or environmental requirements and all vehicle domains are affected. As a consequence, the complexity of automotive E/E architectures is growing exponentially. The automotive industry has recognized that a technological breakthrough is required to address these challenges. Separation ("abstraction") is needed between applications and standardized infrastructure (basic software). This approach allows more separation between the development of applications and the underlying infrastructure and between the life-cycles of hardware and software. Increasing the re-use of basic software also results in higher quality. One central standardization initiative is the AUTomotive Open System ARchitecture (AUTOSAR). AUTOSAR was founded in 2003 by major OEMs and Tier1 suppliers and now includes a large number of automotive, electronics, semiconductor, hardware and software companies.

AUTOSAR aims at facilitating the re-use of software and hardware components between different vehicle platforms, OEMs and suppliers.

The aim of this paper is to expose the strategy used for the migration of in-house applicative software components to the AUTOSAR architecture.

Electronic architecture description

PSA PEUGEOT CITROEN automotive electronic architecture consists of several electronic control units (ECUs), distributed on various networks that are interconnected by a central ECU: the BSI (Boitier de Servitude Intelligent) which is the body controller of the car. Legacy software embedded in the BSI is composed of eight major applicative software components and a basic software platform. Applicative software components are in charge of applicative functionalities, basic software components supply operating system services.

Here is given a schematic of BSI legacy software architecture: The basic software platform is composed of a service layer (middleware) and a hardware abstraction layer. The middleware is in charge of service functionalities (task scheduling, network and UCE life cycle, diagnostic, data storage management). The hardware abstraction layer is a specific low-level component, dedicated to the hardware abstraction. This component is specific to each hardware generation and ensures the compatibility with the other components.

As the BSI is the point of interconnection between all the networks and the different ECUs, PSA PEUGEOT CITROEN decided to develop BSI software with internal developers, as opposed to other ECUs development, with the aim to keep flexibility and reactivity. The strategy used is to develop generic components (CMP0 to CMP8 as seen previously) that may be used by the vehicle projects according to their needs. It means that these components are released every month in order to implement new functionalities or to fix bugs. Each vehicle project can select the used components according to their needs. BSI's applicative software components are based on a proprietary architecture with specific components. The language used is an extension of the C language with the aim to provide data protection mechanisms (such as check of multiple data production) and to simplify the API by using dedicated macro (declaration of a new network signal, automatic data save…). Characteristics of the BSI software are 720 kb of flash memory and 22 kb of RAM memory.

Our strategy consists in migration this specific architecture to the AUTOSAR standard.

AUTOSAR introduction

AUTOSAR stands for AUtomotive Open System Architecture and is a standard used to design ECUs based on standardized interfaces and basic software components. AUTOSAR aims at facilitating the re-use of software components between different vehicle platforms, OEMs and suppliers. To achieve this, AUTOSAR defines a methodology that supports a distributed, function-driven development process and standardizes the software-architecture for each ECU in such a system. AUTOSAR also specifies compatible software-interfaces at application-level. Main advantages of this method are an easy integration, a transferability of functions (between ECUs), a flexible maintenance, scalable functionality and a software independence of hardware.

AUTOSAR migration

For the migration of the legacy software to the AUTOSAR architecture, we have decided to develop a specific release with the same strategy of generic software components. As legacy applicative software components are still going forward within the current architecture, a specific release has to be set up with new generic applicative software components dedicated to the AUTOSAR architecture. Migration of our architecture to AUTOSAR standard is done following several steps: -Architecture of basic software, -Architecture of applicative software components -Development of new basic software components -Migration of applicative components -Functional evolutions These steps are detailed in the following sections.

Architecture of basic software

The aim of this first step is to apply the AUTOSAR software architecture as much as possible while taking into account the PSA PEUGEOT CITROEN's specific needs. Therefore, there was no "reuse" strategy for the basic software. One main strategy point for basic software was also to buy as much as possible standard basic software components.

We first identified the eleven main service domains that are provided by basic software (Data Storage, IO Management, ECU State Management, Software Dynamics, Network Communication, Diagnostic, etc.).

Then we analysed the coverage of PSA PEUGEOT CITROEN specific needs by AUTOSAR specifications. This analysis led us to draw up a hybrid architecture composed of roughly 80% of pure AUTOSAR basic software and 20% of AUTOSAR basic software adapted to our needs.

Architecture of applicative components

At the same time, the idea was to use the benefits of this technological breakthrough to redesign the allocation of functions to the different applicative software components. The current allocation had been designed a few years ago taking into account specific constraints due to the current architecture or historical constraints. The following are some examples of such constraints: -Decoding / encoding of signals from the same frame but needed for different functions had to be in the same component -Function allocation had to take into account the ECU organisation (different functions communicating with the same ECU had to be in the same component)…

This allocation had been updated many times in the past to add or remove functionalities but we never introduced a breakthrough in order to keep software compatibility of the generic components. As the introduction of AUTOSAR standard means a technological breakthrough, it is the right time to optimise our architecture and provide a new function allocation. The idea is to redesign the entire software architecture with the aim to optimize function allocation on the various applicative software components, simplification of the interfaces and integration of specific constraints raised by Autosar architecture.

The beginning point is the current architecture: for each component, the interfaces and the supported functions were analysed. A summary was made in order to propose the new allocation, based on the following rules: -fusion of functions spread out over several components, -internal interfaces and signals simplification, -external signals consumption optimisation, -suppression of unused components and functions, -preparation of new incoming functionalities, according to the interfaces needed, -benefit of AUTOSAR possibilities.

Here is an example of the new allocation that was proposed for component CMP1. As standardised by AUTOSAR, the new architecture is composed of Atomic SoftWare Components (ASWC) that are assembled in compositions. Legacy architecture is composed of 87 applicative components corresponding to 85 functions located in the BSI. With the application of the proposed architecture, it generates 32 new components with a better partition between presentation and application functions.

One of the main difficulties of this step was the definition of software components in charge of communication with basic software. As the conception of basic software was not achieved during the design of applicative components, we needed to proceed with iterative adaptations.

Development of basic software

As mentioned above, 80% of the basic software architecture is composed of pure AUTOSAR basic software and was bought from hardware suppliers. The remaining part of basic software was developed by PSA PEUGEOT CITROEN. One of the main difficulties of this step was the clarification of the process and the responsibilities for the configuration of the whole basic software: -some configuration parameters need to be set by the supplier before delivery -some configuration parameters need to be set by PSA PEUGEOT CITROEN to adapt the basic software for the application software (e.g.: the communication matrix) -Finally, some configuration parameters are deduced from PSA PEUGEOT CITROEN configuration but remain under the responsibility of the supplier.

Migration of applicative components

Once the architecture of the new components has been defined, the next step is the migration of the legacy applicative components to this new architecture: adaptation of the applicative software components has to be compatible with the new function allocation and with the Autosar standard.

For this new architecture, we have chosen to develop a specific release of software components (applicative and basic software components). As the current architecture is still used by projects in development, it means that we need to maintain two software releases: one for current vehicle projects (based on our proprietary architecture) and a second one based on AUTOSAR architecture. These two releases keep the same approach with generic software components and configuration components. Two possibilities exist for development of the AUTOSAR release:

-migration of existing applicative components, -development from a blank page

We have chosen to migrate most of the existing components as the corresponding functions are quite similar between both architectures and with respect to the planning constraints.

For other components (complicated maintainability, important function evolution), we have chosen to benefit by software re-conception.

Migration of applicative components

The objective of the migration is to translate the legacy components in the AUTOSAR architecture. These components are associated with unit test files that simulate elementary input and check corresponding outputs in regard with expected results. As these components are migrated, the corresponding test files have also to be migrated in the new environment and all these new test cases have to be checked in order to prove that the migration is successful. First step is to identify for each migrated component all internal (between software components) and external interfaces (with regard to the BSI ECU). This step was realised by the Software Architecture Team. Interfaces are updated according to the proposed architecture (function allocation among the different components) and normalised with AUTOSAR name conventions (prefix according the interface type…). We have also decided some simplifications such as a limitation to only one data element per port. The internal and external interfaces are also characterised with tags (set in the description fields) to provide specific services (automatic data save, signal supervision, BSI hold…). These tags are recognised by the compilation chain and automatically generate the appropriate source code. These mechanisms are quite similar to the macros used in the legacy architecture. The compilation chain is also in charge of generating the source code for composition port accesses. As most of the components have been migrated, we had to update about 75% of the existing interfaces (2800 internal interfaces, 900 external interfaces and 60 new hardware input / output signals). We have also decided to train team members to use AUTOSAR tools (AUTOSAR Authoring Tool) before starting to update the interface. A specific small project has been set up and has been used by each team member with the aim of experiment these new tools. At the same time, we have also checked the inter-compatibility of all these interfaces from the AAT.

Once the interfaces have been updated and checked, the source code of the corresponding components is migrated in the AUTOSAR environment by the Software Development Team.

We have chosen to develop dedicated tools to migrate main parts of the source files as most of components implement the same functionalities between both architectures (except presentation and diagnostic requirements and component rename). The results of these 2 steps give us a first release of software compliant to AUTOSAR. This software is then frozen in the software configuration tool and will serve as start point for all future functional evolutions.

Functional evolutions

Once the migration step is finished, we have a stable release that has been fully tested and that is available for implementation of the new functionalities. Implementation is done according to a classical development cycle: -software architecture design -interfaces definition -development of source code and unit test cases -unit verification -components integration -validation of the integration Choice for implementation in one or both releases (legacy and/or AUTOSAR releases) is done according to the vehicle project needs as we use two different referentials that contain dedicated and common specifications to implement. Dedicated specifications are specific to the current architecture as opposed to common specifications that cover both architectures.

One of the main difficulties in this step is bug analysis to identify if the correction is needed in one or both releases (definition of criteria such as bug status and severity).

Conclusion

Since the start of the migration activities, a high amount of work had been done to provide BSI software compliant to the AUTOSAR architecture. The presented strategy allowed PSA PEUGEOT CITROEN to optimise the time and effort needed for migration of the BSI software from our current inhouse architecture to the AUTOSAR standard. We have also succeeded in maintaining our strategy with the development of generic applicative software components in two separate releases.

Glossary

Fig. 1 :

 1 Fig. 1: Electronic architecture description

Fig. 2 :

 2 Fig. 2: Legacy BSI software architecture

  Fig. 3: Overview of AUTOSAR layers

Fig. 4 :

 4 Fig. 4: AUTOSAR software architecture

Fig. 5 :

 5 Fig. 5: Legacy architecture for CMP1 and CMP2

Fig. 6 :

 6 Fig. 6: New architecture for CMP1 and CMP2

  ). The Services Layer is the highest layer of the Basic Software. It offers

	Operating	system	functionality,	ECU	state
	management, vehicle network communication and
	management services, memory and diagnostic
	services.
	An ECU based on AUTOSAR architecture is
	composed of the following components:
	AUTOSAR Software Component	AUTOSAR Application Software Component		Actuator Software Component AUTOSAR		Sensor Software Component AUTOSAR	AUTOSAR Software	Application Software Component AUTOSAR
	Interface	Interface		Interface		Interface	Interface
	ECU			AUTOSAR Runtime Environment (RTE)
	Firmware
	Standard Software	Standardized Interface		Standardized AUTOSAR Interface	Standardized Interface	AUTOSAR Interface	AUTOSAR Interface
					Services		Communication	ECU Abstraction
		Operating System	Inteface	Standardized	Basic Software Standardized Interface Standardized Interface	Microcontroller Standardized Interface Standardized Interface	Complex Device Drivers
							Abstraction
						ECU-Hardware

..............


P Cuenot

B Tavernier

J M Talbot

Embedded Software V&V using Virtual Platforms for Powertrain applications

Keywords: TLM, Verification, virtual platform

Current development trends for automotive products are driven by time to market reduction, cost optimization, and quality improvement. Dual to these business constraints are demands for innovation and safety conformance which impose increasing complexity on embedded systems. To address these challenges impacting software and hardware to improve system dependability, new methodology and tools need to be set-up. The use of representative virtual platforms combining speed and accuracy allows earlier software development, improved system testing, and fault injection analysis, with a high potential for reuse of system IPs (including both hardware and software). In this paper, we will present investigation on new methods and associated results using a simplified virtual platform to test a powertrain application.

Introduction

Current development trends in embedded automotive software for Powertrain systems are towards increased complexity due to the very high level of optimization in the control/command. Systems control complexity ranges from low end applications such as gasoline port injection, to more sophisticated applications such as high pressure diesel engine, to very high end applications such as hybrid and power management control. As a consequence, the algorithms applied increase in complexity and require more resources to execute with the level of confidence required by a safetycritical system.

In parallel, the introduction of new features for passenger comfort, the addition of new sensors and actuators to comply with pollution regulation, and interconnection with in-vehicle network communication drives increasing software and hardware complexity which makes the system more difficult to test on a classical test bench. To face the challenge of the greater complexity of both software and hardware, new methodology and tools need to be set-up. In particular, the use of representative virtual platforms which combine speed and accuracy facilitates earlier software development and better testing of the systems. Another industrial issue is hardware design, followed by software development often places the software development in the critical project planning path. Virtual platforms allow early software development in general and hardware dependant software (e.g. device drivers) in particular. Virtual platforms also simplify the distribution of reference hardware architectures throughout geographically distributed development groups within a company. Virtual platforms also benefit the entire supply chain.

Virtual platforms are providing the automotive industry with additional means to face its economical challenges in facilitating Design to Cost optimisation. HW/SW trade-offs, effect of hardware configuration can be assessed by early and fast platform prototyping. New hardware architectures embedding ASICs can be explored to optimize performance.

The key issue for such technology is the availability of hardware models and their conformance to their silicon implementation. Simulation performance and standardization of hardware modelling style are mandatory for industrial usage in automotive embedded systems. We believe that Transaction Level Modelling is adequate to reach these goals as supported by the systemC OSCI initiative [START_REF]OSCI[END_REF].

In this paper, we will present a virtual platform based on a simplified version of the Copperhead microcontroller (MPC5554 from Freescale), including an external ASIC model developed in SystemC by Continental. This platform was developed using the CoMET tool from VaST Systems Technology. We focused our study on demonstrating on how this platform can facilitate early software development and non-regression testing of the system without the need for physical hardware.

In the first section, the methodology used for hardware modelling with a TLM style is presented, while section two describes the use case study and a platform overview. Section three details the technical results obtained and compare them to the initial objectives. Finally, the conclusion outlines the benefits of such approach and possible extensions for industrial application.

Modeling Technology

A virtual platform enabling software development for powertrain application (and more generally safety critical application) must be fast and accurate. With a TLM approach, VaST core models like the e200z6 are able to run classical benchmarks like Viterbi at more than 80 MIPS (with more than 99% cycle accuracy) on a 2 GHz Pentium 4 machine with 1 Go of RAM. Keeping that range of speed at the platform level can be achieved by abstracting the signals and the behaviour to a higher level than RTL without compromising the timing accuracy at the system level.

In this chapter, we will present some modelling principles to maximize the simulation speed in the platform. First we will describe how clock signals are modelled and how communication channels like a serial link, an internal bus, or a CAN bus can be abstracted at a transaction level for modelling (TLM). Then we will propose generic principles for reducing the number of events in a SystemC peripheral model like a timer. We will see that this model can be used for acquisition of frequency inputs (like event capture in powertrain applications) with both speed and accuracy.

Clock Modelling

Clocks are one of the most critical signals we need to abstract for having a fast and accurate virtual platform. Since simulation kernels for modelling virtual platforms are event driven, a pulsing clock will generate an event on every edge, even if most of these events are useless.

For example, if a peripheral is in an inactive state but has a pulsing clock as an input triggering a callback function (for example a SC_METHOD sensitive to positive edges), some code will be executed by the simulation kernel even if it will have no effect on the platform behaviour.

To improve the simulation speed, clock signals can be abstracted by their period, implying the following advantages:

• An event is generated only when the period of the clock signal changes. The occurrence of that kind of event is far less frequent than the clock pulse. In SystemC modelling, sc_clock primitive objects are pulsing clock models. They should be avoided and replaced by an integer signal modelling the clock period. This kind of abstraction will require more computation than using the VaST API, but this can be easily managed by a helper class in charge of all the conversions between number of clock ticks and absolute time (as required in SystemC).

Communication Channels

The way to abstract communications over a specific channel follow the same principles:

• Data frames are passed from the producer to the consumer in one step. • Only observable parts of the protocol are modelled and (if required) associated with events. If the producer (or consumer) does not require these internal events (like partial phases of a burst transaction), the events are suppressed and this makes the protocol even faster. • Channels with arbitration are modelled by a specific "protocol engine" in charge of scheduling each transaction and granting the bus access to each master.

Serial Protocol

A serial transfer is abstracted to convey only the information relevant from the system point of view. Typically, on the simplest cases, only the following information is relevant at the system level:

• Baud rate of the transfer.

• Timestamp of the end of the transfer.

• Data transferred.

So instead of modelling each bit transfer at each clock tick, we can abstract all of these events by a single transaction transferring the data in a single event with the timing calculated by taking the baud rate period multiplied by the number of bits transferred.

Bus Abstraction

Bus transactions are abstracted by observable events from a master or a slave point of view. For example, in an internal bus transaction, only the following events are observable from a master requesting a bus transaction:

• Getting access to the bus (grant event)

• If required, completion of intermediate phases of the transaction such as in the case of a burst access (partial completion event) • Completing the transaction (complete event)

Independent of these events associated with the bus protocol, the data can be transferred in a single step.

The same kind of abstraction are used in the CAN bus model where a specific "Protocol Engine" model is in charge of resolving priority questions build from message configuration. Only observable events are modelled such as when a frame is accepted, or when a frame has been successfully received.

Efficient SystemC Modelling

Since SystemC modelling style is event driven, efficiency in implementing a peripheral is obtained by limiting the number of events generated by the model. This is mainly done by combining modelling techniques like: • Event prediction. This means using the current context to predict an event which will happen in the future. Of course, a change in the peripheral context (for example a change in the registers of the peripheral, or a modification of the reference clock period) must be taken into account and future events must be programmed again. • Context storing and computation. This means storing into the peripheral model any information necessary to update the peripheral state when required (e.g. when the user needs it). In our timer example above, we will see that storing a timestamp can save hundreds of events without losing accuracy.

Another important issue, more related to SystemC implementation than an abstraction principle, is: since a SC_THREAD is implemented as a thread in the OSCI kernel, this kind of construct implies an overhead due to task switching. In most cases, this can be avoided using a "callback" modelling approach by combining a SC_METHOD and an internal event which is used to trigger the callback.

A simple timer model for counting events

In this paragraph, we will see how the above general principles can be implemented in a simple timer and how this methodology offers dynamic clocking capabilities "for free". Then, we will see that this capability can be used to count and measure events, where the input could be a clock signal with a variable frequency (common case in automotive applications).

Timer external interface

The simple timer interface will contain:

• A bus interface composed of a Bus port and a Bus Clock port. The bus interface will be connected to the peripheral bus accessible from the Bus ports of the e200z6 core. • A "Reset" input.

• A "TimerClock" input used to provide the clock reference used by the timer. • A "TimerInt" output. This port is a logical output used to request an interrupt. This output is typically connected to the Interrupt controller.

Timer registers

Remark: In this paper, we will not talk about the particular TLM protocol used to access internal registers. Simulation Tools such as VaST's support several bus protocols and automatically add a Cycle-Accurate Bus transactor to support PV (Programmer View) untimed models. Here we will just suppose that the TLM protocol enables a bus access for reading or writing internal registers. More details can be found in [START_REF] Ghenassia | Transaction-Level Modeling with SystemC: TLM Concepts and Applications for Embedded Systems[END_REF].

Our simple timer will use 5 registers:

• GTR (Global Time Register) contains the current number of clock ticks elapsed. This register is used to clear the interrupt. • TIMER_ENABLE is used to enable/disable the timer.

Timer behaviour modelling

The specification of this very simple timer is the following:

1 -When a reset occurs, all register values are set to zero and the TimerInt output is set to zero. 2 -When the timer is enabled, the GTR register can be read from the bus interface to get the current number of edges since the latest interrupt. Even with such a simple specification, an inefficient modelling style could lead to poor simulation performance. For example, modelling this timer using a pulsing clock used to increment the GTR register could imply the simulation speed to be in the KIPS (Kilo Instruction Per Second) range instead of the MIPS range, even if the e200z6 core model can run at more than 60 MIPS. Furthermore, it is useless trying to keep a continuously updated value in the GTR register, especially if the user (ie the software) does not read it.

We will model the behaviour using the three principles described above:

• No SC_THREAD. Our behaviour will use the following SC_METHOD: o The Reset method, executed when the reset input port changes o The ClockChanged method, executed when the clock port value changes. Since the clock will be abstracted by its period, this method will be triggered only when the period of the clock changes. o A MatchEvent method. This one will be triggered using an internal event used for event prediction. If nothing changes in the context, the mTimerEvent will occur at the scheduled time. This one will trigger the TimerEvent SC_METHOD where we write 1 on the TimerInt output port and in the TIMER_INT register.

Dynamic clocking behaviour

For dynamic clocking, we must take into account that the frequency of the input clock may change. When this occurs, we need to:

• Update the current GTR value: since the ClockPeriod is used to compute the GTR value, the ClockPeriod must be constant since the GTR value and timestamp were last stored.

• Reschedule the match event: the prediction has been done with the previous period value.

void cTimer::ClockChanged(void) { UpdateCurrentTime(); mClockPeriod=mTimerClockPort.read() * sc_get_time_resolution(); SetupNextMatch(); }

Event counting

The timer described above can now be used to generate interrupts at a frequency multiple of the frequency of the input. This control is typical from powertrain applications to build internal system clock from sensor information. The missing part is the "testbench" generation, providing the clock period evolution scenario. This can typically done using a system level modelling tool like Matlab / Simulink or Saber connected to the virtual platform. This test bench will be sampled at a rate defined by the synchronisation period between the system simulation environment and the virtual platform simulation kernel. The input event frequency will be converted to a clock period in picoseconds (VaST kernel resolution) and passed to the timer defined above.

Platform Presentation

The previous chapter has presented a modelling methodology for reaching the TLM level of abstraction by reducing the number of events to the minimum required from an external point of view. This methodology has been illustrated on a very simple example but can be applied to complex peripheral modelling. This chapter will describe a platform made for evaluating the usage of virtual platforms for powertrain application development.

Digital core description

The goal of this platform is to enable early software development on a system based on a Freescale MPC5554 microcontroller (Copperhead) and a customized ASIC design by CONTINENTAL, connected through a serial link to the copperhead, with the DSPI peripheral.

The need to have a SPI link fully functional implies some other peripherals to be added to the platform: • The MPC5554 DSPI itself [START_REF] Freescale | MPC5553/MPC5554 Microcontroller Reference Manual[END_REF]. Only the SPI behaviour will be modelled. The interface of the DSPI will define 3 32 bit signals to abstract the communication :

o SDI signal will contain all the input bits of a reception o SDO signal will contain all the output bits of a transmission o SCI_CONTROL will be used by the master to manage the transaction, provide the cycle accurate timing of the complete transaction, and encode configuration information of the DSPI [START_REF] Freescale | MPC5553/MPC5554 Microcontroller Reference Manual[END_REF] (chip select, control bit status…). No buffering mechanism will be modelled since the eDMA will be used to automatically transfer input and output frames from the memory to the DSPI registers.

• The MPC5554 eDMA. The model will be restricted to only 2 channels (32 and 33) which are used to automatically transfer data to and from the DSPI [START_REF] Freescale | MPC5553/MPC5554 Microcontroller Reference Manual[END_REF]. • The simple timer presented in the previous chapter. Our software is reactive and interrupt driven. This simple timer will be used to generate interrupts at a fixed or dynamic rate. In a full copperhead model, this should be managed by the eTPU. • The MPC5554 INTC [START_REF] Freescale | MPC5553/MPC5554 Microcontroller Reference Manual[END_REF]. This model will implement software interrupts and will be connected to the DSPI, eDMA, and timer.

Figure 1: MPC5554 simplified platform

The platform will be based on the VaST e200z6 core model and the interconnection will be simplified as a single bus. This is a source of inaccuracy at the platform level since the MPC5554 uses a crossbar which can support simultaneous DMA transfers and e200z6 core memory accesses.

ASIC description

Connected to the simplified model of the MPC5554, a power stage output driver is modelled in SystemC/TLM style. As depicted by the hardware schematic in Figure 2, it is a simple component controlled in slave mode through a SPI interface of the microcontroller. The commands transmitted from the master as serial data are converted to parallel digital outputs. The peripheral sends back the diagnosis status of the outputs. Detection of open circuit or short circuit is performed by the peripheral from internal current analysis.

Figure 2: Description of Power stage driver

As explained in digital core description, the SPI interface is abstracted with three signals: sc_in SDO (for output transmission), sc_out SDI (for input transmission) and sc_inout SCI_CONTROL. SC_METHOD of the peripheral model is sensitive to SCI_CONTROL, and manages the transaction by decoding configuration of the cycle accuracy transmission (chip select, first bit transferred, last bit transferred). The diagnosis part is abstracted by a text file. Data from the text file tagged with a transmission date, are copied in the SDO signal and transmitted at the correct time using engine simulation services. This ASIC model has been validated out of the context of virtual platform with a software bench implemented in systemC.

Software description

An industrial software of engine management system is used and adapted to perform the evaluation. The code size of the original software is 8 MB executed on a MPC5554 cadenced at 80MHz. For peripherals, all eTPU channels are configured, software controls communication interfaces (FlexCAN, DPSI, eSCI) and simple or complex Two software versions are adapted to cover the different objectives of the study: one for capability to debug software and another one for performance and accuracy measurement.

For the first one, the software is depopulated to remove all access to the MPC5554 peripherals not implemented in the virtual platform (see digital core description above).

The second software is build by removing the code for all the peripherals control and the eTPU code. Performance and accuracy are measured on core and internal memory accesses (flash and RAM). Software is executed from flash into the e200z6 core using a standard cache configuration of 64KB.

Debug capabilities of the MPC5554 platform

One of the main advantages of the virtual platform is the capability to offer to the end-user much more debug features than the real hardware. This includes complete visibility inside the virtual hardware for purposes such as analysing the cache behaviour (hits / misses, cache evictions) of a specific software routine. It allows optimizing aspects of software like interrupt handlers or high performance routines (to reduce interrupt latency or minimize pipeline bubbles in assembler). All the examples above can be performed by mixing a "user friendly" software debug environment and an extended observability of the hardware, especially the core micro-architecture.

VaST cores are interfaced to industry software debuggers like T32 from Lauterbach and a tool called Metrix enables getting and correlating all the events happening in the simulation kernel. VCD traces (Value Change Dump) can also be easily generated to facilitate analysis of behaviour such as latencies inside the hardware.

Results

The results of the study are based on experiment performed inside Continental Powertrain Division. With detailed criteria functionality, accuracy and performance presented below, we aim to identify if virtual platform could be adequate to powertrain software context.

Functionality

Functional accuracy has been demonstrated using Lauterbach T32 debugger on the virtual platform.

Debugging environment was possible with the same user interface and behaviour as the one used with real target. In respect to limitation of the DLL and service introduced in the e200z6 core model, standard features as break point, trace, patch of code, display of microcontroller and peripheral registers were possible. SPI data interface was also captured using text file with time stamp value in accordance with real peripheral behaviour using observation precision programmed as 1 ms of precision (enough for functional observation of communication speed).

Performance

Simulation performance was calculated from an execution loop of the software performance measured to 1 second on the target. On a Laptop equipped with Dual Core T2400 running at 1.83GHz and 1 GB memory, simulation time for loop execution was measured around 3.5 seconds. A 15% overhead has been measured when the simulator is driven by Lauterbach T32. The table bellow also gives the results of peripheral integration test software intensively reading and writing to the SPI device using the eDMA. As the crossbar switch configuration and memory models were not accurate in the virtual model, the correlation with measurement value is sufficient. Indeed in parallel to this experiment, complete model of MPC5554 was developed and is depicted below in Figure 6.

Conclusion

The objective of the study has been achieved by demonstrating the use of TLM modelling style with the VaST environment to build a virtual platform with acceptable performance and accuracy.

Such virtual platform including ASIC modelling facilitates debugging software of an engine control application. It allows to integrate ASIC models and to close the HW/SW development loop for device drivers. It also provides a solution for designing ASICs by starting with an abstract model implemented in SystemC/TLM. This abstract model could be considered as the golden reference model and specification requirement for hardware development in a RTL modelling style.

In order to face the complexity of industrial application such as engine control software, a scaling demonstration has to be conducted to prove that acceptable overall simulation performance can be obtained. This will be achieved using a complete model of a MPC5554 connected with several ASICs and stimulation bench to activate all software functionality.

Such methods and tools could also be used for architecture exploration of new product family. Anyway, fundamental condition is the availability of the hardware models in advance of silicon delivery. A typical use case, facing potential performance issue, is the foreseen introduction of dual core processor into next generation of automotive embedded systems.

3 -

 3 An interrupt is raised when GTR = OS_PERIOD and INT_ENABLE = 1. Raising an interrupt means writing 1 on the TimerInt logical output and in the INT_FLAG register. 4 -TimerInt output can be cleared by writing zero in the INT_FLAG register. 5 -Dynamic clocking must be taken into account.

  interfaces (EMIOS, eQADC, Port of SIU).

Figure 3 :

 3 Figure 3: Example of hardware analysis with Metrix tool (Cache, VCD, Bus monitor) Using Lauterbach T32 or VaST MFA (Metrix Function Analyser) tools, profiling trees can be

Figure 5 :

 5 Figure 5: Measurement for accuracy

Figure 6 :

 6 Figure 6: Complete MPC5554 VaST Model

  • OS_PERIOD contains the clock ticks target value for generating an interrupt. • INT_ENABLE is used to enable interrupts when GTR = OS_PERIOD. • INT_FLAG reflects the TimerInt output status.

  value of 1.34. It was calculated from real wait state figures in regard of the flash memory configuration, and using cache hit / miss ratio for the number of memory read and write operations of the software. The accuracy was finally estimated to 92.3% as shown below in Figure5.

	MB leads to a Virtual HW / Real HW ratio of 15 (e.g.
	7 MIPS).
	Accuracy
	Measurement of accuracy was calculated by
	comparison of number of cycles between real target
	and simulation target. Since the memory model in
	this platform was a very simple one, we needed to
	introduce an adjustment factor that was estimated to
	a worst case Frequency	Cycle
			number
	Target	80 MHz	10502131
	Simulator (Simple	80 MHz	7232456
	Memory model)
	Simulator corrected	80 MHz	9691491
	with ratio (1,34)
	Accuracy Error		-7.7 %
			Configuration	Virtual HW /	MIPS (s)
				Real HW ratio
			Peripherals test software on	1.7	60 MIPS
			T2400 with 1Go of Memory
			Continental SW on T2400 with	3.5	29 MIPS
			1Go of Memory
			Continental SW on T2400 with	4.0	25 MIPS
			1Go of Memory under
			Lauterbach T32

Figure 4: Measurement for speed Note: A recommended configuration is at least 1GB of memory. As an example, the Continental SW running on an Intel Pentium M at 1.6GHz with 512

Acknowledgement

This work was supported by active contribution of Continental colleagues Christophe Marigo and Norbert Mignot. We wish to acknowledge them for their work and positive exchange during this study.