Laboratory Automation and Testing
A lot of the operations in a laboratory are geared towards performing tests. Some examples are particle counting, titration (moisture determination) or PH tests.
Chemical testing is a time-consuming affair. Steps leading to the test, the test itself and post operations are time-consuming, prone to mistakes and causing repetitive action injuries to operators.
Operators are not cheap either. People who perform these tests are often highly paid employees with advanced degrees (in chemistry or equivalent fields). Often doing tasks that, in essence, could be done by machines. Their time is not consumed doing any type of analysis but doing mundane manual processes. Automation can change this and for those who have had the vision and have invested, the change has already started.
A typical automated process involves a robotic system that performs the physical aspects of the automation. This could be pick and place of labware or placing of samples into some reaction vessel.
The other aspect of testing in a laboratory setting is the interaction with instruments to generate reports related to measurements to complete the cycle. This requires a software that acts as the central point of control to coordinate all operations and interact with not just the mechanical components but the analytical instruments as well.
This can be tricky at times, as a lot of instruments have not been designed to be operated in an automated manner: they expect a user to interact with them through the various physical interfaces (buttons, touch screens, etc). However, most instruments have the means of communication and respond to remote control commands.
To design a fully automated workstation requires that you consider many factors: from the physical layout of various sub-systems for easy accessibility and serviceability to layout of software. It also means that the software needs to have various modes of operation. As much as you need to provide access to a user to be able to perform their tasks, you also need to restrict access to certain parts of software and system.
Finally a test system needs to have a clear way of conveying the results. Reports need to be generated to indicate the results of tests. These results are often quantitative and often have some upper and lower limits that produce pass or fail marks. The system designer needs to allow the end-user to interact with the system (normally through a database) to set the limits.