Romuald Nozahic

Heurung -Mentor Thomas

Page Graphics

Getting ready for AUTOSAR

Getting ready for AUTOSAR

Adopting AUTOSAR comes at a cost. In particular a switch from an existing solution to AUTOSAR without process improvements is difficult to justify as this doesn't necessarily provide for a positive return on investment. This situation is dramatically different when a slightly different approach is taken. Current processes can be optimized and this optimization can yield a good ROI. At the same time this optimization can ease the path to AUTOSAR adoption at a later point and then provide potentially even bigger ROI. This presentation discusses this concept of process improvement and gradual migration towards AUTOSAR, using the network design process as an example. AUTOSAR-the most important standardization initiative of the Industry Original goals of AUTOSAR mainly focused on Scalability, Transferability, and Collaboration. Those goals were defined to save cost in developing new embedded E/E architecture in the automotive industry by:  Reuse of developed ECUs through different platforms/architectures  Reuse of developed and validated software in new ECUs  Optimizing number and size of ECUs  Minimizing specification reviews between stakeholders  Minimizing error cost by earlier validation opportunity  Minimizing integration effort by use of standardized API  Minimizing testing effort by use of validated modules (Hardware and software)  Minimizing Hardware cost by increasing network efficiency  Optimizing architecture cost by scenario exploration This amount of potential benefit from this initiative led to a huge investment from automotive OEMs, TIER1 and TIER2 suppliers; and the AUTOSAR Consortium Open Conference in 2011 showed a forecast of 250 million of AUTOSAR ECU in production in 2016 (Figure 1).

Lessons learned after 10 years of investments Today the automotive industry sees the cost and not hundred per cent of direct benefit which are foreseen by the ideal picture of AUTOSAR. Some reason for that are the increase of the complexity in configuring embedded software stack, the needed infrastructure and process changes to deliver proper ECU extracts to TIERs1, the We can sum-up this by stating that any stakeholder should expect that the first AUTOSAR project takes longer and is more costly than planned. Now, the question is how to make sure that the next AUTOSAR projects will take less time and cost than anticipated?

The lack of maturity of the standard, the cost associated to a migration, the moving target of a stabilized version lead to the different strategies from OEMs and TIER1s:  Use the introduction of AUTOSAR as an opportunity to redesign the whole E/E architecture and tools/ process associated  Carefully introduce AUTOSAR ECU for the utilization of new features  Reserve AUTOSAR standard for big ECUs  Get ready for a future use of AUTOSAR and choose the appropriate timing to move to AUTOSAR (cost and maturity will be monitored variables)

AUTOSAR -Start of a massive deployment

The answers to these questions and many others can help to take advantage of AUTOSAR. A U-turn from automotive industry at this point in time seems impossible and each stakeholder will have to adapt in order to see a return of investment. Based on the number of upcoming projects, in particular with multiple additional OEMs adopting the standard, we expect the following trends for a near future:

 ECUs developed under AUTOSAR will become the standard soon, as the overhead in term of development cost needs to be recuperated by follow up business with higher reuse.  Eventually non-AUTOSAR ECUs will come at a higher cost once AUTOSAR has been adopted as the investment in authoring tools, ECU configuration tools, and embedded software will have to be justified.  Mixed-architectures (AUTOSAR/non-AUTOSAR) will appear more often during a period of transition. This move from proven to none-proven architecture will introduce additional risks.

Observed Benefits

