- Posted on: 2022-10-14
Testing and Validating of Embedded Systems are Difficult
An embedded system is a controller with a dedicated function within a larger mechanical or electrical system, often with real-time computing constraints. It is embedded as part of a complete device often including hardware and mechanical parts. Embedded systems control many devices in common use today.
Ref: Wikipedia
From the two diagrams above you can immediately see why Parallel Processing is faster than Sequential Processing. In addition, with sequential processing an error anywhere in the code will affect everything after it and make the ATS less robust. Testing and Validating without parallel processing is at best error-prone, at worst impossible.
Why? Because to do any testing or validation you must communicate with the device under test (DUT), any other embedded devices, and any actual and/or virtual instruments (VIs). These communications aren’t instantaneous – devices take time to react and respond. If that time is say 0.5 seconds on a power supply command within the manufacturer’s supplied drivers, should your Automatic Test System (ATS) stop all activity and wait 500 milliseconds or should it work on other threads such as updating the user interface (UI) or running a model and updating CAN messages every 10ms to keep the DUT’s control algorithm stable?
A Controller Area Network (CAN bus) is a robust vehicle bus standard designed to allow microcontrollers and devices to communicate with each other in applications without a host.
Ref: Wikipedia
You get the point – waiting for responses can ‘eat’ most of the time so multi-threaded ATS code performing asynchronously tends to perform far better than “sequential” code when waiting for responses. We’ve seen this frustrating situation many times where the CPU is idle (1 or 2%) but the ATS is unresponsive and it’s not especially easy to find the root cause of the delays because manual debugging adds more delays and hides the real source.
Parallel ATS code is:
- Faster and more responsive – for example to service the UI 4 times/sec, the log file 10 times/sec, the power supply once/sec
- More reliable for testing at higher rates – support faster model simulation rates and responsiveness to DUT
- More flexible – This is partly a by-product of the architecture, but a robust communication mechanism must exist between the code module which offers many options for logging, visualization and automation
- More scalable – Developing and troubleshooting code is faster since each driver/code modules tend to be properly encapsulated and decoupled from other code
- Better troubleshooting – As each code module runs separately, the “call chain” provides better location of sources and errors and debugging doesn’t affect other code modules running at “full-speed”.
- Supports better UIs – Usually offer more responsive interface to the user and access to any variable exposed by a code module, both for control and display
How do you ensure your ATS is operating in an optimal multi-threaded manner?
You may be using National Instrument’s (NI) LabVIEW which has parallel processing capabilities (see http://www.ni.com/product-documentation/14/en/) but how do you know if your ATS takes advantage of them? Supplied drivers from instrument vendors and manufacturers DUT drivers often have wait states. You need to integrate those within your architecture supporting multi-threading to perform many tasks in parallel. However, as the complexity of your testing and validation increases, test engineers too often develop LabVIEW graphics/code that’s hard to follow and harder to maintain and debug.
A state machine is a programming architecture that can be used to implement any algorithm that can be explicitly described by a state diagram or flowchart. … A state machine consists of a set of states and a case selector that determines which state the program transitions to next.
Ref: NI.com
For simplicity, it is also wise to develop an ATS application on top of LabVIEW that is based on an architecture designed to execute multiple VI’s with parallel processing, ensuring LabVIEW is used in a multi-threaded manner (for example by that application using the Actor Framework distributed with LabVIEW, the Delacor Queued Message Handler (DQMH) or Synovus’ preferred “state-machine VIs”). You can ensure you never end up spending days debugging false negatives because ATS and DUT models are out of synchronization or dynamic functions don’t meet required timings. BTW if you do have that problem talk to us, or another NI partner, or use SAPHIR “VI Box Probes” (specifically “Chronograph”) to quickly monitor execution time and isolate the culprits in your code (http://sine.ni.com/nips/cds/view/p/lang/en/nid/209756).
Conclusion
By properly designing your application as a parallel processing ATS, your te <sting and validation of embedded devices will readily avoid these all too frequent problems.
Symplify™
Symplify™ is our embedded system ATS that works on top of NI’s LabVIEW – it ensures parallel processing for the reasons outlined above and adds numerous capabilities:
- Error handling and system log as the most basic debugging tool
- Graphing that can display any of thousands of variables for multiple days
- Synchronizing information and control of multiple drivers/UI/models
- Test automation capabilities (script, table playback, etc.)
- Proven supervisor with hardware watchdog compatibility
- And more…
Symplify™ is architected around distributed state machine VIs to run all drivers and models in parallel, along with communication with DUTs, UIs, error handling and the code that monitors its own performance. Symplify™ uses a simple but highly optimized LabVIEW Current Value Table (CVT) as the simplest, yet highly flexible and scalable, communication method.
Learn more about Symplify™ or request a demo.