Race for Success
Embedded solutions currently require both complex hardware and feature-rich software. A classic waterfall approach of product development supposes that hardware design and development precede software development and testing. The harsh truth is that hardware is almost never available, and software development must be started early. The time-to-market factor has recently become very important: releasing products before competitors saves money and gives brands a competitive edge in building a solid presence in new markets. Therefore, this tremendous pressure from sales and marketing teams forces engineering teams to challenge their creativity by building hardware and software in parallel.
Even if hardware already exists, you still might need to work on software without having the ability to interact directly with the hardware, as it is too bulky or fragile, expensive, or classified to ship. It therefore must be assembled as a single copy or be available only in remote locations
One common way in which to develop and test at least some of the software is using pure software simulation techniques such as Software-in-the-Loop (SIL). However, this is not always the best option since embedded systems usually have many advanced peripherals onboard, such as high-speed sensors, liquid-crystal displays, analog components such as DC drives, potentiometers, and transistors. Pure software simulation is not very effective in this case because it does not support proper simulation of all this infrastructure. Thus, SIL may allow the development of the basic logic of a software solution that is abstract enough from the hardware. However, you will still need to implement the hardware integration layer using the real hardware.
The most effective approach is Hardware-in-the-Loop simulation (HIL), a methodology that allows engineers to develop and test the code without having access to the hardware and with minimal adjustments in the production phase. HIL simulation is far more effective than the software simulation approach.
The HIL approach is not something entirely new—anybody with an interest in the topic will satisfy their information hunger in a heartbeat. However, for product owners and project managers handling product development that requires an (HIL) approach, most articles’ content and quality will reveal a sour discovery. HIL-related papers are often too scientific and vague for people who are looking to implement the approach in a real-world environment. To solve this issue, I wanted to share my view on how HIL can be used effectively without costing you an arm and a leg.
HIL in a Nutshell
Generally, HIL is the method of running embedded software deployed onto a testbed that mimics real hardware. The main idea is to simulate the environment around the embedded software, which will make the software work as if it is being executed on actual production hardware.
Practically, a straightforward HIL setup consists of at least two independent hardware parts connected to each other over a bunch of cables. One part is used to execute the embedded software targeted to the production hardware and is referred to as the Device Under Test (DUT). Other hardware parts simulate the external environment for the DUT. In other words, they mimic the behavior of the real external devices, including their feedback and, in some cases, even their physical models. This simulation is executed by managing the electrical output based on input signals from the DUT in both digital and analog forms.
Several types of HIL solutions
The HIL solution may vary depending on the product’s complexity. It can be very simple, with just two microcontroller (MCU)-based prototyping boards connected by wires on a breadboard for a simple product, as shown in Figure 1. In contrast, it can be a complex and expensive set of high-performance hardware blocks that are able simulate physical models with precise resolution and accuracy to be used for applications such as life-critical or mission-critical equipment like medical devices or avionics solutions.
Even a simple «handmade» HIL setup will allow you to run dozens of scenarios and automation. However, engineering teams might be pushed to use high-performing industrial-grade HIL solutions, which are widely available on the market today. I have faced the choice between a more powerful but costly solution and a more affordable one or even building one from scratch in projects I have taken part in. Let’s consider the pros and cons of each option and see what would work better in each case.
A simple/handmade HIL setup
A custom self-made HIL setup would make sense for quick and dirty prototyping of products that do not have high speed or complex peripherals. The main benefit of this approach is that it will enable a simulated environment at a minimal cost in no time at all. If you don’t need to make significant investments, it is worth trying!
In fact, we used this approach for one of our recent projects. We were working on a simple MCU-based product with a limited set of low-speed peripherals, which included buttons, potentiometers, and a DC motor. Using a full-blown HIL solution would be unnecessary in this case and would require more effort in terms of setup. Thus, we decided to take two of the widely available Nucleo with STM32 MCU development boards and used them for both parts: one board as the DUT and the other as the simulation engine. We wired the target board directly to the simulator board using cables. You can see the result in Figure 2. Pretty messy, huh?
Despite the messy look, in many cases, even a minimal HIL setup may lend a hand in running numerous regression, sanity, feature, and other tests and help spot runtime issues. This HIL setup can even be integrated into Continuous Integration (CI), allowing fully automated tests of embedded software in the simulated environment.
Truth to be told, such wiring is acceptable only for a setup with low-frequency and purely digital signals. If the test bench used the same wiring approach but with high-frequency signals, such as Serial Peripheral Interface (SPI) lanes, along with analog lanes, could cause serious interference between lanes and result in software issues, which would be very difficult to trace and fix.
Thus, if your setup is much more complex and requires more cables and even some additional hardware, such as more Digital-to-Analog Converters (DACs)/ Automatic Call Distributors (ACDs), or Field Programmable Gate Arrays (FPGAs), then this type of configuration might cause problems, even when it is simply maintained. In this case, we suggest that you use specialized interconnection boards or even an industrial-grade solution for your HIL setup
Ready-to-use HIL solutions
Naturally, there is no silver bullet—most industrial-grade solutions require time to adjust the simulation logic and code according to the project’s specifics and develop tests that suit your needs. In my opinion, there are three main categories of HIL solutions that are currently on the market:
I – National Instruments PXI and its infrastructure. This is one of the world-leading HIL solutions and is sufficient for most cases. It has a lot of additional modules and can be easily configured for your needs.
II – Vector VT-Suite and its infrastructure. Initially developed for automotive hardware usage, this solution can be applied to any other products, from medical devices to avionics systems. It has a set of modules for various applications and can also be configured for your needs
III – Other vendors’ solutions. There are many low- to mid-sized HIL solutions available on the market. They usually have limited capabilities, but they can be easily customized, assembled, and maintained on the deck by a single developer.
Our team has used the mini-HIL platform by Protos on several projects for hardware manufacturers. In our experience, it perfectly fits the development of non-complex MCU-based solutions, meaning that it can simulate triggers, potentiometers, external SPI sensors and even Brushless DC Electric (BLDC) motors, but will be nearly useless in the simulation of Peripheral Component Interconnect (PCI) Express devices or the high-speed simulation of the inductive load. The most appealing benefit of solutions like mini-HIL are their significantly lower prices than those from categories I and II.
Apparently, HIL solutions that are marketed as «ready to use» cannot mean simply be plugged in and used without modifications. These HIL products are merely platforms and infrastructure for you to use to build a custom HIL setup.
Yes, let’s face it-every HIL setup is a custom one, and an HIL should be built individually for each product. For your HIL solution, you will have to create all simulated environments from scratch. However, if you’re using one of the abovementioned HIL solutions, they likely already provide built-in helpers and pre-existing parts that you can to apply to the simulation.
All in all, if you are dealing with a complex product that requires simulation of the physical processes, advanced logic, and so on, it is worth considering the purchase of a ready-to-use HIL solutions. This way you will get a faster and more reliable result; however, you must be ready to spend a significant amount of time developing a simulation that could require complicated tools, such as Simulink.
Real-life Project HIL Case
To provide a better understanding of the necessary steps and actions to be performed on software development projects with the HIL simulation approach, I will share one of our project experiences
Problem statement. Our customer, the leader in construction tool manufacturing, was developing a new MCU-based product. We caught up with them at the initial phase of the project, during which the customer had an idea and developed the requirements but had not created the actual hardware product, even as a prototype. Even if they had already developed it, there would have been a very limited number of samples, so shipping them to all research and development (R&D) locations would have taken a significant amount of time. However, since the time-to-market factor was crucial, our customer needed the software for this solution available as soon as possible. Ideally, they wanted it to be available when the actual tool was released.
The solution proposed by the team. Auriga’s team was tasked with finding a way to develop software for this product without having access to the hardware. All we had at the time was the target MCU on a Nucleo prototyping board, so the HIL simulation approach was considered the most suitable approach for this project. The product had several external sensors and buttons, as well as a DC motor, and we had to implement the simulation for all of these parts. Low-speed sensors, switches, and potentiometers are usually easy to support; however, proper simulation of the DC motor is tricky, especially in cases where the software should not only turn the motor on and off also give proper feedback, such as current consumption curve, back electromagnetic force, and the inertness of gaining or reducing the Revolutions Per Minute (RPM). Thus, the HIL system used for this product had to support all of these features while being appropriate and optimal in terms of the cost of the feature set. We evaluated the existing HIL solutions against these requirements and identified the best-matching one, which we then used for the project. Our solution consists of four components:
- Baseboard or Testbed: an interconnection board with all other hardware HIL solution components plugged in. We used it to connect all parts and minimize messy air-wiring.
- Core HIL engine: a hardware module that performed simulation. In our case, it was just another Nucleo board with an ST MCU onboard.
- Additional FPGA hardware module to implement advanced simulation. Sometimes, the core HIL engine does not possess enough resources or high enough resolution to simulate specific peripherals, and the additional FPGA module has the flexibility to support such cases. For example, the simulation of RF parts or complex physical models may be implemented on FPGAs.
- HIL simulation software infrastructure, including the integrated development environment (IDE), libraries, and tools used to implement and run simulation logic on the HIL core. Usually, these are proprietary sets of tools and technologies that may require additional examination before implementing the simulation logic.
Building the custom HIL setup for the customer. Team started by simulating relatively easy parts of the external peripherals, such as buttons and sensors. This is a quick and straightforward phase that usually does not consume much effort but allows engineers to start software development in parallel.
Next, we had to consider our approach to the simulation of more complex peripherals, such as a BLDC motor driven by a pulse-width modulation (PWM) signal and external components connected by SPI and universal asynchronous receiver-transmitter (UART) buses. Simulating these parts is similar to test-driven development in that you can start with basic and simplified simulations. Still, it eventually has to be improved to reach a level of precision, which allows software on a DUT to «think» that it works with real hardware. Sometimes this may be tricky because it is not a regular software development task where you have requirements and all you need to do is make sure that you implement them correctly. Instead, this is a research task that requires expertise in both software development and electrical engineering. In other words, you have to clearly understand how the actual hardware works, including the electrical part of the product, to simulate it properly. In some cases, even this is not enough: for one of our projects, we received assistance a professor from a top-ranked university for the simulation of a complex model. For example, we spent weeks working on the proper simulation of the BLDC motor’s physical model until we attained a workable solution.
Thus, we were able to proceed with embedded software development using this assembled HIL setup. Eventually, when the production hardware became available, we had to make final adjustments to calibrate the parameters and logic. These changes were fast and easy, taking only a few days. As a result, our customer got a fully functional product just a few days after their hardware was manufactured.
Best Practices of the HIL Approach
Based on this case and several other cases in other projects I have recently worked on, I came up with a list of seven tips I always mention to customers when I begin an HIL-related project.
- Consider evaluating which HIL approach is better for your project: a «homemade» setup or a commercial-grade HIL system. Since both have advantages and disadvantages, it is worth your time to consider them from the get-go.
- Do not overcomplicate the simulation logic. If your solution does not need a precise behavior simulation of physical models, or other complicated simulations, keep it as simple as possible to save development and maintenance efforts.
- Build and maintain your project-specific pinning matrix: it is usually a table with pinning description tracing pins to show the interconnections between boards. It will be beneficial if you need to re-create your HIL setup from scratch or track down the connections.
- Take care of proper cable management early: if you can’t downsize, at least group your cables by colors—one for external SPI, another for UART communications, yet another one for GPIO, and so on.
- Use cable shielding if your solution has high-speed or -frequency connections, such as SPI, and keep your cables as short as possible.
- Consider using FPGAs for time-critical actions (e.g., BLDC motor simulation). This might require additional time for development, but the use of FPGAs could be critical for some setups.
- Safety first! Remember and apply all necessary measures to prevent electrocuting yourself or damaging the hardware. You should consider using galvanic isolation devices when working with HIL setups and/or a DUT that involves the main voltage power supply.
Summary
Overall, the HIL approach is a hard nut to crack, but investing significant time and effort always pays off during embedded software development projects. The job of putting together a self-maintained or -developed HIL solution or deploying an one is what makes my job challenging and customers happy. After all, HIL allows me to deliver projects on time, and that’s all that matters.
