Wednesday, December 23, 2015

Happy Holidays and Happy New Year!













Best wishes to all our customers, partners and friends for a wonderful holiday season and a successful new year.

We would like to express our sincere appreciation for letting us work with you in 2015. We look forward to launching many exciting projects in 2016!

Our offices are closed December 24 through January 4. We will see you in 2016!
 

Tuesday, December 8, 2015

Is your ECU running out of I/O? Extend its capabilities!

Are you a developer who uses ECU's to accomplish different tasks?  Whether Automotive or other realms, ECU's can be used to drive many systems.  What happens when that ECU runs out of I/O for the specific application being tested?  With off the shelf tools from ETAS, that problem can be solved quickly and seamlessly.  For this example, an ETAS FlexECU was used, but this can be interchanged with most ETK enabled ECU's with some initial prep work.

External bypass with the FlexECU is accomplished by first having the necessary hardware and software.  For this example, an ES910 with ES410 is used to enable additional analog input channels to be used by the FlexECU for development purposes.  Additionally, INTECRIO must be used to configure the ES910 for bypass, as well as EHOOKS and INCA for configuring the FlexECU.  This example uses all hand coded C, but can easily be used with both ASCET and Simulink modeling tools.
       
External bypass is first configured on the ES910 using INTECRIO.  Because this bypass is one way, and we are only providing data to the FlexECU, a few considerations must be made when configuring this project.  First, open and create a new INTECRIO project.  Once a new project is created, add a new hardware system (ES910) and configure both the ES4xx device being used, and the ETK_BYPASS device.  More information on creating this system can be found in the INTECRIO user documentation.

With this system created, we can now configure the EHOOKS a2l to be imported into INTECRIO.
       
Open the EHOOKS configuration that will be used for bypass.  We must first create an On-Target bypass task to run the external bypass code in C.  To do this, add a new function in the “On-Target Bypass” tab.  For this example, ExtByp_C is used.


With this task created, we can now create our C code to make the function call and grab the bypass data.  Navigating to the build tab, we need to create two files.  We must have an .ehdef and .c file.  The .ehdef file is where we will create and configure our bypass variables, and our .c file we will make the necessary function calls to grab the bypass data from the ES910 and assign it to the FlexECU variables.  In order for the FlexECU variables to be seen by INTECRIO, “RP” must be checked.  This makes them visible to the rapid prototyping tool.


For this example, Byp_Test_Var1 is the variable that data will be written to from the ES410.  We must be sure to set the correct data type, and it must be consistent between the two platforms.  Heartbeat is used to ensure our bypass task is running.  Once all of the variables needed are added, we can look at C code.  Opening the new C file, it should be empty.  EHOOKS needs the basic setup for new On-Target Bypass tasks, which can be found in the “Example Code” window in EHOOKS.

This example code is the framework of our function.  This must first be added to our C file.
       
Once this is added, we can go ahead and add our heartbeat counter.

Once we have added our heartbeat counter, an enabler is added to allow for enabling or disabling of the External Bypass.

Bypass is done by making a function call in EHOOKS to grab the data defined at that location in memory.  Once we have built this new A2L file with our “RP” variables, it will be then imported into INTECRIO.  INTECRIO will then know the locations in memory to write the external bypass data, and the EH_Get call will grab that data.  More details on the necessary function call can be found in EHOOKS here:

By adding the EH_GetExtFloat32() call, it will grab the data written from INTECRIO to the specific place in memory defined by the FlexECU.  An example of this can be seen here, as I am grabbing a float32 and assigning it into a new variable, byp_read_test_var1.  It is then assigned to the variable defined in our .ehdef file, Byp_Test_Var1.

Once all variables have been added to this task, build the project.  The resulting A2L file will now be imported into the ETK_BYPASS device in INTECRIO.



Once imported, you will see the variables you added “RP” in your .ehdef file. 

Now that the variables are in INTECRIO, we need to set up the system.  Under “Systems”, double click on your ES910 system.  To create the link from the ES410 channel and ETK output channel, simply drag and drop the input you want from under the “Systems” dropdown, and similarly for the “ETK_Bypass” variable.

Once the variables to be used are found, simply drag them into the system workspace.

Once added, simply connect the output of the daisychain to the input of the bypass variable.

