dev_ops

Manage aging components with a system approach

Jan. 29, 2024
Integrated controls and automation systems with IT and software in a DevOps environment could enable product lifecycle management and overcome component obsolescence

Control systems “in the wild” present a precarious situation. In one instance, they are stable and provide return on investment (ROI) up to 30 years. This is sometimes 20 years past their advised date of renewal.

On the other hand, electronics failures may occur at the five-to-10-year mark, or any moment after the 30-year mark. Original equipment manufacturers (OEMs) may set an “obsolescence” date based on the components inside or the averages known to them, but how does the end user know?

Get your subscription to Control Design's print magazine, free to qualified individuals in North America.

People make bets based on performance, use and environmental conditions, how well the maintenance team performs, whether they have a reliability program and whether the PLC is in constant use.

Does this apply to robots? Of course. Anything with a controller and electronics has a lifespan expectancy. Robot risk and dependency would depend much more heavily on maintaining the mechanical units, but, with that in mind, many people default system reliability to mechanical care.

Why? Because it’s easier. It’s touchable and feelable, and expectations are known. Some electrical engineers would argue the bathtub-curve failure rate doesn’t apply to electrical components. How do you track it if you don’t piggyback it on mechanical failure rates?

Product life cycle management (PLM), as defined by Rockwell Automation’s David Hughes, is influenced by people, processes and technologies, as well as the needs of the business. He also ties it to Industry 4.0 and advises that PLM of digital components is not to be siloed in engineering, but requires an organizational dichotomy of thinking.

According to a 2018 Forrester study by Ted Schadler, 21% of C-Suite technologists thought they were done with digital transformation.

If technology is that important and has such benefits, then why do controls engineers have to fight for upgrades?

A manager might walk past the machine and ask, “If the machine is working, why should I update the controls?” Here are some reasons why controls should be updated, even if the machine is working.

• Physical electronics age: Installation deteriorates; copper brittles or corrodes; cards change with heat and moisture. As this aging occurs, safety risks rise. Circuit breakers age out at 30-40 years.

• Technology changes: Chip technology has improved. Processing speeds have improved. Protocols have been updated.

• Safety rules change: The probability of failure significantly increases with time. In layman’s terms, the reliability of safety components cannot be guaranteed after the component has reached the end of its useful life. Safety-integrity-level (SIL) and performance-level (PL) ratings are in jeopardy at 20 years.

• Business needs change: Businesses need to be able to add products, reduce products and move machines. Also, data and Industry 4.0 have added changes to the industrial machine.

• Cybersecurity: Operational technology (OT) now must think about security issues.

There’s a cost to maintain and a cost to support obsolescence. If the same electrician or engineer has been on one machine for 20 years, then that person will be retiring with the obsolete equipment. If the operation is a critical machine, then the question would be: Where does this machine and this process fall in the reliability program?

Wait. What reliability program?

It costs money to update control systems, and traditionally corporations wait until the last minute to address the problem. Then there are increased costs. At this point, upgrades may not increase usability or throughput, so costs come down to guessing when the electrical failure will occur or when the supply chain runs out of obsolete components.

The risk of failure increases exponentially over time. Yet, since Dick Morley built a programmable logic controller (PLC) for General Motors in 1968, the controls industry has insisted on this kind of product life management. Some reasons are poor return on investment, cost of upgrades and lack of technical expertise in-house. Another reason is the lack of visibility to putting increased maintenance to control systems.

Management of systems also fails to document important reliability trends. What parts are changed on the machine? How often? How many times each month does it go down? Production does not care unless it’s lumped into overall equipment efficiency (OEE), which, unless the manufacturing facility has its Oracle or SQL database set up properly to track maintenance jobs and maintenance parts, it’s never obvious how much time or money is spent on maintaining obsolescence.

Control of machinery PLM was put into the hands of operations in the 1990s, when maintenance managers lost control of being able to tell production when downtime was needed.

Automation requires continuous development for business needs. Integrating controls and automation systems with IT and software in a DevOps environment would help with changing upper management’s attitude. Adopting a system mindset and encouraging system management, instead of machine management, would require CTOs to recognize that automation is not a one-and-done install.