Uncategorized – JME Test Solutions LLC

Are you groaning yet? Of all the interesting things you can do with NI TestStand User Management probably ranks dead last. This feature of TestStand is not flashy but is a lot more important than you think. The reason this gets neglected by test engineers is that most of the value of TestStand’s user management comes after a test system is deployed. I would argue this is a critical deliverable.

If you can get them to think about it, most TestStand developers will tell you the user manager allows you to specify user permissions. The basic use case is to prevent Operators from setting breakpoints or running test sequences in a debug mode. This is a critical control function to help ensure the operators ran all of the required steps. Unfortunately a lot of times the implementation of user management stops here with a generic operator account that is required to be used for testing. Having an operator account is much better than running everything under administrator, but there is a lot of value of having each test operator have their own individual account.

Every test report generated is tagged with the name of the user that was logged in when the test was run. The operators are as much a part of the test system as the DMM or signal generator. How they operate the test can make a difference in the testing process. As such this is a key data field that needs to be recorded for trend analysis and statistical process control (think Gage R&R).

Its also a critical metric if you want to create operator key performance indicators (KPI). Once your operators are required to sign in and you can trace test events back to them then you can create reports to measure how well they are executing the test process. This allows you to identify and correct training deficiencies or bad behaviors (test until pass, “dry-run tests” to improve yield numbers, slow execution times, etc) sooner.

Unfortunately, for such an important part of the TestStand framework NI’s out of the box implementation leaves much to be desired.

For instance, Under the Fundamentals->Managing Users Topic in the TestStand help NI has a very interesting disclaimer.

“Note The user manager helps you implement policies and procedures that concern the use of test stations. The user manager is not a security system, and it does not inhibit or control the operating system or third-party applications. Use the system-level security features the operating system provides to secure test station computers against unauthorized use.” –NI TestStand 2017 Help

They aren’t kidding about this either. The TestStand Engine does not have a real login function. There is a function that will return true if a password is supplied but under the hood switching users is as easy as:

Engine.CurrentUser = RunState.Engine.GetUser(“administrator”)

Don’t believe me? Create a test sequence with an expression step with that in it. Save and then login under an operator account and run it. After you run the test sequence you will be logged in as “administrator” (or any other account you specify)

That’s it! No password prompt required. Of course this still requires you to have access to the TestStand development environment. That is true, but there is another way to do this that is even easier.

Delete the Users.ini file in Teststand’s programdata directory (c:\programdata\National Instruments\Teststand xxx\cfg) then re-launch TestStand. On re-launch Teststand will detect the missing Users.ini file and promptly recreate it with a default one. This will allow you to login to the system as administrator with a blank password.

Not an ideal implementation. You have been warned.

Another issue with TestStand’s user management implementation is that out of the box it doesn’t scale very well.

By default all users information is stored in the test station’s Users.ini file in c:\programdata\National Instruments\Teststand xxx\cfg . This is workable for a single test system, is a pain if you have a handful of test systems and quickly becomes unmanageable when you have 10+. Each station has to be individually updated whenever ANY change happens to users.ini.

One solution I’ve seen to this issue is to host the users.ini file on a network share. This can be done by changing the path to users.ini in the station configuration dialog.

This helps with keeping the users.ini file synced between all of the test systems, but has other drawbacks I won’t get into here. If you can’t implement the better way below than I would recommend doing at least this if you want to implement factory wide user management.

A better way

There is a better way to manage users. Override the Front-End Station Callback to use Window’s .net security objects to authenticate against a domain server (think Active Directory or Kerberos).

Active Directory was designed for secure centralized user management. It has built in support for password requirements, resets, and other security policies. Better yet it is already used by most organizations to manage company PCs.

If your test systems are networked it is best to leverage the existing IT infrastructure. New employees will already have an account generated for them when they start and those accounts will be terminated and cleaned up by IT when an employee leaves the company.

If your test systems are on an isolated factory network than Active Directory can be setup easily with any windows server installation; Your IT department should be able to do a read-only replication of the corporate Active Directory.

Another advantage of active directory is that you can setup active directory groups that correspond to TestStand groups. This allows you to restrict test system access to only trained operators if necessary. If you want to get really strict you could further restrict certain sequences to specific operator groups.

So how do we setup TestStand to user Active Directory? Two things. Modify the Front-End Callback and use Dot net’s System.DirectoryServices.AccountManagement class to query it.