Tuesday, November 18, 2014

Why AUTOSAR? - Part 1

As AUTOSAR gains momentum in the automotive community, you may still be wondering whether it’s a good idea for your company and what benefits it will bring. And it’s just as important to understand the potential drawbacks as well.

The answers, of course, depend on whether you’re an OEM, Tier 1 or Tier 2, and are different for each case. The best approach is to first describe what AUTOSAR is and then consider the varying viewpoints.


In this blog entry, let’s focus on the “what”.


What is AUTOSAR?


AUTOSAR is essentially a collection of specification documents (approximately 200 in all), specifying three major areas:


1) Software Architecture:  

Layered software architecture allowing complete abstraction of application from lower level implementation details. Additionally, a standardized and complete basic or environmental software stack for ECUs – the AUTOSAR Basic Software – is specified.

While layered software architectures are not a new concept, what AUTOSAR provides is standardization. This standardization ensures a consistency between competing solutions as well as interoperability. The major areas defined by AUTOSAR are:



  • Component Template – Provides a specific way to describe a software component. This includes details on the component’s interfaces as well as its internal behavior.
  • System Template – Provides a specific way to describe a system of software components as well as any details regarding what lower level services those components may need.
  • Run-time Environment (RTE) – Can be thought of as the “glue code” that abstracts the lower level interfaces to the application. This includes access to network data as well as scheduling of the application software “runnables”.
  • Operating System – The AUTOSAR OS specification is based on the prior OSEK standard, but can provide some advanced functionality such as memory and timing protection.
  • Basic Software – The basic software in AUTOSAR is organized into three layers: the Microcontroller Abstraction Layer (MCAL), ECU Abstraction Layer and the System Services Layer. The specifications for these modules typically describe the API, the file structure, and the configurability details.

2) Systems/Software Methodology (Data model, workflows):  

Exchange formats & templates to enable a seamless configuration process of the basic software stack and the integration of application software in ECUs, including the methodology for using this framework.



The top diagram above depicts the methodology used in creating an AUTOSAR system. Briefly, the VFB view shows an entire system described as a set of components (or functions), and how they communicate with each other via a Virtual Function Bus (VFB).

The lower diagram shows those components deployed to one or more ECUs. The RTEs and Basic Software in each of these ECUs need to be configured to realize the VFB.


This configuration step is greatly enhanced by the xml-based exchange format that AUTOSAR has defined.



3) Standard Application Interfaces:

Specification of interfaces of typical automotive applications from all domains in terms of syntax and semantics, which should serve as a standard for application software.

Next time, we’ll go into more detail on each of these items and the potential benefits and drawbacks.

Monday, September 29, 2014

EHOOKS enables creative freedom for Controls Developers and Calibrators



Today’s automotive controls development engineers and calibration engineers are highly specialized experts on vehicle systems.  I have always been impressed with their resourcefulness and excellent problem solving skills.  In my experience, they have a much greater understanding of embedded controls software than ever before.  These engineers often have great ideas on how to solve problems and improve vehicle system performance, efficiency, and quality using embedded controls software.

Unfortunately, internal company processes, tools, and organizational structure often limit what engineers are able to do.  One of the biggest problems that I often see is when controls development engineers need to develop and test new controls functions, they are dependent on the ECU Tier 1 or internal software group to create the prototype software necessary to develop and test the new controls function.  Any change or new idea requires a new prototype software build and more waiting for the controls developer.  Similarly, when a calibration engineer needs to bypass a RAM variable to test an idea or workaround a software bug, they are also dependent on the ECU software group to create the prototype software necessary to continue working.  These dependencies and lack of the right tools is very frustrating for engineers and leads to inefficiencies and unnecessary delays in the development process.

