by Gary Mintchell | Jul 1, 2020 | News, Organizations, Standards
CII and MIMOSA sign Memorandum of Understanding (MOU) to use the Open Industrial Interoperability Ecosystem (OIIE) as the interoperability framework for CII best practices.
I’m a believer based upon long experience that standards and interoperability drive industries (and society) forward. Just look, for example, at standard gauge railroad tracks or standard shipping containers or Internet protocols. I should also note that I worked on the development of the OIIE several years ago, but they got to the point where I could not contribute for a while. As I wrote recently, things are coming together in this effort for interoperable data flow from engineering design through construction to operations & maintenance throughout the lifecycle of a large capital project.
Here is the latest, and very important, news.
CII (The Construction Institute) and MIMOSA announce their collaboration to adopt and progress the standards for an open, vendor neutral digital ecosystem supporting data and systems interoperability in capital projects, operations and maintenance enabling digital transformation of the full asset lifecycle. The MOU establishes the basis for a CII/MIMOSA Joint Working Group to develop best practices for standards based interoperability in capital projects leveraging the organizations combined strengths.
It will develop formal OIIE Use Cases for capital projects based on Industry Functional Requirements developed by CII, starting with those associated with Advanced Work Packaging (AWP). These OIIE Use Cases will be validated in the OIIE Oil and Gas Interoperability (OGI) Pilot before they are published and licensed for use on a world-wide royalty free basis. Once the jointly developed OIIE Use Cases are validated in the pilot, CII and MIMOSA intend to submit them to ISO TC 184/WG 6 for inclusion in future parts of ISO 18101.
The OIIE is an outgrowth of collaboration between multiple industry-level Standards Developing Organizations, where MIMOSA plays a key leadership role and has led the workstreams for digitalization and interoperability in support of asset life-cycle management. The OIIE OGI Pilot includes standard use cases for asset intensive industries, currently featuring an example oil and gas industry process unit.
Active collaboration has begun, by sharing the existing OIIE Use Case Architecture and asset lifecycle management OIIE Use Cases previously developed by MIMOSA and validated in the OIIE OGI Pilot. CII has shared the AWP data requirements that are under development by CII.
Next steps will begin to include CII AWP best practices in applicable, OIIE Use Cases for capital projects, including jointly enhancing existing use cases and the joint development of new ones. CII and MIMOSA encourage interested organizations to join and participate in each association to fully support this important industry-led effort.
Organizations that participate have the potential to benefit in many ways including:
- System of Systems interoperability results in less reliance on expensive, fragile, custom integration between systems, reducing IT costs while increasing agility and sustainability.
- Education and training to a common set of industry practices and standards, provides a more flexible and efficient digital economy work force, benefitting industry and workers alike with reduced loss of knowledge and expertise.
- Investment in future proofed, vendor neutral, interoperable data, enables industry to create, capture, manage and reuse digital information, as a strategic asset throughout the entire physical asset lifecycle, deriving significantly more business value from capital projects.
- Owners identified the opportunity to cut CAPEX spend by 15-20% through better information sharing with improved schedules and productivity due to far less time wasted looking for information, and much more time on tools.
CII, based at The University of Texas at Austin, is a consortium of more than 140 leading owner, engineering- contractor, and supplier firms from both the public and private arenas. These organizations have joined together to enhance the business effectiveness and sustainability of the capital facility life cycle through CII research, related initiatives, and industry alliances.
MIMOSA is a 501 (c) 6 not-for-profit industry trade association dedicated to developing and encouraging the adoption of open, supplier-neutral IT and IM standards enabling physical asset lifecycle management spanning manufacturing, fleet and facilities environments. MIMOSA standards and collaboratively developed specifications enable Digital Twins to be defined and maintained on a supplier-neutral basis, while also using Digital Twins to provide Context for Big Data (IIOT and other sensor-related data) and Analytics.
by Gary Mintchell | Nov 2, 2016 | News, Organizations
This announcement reveals important advances in the cause of suppliers, owner/operators, and standards organizations coming together to support and use interoperability standards. Much progress has been made since the OGI Pilot demonstration in 2009. I have written two white papers on the subject that you can download here.
MIMOSA, which provides information standards for physical asset management, announced Nov. 1, 2016 that SAP has joined the organization to incorporate MIMOSA’s industry standards on SAP Asset Intelligence Network. Alan Johnston, president of MIMOSA said, “I am very pleased to have SAP join MIMOSA and support the Open Industrial Interoperability Ecosystem. This way, we expect that many more of the owner/operators in asset-intensive industry groups will gain business value from SAP Asset Intelligence Network running on the new SAP HANA Cloud Platform when they leverage our open standards.”
MIMOSA provides a broadly used portfolio of industry standards for physical asset management and leads the development of the Open Industrial Interoperability Ecosystem (OIIE), in cooperation with other industry standards associations. Ken Dunn from BP, who is chairman of the MIMOSA board, explained: “The OIIE incorporates a portfolio of international and industry standards which enable sustainable standards-based interoperability. It is designed to dramatically reduce the cost of integration across a heterogeneous information technology environment and to facilitate the Industrial Internet of Things (IIOT). The OIIE is even more important in economically challenging times, as it helps owner/operators reduce cost and complexity, while continuing to sustain critical programs around asset integrity management and operational risk management. SAP’s commitment to these industry standards is a major step forward in their widespread adoption.”
SAP Asset Intelligence Network will provide a global registry of industrial equipment designed to enable collaborative business models. Achim Krueger, VP of Global Solutions for the SAP Extended Supply Chain (which includes Asset Management and HSE), commented, “Being part of this interoperability standards organization will become a key support of SAP Asset Intelligence Network, benefitting our entire ecosystem of manufacturers, engineering suppliers and asset operators. The intent is to enable them to automatically exchange their asset management data and reduce manual steps in the process. This is a great example of how SAP continues to work with the industry to co-innovate new solutions that are important for our customers.”
Ken Evans, head of SAP Global O&G Business Unit, stated, “As our customers digitally transform their global operations, they need greater flexibility in their business and operations technology platforms. We view joining MIMOSA as an important step to support their ability to openly integrate SAP Asset Intelligence Network with their ecosystem of service providers. We are excited to continue our innovations with the O&G industry and to utilize standards to improve overall enterprise process efficiency and access to operational content.”
by Gary Mintchell | 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.
by Gary Mintchell | Feb 27, 2015 | Operations Management, Software, Standards
Looks like there is a debate in the software development community again. This time around node.js
Dave Winer is a pioneer in software development. I used his first blogging platform, Radio Userland, from 2003 until about 2009 when it closed and I moved first to SquareSpace and then to WordPress. Below I point to a discussion about whether the node.js community needs a foundation.
His points work out for manufacturing software development, too. Groups of engineers gather to solve a problem. The problem usually involves opening up to some level of interoperability.
This is a double-edged sword for major suppliers. They’d prefer customers buy all their solutions from them. And, yes, if you control all the technology, you can make communications solider, faster. However, no supplier supplies all the components a customer wants. Then some form of interoperability is required.
Therefore, technologies such as OPC, HART, CIP, and the like. These all solved a problem and advanced the industry.
There are today still more efforts by engineers to write interoperability standards. If these worked, then owner/operators would be able to move data seamlessly, or almost seamlessly, from application to application solving many business problems.
Doing this, however, threatens the lucrative market of high-end consultants whose lock-in of custom code writing and maintenance is a billion-dollar business. Therefore, their efforts to prevent adoption of standards.
Winer nails all this.
I am new to Node but I also have a lot of experience with the dynamics [Eran] Hammer is talking about, in my work with RSS, XML-RPC and SOAP. What he says is right. When you get big companies in the loop, the motives change from what they were when it was just a bunch of ambitious engineers trying to build an open underpinning for the software they’re working on. All of a sudden their strategies start determining which way the standard goes. That often means obfuscating simple technology, because if it’s really simple, they won’t be able to sell expensive consulting contracts.
He was right to single out IBM. That’s their main business. RSS hurt their publishing business because it turned something incomprehensible into something trivial to understand. Who needs to pay $500K per year for a consulting contract to advise them on such transparent technology? They lost business.
IBM, Sun and Microsoft, through the W3C, made SOAP utterly incomprehensible. Why? I assume because they wanted to be able to claim standards-compliance without having to deal with all that messy interop.
As I see it Node was born out of a very simple idea. Here’s this great JavaScript interpreter. Wouldn’t it be great to write server apps in it, in addition to code that runs in the browser? After that, a few libraries came along, that factored out things everyone had to do, almost like device drivers in a way. The filesystem, sending and receiving HTTP requests. Parsing various standard content types. Somehow there didn’t end up being eight different versions of the core functionality. That’s where the greatness of Node comes from. We may look back on this having been the golden age of Node.