Based on lesson learned from active stakeholders in the initiative, we have seen that the implementation of AUTOSAR concept is difficult, costly and requires a full investment from the teams. Despite this, it represents a unique opportunity to improve the development process of the E/E architecture. This is the first time in automotive history that all stakeholders agree on a common standard that offers:

 Tool interoperability: OEM and Tier1 can set their flow independently without the need to have the same software providers. This simplifies the collaboration between different OEMs, Tiers1 and Tiers2 and creates an opportunity for each stakeholder individually to introduce advanced tool flows. Tool chains can be consolidated as they don't need to address the individual needs of different OEMs.  Executable specification: Software Component and System templates of AUTOSAR allow modeling the E/E architecture in comprehensive tools instead of manually handling loads of paperwork documents. This enables the digital continuity through different domains and improves communication within the supply chain. The latter point dramatically reduces the effort spent on specification reviews, which are typically time consuming and a source for interpretation errors. Using executable specifications reduces integration effort and allows the application of earlier verification methods to mitigate the risk for design errors.  Top-down approach: Even if AUTOSAR is not limited to a pure top-down design process, AUTOSAR allows using abstract objects such as functions, ECUs, topologies and signals. This helps E/E architects in a structured top-down design process to allocate functions to the best possible location. Signal and timing requirements can be captured the same way to support a requirements-driven network design.  Reuse of design data: This is one of the most important benefits that appear with AUTOSAR. Libraries of ECUs and Vehicle functions can be built, functional "components" can be reused and connected together to create new vehicles, platforms, or just to improve vehicle features during a facelift of a car model. This is where the sentence "Expect your second AUTOSAR project to take less time than expected" makes sense. Digital formats offer the possibility to connect objects together and to verify that those objects will work in proper way at the very first steps of the project. Virtual verification reduces the need for a prototype and it is possible to better define the new development requirements and their consequence for the project. Project management is facilitated.  Compliancy to ISO26262: This safety standard is now the reference for the automotive industry and is mandatory. AUTOSAR by itself doesn't magically make any system ISO26262 compliant but the structured approach introduced helps safety managers to cope with the safety rules.

Observation of current and past projects showed that users focused on some particular aspects of the standard and disregarded some important features. This behavior prevents to take advantage of the foreseen benefits. AUTOSAR has been defined as a whole and leaving aside some aspects can have more consequences than anticipated. For example if the post build configuration feature and a flexible communication design are not used, it will be very difficult the reuse the ECU in a different project or to reuse the validated software modules of the ECUs.

Flexible Network Design -A key for function allocation and ECU Reuse

Most OEMs use the same fixed communication matrix for all their car platforms and models (Figure 2). Their main objective is to maximize the reuse of ECUs across different car models as well as different brands. Coordinating the requirements of that many configurations, which also continually evolve, is a challenge that is typically met by limiting the changes to the communication design, i.e. limiting the introduction of new signals as well as retiring obsolete signals. Not only does this require a resource intensive process to manage the signals, it also leads to a sub-optimal communication design as each car model must run with the communication requirements of other vehicles with a very different specification and this typically wastes network bandwidth and hardware resources. Using this fixed communication matrix for AUTOSAR designs results in an introduction of overhead without taking advantage of the more flexible function allocation. Instead of being a means to enable software functions exchanging data over a physical network, this process becomes a constraint that the software and system architect must take into account (Figure 3). The connection between the signal database and the SW to HW mapping is managed by a process that only loosely couples these two aspects of the design process. In some cases this lead to inconsistencies which were discovered during the ECU configuration. With this approach the designs can be validated early and there's no confusion between design errors and implementation errors. Implementation errors can be found comparatively easy as the network behavior is well defined.

Designing the network based on the system requirements isn't an easy task and needs to cope with different constraints: timing requirements at function level, limited resource for data transfer depending of the type of network (CAN, LIN, Flexray, Ethernet), enabling the reuse of ECUs.

In order to fulfill the timing requirements, a timing model can be used (Figure 5). The Timing model handles the AUTOSAR objects and allows specifying end-to-end timing requirements for all vehicle functions. During the first steps, when function allocation has not been decided, it is possible to verify the correctness of the function behavior at a VFB level, and validate that the function executes the tasks in a timely manner. After the architect has done the function allocation, the overall timing requirements can be split and are used to automatically build a communication matrix fulfilling all the requirements of all signals.

