“Hello World” – the first thing I ever programmed on a PC back in 1983 at a summertime coding camp at Indiana University Northwest. Today, I’m employed by ETAS, Inc. and I have been working with embedded electronics in several automotive domains for almost 18 years. I’m starting this blog so that I can interact with ETAS Test and Validation customers and with other visitors to our website. From time to time, my colleagues and I will post articles or other short experiential stories that I hope you will find informative.
ETAS Test and Validation Group
Our group is mainly responsible for Hardware-in the-Loop (HiL) products, under the trademark LABCAR. The LABCAR platform is very extensible and provides ETAS with a base for integrating hardware and software systems that cross many boundaries and it even works well with products from third party vendors. Facilitating that integration is a core strength of our group and of the tools we provide. Whether customers need to configure a test bench for communication bus testing in a compact, desktop solution, or in a large, multi-rack, vehicle network that includes powertrain, body, chassis, infotainment and other systems, we have reliable solutions that deliver results.
ETAS Real-Time PC
In a testing environment, especially in one that is largely based on models of the hardware and the environment, sensitivity, speed and accuracy are critical. One thing is for certain, users don’t have copious amount of time to tinker with “projects” that have minimal transferable value towards the end product. Furthermore, the complexity of some technologies warrant system management across many domains with stimulus to a device under test that may be supported by real or virtual sources. For a LABCAR, the time critical tasks of embedded electronics depend on a key component to facilitate the overall integration and execution. That component is called the Real-Time PC (RTPC).
It has been written that the “ETAS RTPC transforms your standard PC into a high performance simulation target.” The ETAS RTPC allows for multi-core and multi-processor solutions that are the central device(s) between a user’s PC and I/O hardware. In the RTPC, data from the I/O gets to its target deterministically and securely via a highly optimized point-to-point connection. The ETAS RTPC is also compatible with many third party solutions.
Depending on the type of workflow the user chooses, be it drive cycle calibration, regression analysis or for diagnostic testing, the type of stimulus required can range from simple triggers to complex calculations. The applications might include body and chassis dynamics, or fractional, crank-angle-based combustion physics. The ETAS RTPC has the flexibility and the range to meet the challenge of many embedded electronics tests.
In this first post, I will share a workflow from Gamma Technologies, LLC (www.gtisoft.com). Starting with this post, I will introduce GT’s solutions and give readers an overview of how it is set up on the LABCAR. In subsequent postings, I hope to share examples on the negative effects of a poorly-configured system, focusing on simulation execution across cores, process priority conflicts and multitasking.
Let’s get on with it.
GT-SUITE is the #1 vehicle and powertrain simulation software and is recognized worldwide as the industry standard. It has a fast solver for 1D and 3D simulations in one tool, making the simulations of large systems practical. For engine combustion calculations, users create models in GT-POWER. These models include details about the valves, cylinders, combustion behavior (predictive or data-driven functions) and solve the Navier-Stokes equations for airflow prediction. These fast-running, comprehensive models allow for a broad range of intelligent complexity reductions that can be used to vary the gas dynamics (emptying and filling calculations) and thus allow models that run natively at 100 times Real-Time (xRT) to run at 0.4 xRT while maintaining crank-resolved combustion. The advantage of using these models for real-time simulation aligns with three main characteristics:
- Dynamic: the reduction is not based on a training set, so the model has more open boundaries
- Fully Physical: calculations in real-time are still based on physical equations and not merely lookup tables and maps
- Fast: depending on the complexity of the user’s design, simulations can run reliably 2-3 times faster than Real-Time, which provide enormous margin for trading-off reduction options.
At Gamma Technologies this reduced model is called a Fast Running Model (FRM). When users decide to compile the model for Real-Time testing using GT-SUITE-RT, the computational acceleration of the FRM is practically automatic.
In Figure 1, you’ll see three model variants. On the far left, the reader can see a detailed model with many airpath segments that describe the critical components. Often times, those components might be supported by accurate design characteristics (dimensionally and possibly using CFD criterion). Further to the right, the model creator goes through an iterative, stepped approach to reach an optimal reduction / speed-up trade-off. This intelligent lumping of elements is checked against the results of the detailed model. As shown in the most reduced illustration to the right, there are still many details that a controls engineer would have access to during Real-Time testing. Lastly, this intelligent lumping of elements is checked against the results of the detailed model so the user knows the accuracy they can achieve before proceeding.
Once a final FRM form has been decided, then there are only a few remaining steps before users can begin simulations on an RTPC.
GT-SUITE Model Integration on the ETAS RTPC
Once the detailed model’s complexity has been reduced through FRM iterations, then users should execute the following workflow:
The workflow in Figure 2 is an example of the GT-POWER package. However, GT-SUITE has packages that cover many applications areas of vehicle systems. Each package integration follows a similar approach to the GT-POWER integration. Each of those systems can be separately prepared and arranged within the RTPC over several CPU cores.
Figure 3 illustrates a potential way to distribute models across the RTPC. This figure can be interpreted as all of the models running within separate processes on a single core of the ETAS RTPC, or on exclusive cores within the RTPC. In the following figures, the reader can see the difference in core usage depending on how three of the models are distributed within an RTPC.
In both Figure 4 and Figure 5, there are three GT-SUITE models/processes: FRM Engine, Vehicle and Controller/Operator. In Figure 4, all three processes are executed within a single core (Core 1) and these use roughly 60.8% of the core’s resources. In Figure 5, all three processes are distributed across cores.
- Core 1: Controller/Operator
- Core 2: FRM Engine
- Core 3: Vehicle
In both Figure 4 and Figure 5, the results show that there is considerable margin to add more complexity back into models. Those trade-offs will be explored in future posts. Thank you for taking a few minutes to read this post and if you have any questions, please comment below or contact your ETAS account manager. I look forward to hearing your thoughts.