This creates the link. 
      
 Lastly, we must configure the OS to run the bypass without a condition.  To do this, move the ETK_Bypass send commands from “Software Tasks” to the 10ms task by dragging and dropping.  This will trigger the INTECRIO Bypass task every 10ms.


       
All that is needed now is to build this INTECRIO project, and create a new INCA workspace with both the FlexECU and ES910 simulation targets.  For more information on creating INCA projects, please consult the INCA user documentation.

Thursday, October 29, 2015

Online DoE with ETAS ASCMO and A&D’s ORION Minimizes Test Cell Time and Costs



Press Release


ETAS and A&D Technology are pleased to announce the integration of their products ETAS ASCMO and ORION. Both products on their own accelerate the often tedious automotive calibration procedures by automating the process and reducing the number of necessary data points to be acquired. In combination, the two products shorten the process even more.
Test cell time is expensive, and running a large number of Design of Experiment (DoE) points takes a long time. Integrating A&D’s ORION with ETAS’ ASCMO DoE tool provides a way to minimize both time and cost by indicating when the model quality is high enough to yield accurate results. Monitoring the model quality throughout the data collection enables users to stop the entire process early, eliminating superfluous measurements.

ETAS ASCMO is a model-based calibration software that automatically generates DoE test plans and enables the development of very accurate data-based models. Once created, these models can be used to optimize parameters of real systems such as the control parameters of engine ECUs and also as plant models in different simulation environments (e.g. Simulink® or HiL-Systems). Both steady state and dynamic/transient behaviors can be captured.

The ORION automated calibration tool facilitates the calibration process by taking control of both the ECU calibration system and the test cell control system to run experiments as part of an automated process. Using a user-friendly GUI and a Design of Experiment (DoE) as input, the user defines a sequence of actions for completing the calibration task. ORION then commands the test cell control system and the calibration system to run the sequence as defined. Data is collected as directed to characterize the engine, and then output after the test to the next step in the model-based calibration process.

“Integrating ETAS ASCMO with ORION is a logical next step in engine base calibration”, says Tobias Gutjahr, Program Manager at ETAS Inc. “Knowing exactly that the desired model quality has been achieved takes the guesswork out of the DoE test planning and measurement campaign.”


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 www.etas.com



About A& D Technology

A&D Technology provides advanced test and simulation solutions for alternative energy, hybrid and conventional powertrain testing, and vehicle development. Our open, flexible and cost-effective tools are designed to fit a wide variety of applications, from durability and performance to hybrid/electric vehicle and battery test systems, and hardware-in-the-loop (HiL) simulation.

For more information, visit www.aanddtech.com



###

Originally released on 10-29-2015; Press Contact: Claudia Hartwell

Friday, October 16, 2015

Come see ETAS at Automotive Testing Expo 2015!

The 2015 Automotive Testing Expo North America will take place October 20 - 22 at the Suburban Collection Showplace in Novi, Michigan. In its thirteenth year, Automotive Testing Expo is the event to see the very latest technologies and services that are designed to ensure that the highest standards are met in terms of product quality, reliability, durability and safety. 

Visit us at booth 11003, where we focus on several PC-based technologies, including Hardware-in-the-Loop directly on your desktop, model-based calibration and data-based modeling, and interactive ECU documentation ... all designed to help you increase efficiency and quality of your embedded systems.

Come see our displays:


DESK-LABCAR - Reinvent Software Testing



DESK-LABCAR is a professional, compact Hardware-in-the-Loop (HiL) system that brings the test environment closer to the software developer. Based on mature ETAS LABCAR technology, DESK-LABCAR is a cost effective system for many use cases in which a full HiL system is just not required. 


ETAS ASCMO - Accurate Prediction of Complex System Behaviors 




ETAS ASCMO is an easy-to-use solution for significantly faster advanced model-based calibration and data-based modeling. It lets you create very accurate data-based models which can be used to optimize parameters of real systems such as engine ECUs and also as plant models in simulation environments.
More ... 


ETAS EHANDBOOK - Interactive ECU Documentation for Efficient Calibration 

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.
More ... 


Exhibit Hours


Tuesday: 9 am - 5 pm

Wednesday: 9 am - 5 pm

Thursday: 9 am - 3 pm

-> Free Visitor Pass

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 www.etas.com


###

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 www.etas.com


###

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.