Gradual Migration to AUTOSAR

This approach of using most of AUTOSAR features enabling function reallocation and ECU reuse in the E/E design can be apprehended without necessarily using the last step, which is the implementation and integration of the AUTOSAR Basic Software. An appropriate AUTOSAR authoring tool handling network design can easily generate the appropriate configuration files for non-AUTOSAR middleware configurations. OEMs can keep the benefit of using the standardized ARXML format and its associated templates (SWC, system, and hardware) for application specification and verification with all the benefit listed earlier. By using other, non-AUTOSAR, embedded software stacks it is possible avoid the overhead in terms of higher specification for microcontrollers as well as less complexity and less engineering effort configuring the embedded software stack.

In most cases the question for AUTOSAR is not about "if", but about "when" and "how".

The "when"-part is typically a function of cost. Currently non-AUTOSAR solutions are less expensive due to maturity and complexity of the existing solution. As more ECUs are put into production, the maturity of the standard as well as the supporting software solutions will improve. Together with the increase in experience in the engineering departments the cost of AUTOSAR ECUs will decrease and the cost for non-AUTOSAR ECUs will increase. In particular AUTOSAR ECUs that can be reused with little effort between brands and OEMs are expected to see the biggest benefit versus the non-AUTOSAR architectures.

The "how"-part offers a variety of options. In particular if the flow from Figure 5 is used, and software and system architectures are designed under AUTOSAR templates, the implementation (AUTOSAR, non-AUTOSAR) can be selected for each ECU individually. If a scenario other than the "leap of faith", i.e. all ECUs on AUTOSAR, is selected, then the migration scenario must include a clear strategy to handle mixed networks. Handling more than two types of network management requires use and configuration of a network management coordinator. This technology enables coordination of wakeup and sleep mode and must be implemented in one single ECU of each network.

Digital Specification

The digital continuity is crucial to take advantages from the AUTOSAR standard. As we have seen earlier it prevents interpretation errors, lower the workload of specification review, avoid human errors in recapturing data across different systems, etc... When the designer must cope with mixed architecture, this digital continuity is even more important. It is worthwhile to use software that allows not only generating the AUTOSAR related specifications like ECU Extract, but as well allows generating other artefacts that can help to handle other format to enable proper configuration of "non-AUTOSAR"ECUs. Figure 7 shows how Vehicle System Architect (VSA) from Mentor Graphics can make this happen.

Figure 7: Possible workflow to address mixed architectures

The idea of this solution is to make all the different data converging to the AUTOSAR format, to use the strength of AUTOSAR to execute the design tasks, and then choose the final implementation at ECU level. The designer can generate an ECU extract to be used for an AUTOSAR implementation, DBC or FIBEX files for network description, or FIX and NET which will automatically configure Components Off The Shelf (COTS) software.

The ability to import and reuse legacy data coming from Model Based Design tools, network design solution and diagnostic solution is something important to gradually and efficiently move from a legacy proprietary solution to an AUTOSAR compliant solution.

Conclusion

The current focus on the Basic Software showed the amount of effort needed to succeed an AUTOSAR implementation and the possible overhead in small and medium ECUs. A lot of the expected ROI in AUTOSAR cannot be reached without changing the design process. This design process brings a lot of benefits for OEMs who are currently not targeting an AUTOSAR implementation in Basic Software at this point in time, while at the same time helps to make the transition whenever they are ready for AUTOSAR.

Our recommendation therefore is to use the opportunity to redesign the design process now and decided on the implementation independently.

Key words

AUTOSAR; process; improvement; ROI; cost optimization; gradual migration; network design; Scalability; transferability; Collaboration; Digital continuity; Architecture design

Figure 1 :

 1 Figure 1: Forecast of number of AUTOSAR ECUs -Reference: AUTOSAR Consortium Open Conference 2011

  of microcontroller utilization, the training of hundreds of engineers, and the improvement of the standard itself, which lead to different and partly compatible versions of AUTOSAR in production.

