Wednesday, September 30, 2015

Visit ETAS at the SAE 2015 Commercial Vehicle Engineering Congress

We look forward to seeing you at the SAE 2015 Commercial Vehicle Engineering Congress, taking place October 6 - 8 at the Donald E. Stephens Convention Center in Rosemont, Illinois. It is the conference of choice for the sharing of technical knowledge and networking for the global on-road and off-road commercial vehicle industry.

You can find ETAS at table 24, close to the entrance. At our table, you will find information on our latest technologies, all designed to help you increase efficiency and quality of your embedded systems.

This year, we focus on several PC-based technologies, including Hardware-in-the-Loop directly on your desktop; model-based calibration, and AUTOSAR based software development. Our experts will be on hand to answer all your questions.

Are you in town the evening before SAE ComVec?

If yes, please join us Monday evening for a free seminar on Advanced Calibration Techniques where we will provide an overview of the current status of model-based calibration and discuss several specific model-based calibration/design of experiments use cases.

If advanced calibration is not your main area of interest, but you happen to be in town, we'd love to have you for the Social Hour only, beginning at 7:30 pm. Come to meet and mingle with the ETAS experts and your industry peers. Pre-registration is required. Click here for more information or to register.

We hope to see you next week!

Friday, September 25, 2015

New Interactive Documentation Tool Makes ECU Calibration Easier

Press Release

As engineers develop ECU functions, thousands of pages of PDF documentation are generated. These pages are often referred back to during calibration, when the functions are fine-tuned. Sifting through huge PDF files is a tedious, time-consuming process.

The solution to this common problem is ETAS’ EHANDBOOK –an interactive tool that offers intelligent search functionality in place of tiresome manual searches and that automatically generates interactive graphics and models from ASCET, Simulink®, or C-code.

“Switching from PDF documentation to EHANDBOOK is just like making the move from a road atlas to a navigation system,” says ETAS product manager Dr. Patrick Frey. Instead of having to laboriously follow, say, the signal flows in a particular model over several pages of PDF documentation, this tool lets developers zoom seamlessly in and out of whatever models they choose. The graphical representation of information makes signal flows much easier to understand.

EHANDBOOK helps calibration engineers manage information and work efficiently, offering them a deep understanding of the ECU functions their colleagues in function development have produced. This interaction improves quality in the development process and shares knowledge within the organization, but above all it saves valuable time. “EHANDBOOK will change the way calibration engineers work” states Jayesh Patel, Program Manager at ETAS Inc. “Our automotive and heavy-duty diesel customers are very excited at the prospect that arduous PDF searches will soon be a thing of the past.”

About ETAS

ETAS provides innovative solutions for the development of embedded systems for the automotive industry and other sectors of the embedded industry.

As a systems provider, ETAS supplies a multifaceted portfolio that covers the range from integrated tools and tool solutions to engineering services, consulting, training, and support. Security solutions in the area of embedded systems are offered by the ETAS subsidiary ESCRYPT. Established in 1994, ETAS GmbH is a 100-percent subsidiary of the Bosch Group, with international subsidiaries and sales offices in 14 countries in Europe, North and South America, and Asia.

For more information, visit


Originally released on 07-09-2015; Press Contact: Claudia Hartwell

Wednesday, September 23, 2015

Software on Wheels - Part 1 of 2

Long before there is a product on the market, there are people who conceive the product, those who then write the requirements for its use in real life, and then those who translate those requirements into code. Of course, this assumes that the product is software-driven, but that’s not a wild assumption these days. What is interesting, however, is the process by which those abstract requirements turn into useful software that actually powers the thing. And the people who make this happen! Are they coders, programmers, or software developers?

I started my career as an engineer – consumed by thinking about how to make life more comfortable by designing products to take care of mundane, repetitive tasks. For me, that led to the discovery of the power of code. Not software, but code. Code that would automatically loop through hundreds of sequences or crunch through powerful math equations in no time. It was not until later that I understood how to unleash the power of code into meaningful programs that actually did something and then stitch those programs into useful software that could turn an otherwise mundane piece of metal into pure magic. A lot has been written on this topic already. Software runs our devices, not programs or code. Software is intelligent, it is re-usable, it creates value. In short, good software is like good poetry - more than a collection of words, it conveys emotion, turns on your imagination and brings delight in many ways.

