Back then, Windows relied on a series of dynamic linking libraries (DLLs) that make development of reusable content like printer and other device drivers much easier to do. In the 1980s, Microsoft developed ways to use object-oriented code and produced a specification it called OLE—object linking and embedding. This made it possible to link a spreadsheet cell to a word processing table cell to an interactive graph to a presentation slide…well, you get the idea.
A group of vendors and some end users in the process automation market space thought OLE was just the ticket to fix the huge problems with connecting multiple kinds of software from multiple vendors. They produced a sort of ad hoc version of the OLE specification they called OLE for Process Control, which became OPC.
Even as the original OPC standard was developed, two standards groups from ISA and several groups around the manufacturing industries began talking about developing a higher level language to be able to describe manufacturing processes.
The first of these was the ISA’s S88 Batch Manufacturing Standard, which was followed by the S95 Manufacturing Standard. Other groups, such as Mimosa, OAGIS and others, have contributed to and made parallel contributions to this process.
In recent years, the OPC standard has grown into the standard interchange format in process automation, while the use of XML (extensible markup language) has grown as a parallel methodology.
Indeed, OPC is no longer an acronym and the technology is simply known as “OPC,” and applies to more than just process control. The WBF and the ISA88 and ISA95 standards organizations have been instrumental in developing the special-purpose variant of XML called B2MML, or “Batch to Manufacturing Markup Language” to use in conjunction with OPC and the other data interchange languages.
OPC has very little connection any longer with the original OLE standard Microsoft created. Recently the OPC Foundation released OPC-UA, designed to be a “universal architecture” for process data interchange.
OPC-UA can be implemented with Java, Microsoft .NET or C, eliminating the need to use a Microsoft Windows-based platform of earlier OPC versions. UA combines the functionality of the existing OPC interfaces with new technologies such as XML and Web services to deliver higher level MES and ERP support.
So what does all this three letter alphabet soup mean? The Holy Grail of process data interchange is to be able to use software that can be made up of existing building blocks, like a Lego set, so that nobody ever has to write dedicated custom code to do any project or do any interconnection between software packages or applications.
According to many experts, the various projects like OPC UA, B2MML, MIMOSA, OAGIS and the various versions of XML are getting closer to that point. Add to this movement the drive at the international level under the aegis of the IEC to do the same for programming software platforms for programmable controllers, and we’re getting close to having modular object building blocks for building the appliations that we need. And we can get on with the jobs we need to be doing: improving the efficiency, productivity and capability of our process manufacturing plants.
Software applications like building blocks…that’s what we see in the future of control.
In the bad old days, we had no way to connect different pieces of hardware, software and operating systems. We called that “islands of automation” and moaned a lot about the expense of interconnecting devices and systems. The good news was that Windows became the dominant operating system for both the commercial world and for
industrial automation, and as it did so, things became easier and easier to interconnect.
Back then, Windows relied on a series of dynamic linking libraries (DLLs) that make development of reusable content like printer and other device drivers much easier to do. In the 1980s, Microsoft developed ways to use object-oriented code and produced a specification it called OLE—object linking and embedding. This made it possible to link a spreadsheet cell to a word processing table cell to an interactive graph to a presentation slide…well, you get the idea.
A group of vendors and some end users in the process automation market space thought OLE was just the ticket to fix the huge problems with connecting multiple kinds of software from multiple vendors. They produced a sort of ad hoc version of the OLE specification they called OLE for Process Control, which became OPC.
Even as the original OPC standard was developed, two standards groups from ISA and several groups around the manufacturing industries began talking about developing a higher level language to be able to describe manufacturing processes.
The first of these was the ISA’s S88 Batch Manufacturing Standard, which was followed by the S95 Manufacturing Standard. Other groups, such as Mimosa, OAGIS and others, have contributed to and made parallel contributions to this process.
In recent years, the OPC standard has grown into the standard interchange format in process automation, while the use of XML (extensible markup language) has grown as a parallel methodology.
Indeed, OPC is no longer an acronym and the technology is simply known as “OPC,” and applies to more than just process control. The WBF and the ISA88 and ISA95 standards organizations have been instrumental in developing the special-purpose variant of XML called B2MML, or “Batch to Manufacturing Markup Language” to use in conjunction with OPC and the other data interchange languages.
OPC has very little connection any longer with the original OLE standard Microsoft created. Recently the OPC Foundation released OPC-UA, designed to be a “universal architecture” for process data interchange.
OPC-UA can be implemented with Java, Microsoft .NET or C, eliminating the need to use a Microsoft Windows-based platform of earlier OPC versions. UA combines the functionality of the existing OPC interfaces with new technologies such as XML and Web services to deliver higher level MES and ERP support.
So what does all this three letter alphabet soup mean? The Holy Grail of process data interchange is to be able to use software that can be made up of existing building blocks, like a Lego set, so that nobody ever has to write dedicated custom code to do any project or do any interconnection between software packages or applications.
According to many experts, the various projects like OPC UA, B2MML, MIMOSA, OAGIS and the various versions of XML are getting closer to that point. Add to this movement the drive at the international level under the aegis of the IEC to do the same for programming software platforms for programmable controllers, and we’re getting close to having modular object building blocks for building the appliations that we need. And we can get on with the jobs we need to be doing: improving the efficiency, productivity and capability of our process manufacturing plants.
Software applications like building blocks…that’s what we see in the future of control.