Figure 2 :

 2 Figure 2: Fixed Network design in a non AUTOSAR process

Figure 3 :

 3 Figure 3: Fixed Network Design in AUTOSAR Process

Figure 4 :

 4 Figure 4: Flexible Network Design Process

Figure 5 :

 5 Figure 5: End-to-End Timing Model

Figure 6 :

 6 Figure 6: Post Build Configuration The Postbuild configuration illustrated in Figure 6: Post Build Configuration will enable the reuse of the ECU in different platforms and variants as it will be possible to use it in different configurations of the communication matrix (IE different signal to frame mapping).

  Those four strategies are not exhaustive and we see a lot of different positions toward AUTOSAR. The status quo today is that the amount of money invested in the standard means that we are past the point of no return.

	on what you learned in your personal car, even if it is a sport car. That means, even if a
	reasonable development process flow is in place before the introduction of AUTOSAR, the flow needs to be
	compatible with the AUTOSAR goals:
	 Flexibility of allocating functions. Reusing ECUs across platforms with minimum configuration and
	validation effort.
	 Balancing architectures for cost, size and physical distribution in the vehicle.
	 Support functional safety design aspects
	 Minimize manual specification review
	 Continuous check of implementation against requirements

A major part of this investment was spent on the "AUTOSAR Basic Software" (BSW) part. The results of this huge effort of the automotive industry are mixed: Basic software usage increased development complexity which requires more engineering effort. At the same time the hardware, i.e. the microcontrollers, are more utilized and may need to be upgraded. The possibility of reuse is still a question mark and is subject to a lot of parameters: AUTOSAR version, AUTOSAR features used for the targeted ECU (IE: post build configuration, partial networking...), safety level linked to ISO 26262, etc...

AUTOSAR -use the right standard in the right context

Getting benefits from AUTOSAR requires deep changes in the way of developing E/E architecture: You cannot drive a Formula One based only


Eric Bensana

Xavier Pucel

Christel Seguin

Improving FDIR of Spacecraft Systems with Advanced Tools and Concepts

de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Improving FDIR of Spacecraft Systems with Advanced Tools and Concepts

Eric Bensana, Xavier Pucel, Christel Seguin ONERA Toulouse, 2 av. Edouard Belin 31077 Toulouse CEDEX 4

July 5, 2013

Faults in spacecraft systems are an important problem, mainly because of the cost of downtime, and because their remoteness makes maintenance more difficult. This is why automated handling of faults can greatly enhance the system overall performance. This automated fault management relies on dedicated functions for fault detection, identification, and recovery (FDIR), that are often interleaved with the system, which makes it difficult to guarantee tolerance with respect to a particular anomaly, and makes the system difficult to maintain as well. On the other hand, several advanced computational tools exist that are known to support the tasks of FDIR. In this paper, starting from the current state of affairs in spacecraft system development, we develop and test several options for enhancing the quality of FDIR functions. First, we use software validation and verification tools to prove that the FDIR functions meet some functional quality goals. A second option we explore is to re-implement FDIR functions by Model-Based Reasoning algorithms, that are guaranteed to produce exact results with respect to a model of the system's behaviour. In each option, we use and compare several software tools, we compare the effort required to adapt, integrate and use them, and estimate the overall benefits they provide.

Verification and Validation of FDIR

Verification and validation of FDIR functions aims at offering guarantees of functional quality, as in how the system reacts to faults. It also supports the prototyping and early development of FDIR functions, which can greatly enhance their integration and utility in the system. These approaches rely on a formal representation of the system's behaviour, in absence and in presence of faults, as well as a representation of the quality requirements in the same formalism. Because these approaches involve computationally expensive algorithms, the modelling phase is critical for the success of the validation tasks, and we show in two studies how this complexity can be handled, for instance by analysing subsystems separately, or by using abstract or situational models.