But to get that way, software has to be designed well, written elegantly, and tested thoroughly. Tested as it is developed. Tested as it is integrated, debugged, enhanced, chopped, re-designed, re-evaluated and re-coded. In the automotive industry, software tends to be tested only after it is fully integrated into the ECU. That’s when it is often too late or too difficult to catch those nagging problems lurking in the lower layers of code. Testing is often cursory, not the least because of looming release deadlines. And that leads to huge problems – the least of which are expensive warranty recalls. In short, what the automotive industry needs is to re-invent software testing.

Or does it? That software in automotive ECUs is growing exponentially is a well-known fact, but that’s true for all other industries as well. One only needs reach into one’s pocket to appreciate the growing complexity of software – in our mobile phones. Mobile phones are released at a more rapid pace than automobiles, with new features and improvements added continuously. Only to be outpaced by the relentless pace of new apps that simplify almost every facet of our lives. Sure, they are not all perfect, but there are lessons that can be learnt from this. The automotive industry does not introduce new products at this rate yet, but considering McLaren’s frenetic pace of Formula 1 innovation (a new upgrade every 17 min, wow!!), the days of a new car model every 6 months may not be too far out! Not to speak of OTA updates which Tesla plans to push every three months using CarSync’s innovative technology. Such software-centric innovations are no doubt going to shake up the auto industry. What does that mean for software release cycles and consequently the software testing paradigm? Stay tuned for more in Part 2 of this blog.

ETAS Releases New ES523 CAN FD Interface Module

Press Release

Automotive OEMs are always looking for ways to increase speed and efficiency of their measurement and calibration tasks. CAN FD (CAN with Flexible Data rate) allows for 64 bytes and higher data rates in the data phase and fulfills future bandwidth requirements of up to 8 Mbit/s at low node cost.

Ann Arbor, Michigan, ̶ ETAS’ new ES523 CAN FD Interface Module is designed to calibrate ECUs and to capture measurement data from ECUs and ECU environments. It comes with four CAN and three Ethernet connections and supports the new high-performance CAN FD protocol on all CAN channels. The backward-compatible CAN FD protocol developed by Bosch meets the automotive industry’s need for networks with high bandwidth.

The ES523 module synchronizes all signals that are measured over the CAN and Ethernet channels. This makes the module ideally suited to the task of capturing signals transmitted in short time frames from an ECU via Ethernet through an ETAS XETK interface synchronously with CAN and CAN FD signals. In addition to ECUs and vehicle buses, the Ethernet measurement modules of the ETAS ES400 and ES600 product families can be connected to the interface module.

On the software side, the ES523 module is supported by INCA, the ETAS tool for measuring, ECU calibration, and diagnostics. In conjunction with the BUSMASTER open source software tool, the ES523 module can be used to simulate, analyze, and test CAN FD networks. To enable the integration of ECU and bus interfaces with third-party applications, ETAS provides the EBI-IP software package as a free download on its website.

ETAS North America’s president, David J Howarth states “ETAS was the first vendor to publicly demonstrate a working CAN FD system, using an early prototype of the ES523 with the Open Source Software CAN analysis tool BUSMASTER. We are excited to ship the release version of the ES523, which is also fully supported in the ETAS INCA-MCD software, as well as in BUSMASTER.”

About ETAS

ETAS provides innovative solutions for the development of embedded systems for the automotive industry and other sectors of the embedded industry.

As a systems provider, ETAS supplies a multifaceted portfolio that covers the range from integrated tools and tool solutions to engineering services, consulting, training, and support. Security solutions in the area of embedded systems are offered by the ETAS subsidiary ESCRYPT. Established in 1994, ETAS GmbH is a 100-percent subsidiary of the Bosch Group, with international subsidiaries and sales offices in 14 countries in Europe, North and South America, and Asia.

For more information, visit


Originally released on 02-11-2015; Press Contact: Claudia Hartwell

Monday, September 7, 2015

No hardware prototype, no problem! Do software tests on the PC.

Recently I published a blogpost announcing the new ETAS ISOLAR-EVE release and you’re maybe wondering what exactly I was talking about. So now I’d like to start a series of new posts about software testing in the automotive industry and what is nowadays possible to do on the PC. Before going into the details I'd like to focus first on what is actually needed in order to perform embedded software tests in a development process.

