Why the turnkey promise is ruining margins, and how software-defined automation fixes it

When to modernize integration with universal I/O, cloud SCADA and AI

Key Highlights

  • Claiming a true turnkey solution is often a red flag that damages customer trust; success requires clear front-end scope definitions and active collaboration from the customer.
  • Integrators must flip the traditional workflow by prioritizing software-defined automation over hardware selection to streamline development, reduce overhead and protect margins.
  • Adopting tools like universal I/O, cloud-native SCADA and AI code generation boosts profitability, provided integrators thoroughly validate AI outputs and manage the culture shift inherent in legacy facilities.

Integration costs affect the machine builder and the customer. Uncontrolled project scopes and poor administration of executable tasks can delay project starts, execution and completion. Inflexibility of processes can also cause problems. Combine that with third-party commitments and logistics, licensing costs and new technologies, and it becomes difficult for integrators to control margins and win customer trust, especially when. It is also difficult for customers to justify costs. How do the two sides meet in the middle, and what can integrators do to control margins to benefit the customer and the bottom line?

First, do not claim a turnkey system unless you have a perfect greenfield situation. Second, make project requirements with your customer. The assumption that the integrator is the expert is false. The customer needs to know their lines, what equipment they want and what they want to end up with.

Many integrators claim that they can do it turnkey, and this is a turn-off to seasoned engineers that understand that engineers overspeak their qualifications. It’s also not possible to do a turnkey solution on greenfield projects without understanding the current machine first. Because all industries do not use strong requirements or standardize on International Society of Automation (ISA) recommendations, then there is a mismatch in the definition of the system in relationship to turnkey from the get-go.

Who is left holding the bag? The installation engineer, the electrician installing and the install manager.

How does this affect the integrator? It makes for a poor relationship.

Thus, the idea should be about getting follow-on work and not a prepackaged, not fully designed concept with no predetermined end to the project that creates stretched margins for the integrator and doubt for the customer.

It’s the difference between the customer thinking they got an obsolescence replacement or a retrofit vs. an upgrade.

How can margins be contained? First, the front-end loading should be agreed upon, and it’s normally too vague. Second, integrators are shifting focus of revenue from engineering hours and commissioning to high-value recurring software.

High-value recurring software and analytics services means shifting focus to software-defined automation, artificial intelligence code generation, cloud native SCADA systems and universal I/O for hardware.

Software-defined automation: This means using software definitions to drive development and hardware selection. Software-defined automation includes using dev ops to create an intelligent coding system allowing for faster production of PLC code, as well as version control.

Get your subscription to Control Design’s daily newsletter.

AI-associated code generation: This means using AI tools to create code. If you’re not comfortable with this, then integrators use libraries where they have pre-canned code for use on any project. Code structure and functions for items used in every system should not change. This includes alarm tables, valve control, LDVT control, e-stops and HMI templates.

Cloud native SCADA systems: SCADAs have gone to a remote server for a while now, and it’s popular because of the reduced licensing. And it allows engineering changes while running.

Universal I/O hardware: Universal I/O hardware means that one card type is bought, and it can be configured as an analog input or output, or a discrete input or output. This reduces hardware costs, and spares are simplified. It also removes the need for fixed-purpose wiring, jumpers and specialized martialing.

The last two suggestions are popular. Some integrators are still working with the code structure from the 1990s and early 2000s and doing hardware before software. This is discouraging because it’s timelier to define software last than it is to define hardware after software. Also, the hardware should be bought based on the needs of system functionality. Software should not be made to fit the hardware.

AI tools are handy, but integrators need to not use them without checks. For instance, having CAD-generated drawings is great, but if the output is unreadable in the field due to the size, then it’s useless from a practical standpoint. Many of the AI type tools are not advanced enough to cover the many years of standards because the people making the AI applications are not considering the use of what is being output but only the ease of time and overhead to output it. An example is using simulated digital twins, but if there is not enough information for the twin to run realistically, then the amount of effort to create a digital twin has little return.

This is the balancing act that should be noted before choosing to generate or simulate. Overall, if integrators would create software-defined processes that are adaptable to customer needs, then they could reduce overhead costs.

In general, it should be a team effort between the customer and the integrator to reduce costs so that upgrades are possible. Shifting focus to software defined automation, artificial intelligence code generation, cloud native SCADA systems and universal I/O for hardware is also a culture change in some industries because some industries will not be familiar with all the technology changes due to system life exceeding 30 years. This makes modernizing integration services difficult and costly.

About the Author

Tobey Strauch

Arconic Davenport

Tobey Strauch is currently managing brownfield installations for controls upgrades at Arconic Davenport.  She has previously worked as principal controls engineer and before getting her bachelor’s in electrical engineering, was a telecommunications network technician.  She has 20 plus years in automation and controls.  She has commissioned systems, programmed PLCs and robots, and SCADAs, as well as managed maintenance crews.  She has a broad mix of mechatronics with process control.  She enjoys solving problems with Matlab and Simscape.  Contact her at [email protected].

Sign up for our eNewsletters
Get the latest news and updates