//php echo do_shortcode(‘[responsivevoice_button voice=”US English Male” buttontext=”Listen to Post”]’) ?>
For OEMs to compete in global markets, product quality is of paramount importance. Products must be reliable and function as intended in all countries in which they are to be sold.
To this end, many mid-price, high-volume products for commercial applications — IoT devices are a good example — must meet the quality expectations of products intended for use in safety-critical applications. Granted, they don’t need to satisfy the requirements of, say, DO-254, but my point is this: Thorough verification is important, and detailed documentation is needed for traceability purposes.
But there’s a problem: Most mid-price commercial products are developed by SMEs. They don’t have the resources of an OEM of high-value, low-volume products for safety-critical applications.
Embedded systems engineers developing products for commercial markets work in small teams, and the pressure is ever present to meet time- and volume-to-market goals. Software developed on a PC will be verified using software-in-the-loop (simulations, testbenches, etc.). Then a few prototype PCBs will be made.
These boards will be tested as thoroughly as possible, as it will be the first time that software meets real hardware. There will undoubtedly be some real-world issues like latency to address, and there is likely to be at least one more hardware spin.
Seldom done, however, is the verification of the product’s hardware and software in the environments in which they are to operate. In sectors like aerospace, safety-critical avionic equipment is verified using hardware-in-the-loop (HIL) and connecting the design under test (DUT) to sensors, motors and actuators on an iron bird.
The SMEs of embedded systems for commercial applications just don’t have the luxury of HIL.
For example, consider a device that is designed to interface with a wireless carrier, such as AT&T or Verizon in the United States, as well as other carriers around the world. If the device is built in the U.S., then functional verification on the domestic carriers is easy. Verification against other carriers is not as easy.
Unless the DUT can be tested under all intended operating environments, there’s just no way of knowing if there are any corner cases that will result in errors.
Another real danger is when accommodating last-minute changes. Change-impact analysis cannot be skipped.
For instance, since 2018, Bermondsey Electronics has been supporting a company called Healthmatic. It designs, installs and maintains restrooms for local authorities and transport hubs in the United Kingdom and Ireland. Servicing is scheduled around usage, as opposed to being time-based, as many of the restrooms are in locations at which the number of visitors per day changes depending on the time of year and the weather.
In 2021, we designed a two-part system for monitoring restroom usage. One part is a 3-V battery-powered unit that uses passive infrared to detect the presence of people in the restroom. Data is sent via LoRa to the second part of the system, a Raspberry Pi acting as a gateway.
We designed the firmware for both devices. We also wrote a series of fully automated tests written in JavaScript to run on a PC connected to and driving networked benchtop instrumentation. In this way, we crafted an HIL environment for both DUTs.
Very late in the project, Healthmatic asked us to determine the impact of switching from 3-V primary (non-rechargeable) batteries in the sensor unit to rechargeable ones that would be considered fully charged at 4.2 V and in need of replacement at 3.2 V.
Our series of tests confirmed that the core circuitry could accommodate the higher supply voltage. However, the firmware used to implement the reporting-state-of-charge function was unable to report anything above 3.3 V. This was discovered by a test that reduces a PSU’s output (simulating the battery) in 10-mV decrements and accessing the sensor unit’s micro via debugger to determine what voltage it thinks it is seeing.
Had we not had our automated integration verification engine (which has subsequently been commercialized as BELIeVE), the change-impact analysis — on the entire product and not just the battery-monitoring function — would not have been as easy to perform and document.
So why don’t SMEs do more HIL? The answer is that it can take up to four months and cost about $100,000 in engineering hours to stitch together all of the equipment needed.
