Deployment and Maintenance

Deploying a test bench with our design freshly in mind is usually not a problem. It is another matter when the test bench is deployed half-way around the globe at a third-party contract manufacturer’s plant by a technician whose priorities are not necessarily aligned with ours.

To create a dedicated deployment and update channel with a third party manufacturer takes a lot of time and work at the process level. It can severely affect time-to-market and the scaling of deliveries through the duplication of production lines. It requires a lot of back and forth work - such as sending emails, software binaries and procedures - all while everyone is carefully counting hours spent on the deployment. Worse still, if a large time zone difference is involved, the daily window to make progress on the deployment is very short and can drag it along for weeks.

Wouldn’t it be nice if your test bench handled all of this for you?

Automated Deployment

The automated deployment of test benches is one of the core features of our Spintop Suite. Once a test station is registered on our cloud platform, a committed version of a test bench can be remotely deployed directly from your dashboard. A sandbox environment receives preliminary test results to allow their validation by the test bench developer until the station is ready to produce actual units.

The following diagram illustrates the process.


Maintenance Updates

Once the test bench is deployed and production has run for some time, a slew of issues can occur that trigger the need for test bench maintenance and an update. The maintenance can either be preventive or under pressure if the production line is halted unwillingly. Such stops can be caused by a bug in the test bench or an engineering change requiring a modification to the test plan. In both cases, an efficient method of applying the update is required, as is the case for initial deployment.

Differences with Deployment

There are two main differences between the deployment and maintenance use cases:

  • First is that the testers must be made aware of the upgrade, whether it is mandatory or not. An upgrade procedure must be created if the maintenance is not simply a software one (for example, changing or adding a test equipment) and it must be followed.
  • Second is that it is possible to render a fully functional test station unusable by even the most simple upgrade. Time and energy were spent during the deployment to render the test station stable and functional. This energy must not be spoiled by a bad update.

How we Handle it

By allowing a versioning and a lock of your test benches to your test stations, the Spintop Suite gives you the possibility to instantly roll back an update if an error was made during its development.

The following diagram illustrates the test bench maintenance process.


Would you like to use our software suite to remotely deploy and maintain your test benches? Get started with our test executor, spintop-openhtf.