The Four Pillars of a Successful Automation Project
In any industry, there are certain factors that are crucial to a project’s success. We’ve identified four pillars that are essential in the automation industry and without taking these four factors into consideration, it’s likely that your automation project is destined to fail – or at risk of mishap at the very least. So without further ado, let us introduce you to what we like to call the Four Pillars of a Successful Automation Project – it’s worth getting well-acquainted with them if you like hitting your targets.
Perhaps one of the most important things to consider in automation, is the people you’ve got working for you. Engineering is a broad field and engineers themselves have even broader specialisations. Having the right automation partner or team on board will be integral to the success of your project and it’s one of the most valuable decisions you’ll make.
Ask yourself, do you need project people or support people?
A project engineer specialises in building projects from the ground up. This includes skills such as software library development and interpreting functional specifications into detailed control logic. A support engineer on the other hand has specialty skills in the realms of fault finding, ongoing system upgrades and the key process knowledge and system operational requirements.
Yes, both are different, but both are equally as important. Many projects fail because they are not tuned to meet the specific process and operational requirements. The systems are built to a specification, but are quite often designed by people with little operational experience.
With that in mind, communication and collaboration between both the project and support / operations engineers is the key to a successful automation project. In addition, the skills of the people working on the project will differ, as will the need for certain skill sets, depending on various things – what the project is, the process that is involved, the technology to be used and the software to be developed.
Finally, your team’s attitude will also impact upon the outcome of the project, so it is important to have dedicated people on board. Do they take responsibility for their role? Are they proactive? Do they use their initiative to identify issues that need to be rectified, whether they are within the team’s scope or not? To often the ‘not my job’ attitude leaves hidden landmines waiting to be uncovered at the critical commissioning phase of the project.
The second essential element of an automation project is the plan. A little too obvious, you say… well, take it from us – you’d be surprised at how many companies begin a project with no plan in place. Without a plan, you might as well have a regular person with an instruction manual doing the job and that is never a good idea, unless we’re talking about assembling an IKEA flatpack.
In other cases, the plan is not even adhered to, nor is there any review or root cause analysis of changes in the plan along the way. Many projects are just floundering ships buffeted by random currents and winds, unlikely to reach their intended destination.
Most project plans do not address the technical risk aspects of the project. Technical development is seen only as ‘packages of work’, e.g. SCADA Screens, or Network Configuration. Your plan must detail all of the technical aspects of the project and include an in-depth risk analysis. You should also have activities in place throughout the process, to ensure success along the way, for example, a Network Configuration loading test to validate the design.
Verification and validation processes are key areas which ensure the project or product fulfills its intended purpose. These however, are often not fully addressed. As a result, the client may order a ‘kettle’ and end up with a ‘toaster’, weakly justified by the fact that they both heat something! The software and hardware should be rigorously tested at each phase of the process, especially for technical risk areas, so that action can be taken to avoid future failures.
Process is the next integral part of an automation project. Firstly, for any chance of consistent and reliable project performance there must be design and development standards. How can you have confidence in the project if your supplier has no repeatable and known set of standards and processes to get your project delivered on time and to specification? There needs to be a clear understanding of which design and development philosophies are being employed and a process for building the system’s software needs to be in place. What IEC or ISA Standards will it follow? Is there a device layer? How will the sequences be structured? How will interlocking be done?
In many projects there is no actual design/development philosophy or standards and many sites have a broad range of system styles. Why should you care? Without them you’ll end up with a hodge-podge of different systems, significantly increasing your maintenance supports costs over the life of the system.
Getting the technology platform right the first time will save time and money. Remember, the sales guy always assures you that the technology will work, but they are never around later on to deal with the repercussions if it doesn’t. It’s worth finding out if they’ll refund you or pay for rectification if something was to go wrong technology-wise – as if! Don’t let your automation project end up being a crash-test dummy for the suppliers, using version 1.0 or a recent major product release.
When taking technology into account, you’ll be faced with some major decisions. What’s more suitable – a centralized IO system with concentrated IO hardware in a single entity, or a distributed IO system whose hardware is placed across a range of operational and physical areas? Is SCADA or HMI a better choice? Will the processing be centralised or distributed? What kind of communication protocols will you put into place? What is the range of field communications and what kind of network hardware is required to achieve this?
Technology is complicated, but by implementing the right platforms, your project doesn’t have to be. Most suppliers provide very good hardware and systems to meet your needs. The key is implementation. Most platforms are very powerful and flexible, but there are optimal and sub optimal methods of implementation. In many cases, when the platform is blamed the actual fault resides in the implementation.A basic and very common example is in communications, e.g. Profibus and the terminations and routing of the actual cables causing devices on the system to drop off the network intermittently.
Poor execution, can impact various key areas of the system, for example PLC scan time or overall speed. There is nothing worse than an operator clicking on his SCADA screen and waiting five seconds for it to respond! An example is when a specific programming style that works well on one platform is implemented on another to which it is not suited, resulting in very slow scan times or complex coding to replicate another platform’s in built functions.
Hopefully you now have a better understanding of the four pillars and we’d encourage you to keep an eye out for them during your next automation project to ensure success!
Coengineer is Australia’s leading team of automation specialists. Our dynamic team of engineers and project managers are experts at driving bottom line business objectives through automation. If you’ve got an automation challenge, or are looking for a long-term partner to support you, don’t hesitate to get in touch. We’d love to hear from you.
Get helpful articles, news and events straight to your inbox:
Comments are closed.