Fortunately, we have a product called EHOOKS that has become the game changing solution for ECU software development process bottlenecks and dependencies.  Many automotive OEM departments from around the world have already adopted EHOOKS and have seen immediate benefits for controls development and calibration processes.  With EHOOKS, users simply pick any ECU RAM variable(s) and choose to bypass the variable(s) with a constant, a new calibration variable, a Simulink model, or a C-Code function.  EHOOKS will generate a new ECU software file that can be flashed on to the ECU.  A calibration tool like INCA can then be used to turn on the bypass variables, edit the newly created calibration variables, and measure the results.   The best part is that it only takes a few minutes to make changes in EHOOKS and generate new ECU software to test.
Benefits for the Controls Developer

With EHOOKS, the controls developer now has the freedom to quickly add their own hooks into the ECU software without depending on the software group.  This allows them to easily integrate and test their prototype Simulink model or C-Code function with the ECU software.  The other benefit is that EHOOKS supports on target bypass and external bypass.  If the size of the Simulink model or C-Code function becomes too large for the available space on the ECU, then they can use an external simulation device (e.g. ES910 module) to run the prototype model or function.  

Benefits for the Calibration Engineer

With EHOOKS, the calibration engineer can quickly and easily bypass any ECU RAM variables.  This enables calibrators to test and calibrate diagnostic monitors and ECU software robustness by bypassing ECU RAM variables (e.g. sensors) with calibration variables.  EHOOKS also enables calibrators to work around ECU software bugs and continue working instead of waiting for the software group to provide new ECU software.  This can all be done on the target ECU so there is no need for an external prototyping hardware or simulation device.   

For more information on EHOOKS, check out the links below to a couple of short and interesting YouTube videos.

Monday, September 15, 2014

Simplifying the Transition to AUTOSAR

As AUTOSAR becomes more and more popular, companies are looking to make the transition.  However, this transition can seem like a daunting task.  Things like legacy code, resources, lack of knowledge of the standard, cost, and timing can make the transition difficult to do alone.  At ETAS, we strive to make this migration as painless as possible.  While we understand the transition isn’t going occur overnight, we work with our customers to provide them complete example AUTOSAR software, provide training, and assist during the integration of legacy and new code. 

Some of the most common features in an automotive system are CAN, non-volatile memory and diagnostics.  For someone unfamiliar with the AUTOSAR architecture, configuring each of these features in a system can take a significant amount of time and resources.  As an OEM, most of these services are not providing additional value and innovation to your system, but are required to make it work.  The less time spent designing and configuring these services, the more time can be spent on making application software, which provides significant value to your products.  For this reason, ETAS offers services and products to provide your company a jump-start on integrating AUTOSAR into your system.

By working with our customers up-front, we can provide example configurations that will demonstrate the features which your project requires in complete packages.  These packages would include example application software components that take advantage of the various system services like CAN and NvM, basic software component from COMASSO (an open-source BSW consortium), a complete OS that has been proven on millions of vehicles worldwide, and an RTE as required by the AUTOSAR standard.  We’ve worked with many different MCAL providers as well, and can even assist in integrating this software into your system.  For example, one of the first configuration examples customers would ask for would include communications, generally over CAN.  In this case, ETAS will work with the required MCAL provider for the target hardware, and provide example configuration for all of the AUTOSAR modules required: Can driver, CanIf, Com, ComM, and PduR.  Using this approach, ETAS can then work with you to provide all the necessary training and expertise required to integrate your software into AUTOSAR.

We think that AUTOSAR provides a lot of opportunity of collaboration among companies.  At ETAS, we hope to make the switch easier for you and your company.

For an even more in-depth look at ETAS AUTOSAR solutions see,  "Open Source" AUTOSAR

Thursday, August 28, 2014

Innovative solution for calibration tasks that require automated high speed ECU access



Sometimes there are calibration tasks that require an innovative solution.  For example, a calibration engineer was tasked with the responsibility of calibrating the vehicle “lift foot” logic on an Engine ECU.  The calibration process required that a sequence of calibration commands be sent to the “lift foot” logic in the ECU software within 10ms of measuring that a “kick down” event has occurred in the vehicle.  The calibrator created a test script in Matlab and used the INCA-MIP (Matlab Integration Package) to automate INCA for this task.  The problem is that INCA-MIP uses the COM API interface to INCA and COM API is limited to 100ms access times. Therefore, it was not possible to send calibration commands within 10ms of measuring the “kick down” event using Matlab/COM API.

