Innovation on the DCS Object Model

This audio was created using Microsoft Azure Speech Services

The object model is a familiar term for those who know the DCS. Objects are the cornerstone of any DCS and many market-players speak about objects. But do you sometimes think that a “cornerstone” often goes untouched or unturned under the guise of “if it’s not broken, don’t fix it?”

I believe this philosophy has, in the past, applied to the DCS object model. This phrase means that in the absence of any real problem, changing something would not deliver an effective improvement and would indeed waste your, and other people’s, time.

So the question becomes: if an object is not broken, should we bother improving it?

I believe the answer is yes.

How do we improve the object model?

The first thing to remember is that today’s market is demanding innovation on the DCS. Indeed, industry analyst ARC points to the same future it its 2012 report: Collaborative Process Automation Systems 2.0. This report goes on to say that DCS innovation is not constrained by technology, and the needs being identified can be met – with a little innovation.

So how did we innovate on the object model?

With an open and modular object we can take it much further than with a traditional system. Just like in real life, a open and modular object means it is possible to attach any kind of information to an object in the system. Information like operating manuals, settings, historical data, maintenance videos and so on are all pieces of information that are attached to process objects – and with this open and modular foundation you can navigate through the system straight to them.

Straight away this improves operational efficiency – operators are led right to the root cause of any issue, and can get the system back up and running as quickly as possible. 

Know where to find your process information

In many cases, this information – like the operating manuals, settings, historical data, maintenance information and so on – is all over the place. In store cupboards, backed up in various places, and even inside the brains of your operations and maintenance personnel.

Storing information in your operators’ brains could be problematic for a few reasons:

What if your operator is sick, or injured, or busy with something else when you face some kind of equipment issue? How will you find the information you need?

What about when your senior operator retires? How will your new recruits (who are great, but not up to speed yet) know about the history of the process and the modifications that have been made over the years?

What if sometime in the future you want to change your process or even add something completely new? You will have new information about your process. What do you do with it?

How do you close this knowledge gap?

By simply adding all process information to the object template.

Link with other objects

With an open and modular object model you also create links between all objects (and the information related to those objects) that collaborate to achieve a common purpose. You then navigate through the system using a series of hyperlinks to find any document stored in a content repository. You can even go to an external website. These are the “facets” of the object.

Extend your objects

A virtual object is also extendable. So you are not restricting the future of your plant simply because you may not have thought about all your possible future requirements.

Choose your own options

You also have the option to choose which “facets” you really need for a particular instance of an object. Since only those facets which you want are downloaded, your system consumes less memory which means you have an optimized architecture which is more efficient and cost effective.