Moving from a fully manual to an automated process takes a biological assay to the next level: commercialisation, standardisation or scaleup. However, taking the first step in the direction of automation can be daunting, with various pitfalls to navigate along the way. Yet, with the right knowledge, awareness and guidance, it is possible to navigate this path
successfully.
The opportunities of automation
There can be many reasons for a company to choose automating a process, including:
• Improving process quality or reproducibility
• Increasing scale
• Minimising aligned resource
• Enabling out-of-hours operation
• Improving data quality
The level of automation of the assay in question that an organisation wants to achieve varies
enormously. Automating a process can simply involve moving from a cuvette reader to a
microplate reader, while more advanced automation might involve acquiring a bulk reagent
dispenser to avoid repetitive pipetting or adding stacking systems to remove the need for manual feed. However, what most people mean by automation is moving to fully controlled, hands-off processing of the workflow, with traceability of the sample as it progresses through the process, as well as automated data recovery and data manipulation.
Know what to automate... from the start
The path to automation can be complex, and so a roadmap is necessary before embarking on that journey, including checkpoints. It is essential to be clear on the (parts of) processes requiring automation, the level of automation needed and what that automation should achieve (saving time, reducing costs, increasing throughput, etc.). It is also important that this information is based on real data and with the input of all personnel involved in the performance of the manual process – from the lab manager to the technicians conducting the assay. Without this input, any plan for automation is likely to overlook key details, resulting in delays later in the process.
What also needs to be clear from the beginning is the composition of the team responsible
for delivering the project. It is beneficial to have staff members within the organisation with
good knowledge of both the science of an assay and the engineering challenges associated
with automating that assay. It can be challenging to go through this process, but there is the
possibility of external consultancy from automation experts to ease the burden – as well as from suppliers of automated systems.
Making automation feasible
To help ensure a smooth and speedy route to automation, Peak Analysis and Automation (PAA) offers an S-CEL feasibility study to organisations looking to automate their assays and processes. This helps to align automation expectations with the organisation’s vision for growth and can become a corner stone for the automation strategy. In a feasibility study, PAA’s dedicated team of scientists and engineers works closely with the organisation stakeholders and uses its experience in delivering lab automation to identify the best route to automation, highlighting any potential issues early. Many instances of overspending and delays are the result of issues identified late in the process, and a feasibility study can help resolve these before they become a concern.
As part of a feasibility study and later implementation, PAA supports organisations
throughout each key stage of automating a process – from concept to completion.
These stages include:
1. Carrying out an automation assessment
2. Writing a user requirement specification
3. Delivering a functional specification
4. Deployment of the automated system
5. Carrying out acceptance testing
6. Training and post-implementation support
Expert advice and support from an automation company such as PAA that is
vendor neutral or an instrument re-seller is invaluable in delivering automation to
specification, on time and within budget.
The path to automation
Stage 1 | Carrying out an automation assessment
An automation assessment ensures that the proposed process aligns with the automation
strategy. The assessment involves a detailed workflow analysis evaluating the suitability of
moving from the existing fully manual process to an automated one. The analysis would
review processes, current and future equipment needs, and include input from the process
owners and management. It would also evaluate current workflows and capabilities against the desired targets and review data transfer between the processes to ensure a smooth transition of data across the entire workflow with recommendations for databases and data handling. The assessment identifies any issues that could delay or derail the project, allowing them to be addressed before the automation project begins.
A key element of the automation assessment is an on-site study to assess the suitability of the site for automation. Early identification of potential locations for systems, building services requirements, workflow adjacencies and limitations can highlight unforeseen costs. During the site visit, managers and staff from each work area will be interviewed, and processes and workflows reviewed to gain a clear understanding of the scope of work required to meet the automation objectives. The study will be designed to cover the processes and data transfer within the company and how data is currently managed.
The visit should also include building capabilities, space available, services, data capacity and material flow. The findings of the on-site study would be presented at the end of the visit
to confirm a correct understanding of the current operations, with recommendations for
improvements to data handling and potential areas where the processes can be enhanced by automation. The document would also outline areas where further consultation would be of benefit to highlight additional improvements in the processes and workflows.
The goal of the automation assessment is to generate a proposal that provides a strategic
plan and framework for implementing a cascade of well-defined, prioritised user requirement
specification documents that fully meet the business needs and are aligned with the automation strategy.
Stage 2 | Writing a user requirement specification
The user requirement specification (URS) is a detailed description of what the automated system needs to deliver. It is intended to be shared with one or more potential suppliers to form the basis of the functional specification, which the supplier prepares for a client. A well written URS helps to cut through the noise of the purchasing process. Therefore, a URS needs to include:
• A description of the issues with the existing setup or procedure
• A detailed description of the requirements of an automated system
• Process maps, both for the physical process and for data analysis
• A prioritised list of physical and data deliverables
• A prioritised set of acceptance criteria
• A glossary of terms to ensure consistency and correct interpretations of terminology
Producing a good, comprehensive URS that minimises the risk of finding issues during
implementation requires assessing several aspects of automation:
Operating procedures
The first key aspect of writing a URS is to accurately record every action that operators undertake when carrying out the assay. This includes minute details that may not be documented in manual operating procedures, but could have become standard practice through habit or through trial and error. Examples include actions such as swirling a reagent bottle before pipetting or tapping a plate before use. Whether these details are critical to the assay’s success or not, it is important to evaluate the existing process to this level of detail as accounting for these actions could make the difference between success and failure of an automation project.
Timing
When many people think about automation, they imagine robotic arms rapidly assembling
vehicles and other machines on a production line. However, in life science this is rarely the case. Most automation systems are not necessarily faster than the actions of an individual user as this might have an impact on the smooth running of an automated assay. Stability of the reagents involved, for example, is a time-dependent factor. If an assay runs for several hours, it would be necessary to confirm that cells and reagents are not affected during the course of the assay.
Data handling
While data handling is challenging for operations of every size, it is the potentially greater volume of data generated by automated systems that leads to a bottleneck if not collated in an effective way. Employing full sample tracking and ease of operation is highly advantageous for efficient routine use, and each factor must remain flexible to fit around the great variety of demands of individual laboratories and their existing data infrastructure. Sophisticated and flexible automation software, such as PAA’s Overlord package, can help to ensure that the increased amounts of data are handled effectively, but this issue needs to be considered from the outset.
Infrastructure
Potential changes to the building’s infrastructure within which the new automated system will
be based should also be considered early and thoroughly. Getting the right infrastructure in
place can be a costly and time-consuming process that requires extensive liaison with building and facility managers. Also, the responsibility for adequate infrastructure does not lie with the automation vendor, but with the buyer. Examples of the extensive lab modifications often needed are:
• Removing lab benches
• Moving existing lab equipment
• Creating space for storage of labware
• Creating space for associated processes
• Adding services such as (purified) water, data communication, gasses, compressed air, etc.
• Ensuring usable delivery routes for the on-site system build
Safety
When moving from a manual to an automated system, there will always be safety aspects that need to be (re)considered. For example, it might be necessary to check the relevant CE standards, as well as other international safety standards, at an early stage to avoid considerable additional expense and effort during implementation.
A thorough review of COSHH assessments also needs to be carried out due to the inevitable
increases in reagent volumes and waste from higher throughput processes of the automated
system. Once the system is operational, it becomes the client’s responsibility to ensure it is safe to use on a day-to-day basis. This potentially includes a post-delivery assessment to comply with local regulations. For companies in the UK, for example, this would include a Provision and Use of Work Equipment Regulations (PUWER) assessment.
When detailing operational, timing, data handling, infrastructure and safety requirements in
a URS, each should be subdivided into critical, optional and optimistic requirements. These
divisions provide a useful insight to suppliers, providing some flexibility and making decisions on the final system easier, especially when a balance needs to be struck between requirements and budget.
Ensuring that all these aspects are thoroughly assessed and clearly reflected in the URS requires a considerable investment of time and effort. Though the process can be complex, requiring close attention to detail, this extra investment will be recouped, both in terms of time spent and overall cost of the project.
Working closely with automation experts, for example via PAA’s feasibility study, will help in
establishing an accurate and detailed URS that is fit for purpose, thereby paving the way for
a smoother process in implementation. PAA’s personalised and vendor-neutral approach, in
particular, can help ensure the URS is unbiased and based only on actual requirements of the organisation.
The feasibility study will produce a document that will be the property of the customer and will outline the processes and data fl ows that are currently used and suggest ways forward using automation of the processes or enhancing data generation and analysis. The document will recommend areas that will require additional consultancy to further understand the processes and will be in suffi cient detail to enable the work to be costed. The document can be used by the customer to contract additional work as required.
Stage 3 | Delivering a functional specifi cation
A functional design specifi cation (FDS), which can include a hardware design specifi cation
(HDS) and a software design specifi cation (SDS), is the document in which a supplier sets out the specifi cations of the system it off ers to the client. When preparing this document, the supplier assesses the critical, optional and optimistic requirements in the URS and uses these to propose a system it can deliver while also taking all practical and budgeting constraints into account.
This FDS document is reviewed by the client organisation to confi rm that the specifi cations
match the URS, and is a critical point in the process. The fi nal FDS acts as the contract between the supplier and the client, meaning that any modifi cations to the proposed system after this point are likely to lead to delays and additional costs. For this reason, working closely with a supplier to ensure the fi nal FDS is fi t for purpose is essential in keeping the project on track, within budget and aligned with expectations.
Figure 1: Examples of detailed CAD designs of the workcell and its location within the laboratory which are included in the FDS document
Stage 4 | Deployment of the automated system
After the often-hectic period of preparing the URS and checking the FDS, the build phase of the project is seemingly less busy from the client’s perspective. Timelines and project milestones will be clearly defined in the FDS and the client should receive regular updates from the supplier and notified in case of any delays in the build process.
During this time, there is the possibility for the client to visit the supplier to see and input on the system as it is being built. This is a valuable opportunity for the client to learn more about the inner workings of the system. It is highly beneficial to extract as much information from a supplier as possible during this visit, and to bring the right people from within the organisation. For example, in addition to a project manager, staff involved in future operation, maintenance and troubleshooting of the system can benefit from these insights.
Stage 5 | Carrying out acceptance testing
After the system build is completed, there are generally two acceptance tests that need to be
carried out:
• The factory acceptance test (FAT)
• The site acceptance test (SAT)
There is usually a degree of overlap between the tests, but both are opportunities for the client to confirm the system is within specification and, if necessary, point out any discrepancies between the FDS and the actual system delivered.
To ensure a fast and smooth process of acceptance testing, PAA’s team of scientists and
engineers carries out highly detailed, thorough FATs. Experience in carrying out these tests
has shown that extra care at this stage saves time by discovering and addressing any issues
at the factory, rather than at the SAT stage. When taking every possible precaution to spot errors early, for example by using PAA’s feasibility study, major issues at this stage are
significantly reduced, benefitting both client and supplier.
FATs focus on aspects such as liquid handling, integration of equipment and data handling. In the case of testing highly complex systems, there may be a need for two FATs before the system is transferred to the client site.
After successful completion of the FAT and installation at the client site, a SAT will be carried out. This test is usually a partial repeat of the FAT, but will often include additional tests for aspects such as data handling and the use of biological reagents.
Once the SAT has been successfully completed and all the relevant paperwork relating to the
tests has been handed over to the client, the supplier will consider the system delivered.
Stage 6 | Training and post implementation support
After all the effort of selecting, testing and implementing the system, the final key stage is
ensuring that the system is used, that it is used correctly and that there are processes in place for maintenance and troubleshooting. A central element in this is staff training, which usually begins with appointing an ‘owner’ of the system, often the person responsible for delivering the automation project, but not in all cases. The ‘owner’ should ideally be somebody that understands both the assay and the automation aspect, and who was involved in the project from an early stage.
It is the owner’s responsibility to make sure that the system is not underutilised and that it
delivers the anticipated return on investment. It is likely that this person will carry out user
training, but they will also need so-called ‘expert user training’ to be able to assist when other
users run into difficulties. When this is an existing employee, it is likely that these additional
responsibilities could take up at least 20% of their time in the short term to deal with challenges relating to the increase in throughput, validation of the system and (in regulated environments) ensuring that an operational qualification (OQ) is in place. The availability of this bandwidth accelerates the learning process and user buy-in.
Once set up and embedded, the automation will require regular preventative maintenance. This can be provided by PAA’s service and support team. This is often overlooked when calculating the total cost of ownership but should not be undervalued. If the client organisation has in-house engineers, it is important that they receive certified training as mistakes can be costly and contribute heavily to system downtime. Service contracts give users access to PAA’s “Helpserve” support, which can involve rapid remote dial-in or a site visit from an engineer. This can provide much needed backup for the in-house system owner. Frequent and prolonged downtime can lead to user frustration and while all systems can suffer problems (instrument failures, recalibration, etc.) preventative maintenance and good support minimises the downtime and increases return on investment.
Another factor for consideration is that although an automation system is a long-term
investment (~7 years depreciation as standard in most companies) the science it is performing can change rapidly. PAA’s software and hardware configurations can be re-worked to transform a system that is deemed no longer useful into an ongoing resource. Care should be taken during the scoping process to define flexibility in the setup. It is easy to fall into the trap of thinking ‘this process will not change’. Whilst most reconfigurations will involve further investment, it is usually far better value than starting from scratch.
The path to automation
AUTOMATION FEASIBILITY STUDY
Stage 1: Automation Assessment
• Automation strategy
• Process analysis
Stage 2: User Requirement Specification
• Operating procedures
• Timing
• Data handling
• Infrastructure
• Safety
AUTOMATION IMPLEMENTATION
Stage 3: Functional Specification
Stage 4: System Build
Stage 5: Acceptance Testing
• Factory acceptence testing
• Site acceptance testing
Stage 6: Training and post implementation support
Reaching the destination of successful automation
Many automation projects go through the six stages outlined, regardless of the actual process or degree to which it is being automated. Being aware of these – and the consequences of errors, oversights or other setbacks at any of these steps – will help to stay on top of the challenges that lie ahead.
PAA’s feasibility study offers clients the ability to clearly understand the project deliverables,
as well as the cost, time and resource requirements for automating their workflows at the
outset of the project. The study helps reduce the issues involved in delivering automation
projects and prevent any project scope creep that could lead to extended delivery
estimates.
The benefits of a PAA feasibility study include:
• PAA consultancy when writing the URS
• Advice on selecting the best equipment
• CAD design of the workcell
• Survey of the installation area
• Identification of key project risks
• Identification of customer stakeholders and skillsets
Comments