Enabling Real-Time System-Level Simulation with Reduced Order Models

Embedded constraints

Automotive and industrial industries are spending millions developing high-fidelity plant models, only to realize those models are completely un-deployable on the 300MHz, 1MB RAM microcontrollers that actually control the hardware.

Unlike a CPU operating in the Gigahertz region, which can be paired with Gigabytes of RAM, a typical automotive microcontroller will operate at 300MHz or less, and have access to 1MB or less of RAM. Additionally, the integrated Flash memory, used to store the application, is also typically below 2MB. This poses significant challenges in running complex software applications, particularly in time critical scenarios.

The majority of the industry uses a RTOS (real-time operating system) setup, where most functions are called on a periodic basis, for example, every 10ms. While the RTOS does its best to keep the scheduler on time, it is critical that the individual functions are executed much faster than their period. To maintain safety margins and future-proof the design, industries typically mandate a maximum 80% CPU and memory utilization.

When the application requires very high frequency triggers, such as motor controllers, the embedded systems are typically paired with HW-level solutions which can be used to overcome the resource limitations, as is the case of DSPs. While such embedded systems can be used to actuate extremely fast physical systems (e.g. switching of a GaN DCDC converter in the MHz region), it is impossible to run complex mathematical and physical models in software. Such models cannot even run in real-time in our much more powerful laptop CPUs most of the times.

Virtual Sensor use case

These detailed models can be extremely accurate, demonstrating the very fast and transient behaviors of the system. Given certain input stimuli such as frequency or duty cycle, the model outputs internal measurements such as currents and voltages. Effectively, this provides a model capable of accurately predicting physical states that would traditionally require dedicated hardware sensors, such as voltage dividers and current shunts.

If one implements these accurate and complex models inside the real-time embedded system which is interacting with the physical environment, it is possible to completely remove some of these hardware sensors, or at least simplify them. This could directly impact eBOM costs, supply chain overhead, assembly time and validation efforts. It also increases system reliability by removing physical points of failure, such as current shunt solder joints.

This is where Simthetic's ROM truly shines. At the cost of slightly lower model accuracy, we can reduce the complexity of the detailed model and boost the performance by up to a factor of 100. This opens the door to the implementation of such models inside tiny MCUs, which could now act as virtual sensor modules.

Depending on the safety-critical level of the environment, it may not be possible to fully remove sensor hardware. But even in such cases, redundancy is many times required to achieve FIT rates or safety integrity levels. This redundancy could be achieved via virtual sensors rather than additional hardware ones. Such heterogeneous redundant solutions are fully compatible with industry standards such as ISO 26262, and Simthetic can provide support and documentation to ensure that your ROM is compliant.

System-level integration and deployment

At Simthetic, we have demonstrated the Virtual Sensor use case by utilizing a detailed 10kHz Buck DCDC converter, using Matlab Simulink and Simscape toolbox.

After setting up the complex model, we generated the corresponding ROM. This step can be fully automated, given specific optimization goals such as accuracy, model size, and deployment platform. Our target system is a NXP K66F Freedom development board, with the following specifications:

• MK66FN2M0VMD18 MCU
• 180 MHz
• 2 MB Flash
• 256 KB SRAM

It is then critical to evaluate the ROM versus the original detailed model, in a back-to-back validation. Our workflow includes the C-Code generation of the ROM, which is then imported back into Matlab Simulink so that it can be run in parallel with the original detailed model as an S-Function. Again, this process is completely automated, as part of Simthetic's workflow is the generation of S-Functions or FMUs, depending on your target simulation environment.

Below are some of the obtained validation metrics for the ROM, using the detailed plant model as ground truth. Each row represents a function outputs, i.e., a signal which the ROM is predicting. These results reveal that the ROM is more than adequately accurate.

Finally, we deploy it to our embedded system. We setup a simple webserver, which is used to interact with the MCU. Within the MCU, we are executing the ROM application as well as feeding the python webserver with data. The overall footprint of the application is tiny, as reported by MCUXpresso – NXP's development IDE:

Our webserver has the capability of also validating the ROM, by executing test vectors that have been pre-validated against the detailed model. This allows us to further debug issues during deployment, such as task timing, data type numerical computation issues, and more.

The ROM easily meets its 1ms real-time deadline, requiring only 0.373ms to execute. At 37% CPU load, this comfortably satisfies the strict 80% CPU load limits required in safety-critical RTOS environments, leaving ample headroom for base software and control logic. In such a resource-starved environment, having a highly accurate plant model of such a complex physical system running in the edge embedded system opens up a world of applications.

Simthetic gives you the accuracy of a Simscape model, the execution footprint of a standard C-function, and the workflow automation to deploy to an MCU in minutes, not months. Reach out to us to see a live demonstration of how Simthetic can accelerate your simulation pipelines today.