ATE systems have always been "islands of automation." They are highly focused and efficient at gathering data but are difficult to connect with other test and data systems. Managing file organization, backups, and setup configurations can quickly escalate in volume and complexity burdening the user with additional tasks in the development process. Guru strives to change that by making it simple and easy to share data, control the distribution of information, and manage the logistics of production test. Assembling the elements that comprise a production test draws upon a collection of associated resources: handler configuration files, instrument calibration settings, Fixture definitions, etc. Cassini’s use of software objects throughout its system allows for unique organization, management of the test process, and distribution control. Previous documents have introduced the various software and hardware components that make these capabilities possible. This section discusses how these parts come together into a unified workflow to allow a user to coordinate the tasks of production test.
Cassini is a collection of focused parts that function as a single unit, and Guru can be thought of as the nervous system that connects it all together. It’s an application that works in concert and in the background with the system’s software and workflow to provide the user with three powerful tools in one:
- An easy to use interface for controlling the release of software updates and applications.
- A tool for locating and organizing test configuration files, resources, and data.
- An automated repository and backup service that makes test design iteration and setup recovery simple.
Cassini calls upon a number of resources within its expert system to execute a test: handler configurations, test patterns, calibration data, fixture definitions, etc. Guru provides the user with a way to keep all of these resources organized and linked to their respective test plans. When files are created or modified, they are shown chronologically with a revision history that mirrors the test iteration process. Guru also allows the creation of metadata, or tags and values assigned to these files by the user in order to group them. For example, a test plan, handler config, and test pattern can have tags such as “in development” or “released to production” associated with them. This allows the user to locate and load them as a set or to easily control which ones should or should not be seen by operators on the production floor.
Network to Other Gurus
Guru connects to other Gurus using a hierarchy structure to control the flow of information. A requested file is automatically retrieved from the Server on every request. Data, tester configurations, and test code can easily be shuttled from one tester to another through this framework for quick distribution and validation. Files can be searched and selected using keys and values assigned by the user, for example, to send any new data to a special FTP account for processing by a separate database. The setup is highly flexible allowing for any number of networked schemes that can be expanded to suit a customers specific needs.
Cassini testers and Virtual Workstations on multiple sites in order to control “development” releases to “production” and share tester configurations, test code, and data between locations. RI Guru provides cloud based automated support for rapid debugging (send to RI Support) and streamlined updating (retrieve updates).
These advanced features are enhanced by Guru’s integrated networking capabilities providing a secure and dedicated link to pass data between other testers, servers, and third party services. Data flow and permission controls are built in and accessed via Guru Agents. This assistant makes networked data sharing easy, giving a user the confidence to manage large amounts of test information with ease. Distributing a test setup or data between multiple Cassini’s on different continents is now as easy as sharing it between multiple testers in the same room.
Guru helps us support the tester
We maintain a Guru server at Roos Instruments which distributes software updates to our customers. It also gives customers a way of sending back data as “service request” information that helps us diagnose and resolve customer issues which may occur in the field.
Each RI ATE system has a local Guru that backs up every test, configuration, and resource file automatically to a “backup” Guru server. This routine prevents a system controller failure, one of the most disruptive and costly failures that can occur on a test floor, from compromising production schedules. If the controller fails on Cassini, getting a replacement tester back online is as simple as rolling out a new controller, inserting the Guru key, and plugging in the network cable. As soon as the system controller is powered up, the empty Guru will request files from the backup Guru automatically. The “restore” process takes seconds and all of the recovered files are then saved locally, making the new controller a duplicate of the previous controller.
Guru is Reliable
Reliability is a high priority when sharing information between sites, and Guru has multiple built-in safeguards:
- • Guru only talks to Guru. Every file is digitally signed by the Guru which created it. When an object is received the contents and the signature is verified and if the signer is unknown to the receiver, the document is not trusted.
Production test is a large undertaking that involves a team of people using the tester in various purposes:
- • Test plan developers work with the design engineer to translate part specifications and operating limits into a set of measurement on the tester to determine the functionality of parts.
• Test floor managers implement the tester setups and procedures to support these test, supervising the logistics associated with the production environment.
• Operators execute the designed tests quickly, maintaining tester up time and throughput of parts.
The above diagram shows Cassini’s system permission topology, comprised of two main control mechanisms: user roles and groups. Both exploit the tester’s object-oriented software architecture to set application access and manage services:
- • User Roles allow the system to augment the user interface and limit what a user can see in menus
• Groups provide a user-defined mechanism to limit access to system applications, data, and resources
Depending on the rank of the user, the system links a set of corresponding permissions to access applications within the tester. The higher the rank, the more applications the user can access. If a floor operator was going to run a production test for instance, an engineer does not want that operator to be able to directly or inadvertently change a test plan or alter the calibration information of the tester. By assigning that user to an operator role, the system will not only restrict what files and data can be changed, but limit the interface to show only commands that execute a set test plan. If a higher-ranking user wanted to give specific access to certain parts of the tester to a lower-ranking user, they can assign a collection of custom permissions by creating groups and linking those users to a particular group or set of groups. This delegated access control was designed to be highly flexible, and can have overlapping and isolated permissions to support multiple users with custom or complex access needs. For instance, if an engineer user wanted to allow a maintenance user to have access to data within a test plan, or a subset of data within the test plan for calibration purposes, a group with these permissions could be used. Another common scenario would be to use groups to manage separate projects on the tester that involve multiple engineer users. This allows each to access applications and files associated with their project, while hiding and barring access to other engineer’s projects on the test system. This gives each individual a simple, clean, and familiar interface on the tester to manage data and perform their tasks efficiently without the fear of altering another user’s setup or files.
Both Server and Client Guru's share the same internal code, they only behave differently based on their preferences. A Guru Server is designed to scale while a Guru Client is designed to support local running Guru Applications. Some Guru "Admin" Applications (like the Guru Browser) can connect directly to other Guru servers, however most Guru Applications only talk to the "local" Guru.
Typical Development Workflow
Once permissions and system access have been set, it’s time to build a test. Cassini’s workflow has a device-oriented workflow that starts at the part and works backward to the tester and into the design of the measurements in software:
- 1. Assign resources to the device pins.
- • This is the development of the physical interconnect between the tester and the device under test.• Helps to determine the design of the device interface board (DIB) and configurations of the Fixture and TIMs.
- • The physical connections between the tester’s Fixture and DUT are defined in the software so that the system can automate the switching of signal needs to support measurements.
- • The communication link to manipulate and set control logic n the DUT is established to allow the tester to automate the control setup of the part.
• Interconnect paths from the test instrument modules (TIMs) to the Fixture are defined.
- • Now that all of the physical interconnects are in place, and the tester has defined control and signal paths to the DUT, the user can build a test program to validate the part.
In the background, Guru organizes and recalls these definitions, test setups, and test resource configurations according to the user’s meta tags, to keep a running log of design iterations and current tests. When it is time to release a test to the production floor, Guru provides the distribution gateway to pass the test plans to other testers.
There are two distinct roles a tester must support during its lifecycle: test development and production test. During the development phase, the tester is used to explore, validate, and optimize setups and test configurations. In the production phase, the setup and configuration must be locked and the focus is on reliability, repeatability, and speed. Guru provides a control mechanism for these two roles in the software that’s reliable and simple for the user to deploy:
- Development: Can experiment with new software enhancements without disrupting production, log incremental design changes in tester setup, and validate test plans before release
- Production: Test plans, configurations, and software versions are locked, permission to modify files or setups can be restricted, and the user interface is simplified to display only essential controls to execute tests
Much like the development sandbox, Guru provides the ability to quickly and easily save and roll back test setups and software configurations to a previous setting, giving the user the freedom to experiment without the fear of losing a previous design iteration. To make the step of going back to a previous setup easier, the software allows the user to save an entire configuration as a shortcut. Using the Guru History interface, the user can sort through a chronological record of shortcuts, and then select one to resort back to a previous setup. By taking the time to create shortcuts, the user always has a quick and simple way of recovering their setup.