Test and validation are the most important activities to ensure the quality of automotive embedded software

Strong competitiveness on the market and high product renewal rates create short development cycles in the automotive industry. This obviously applies to the development of embedded systems. Unlike other industries such as avionics or railways, the automotive industry implements highly test-driven development processes in order to ensure the quality of the software.

Test and validation typically starts as early as possible using executable specification. It is of course then not really verification or validation in a software engineering sense but still already at this level system design and behavior of the embedded controls is often specified with models. The embedded functions are validated using specific rapid prototyping solutions – such as bypass in the engine management domain - and nowadays modeling at a higher level and system components integration at early stages are gaining more and more momentum (so called Model-in-the-Loop solutions). The reason behind this is of course the reduction of costly hardware prototypes.

Software testing on the PC: what am I talking about?

Later in the development process this move toward virtualization also impacts the software development process. The idea is simple: to perform all software testing activities without evaluation boards, electrically complex set-up or even A-sample ECU connected to a Hardware-in-the-Loop system. At this level benefits are clear: lower costs – only software needed – time savings in setting-up the test platform and generally speaking better user experience through flexibility. Tests can be done significantly faster or slower for better investigation and there are no performance limits such as emulators or debug interface bandwidth. Furthermore it allows for dedicated software integration tests.

These promising perspectives need nevertheless to be implemented in an established test process. Because of the importance of those tests and in order to guarantee the quality of the final product it is definitely something to be considered carefully. The issue is basically twofold:
  • to have a methodology and a corresponding process, ensuring that one knows what is tested and what is still to be tested all along the development cycle. 
  • to have the right virtualization technology fitting the defined process ensuring that the test intended to be performed is actually performed and provides relevant results

The topic of the methodology is my favorite. I have my taste for cerebral thinking - no I didn't write theoretical - defining how the world should be. After all I am an offspring of the culture which created René Descartes so that's understandable. But that's a very complex one too. Despite the homogenization and standardization of software architectures diversity is still the rule, between domains and sub-systems, depending on the cooperation models as well as business models between the market players. And culture plays quite a role too. Drawing a picture considering all the variants is not a topic for a blogpost rather for a discussion.

I have on the other side gathered experience for years discussing various use cases in different contexts and this is enough to extract some prerequisites that should be considered before deciding for a platform for software testing on the PC. At least I think. And that's what I will try to do now - without the ambition to be exhaustive in any way.

Make embedded software run on a standard PC

Obviously the first thing to consider is to make possible the execution of a target-specific code on the PC. There are different technical solutions:

  • solutions based on HW simulation/emulation
  • solutions recompiling the code for the PC target providing full access to the source code needing another level of abstraction

Both technical solutions have their strengths and weaknesses and they are highly depending on the use cases. So for now I will just allow myself a quite rough simplification: software testing is all about investigating software ensuring robust, bug-free and reliable behavior and for this access to the C-code during the execution is necessary. Thus solutions recompiling the code for the PC offer more flexibility and functionality whereas solutions based on HW simulation/emulation are more suitable for integration of the whole software into a virtual environment and its functional validation.

As I am blogging on software testing here I am focusing on the solutions integrating and recompiling the source code for the PC.

Having the HW abstraction at the software level is today made pretty easily possible with AUTOSAR. It might actually be more correct to write that it is made pretty easy as soon as a well-defined layered architecture is defined at an early stage. I have seen several "in-house" solutions in use that have been developed even before AUTOSAR. But nowadays the use of an industry-wide standard seems obvious. It is indeed the only way to cope with the significant increase of ECU functions exchanged in one format or another between more a more actors, due to:
  • more and more distributed development worldwide 
  • more complex software sharing models between OEMs and ECU suppliers 
  • co-development of reusable components inside organizations that are getting bigger
  • development partnerships 
  • the emergence of strong software engineering companies developing cross-industry expertise available at lower costs
And by the way it offers a well-defined architecture to virtualize embedded software. Dave Howarth wrote something on this topic here.

According to AUTOSAR architecture the hardware abstraction is done at the lowest possible software level thanks to the MCAL. It provides standardized interfaces to the software components above. It means they are all hardware independent, including Basic Software services or hardware abstraction module (diagnostic, I/O, communication, memory management).

