Test Engineering Nuggets

Enhancing Automated Test Systems with Simulation: Unlocking Continuous Development and Flexibility

Wed, 11 Sep 2024 12:57:18 GMT

Strengthen Your Automated Test System with Simulation

In electronics manufacturing, the testing process can often be delayed due to hardware availability and/or other logistical issues. These delays can hinder progress, but adding simulation capabilities to your automated hardware test system can help keep development moving forward efficiently.

Early Error Detection

Simulation allows for the identification and correction of design flaws early in the development process, before any physical prototypes are built. This can prevent costly revisions later and helps ensure that the hardware will function correctly under various conditions.

Cost Reduction

Building multiple physical prototypes to test different scenarios can be expensive. Simulation offers an alternative by enabling comprehensive virtual testing without the need for additional hardware. This reduces costs and allows for more extensive testing and validation.

Testing Under Varied Conditions

Simulations can replicate extreme conditions and stress tests that might be difficult or risky to conduct with physical hardware. This allows for thorough testing of the hardware's performance under a range of environmental and operational scenarios.

Enhanced Flexibility

Simulated environments make it easy to adjust configurations or test parameters quickly, which is often time-consuming when working with physical hardware. This flexibility ensures that more testing scenarios can be covered, improving the robustness of the final product.

Efficient Debugging

Simulation tools provide detailed data that can aid in diagnosing issues during development. This makes it easier to debug and optimize both hardware and software, reducing the time and resources needed for troubleshooting.

Continuity of Development

When physical hardware is not yet available due to long lead times or supply chain issues, simulation allows for continuous development. This ensures that projects stay on schedule and that teams can proceed with testing and refinement without delay.

Parallel Development

Simulation enables parallel development processes, where different teams can work on software and hardware simultaneously. This synchronization reduces the overall development time and ensures that the final product is thoroughly tested and ready for deployment.

Using LabVIEW to Simulate Your Test System

LabVIEW provides powerful capabilities for integrating simulation into automated test systems through the use of simulation classes. These classes allow developers to model hardware behavior, enabling software development and testing to proceed without needing the actual hardware. By using simulation classes, developers can create virtual instruments that mimic the interfaces and behaviors of real-world devices.

Continuing on from our recent blog post Why Every Great Automated Test System Starts with a HAL , we can extend the HAL capabilities to include a simulation class. Below is an example of such extension using a new "PSU SIM" LabVIEW class.

LabVIEW HAL Diagram with Simulation Classes

With simulation classes, you can define different operational states, inputs, and outputs for your virtual instruments, making it possible to simulate a wide range of scenarios and conditions. This is particularly useful in environments where hardware availability is a bottleneck or when testing needs to cover extreme or rare conditions that would be difficult to replicate with physical hardware.

The LabVIEW class hierarchy of simulation classes could look as follows: Each generic concrete device could extend to a more specific simulation device class. This flexibility allows you to test your entire system with or without hardware, as shown below.

Implementing PSU Simulation Class

Conclusion

Incorporating simulation capabilities into your automated hardware test system can significantly enhance the efficiency and effectiveness of the development process. It allows for continuous progress, reduces costs, and improves the overall quality and reliability of the final product.

Embracing Open Source: Industry Leaders Paving the Way in AI Transparency

Wed, 31 Jul 2024 17:35:07 GMT

Accessible AI in Smart Manufacturing

In our fast-evolving world of smart manufacturing, the push towards transparency in AI is more than just a trend—it's a game-changer. As technology juggernauts embrace open-source models, the landscape of Industry 4.0 is being transformed, offering new opportunities for innovation, collaboration, and efficiency. This shift towards openness is not only democratizing access to cutting-edge technology but also fostering an environment where continuous improvement and adaptability thrive. In this blog post, we'll explore how the embrace of transparency in AI is revolutionizing smart manufacturing, driving new levels of precision, and creating pathways for industries to thrive in the digital age.

Benefits for Industry 4.0 and Smart Manufacturing

The shift towards open source is not merely a trend but a strategic move with profound implications for Industry 4.0 and smart manufacturing:

Our Commitment

At Aurum Automation , we recognize the transformative nature of open-source technology in driving the future of industrial automation and electronics testing in manufacturing. As industry leaders embrace open-source principles, we are committed to harnessing these innovations to deliver solutions that empower our clients to thrive in the era of Industry 4.0 and Smart Manufacturing.

Stay tuned for more exciting news to come!

Why Every Great Automated Test System Starts with a HAL

Mon, 17 Jun 2024 16:10:50 GMT

Decoupling Your Hardware Vendors in Software

Ah, the good old days of working at a top-tech company. I was tasked with retrofitting an End-Of-Line test system with a proprietary piece of in-house equipment. Part of the program involved replacing outdated equipment with a more complex device while maintaining backward compatibility with existing production lines in the field.

This was somewhat of a painstaking task when it was discovered that the existing software architecture had device calls sprinkled across various parts of the code—from the instrument level to the test sequence and the reporting mechanism. Data types for devices were even embedded into the UI!

The simplest solution would have been to place conditions around the existing code to determine which device to use. However, this approach would have become a maintenance nightmare, making the system difficult to understand and use. It simply wouldn’t scale and would create excessive technical debt for sustaining engineers. No bueno.

Also recall the supply chain crisis during the global pandemic, when test equipment had up to 52-week lead times! Technology leaders had to pivot quickly, substituting hardware for secondary and tertiary sources, leading to software development changes and a whole host of other propagation delays.

These are just some scenarios where a Hardware Abstraction Layer (HAL) becomes incredibly useful. A HAL decouples the instrument drivers from the rest of your test system while providing a common API with equivalent functionality between test instruments. Great HALs can be written with a deep understanding of each test instrument, with functionality often abstracted for the most critical components. This understanding aids in making the best class hierarchy decisions in an architecture.

Today, we are going to demonstrate a simple HAL using a common test setup—a programmable power supply, digital multimeter, and switch card—implemented with none other than National Instruments LabVIEW.

Consider a simple Programmable Power Supply (PSU) instrument. A UML class diagram for a PSU class with some standard functionality might look like so:

Using LabVIEW, we can create the classes of the base PSU class, override them in Keithley_PSU and NI_PSU, while implementing driver-specific logic in those child classes. Now you can call your common PSU API at your sequence level, without it having any knowledge of the vendor-specific device!

Here's an example of how your block diagram may look like for setting 24V DC, 1A current limit and enabling its output:

Similarly, with a Digital Multimeter (DMM) and Switch card, your class design may look comparable to that of the PSU. Your UML class diagram could look something like this:

Now suppose you had a more complex device, such as a multifunction data acquisition module that was comprised of a DMM and a Switch module. How could you re-use the Switch and DMM device, combining them to create a DAQ device with LabVIEW?

Enter Interfaces.

National Instruments introduced Interfaces to LabVIEW in 2020 , allowing for multiple class inheritance. This means that DMM and Switch devices could be made into interfaces, with corresponding classes using each interface. Finally a DAQ device could implement both DMM and Switch interfaces. A UML diagram might look like the following:

This becomes incredibly handy if your device has multi-functions, such as connecting MUX, Matrix or Relays, taking a measurement and disconnecting. Using LabVIEW, here's how your block diagram may look:

In the example above, your DMM functions could come from both a DMM and DAQ device, while your Switch functions could come from either DAQ or Switch. Vendor-specific implementations would go in their corresponding classes. LabVIEW interface VIs must all be overriden by classes that implement them, and interfaces can also inherit from other interfaces.

Just as importantly, here's how to create LabVIEW classes and interfaces

Advantages

Test Team Familiarity - Having generic device calls throughout your Test Sequences makes for simpler readability and standardization across your manufacturing test team. Your team does not require an understanding on all device specifics, but rather an understanding of the API functionality that abstracts away vendor implementation.

Updating a test sequence for a new instrument or obsolete instrument - This task mainly consists of creating a new device class, implementing its vendor-specific functionality, and then adding it to your instrument selection list. No other piece of code should be touched, unless your HAL API needs to include a specific function of the new device that's not already covered. In that scenario, only configuration or database information would require updating.

Clean Code - Just as importantly, not having various conditions and corner cases scattered throughout your application to handle custom logic. Keeping technical debt at an absolute minimum will help make for a happier team, especially your sustaining engineers .

Summary

A HAL can provide a powerful, scalable software solution that will mitigate technical debt down the road. While there may be additional up-front architecture design and development time, this level of abstraction can pay significant dividends if properly designed. Consider scope changes, device obsolescence and spare part availability when designing your test system.

[Updated July 14, 2024] Code sample can be found in our company open-source repository here