In a first study with Astrium, we have validated the FDIR functions for a satellite thermal control system by analyzing separately 3 aspects of the system in 3 different modelling tools: the system architecture with Altarica and 1 Cecilia OCAS, the control software with Scade 6 and the physical components with HyTech. In each case, the tool offered both a language for modelling the subsystem's behaviour and FDIR requirements, as well an a model specific algorithm for checking which requirements were met.

In a separate study with Thales Alenia Space, we have validated an Attitude and Orbit Control System the COMPASS and SLIM tools. Separate analyses were performed for a model of the nominal behaviour (in absence of faults) and for a model that accounts for faults. In both cases, the model is qualitative and focuses on the system's architecture and ability to make use of the component redundancies.

Experience shows that although modelling a system's behaviour and requirements can be difficult, validating FDIR algorithms helps discovering design problems and correcting them. Validation tools have proven to be useful for critical systems development in general, and for FDIR modules in particular.

FDIR with Model-Based Reasoning

Model-Based Reasoning for FDIR is a different development approach, that rely on formal models of the system's behaviour, and analysis algorithms. It usually requires the encapsulation of the FDIR functions in a separate module, which makes validation and maintenance easier, at the potential cost of increased development time due to the architectural constraint and the complexity of the analysis algorithms. In this section we present two studies: the first study consists in the complete implementation of a FDIR module in a satellite flight control software demonstrator, the second study consists in the integration of academic diagnosis modules in a flight control software.

A BDD based FDIR module

The first implementation of a Model-Based FDIR module took place in a flight control software demonstrator from CNES. The system was already implemented in a hierarchical architecture. Some equipment redundancy mechanisms were already in place at the lowest level of the hierarchy, while at the topmost level several global reconfiguration modes could be activated, such as turning off the payload, or switch to safe flight mode. We used a custom made Binary Decision Diagram (BDD) library to build our FDIR module. We expressed the precondition for each reconfiguration action as a BDD, and implemented a state monitoring mechanism that encodes the system's current state as a BDD as well. Our FDIR module had a hierarchical architecture that maps that of the system, so that state monitoring and reconfiguration actions could be taken at any level of the architecture, thus restricting the affected part of the satellite and effectively containing the faults. BDD tend to lower memory consumption, and can easily be implemented without dynamic memory allocation, which makes them suited for satellite systems. The implementation was successful.

Complex tools and models

The second implementation of a FDIR module aimed at integrating and comparing several Model-Based Diagnosis tools. The challenge behind this integration relies on the fact that each tool provides different interpretations for diagnosis : the Lydia tool from TU Deltf produces sets of faulty components, the Diades tool from LAAS a classification of faults, the Livingstone tool a trajectory (i.e. a sequence of events) that explain an abnormal behaviour. We have also included a custom made diagnosis engine based on Prolog Eclipse based on predicate logic. Despite the variety of tools, we have established a common interface, based on common concepts such as modes, commands and faults, common data types such as assignments, observations, candidate and diagnosis, and common functions, such as initialization, model loading, observation and analysis, and integrated the four diagnosis engines in a flight software simulator. While the integration of the diagnosers was successful, it was difficult to evaluate the optimal granularity of the models to produce a useful diagnosis while containing the algorithmic complexity of the diagnosis reasoning. Moreover, it exhibited that without being guided by a collection of possible reconfigurations, it is difficult to judge how precise a diagnosis, and how precise a model, is needed.

Our Model-Based implementations of FDIR modules have confirmed our expectations in terms of greater modularity and maintainability. We also claim that they offer greater potential for validation, since the modeling formalisms for Model-Based FDIR are similar to those used in validation. We have discovered that modelling the system can be difficult, especially when there is no clear specification of the FDIR objectives. Such specification can be a predefined set of possible reconfiguration actions that must be taken automatically, which when available makes the implementation possible and efficient.