While at the Microsoft Manufacturing Operations Forum, I had the opportunity to chat with Mike Brooks of Chevron. He has many great views on technology, architecture and most importantly business and people processes. I see from an article on ControlGlobal, that he is doing a presentation on mature service orientated architectures (SOA) that aligns nicely with OPC UA.
The article states: “Brooks advocated collaborative work processes enabled by, but separated from IT underpinnings; secured data within primary systems, but easy, seamless data access and sharing for secondary users; and isolated implementation and vendor packages.” It goes on to say: “To create these building blocks, Brooks sees standards coming to the fore. “We like to use business standards because in the long run we will get lower cost of ownership, interoperability and agility,” he explained. “We need interoperable standards. That’s the end game. That’s the implementation standard. In the open O&M initiative, we make sure the bodies work together. What I’ve been encouraging is for all other companies to get behind this and use this—combining maintenance systems with operations.”
Hmm. Service based system. Secure, seamless data access. Separated from IT underpinnings. Interoperable standards. Can you spell OPC UA? (Actually the Open O&M initiative he mentions uses OPC, that’s the O part). So how does OPC UA stack up with other service orientated architectures? There is a post on the OPC Exchange blog that deals with a similar idea. There were several questions I found on various SOA sites that help determine whether or not an implementation is truly SOA. I thought I repost them here:
1. Are the services a true representation of the core behaviors found in your key enterprise systems, as well as new services required to provide other critical behaviors?
The important word here is ‘enterprise’. OPC UA covers real-time, historical and event based data regardless of its source. OPC UA also provides for security, redundancy, communication robustness and a comprehensive and extensible information model.
2. Have those services been abstracted for most foreseeable uses?
The base services sets are highly abstracted, with Functional specifications that provide implementations commonly used by OPC today.
3. Are the services combinable into composites, and are those composites well defined?
The services sets are broken down into well defined, combinable composites that cover server management, address space, data management and subscriptions.
4. Is there a plan for governance and security, managing the use the services?
The Profiles specification and the OPC Certification process is a clearly defined and measurable process
5. Are both the information and services abstract-able to an orchestration/process layer for configuration-oriented agility of most of the IT assets?
The services sets and information model are abstracted for agility and flexibility.
6. Is your information/data managed in such a way that you're loosely coupled from the underlying physical schemas?
Being loosely coupled from the underlying physical schema has always been the key feature of OPC. OPC UA follows the same principle.
It seems to me that OPC UA is well on its way up the SOA maturity chain. Who knows maybe this time next year Mike Brooks will be presenting that they have achieved the ‘dream of technology’ with OPC UA :)