Automation Code Libraries

The paradigm of using a library for automation code has led to a marked improvement in outcomes. It’s also made it easier for engineers to deploy new facilities by helping eliminate most of the debate on physical layer items. These include control modules including graphic elements, and shell equipment modules.

There are natural limitations to using libraries and considerable amounts of energy have been poured into managing custom libraries. It is intensive work to maintain a broad library that captures updates from multiple installations.

Positioning is very important, and companies like Emerson and Rockwell (PCSD in DeltaV, Plant PAX in Rockwell) are ideally positioned to control and maintain a library on behalf of clients. While these are overly complex libraries, they are good enough. To the point where it is very hard to justify a global automation department at a large company to manage and enforce company specific libraries.

Of course you will still hear “It works slightly differently here”. It’s a valid argument on sites because the local automation manager knows the site and the people.

Alignment is really hard and projects are complicated. Hence as a site which is new to a platform, it’s great to have guidance from a global group to help you along. Here, however, the business benefits are lost by doing things “slightly differently” every time.

Libraries tend to be too flexible in response to this “slightly different” framework as a way of staying relevant. An overly flexible library is a cumbersome library.

I think the learning is that libraries can be a cash sink for reinventing the wheel. I also feel like the days of bringing value to your company by managing a custom automation library are behind us.