Critical Physical Infrastructure Interoperability Advances

Critical Physical Infrastructure Interoperability Advances

MIMOSA LogoCollaboration works. Engineers and IT architects have been donating time to projects that stand to decrease the time from building large critical physical infrastructure assets to the operate and maintain phase. The resulting system could benefit owner/operators of those assets to the tune of millions of dollars.

Much of the work has been under the radar, but also much has been accomplished. MIMOSA, the “Operations and Maintenance Information Open System Alliance” a 501(c)6 non-profit industry association, focuses on enabling industry solutions leveraging supplier neutral, open standards. The methodology is to establish an interoperable industrial ecosystem for Commercial Off The Shelf (COTS) solutions components provided by major industry suppliers.

As I wrote a few weeks ago, the most amazing thing about MIMOSA, the organization, and the Oil&Gas Interoperability Pilot (OGI Pilot) specifically, is the amount of progress they have made over the past few years. Some of the work has been ongoing for over a decade. Emphases have shifted over time reflecting the needs of the moment and the readiness of technology.

The premise of the work going on is that major productivity gains critical physical infrastructure design, build, operate and maintain depend on transitioning to an interoperable, componentized architecture with shared supplier-neutral industry information models, information and utility services.

Large enterprises are now spending 15x or more of license fees on integration efforts. The standards-based interoperability model will dramatically reduce these direct costs while also improving quality, security and sustainability.

This boils down to the core problem of lack of interoperability between key people, processes and systems.

Here are just some of the accomplishments:

  • Achieved a better strategic alignment with the PCA and Fiatech organizations
  • Built a broader consensus around downstream system architecture demonstrated through OGI Pilot
  • Beginning to expand from its downstream work to working with the Oil & Gas Standards Leadership Council on upstream solutions as well

The long-running OGI Pilot program builds out a test bed and pilots the ecosystem of data standards. The pilot provides for a continuous gap analysis and drove out the need for a standardized data sheet. The pilot started with a process flow diagram (PFD) and worked out the P&ID including most of the schematic for the P&ID schema that are variations of ISO 15926. The next part of the project is to develop all the data sheets that describe all the parts in detail. That’s the reason for the Industry Standard Data Sheet project (ISDD). That will pick up mechanical, electronic, and thermodynamic information. Then the project returns to the PFD to pick streams data.

Thus far, the project has focused on the CAPEX side of the system. Work is now returning to the OPEX (operations and maintenance) side.

This all returns focus to the OpenO&M Initiative to bring testable interoperability for Business Object Document (BOD) architecture from OAGIS.

Everything is built upon real implementation specifications including PRODML (production markup language), B2MML (business to manufacturing markup language), MIMOSA, CCOM-ML (Common conceptual Object Model), ISBM (information service bus model), CIR (common interoperability registry), OPC UA.

 

 

 

Flow Diagram Programming

Flow Diagram Programming

Flow Diagram Programming

Source: Wikipedia

It is interesting, or maybe coincidental, that I had just left the National Instruments user conference about Graphical Programming (among other things) when I downloaded a Robert Scoble podcast interview with the principles of a new company who just launched a flow chart programming tool for high-tech programmers. (I couldn’t find a link for Scoble, but search Scobleizer on iTunes.)

The company has released No Flow JS and many companies had picked it up. A sample of the Flow Diagram Programming accompanies this post.

This brought back all the memories of flow-chart programming from the 90s. The only company still successfully pushing that paradigm to my knowledge is Opto 22. Phoenix Contact picked up the remnants of Think ‘n Do and Steeplechase many years ago. I can remember when the latter two companies thought that everyone would flock to their controllers because it was so much easier and more understandable to program in with flow charts than ladder diagram.

Unfortunately for them, engineers were afraid of the control platform–a PC. I told the CEOs for years that they should stop arguing in their ads about whose real-time operating system was better and concentrate on why engineers should switch from PLCs to the new platform. Meanwhile, Opto 22 found its niche and happily keeps customers happy with its controller and flow-chart programming.

NI uses a paradigm much like function block programming. I have programmed in LabView and recommend it over Ladder. On the other hand, I realize that there remain many thousands of technicians who are quite comfortable in Ladder. But even for those who love Structured Text, perhaps they should take a look at flow chart programming. If it’s coming to mainstream programming, could industrial be far behind?