International audienceAdopting 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

Heurung, Thomas

Nozahic, Romuald

English

Archive Ouverte en Sciences de l'Information et de la Communication

HAL Id: hal-02272357
https://hal.archives-ouvertes.fr/hal-02272357
Submitted on 27 Aug 2019
HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.
L’archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques 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.
Getting ready for AUTOSAR
Romuald Nozahic, Thomas Heurung
To cite this version:
Romuald Nozahic, Thomas Heurung. Getting ready for AUTOSAR. Embedded Real Time Software
and Systems (ERTS2014), Feb 2014, Toulouse, France. ￿hal-02272357￿
Getting ready for AUTOSAR 
 
Romuald Nozahic & Thomas Heurung – Mentor Graphics Page 1 
 
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). 
 
Figure 1: Forecast of number of AUTOSAR ECUs - Reference: AUTOSAR Consortium Open Conference 2011 
 
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 
0
50
100
150
200
250
already in use 2011 2012 2013 2014 2015 2016
Volume of ECUs with AUTOSAR
Rel. 4.x
Rel. 3.x
Rel. 2.x
Million
Getting ready for AUTOSAR 
 
Romuald Nozahic & Thomas Heurung – Mentor Graphics Page 2 
 
overhead in term 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.  
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) 
 
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. 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 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 
 
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: 
Getting ready for AUTOSAR 
 
Romuald Nozahic & Thomas Heurung – Mentor Graphics Page 3 
 
 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. 
 
Getting ready for AUTOSAR 
 
Romuald Nozahic & Thomas Heurung – Mentor Graphics Page 4 
 
 
Figure 2: Fixed Network design in a non AUTOSAR process 
 
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. 
 
 
Figure 3: Fixed Network Design in AUTOSAR Process 
 
Flexible function allocation and improved ECU reuse require a network design approach based on software to ECU 
mapping requirements as illustrated in Figure 4. A disconnected signal database is not part of the process and 
instead a network design step is in place. In this step the communication requirements are analyzed and either 
guidance for the user for the creation of the communication design is provided or the communication matrix is 
synthesized completely – providing a correct-by-construction design.  
 
Getting ready for AUTOSAR 
 
Romuald Nozahic & Thomas Heurung – Mentor Graphics Page 5 
 
 
Figure 4: Flexible Network Design Process 
 
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).  
 
Figure 5: End-to-End Timing Model 
 
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. 
 
Getting ready for AUTOSAR 
 
Romuald Nozahic & Thomas Heurung – Mentor Graphics Page 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). 
  
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 
Getting ready for AUTOSAR 
 
Romuald Nozahic & Thomas Heurung – Mentor Graphics Page 7 
 
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 
 


Getting ready for AUTOSAR

https://hal.archives-ouvertes.fr/hal-02272357/document

Getting ready for AUTOSAR

Abstract

Similar works

Full text

Available Versions

Archive Ouverte en Sciences de l'Information et de la Communication