The solution proposed by ETAS was to use INCA-FLOW and INCA-MCE together.  INCA-FLOW enables the automation of vehicle calibration tasks with a powerful yet easy-to-use graphical scripting interface.  INCA-MCE (Measurement Calibration Embedded) software with the ETAS ES910 hardware provides “fast ECU access” capability for rapid ECU calibration turn-around times and high speed measurement throughput.  With the latest release of INCA-FLOW v3.1, it is now possible to use these two powerful solutions together.  

The ES910 hardware, which is required to run the INCA-MCE “fast ECU access” connection between INCA-FLOW and the ECU, was installed in the vehicle.  The calibrator then used INCA-FLOW to create the calibration process.  For the calibration variables that needed be modified very fast (e.g. within 10ms), the calibrator added them to the MCE list as shown below.

Figure 1.  Screen shot of INCA-FLOW calibration variable selection



INCA-FLOW with INCA-MCE enabled the calibrator to create and run automated optimization routines that could successfully calibrate the Engine ECU “lift foot” logic within 10ms of measuring the “kick down” event in the vehicle.  This innovative solution will open the door to many other calibration tasks that require automated high speed ECU access.

Figure 2.  INCA-FLOW and INCA-MCE setup in the vehicle


Wednesday, August 13, 2014

Easily and quickly automate vehicle calibration tasks – no scripting expertise required!



In vehicle calibration is becoming more and more complex and time consuming.  Calibration groups are tasked with calibrating more complex ECU software and an increasing number of variants with limited resources and time to complete the tasks.  One way that calibration groups are working to improve their efficiency and overall quality of software calibration is by automating calibration and validation tasks as much as possible.  Many ETAS customers have created Matlab scripts to automate INCA using the ETAS INCA-MIP (Matlab Integration Package) interface.  This requires Matlab scripting expertise.  Most calibrators do not know Matlab well enough to create Matlab scripts or to even modify existing scripts to meet their needs.  Some calibration groups have had to hire scripting experts, but they may not have the calibration experience necessary to create the calibration scripts.

A Better Way….

This challenge has led to the growing popularity of ETAS INCA-FLOW within many calibration departments at various OEM’s and Tier 1’s.  INCA-FLOW enables the automation of vehicle calibration tasks with a powerful yet easy-to-use graphical scripting interface.  Since it does not require scripting expertise, calibrators can easily and quickly create automation tests with INCA.  The graphical modeling interface of INCA-FLOW allows users to drag method blocks into the graphical space, connect the blocks, then compile the script into an executable and run with INCA.  There is a large library of method blocks in INCA-FLOW that contains simple base method blocks and more advanced method blocks for calibration optimization and analysis.


Figure 1:  ETAS INCA-FLOW graphical scripting interface

There are many benefits with INCA-FLOW.  It is not only easy to use for any calibrator; it is also flexible for the calibrator to modify existing INCA-FLOW test scripts as needed.  INCA-FLOW helps less experienced calibrators learn and understand the calibration process by viewing the block diagrams in the graphical interface.  INCA-FLOW enables calibration and validation test departments to establish global best-practices with identical and repeatable results.

INCA-FLOW has been successfully utilized many different use cases.  Tests that are required to be repeated on every software release or program variant are prime examples of using INCA-FLOW.  In many of these cases, the calibration expert creates the INCA-FLOW script and then distributes the compiled script to calibration groups, vehicle drivers, or test cell operators.  The latest release of INCA-FLOW v3.1 contains method blocks for the read/write of Excel.  This has enabled validation groups to create diagnostic test scripts that read values from existing Excel files and write the results of the diagnostic test back to the Excel file.  Many calibrators have also created calibration processes in INCA-FLOW that automatically optimizes calibrations of specific ECU functions (e.g. low-idle speed control, optimization for variable cam shaft, misfire detection, and shift quality).  

For more information on INCA-FLOW, please refer to the following link: