Monday, 1 November 2010

Instant SCADA

SCADA product manufacturers such as Allen-Bradley, Siemens, Honeywell etc. each try to distinguish themselves in the market place with their own proprietry protocols and extensions to industry standards. The benefits of connecting disparate products together have given them incentive to join together and standardise data collection and HMI protocols. These standards were based on the middleware systems available at the time. In my opinion, the increasingly popluar Extensible Messaging and Presence Protocol (XMPP) should be the basis fo the next dominant internet middleware and hence the next technology for connecting disparate SCADA systems. This post discusses some history of middleware in SCADA and how I came to believe that XMPP should be next.

Microsoft OLE -> Microsoft DCOM -> OPC

The OPC foundation is a collaboration of industry partners and is the steward of the Object Linking and Embedding (OLE) for Process Control (OPC). The purpose of the original OPC spec was to provide a standard method of connecting SCADA equipment to personal computers running the Windows operating system. OLE and COM were the Windows way of making re-usable, object oriented components that could be joined together to make applications. These components (a COM object) often had visual representations and could be programmatically glued together to make more complex applicaitons. DCOM or Distributed COM is the way of bundling up the state of the COM object and transferring it across a network. In OPC, the state of a process component is bundled into DCOM representation and the COM object is transmitted to a Windows machine or SCADA equipment. OPC leveraged off a popular technology at the time of it's inception.

HTTP -> SOAP -> OPC Unified Architecture

Next is OPC Unified Architecture (OPC UA). In people's day to day lives, the importance of the PC for storing and processing data is now surpassed by the internet. The OPC Unified Architecture (OPC UA) brings process automation into the internet age by being built upon standard internet technologies. The internet is not a homogenous environment like Windows so a prioprietary microsoft only technology is not adequate. OPC UA has thrown out COM an DCOM and replaced it with Simple Object Access Protocol (SOAP). SOAP is the Microsoft sponsored, open successor to DCOM. It is based on the Extensible Markup Language (XML) which is not easy to implement on embedded systems, so OPC UA also has a parallel binary protocol.

Human eyeballs -> Middleware -> SCADA

One obvious trend is that the previous incarnations of OPC were based on Microsoft sponsored technologies, but the Internet has levelled the playing field and Microsoft tech is no longer a pre-requisite for its adoption. The trend that this taxonomy proves is technology originally designed for data dissemination to humans has become the basis for system to system middleware. SCADA is an application of middleware and the trends in middleware become the trends in SCADA.

The current trend in middleware is messaging. The reason why there is a shift from REST protocols, like SOAP, to message based ones is the peer to peer architecture. Peer to peer architectures decrease latency and messaging overhead when compared to client server based architectures. Decreasing latency makes processing faster, important for fast paced processes such as stock trading. Decreasing overhead is important for power consumption.

XMPP was previously known as the Jabber protocol and designed to be an alternative to proprietary systems such as ICQ, MSN and Yahoo. It is an open IETF standard protocol for instant messaging. Facebook chat,  Google talk and Google Wave are all based on it.  Why I think XMPP will become the next dominant middleware instead of other messaging protocols such as AMQP or ZeroMQ is the same reason why SOAP and not CORBA, JMI or RMI was chosen for OPC UA. Education and resources. Developer education in writing dynamic web applications was easily transferable to SOAP and infrastructure that serves web pages also serve SOAP remote procedure calls. For XMPP,  chatting teaches you the concepts of messaging and XMPP software is proliferating and maturing as more and more people instant message rather than email.

No comments: