STANDARDISED PRODUCTION TEST SOFTWARE ARCHITECTURE
Overview
In developing production test systems for a variety of clients, it was found that there were many recurring requirements. Rather than re-inventing the wheel for each test system, it was decided to develop a software framework which supported a set of standard requirements, but also gave flexibility for customisation and expansion. Originally developed to fulfil a specific customer need, this framework is now widely used in all similar Simplicity AI projects and by in-house developers at a variety of clients.1) Streamlined, Standardised Development Environment
2) Reusable Modules
3) Minimal Programming (Configuration Based)
4) Hardware Vendor Independence
5) Intuitive Operator Environment
6) Flexible, Customisable Reporting/Database Logging
Core Tools
Rather than develop a completely bespoke solution, it was decided to base the solution on industry standard tools, whilst adding a variety of customisations to deliver better functionality, an enhanced user experience and enabling rapid software development.NI TestStand
The primary purpose of TestStand is to sequence test steps (which can be written in any language) and provide a standard framework for sequence development, execution, display, user management and logging. The vast majority of TestStand’s features are fully customisable, which will be tailored to match specific requirements. 14 of the top 15 largest electronic manufacturers and 9 of the top 10 largest contract manufacturers use TestStand for their testing solutions [1]. Due to its extensive utilisation in production test environments and its array of customisation options, the core of the software architecture presented in this solution is based around TestStand. A number of customisations have been introduced to the product to augment the out-of-the-box functionality.
NI LabVIEW
While TestStand can sequence test steps written in any language, the primary development environment was chosen to be National Instruments’ LabVIEW – owing to its productivity enhancing features, allowing engineers and scientists to develop software quickly without a steep learning curve. Many of the customisations delivered as part of the framework were written using LabVIEW, which gives the end customer examples of how to implement their own customisations
IVI Drivers
For many customers, obsolescence is a major issue. For example, some aerospace clients require test systems to be in use for many decades to support the entire life-cycle for their products. Ensuring that instrumentation can be calibrated and replaced becomes very difficult once a particular instrument reaches its end-of-life. In the past, solutions to this problem often included batch-buys of equipment or re-writing (and re-validating) test applications to use new hardware – both of which waste huge amounts of money. Interchangeable Virtual Instruments (IVI) aim to solve this problem by standardising the software driver layer between instruments of the same class. For example, a test system utilises a Digital Multimeter (DMM) and the software has been written using an IVI DMM Class Driver which provides a standard set of functionality that applies to all instruments that are IVI DMM Class Compliant. The current DMM is later declared obsolete – no spares are available and standard calibration services have ceased. In this architecture, it is then possible to “swap out” the DMM with a new model from the same vendor or one from a completely different vendor without modifying the test software. Therefore, IVI drivers have been used for instrumentation wherever possible in the software architecture.
NI Switch Executive
In most cases, the target test systems incorporated complex switching systems. In order to simplify the process of routing signals from one place to another and to abstract the physical hardware configuration from the test software, National Instruments’ Switch Executive product was selected. This allows for far more readable test applications and allows changes to the physical switching system without having to modify any software.
Customisations
Reuseable Step TypesA set of drop-in reusable “Steps” for TestStand were developed for interfacing with various instruments, along with a standard template for developing steps “in-house”. Once added to the TestStand environment, these steps can then enable test program development to be almost entirely configuration-based. For example, to set a power supply output a developer can drag the Power Supply step into a test sequence then configure the necessary settings through a dialogue box. By repeating this process for all the other steps in the test procedure, a full test program can be constructed very quickly. Various other steps have been created to allow users to perform common tasks much more easily, such as adding information to the header of a report.
Step Type Edit Dialogue (Click to enlarge)
Reporting
While TestStand does include report generation in the “out-of-the-box” product, the supplied formats were not sufficient for many customer requirements. Simplicity AI added native PDF report generation and a unique expandable architecture for adding other custom reporting formats. Logging to a variety of databases is also possible using the architecture (SQL Server, MySQL, Oracle, SQLite, Access, Db4o and others).
Custom Report Header (Click to enlarge) Custom TestStand Report (Click to enlarge)
User Interface
A set of configuration dialogue boxes simplifies the configuration of many aspects of the system. In addition, a feature-rich, intuitive operator interface has been built to include many new features not present in TestStand’s included interface:
1) On-the-fly Pass/Fail indication
2) Yield Counters
3) Display of dynamic test information (such as serial number, test program name and any other custom items that have been added).
4) Execution Summary view of recorded results, also showing test limits
Custom Operator Interface (Click to enlarge)
Training & Support
The software architecture was augmented with a package of customer specific training and support packages. For example, for one particular customer, Simplicity AI developed training packages covering the “need-to-know” features of the core tools and the specific customisations applied to the tools – enabling in-house engineers to get up and running very quickly. One particular training session involved the group interactively developing a test solution for one of their products whilst being led by an instructor.Conclusion
The software architecture provides a standard framework for test software development. It encourages reuse through the use of modular components, many of which were supplied with the framework. Test software applications can be developed by Simplicity AI or in-house engineers in a fraction of the time compared with traditional approaches. The use of a standard framework means that extra features developed for particular requirements can be made available to all customers using the standard framework, whilst still maintaining full compatibility with the core tools.What Next?
Contact Simplicity AI >Learn more about Simplicity AI services >
Watch a video on this solution >