Typical ATE systems have always been "islands of automation"; they are highly automated but lack an easy connection to other test and data systems. Guru strives to change that; Guru makes it easy and automatic to share files and information between testers and other systems. Guru saves every revision and automatically uses the latest version, so you can develop tests without worrying about breaking anything because an old revision can be restored very easily.
Guru is networked to other Gurus
Unlike a normal filesystem, Guru is a specialized database networked in a hierarchical way. If a file is requested from a Guru and it does not have a match, the Guru requests the file from another Guru which acts as a server. In this way, Test Plans can easily be shared among testers simply by placing the Test Plan on the shared Guru server. Each tester connected to it will find the Test Plan when it is needed by the operator. The networking of Guru requires a TCP port, typically port 50000, for communications with other Gurus. The connection is firewall-safe since the client or "cache" Guru always initiates the communications with the "server" Guru. There is never a need for the server to contact the client directly, so communication is permitted simply by opening a port for outgoing communications.
Guru is like a file system
It is used to store files such as Test Plans and Test Executives, data files, calibration information, and even system software and updates. Files in Guru are like those in a database which can be accessed by file name, like a typical file system, but they can also be found using "metadata", or keys and values assigned to the file. For example, a test executive has key values such as "in development" and "released to production" to easily find the execs which should or should not be seen by operators on the production line. Because of these tags, Guru is also like a database. And because Guru saves every change to every file and automatically uses the latest version of any file, it is much more than a typical file system.
Guru keeps revision histories
Each time a file is revised and stored in Guru, the previous edition is saved in the file's revision history. If the previous version is ever needed, it can easily be retrieved and made current. This automatic revision history occurs for all files stored in Guru, including Test Plans, Test Executives, test data, calibration data, etc. When the storage capacity becomes full, the oldest revisions are discarded according to an expiration policy.
Guru is script capable
Guru is able to start programs on timed events, such as when Guru is itself started or every hour while Guru is running. A Guru Agent script is available that copies files from the Guru to another file system, either a disk drive or a FTP server. Files can be selected using the Guru keys and values, for example, to send any new data logs to a special FTP account for processing by your own database.
Guru is reliable
The RI Software Architecture allows for high amounts of reuse and reliable software control to remove any possibility of undetected technical errors. All files are cryptographically verified with hash codes when read to prevent errors associated with network or hard drive instability. By default, no file is ever deleted until the space is required and an expiration policy is established. Any corruption is detected and the file is automatically repaired.
Guru is secure
Every file is digitally signed by the Guru which created the original file. The signatures are checked by any Guru which receives the object and if the signer is unknown to the receiver, the document is not trusted. Files may also be encrypted by Guru so that only a Guru with the matching key can decrypt and use the file. The encryption and decryption is done automatically so the end user is not burdened with the process.
Guru is safe
Each RI ATE System local Guru is backed up automatically to a "backup" Guru server. Every document that is saved locally is also sent to the backup Guru. If the controller which operates the tester fails, getting back up is as simple as rolling out a new controller with the operating system loaded and connecting it to the network. As soon as the tester is started, the new empty Guru will start requesting files from its backup Guru automatically. The "restore" process is completely transparent to the user. It may take a few milliseconds longer to retrieve the file from the backup Guru, but the file is saved again locally making the new Guru a duplicate of the failed computer. This reduces downtime for a computer failure, one of the most disruptive failures that can occur on a test floor.
Guru helps RI 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 such as "service request" information that helps us diagnose and fix software issues which may occur in the field.