Open Process Automation Forum

Open Process Automation Forum

by | Feb 20, 2017 | Automation, News, Operations Management, Process Control, Software, Standards

Open Process Automation and IT/OT Convergence. Thursday, the last day of the ARC Forum, is not always all that well attended. The 2017 edition witnessed two sessions that held the attention of the later departing attendees. These two attracted a reasonably good attendance.

I didn’t do the IT/OT one, but I had great interest in the Open Process Automation Forum (Open DCS?).

This was my 20th ARC Forum. My first Forum featured another open control series of meetings on Thursday morning—The Open Modular Architecture Controller group. That group of engineers and managers sought to specify a PLC based upon the computing standards of the time. The culmination of that effort was a CompactPCI chassis cobbled together by an entrepreneur. It was not picked up. Meanwhile OMAC pivoted when end user companies principally P&G and Nestle moved the focus to packaging machines. The goal became machines that used standard states and HMI in order to reduce training time for operators as they moved from machine to machine.

ExxonMobil appeared at the Forum last year with an idea. It wished to reduce the cost to deploy and eventually upgrade its control systems. It had worked with Lockheed Martin to devise a plan from the avionics industry (FACE).

This session at the Forum updated attendees with progress. It has formed under The Open Group as the Open Process Automation Forum. Although driven by ExxonMobil initially, the goal is to form a broad alliance of owner/operators, end users, systems integrators, and suppliers developing this new automation platform.

Many people at the conference relate this effort to the old OMAC work. They see the end game as a customer trying to drive down the cost of the system. Especially a customer who faces two problems: the immediate problem of upgrading old technology; the long range cost of upgrading technology to newer levels.

Another way to view this initiative is more altruistic in the sense of driving disruptive change in the market for all users using standards.

I am conflicted in trying to understand the dynamics of the situation. As a proponent of standards, I applaud the effort to find ways to implement standards and interoperability. Interoperability has been proven in many industries as a driver for business growth. The idea of decoupling hardware and software holds great promise for future upgrades.

But if, in effect, the customers simply wish to drive automation components and software to commodity level, then I see problems. Such ideas have killed entire industries in the past.

I also look at the old PC technology when there many players developing cards for the PC bus to add on to an “IBM PC.” But over time, technology enabled chip manufacturers to incorporate all those features into the main CPU and the industry returned to basically a single source for a computer.

Predictions? I’m not making any right now. However…

This process is now more than a year old, and yet, the theme of the Forum in Orlando was a plea for participation. There were few other owner/operators. Even though almost all major suppliers have signed on, only two (Schneider Electric and Yokogawa) appear to be active. The leaders have put forth an ambitious timing plan. The group is going to have to build a critical mass of participants quickly.

One more point. There is an age-old tension between an end-user wishing to reduce procurement costs by being able to competitively bid everything. However that means that someone must assemble all the components. On the other hand, end user companies also like partnerships with suppliers for joint development and better service.

By decoupling end user from supplier, something or someone must fill the gap. That would be the system integrator, I guess.

There are many questions.

Without further comment, I’ll leave you with the Open Process Automation Forum’s Vision Statement.

Composed of a broad group of end users, product suppliers, systems integrators, and academics, the Forum will create a technologically appropriate open process automation architecture and specifications along with business guidance for its adoption and use.

  • This will result in a standards-based open, secure, and interoperable process automation architecture and instances thereof that have the following characteristics:
    Easily integrates best-in-class components to provide timely access to leading edge performance
  • Employs an adaptive intrinsic security model
  • Enables the procurement and modular interaction of certified conformant components into systems that are fit-for-purpose for the end users’ needs
  • Is commercially available and applicable to multiple industry sectors
  • Protects suppliers’ Intellectual Property within conformant components
  • Enables portability and preservation of end users’ application software
  • Significantly reduces the difficulty of future replacements and reduces the lifecycle cost of systems
Enterprise Need for Standards for Interoperability

Enterprise Need for Standards for Interoperability

by | Mar 24, 2016 | Automation, Internet of Things, Interoperability, Operations Management

Owner/Operators do see great benefits to standards for system-of-systems interoperability. Getting there is the problem.

Aaron Crews talked about what Emerson is doing along the lines I’ve been discussing. Tim Sowell of Schneider Electric Software hasn’t commented (that’s OK), but I’ve been looking at his blog posts and commenting for a while. He has been addressing some of these issues from another point of view. I’m interested in what the rest of the technology development community is working on.

Let’s take the idea of what various suppliers are working on and raise our point of view to that of an enterprise solutions architect. These professionals are concerned about what individual suppliers are doing, of course, but they also must make all of this work together for the common good.

Up until now, they must depend upon expensive integrators to piece all the parts together. So maybe they find custom ways to tie together Intergraph, SAP, Maximo, Emerson (just to pull a few suppliers out of the air) so that appropriate solutions can be devised for specific problems. And maybe they are still paying high rates for the integration while the integrator hires low cost engineering from India or other countries.

When the owner/operators see their benefits and decide to act, then useful interoperability standards can be written, approved, and implemented in such a way to benefit all parties.

Standards Driving Products

I think back to the early OMAC work of the late 90s. Here a few large end users wanted to drive down the cost of machine controllers that they felt were higher than the value they were getting. They wanted to develop a specification for a generic, commodity PLC. No supplier was interested. (Are we surprised?) In the end the customers didn’t drive enough value proposition to drive a new controller. (I was told behind the scenes that they did succeed in getting the major supplier to drop prices and everything else was forgotten.)

Another OMAC drive for an industry standard was PackML—a markup language for packaging machines. This one was closer to working. It did not try to dictate the inside of the control, but it merely provided an industry standard way of interfacing with the machine. That part was successful. However, two problems ensued. A major consumer products company put it in the spec, but that did not guarantee that purchasing would open up bidding to other suppliers. Smaller control companies hoped that following the spec would level the playing field and allow them to compete against the majors. In the end, nothing much changed—except machine interface did become more standardized from machine to machine greatly aiding training and workforce deployment problems for CPG manufacturers.

These experiences make me pay close attention to the ExxonMobil / Lockheed Martin quest for a “commodity” DCS system. Will this idea work this time? Will there be a standard specification for a commodity DCS?

Owner/Operator Driven Interoperability

I say all that to address the real problem—buy in by owner/operators and end users. if they drive compliance to the standard, then change will happen.

Satish commented again yesterday, “I could see active participation of consultants and vendors than that of the real end users. Being a voluntary activity, my personal reading is standards are more influenced by organizations who expect to reap benefit out of it by investing on them. Adoption of standard could fine tune it better and match it to the real use but it takes much longer! The challenge is : How to ensure end user problems are in the top of the list for developing / updating a standard?”

He is exactly right. The OpenO&M and MIMOSA work that I have been referencing is build upon several ISO standard, but, importantly, has been pushed by several large owner/operators who project immense savings (millions of dollars) by implementing the ecosystem. I have published an executive summary white paper of the project that you can download. A more detailed view is in process.

I like Jake Brodsky’s comment, “I often refer to IoT as ‘SCADA in drag.’ ” Check out his entire comment on yesterday’s post. I’d be most interested in following up on his comment about mistakes SCADA people made and learned from that the IoT people could learn. That would be interesting.

Follow this blog

Get a weekly email of all new posts.