Implementing automation into factories can be technically and financially challenging. The technical issues can cost both time and money and consume significant engineering resources. This article discusses ways to manage these issues.

User Requirement Specification

The User Requirement Specification (URS) tells everyone what the automation system needs to deliver. If the URS is done well, we have a clear target that everyone involved understands. This is very often not clear enough and not understood by all stakeholders. For highly regulated industries, such as pharmaceutical and medical device manufacturers, there are templates available. With some internet research, URS writers can often find a suitable template if they don’t already have one. These can be helpful, even if not prescribed in your industry. For other industries, it may be necessary or desirable to design your own URS template. The URS will always have some characteristics to make it work well. It will have testable or measurable requirements, be clear, unambiguous and understandable by the intended audience and be agreed by the stakeholders. It will have physically viable goals. The requirements will be necessary for function. It will not define the method of implementing the requirements. That is the role of the Functional Design Specification (FDS).

URS works better as a living document

It is my experience that the URS works better as a living document. This allows changes to be inserted as a project develops while keeping stakeholders on board. There can be physical limitations or constraints (cost, viability, time schedules) preventing the ideal outcome. Sometimes what is asked for is not physically possible. In other instances, improved performance potential may be identified which can then be included in the updated URS. A vague URS can be used initially to get input from automation suppliers and machine builders. This is okay, but cannot be used as the defining document. I have seen instances where the machine builder has written the URS for the end user, based on the machine builder’s preferred method. This can work, but it is not guaranteed. The issue here is that the end user has not taken the trouble to truly understand the details and can be surprised by the end result. It can be easy for an end user to uncritically accept the URS from somebody else if they didn’t do the work required to develop it initially, especially if they are under time pressure.

Functional Design Specification

Unlike the URS, the FDS lays out how a process will work. The FDS must meet the requirements of the URS. Sometimes it doesn’t and this causes friction between the supplier and end user. If this is the case, the URS and/or FDS must be adjusted to make them match. Perhaps a URS requirement is unachievable within a budget. In this case, the compromise is to agree to increase the budget or change or remove the requirement, or possibly use a different supplier or designer. When agreement cannot be reached, the options need to be reconsidered by the end user. Maybe the supplier is the wrong choice, or the requirement is unrealistic. An independent opinion can be helpful in these instances.

Testing viability

New technology and technology transfer both have potential for difficulty. In my experience, technology transfer never works exactly the same in an environment different to that in which it was developed. There are valid reasons for this, and they will need to be addressed. New technology is necessarily different, so this should be verified. Proof of Principle prototyping is often used. This can consist of anything from a simple test rig to a fully functional machine running for an extended period. It is important to be careful about who pays for it. The intellectual property (IP) rights need to be determined. If an end user wants to keep the IP, they might decide it is worth paying up front for the prototype. All testing needs to be recorded. I find a date and time stamp is very useful for this as it allows correlation of issues to be done retrospectively. When recording data, I recommend recording everything one can reasonably measure. I never recorded too much data and with video, automatic data logging and digital storage this is much easier than ever before. Make sure the engineers understand the principles involved. Useful tools for mechanical processes are video and data loggers. Very fast and very slow processes can be monitored and intermittent faults isolated for study. Many times software problems turn out to be a result of hardware. Simple things like a wire in the wrong terminal, noise from a missing solenoid flywheel diode, etc. Ensure the software is commented comprehensively so others can follow it, and that revision control is strictly applied.

Data

The data you collect is essential for other things. It is used to verify that the process meets the URS or, if not, shows why it doesn’t. For presentation to stakeholders, this is very important. Blame cannot be assigned to physical results; that’s just what happened.

Addressing the problem

When something doesn’t meet the URS, there are ways to address it: 1. Revisit the Proof of Principle prototype. Get independent advice if a solution isn’t evident. 2. Be aware of the personalities of the designers and software engineers. They can be understandably very defensive regarding their design decisions. It is easy to criticise, so if criticism is valid, try to present alternatives and avoid blaming people. 3. Ask for help. It is better to ask for help than struggle with a problem that you cannot see how to solve. The help can be internal to a company or it can be from an external source, such as a consultant. When getting help internally, it can be difficult to ignore the advice given even if you know it is not good advice. External help can be better. The consultant will be looking at the problem from a different perspective and has no company political baggage to deal with. The consultant is only concerned with the problem. 4. Adjust the URS. This is unlikely to be the first choice, and won’t be popular. 5. If the problem is not solvable, a presentation to the project sponsors will be required. The data you collected will be invaluable. Also, the consultant can support you or even present it. The consultant adds credibility to your presentation. 6. When presenting an unsolvable issue, always provide at least one alternative, preferably costed. This allows the sponsors to consider what may be done and reflects favourably on the engineers involved. It shows they are considering the whole picture as far as they can.

Arthur Middleton will be delivering a CPD course on 'Factory Automation: How to Successfully Deal with Technical Implementation Issues' on May 8, 2018, at Engineers Ireland, 22 Clyde Road.

Author: Arthur Middleton C Eng, MED, B Eng (mech), MIEI, technical director, Arthur Middleton Ltd. He has 30 years’ experience in factory automation design, development and implementation. Since 2004 he has provided independent machine design and consultancy services, primarily focusing on the automation of difficult processes. Clients include Dell Computers, Festo, Hollister ULC, Procter and Gamble, Quantum 3, Reconcile Engineering, TSM Control Systems, Vistakon, Yushin Automation. www.arthurmiddleton.ie