Use a production OS – don’t test it

The Operating System is of course largely hardware dependent and also needs to be abstracted from its hardware dependencies. This is feasible using a scheduler, or a simulation of the target OS. But for most of the software validation tasks the correct scheduling according to the AUTOSAR models and the execution according to the final configuration is necessary to achieve the needed representativeness, especially for interrupts. The easiest thing to do here is to use the PC port of the AUTOSAR OS in addition to the PC MCAL modules. You then have all you need to abstract the execution of embedded software on the PC.

Nevertheless it has to be clear that the Operating System itself won't be part of the software-under-test on the PC. The OS configuration is tested and validated, the scheduling is ensured, but the overall timing behavior is obviously not, as it is highly dependent on the hardware resources management. You will do those tests later on the target anyway. So don't waste time doing them on the PC. What I mean is: it doesn't matter whether you're using the target OS on the PC or another one as long as you can read the very same configuration. There are much more important things to consider talking about the OS.

Control the time

In a purely virtual environment controlling the time is not only controlling the scheduling of the software-under-test. One still needs to make sure that its execution is synchronized with the test environment where test sequences and scenarios are defined. In other words: if a test sequence defines two events happening in a one second time frame, one must make sure that this second is the same for all other components of the test platform even if this is not a real second. If not, you will face significant timing inconsistencies and at the end of the day won’t get results that can really go through a quality assessment process. You will actually most likely have different results if the same test is run several times.

The implementation of a global time control mechanism is mandatory to make sure the tests performed on the PC are really verifying or validating anything at all. Having a time control for all inputs and outputs of the software-under-test enables a deeper investigation of the software and its interaction with the environment. It is then possible to apply detailed scenarios that are extremely complicated to reproduce in a real-time system, especially when it comes to testing safety critical software. Even before porting your software on the real target, software integration is possible up to the whole ECU software above the MCAL. The software quality is significantly improved especially in terms of robustness.

ETAS ISOLAR-EVE: complete infrastructure for software testing on the PC

All in all, a solution for software testing on the PC shall provide at least:
  • the infrastructure for the integration of components to be tested through these 2 key components: the MCAL and the OS for the PC. 
  • a deterministic scheduling for the software-under-test according the OS specification, for real-time and virtual time execution 
  • a time control mechanism in order to ensure the consistency of the tests performed

Only with this one can consider to test software intended to be produced on the PC and to use the results of those tests in a quality assessment process.

We kept these foundations in mind while developing ISOLAR-EVE and they are now available out-of-the-box for all addressable use cases.

ISOLAR-EVE completely supports the AUTOSAR standard, both from an infrastructure and a configuration point of view. It is based on Eclipse and ARTOP, meaning it works on the real production software configuration without the use of a specific database or format. Because of this, a consistent AUTOSAR architecture can directly be read and tested with ISOLAR-EVE.

Configurable time and data flow control mechanism thanks to the RTA-OS for Windows PC

Most important, ISOLAR-EVE comes with the PC port of the AUTOSAR OS from ETAS. The PC ports – RTA-OS for RTPC and RTA-OS for Windows PC – allows for real-time and non real-time execution. It ensures in all cases the deterministic scheduling for the software-under-test according to the OS specification in AUTOSAR format.

In non real-time the RTA-OS for Windows PC provides a unique technology ensuring time control. A server exposes all variables of the software-under-test. The variables are created as a Virtual Device during the configuration of the software to be tested. Depending on the tests intended to be performed, this can be done automatically by ISOLAR-EVE. All the Virtual Devices are available with open and documented APIs and it is a matter of scripting to then simply connect to any 3rd party tool.

This technology is used by our development team to provide new product features such as the generation of Simulink® S-function for the integration into Simulink® models, the coupling with a rest-bus simulation tool, or connection with the ETAS Experiment Environment. It can also be used to develop customer-specific interfaces via engineering.

But this is a story for another post, I guess this one is long enough already and I thank you for making it all the way to here. Next time I will give examples and it should be more concrete dealing with use cases.

But whatever the use cases you may have and we may be able to tackle with EVE, the underlying technology will always be the same: a full AUTOSAR conform infrastructure and environment ensuring abstraction, and a time synchronization mechanism.