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.


Tags: , ,



    11 years ago

    1:- There must be an option of recalling the best operation.
    For example :- in thermal power plant ( CPP ) load varies as per requirement, all operator performs the same operation but quite differently. DCS must store that particular type of operation (As designed by Engg. ), compare all that and suggest the best sequence of operation, that is, abstract of all and show that in a “pop up”.
    for example :- if load suddenly dropped by 10 MW, drum level & steam Pressure start increasing rapidly for maintaining that operator reduces the feed water flow also may reduce coal flow….. By comparing all such case system should suggest the best operation.
    2 :- For making display friendly, display parameters must be lesser.
    for example :- if i have to operate boiler, i need to maintain drum level, pressure, temperature & flow. for that i need to operate FANs, & PUMPs etc. ……. for making page lighter, there should be a feature of “pop up display ” in DCS. for example, if i hold the cursor on a fan motor for 1 second a pop up page will appear automatically which will show the parameters related to that particular motor ( temperature, vibration etc).
    note :- holding time & pop up display location must be configurable.

    • Michel Fontvieille

      11 years ago

      Good feedback
      1- Very nice feature indeed. We put in our PlantStruxure PES list of requirements.
      2- This is depending on the way you configure your template. In the design object approach of PlantStruxure PES the supervision facet can be set to the user defined set of parameters enabling the “just enough” if needed. Again it is a good way of designing your application.

  • Michel Fontvieille

    11 years ago

    Thanks for the feedback
    1- Very good suggestion indeed. We put in our PlantStruxure PES list of requirements
    2- This is part of the PlantStruxure PES object model approach features.
    You can define the setup of parameters in the supervision facet, enabling to display the “just enough” data. Good way of operating!

Comments are closed.