iGeneering

Database centric architecture is proving itself as an effective approach to automation engineering and electrical design complexity.

From what derives this complexity? Well, the process of automation and electrical engineering planning is a process of accumulation of data. In each subsequent step we accumulate more data which has to be represented in the correct way in the final product/document. In my concrete case it all starts with preplanning. Where the crucial part of the work is not only designing the final P&IDs which describe the process itself, but with it already comes a more detailed description of the automation process, like the I/O lists, definition of the symbolic addresses, operational sequences, etc. In the same step  we also define the field devices lists, like the exact types of sensors, actors and other devices to be used.

In the next step we might start a detailed planning of the single electrical cabinet. The planning is based on the preplanning information which already includes all the crucial data about the process to automate. So what are we doing here is adding another layer of information, which is composed of detailed electrical plans, cabinet devices lists, cable lists and other information.

What are we getting now is a stack of data layers one above the other and with relations between them. We are also dealing with a lot of derived data, which is deducted from the primary data and can be created and/or processed automatically. Like the terminal bridges configuration and terminal numbering which can be automatically derived from the electrical design itself.

Now we have to imagine a big system, with dozens of automation cabinets, hundreds or even thousands of devices like sensors, actors, etc. and tens of thousands of terminals, which connect all of this together.

Now we add-on top of that a multitude of concurrent groups of creators and/or users of all of this information. Those can be architects, mechanical engineers, automation engineers, automation programmers, technicians, maintenance staff, project managers, construction contractors and so on. Lets call them project stakeholders.

Any of them can produce new information at any time and in any format. Any of them can also request up-to date information or produce a change/correction to the existing information.

If we take a look to the image below, we can see that the managing of all this information in an environment of complex relations and maintain the ability to deliver up-to-date information in time to all the interested parties and maintain a general overwiev over it can soon become a major challenge.

A solution to all of this can be found embracing a data-centric approach.

That would mean coming to a situation where all project related data is concentrated and managed from one single point. This brings some advantages, like:

• clarity as everybody knows at any time where to get the latest information. Also everybody knows where to deliver the newest information on the development of the project.
• reliability of data and fast discovery of eventual data mismatch as the available information can be cross-checked with the information coming from engineering (sub)contractors or, on later phases, the construction site.
• higher efficiency as we need less coordination between different engineering teams.

As we get to a single-point approach we can soon realise that the usual mix of  CAD designs, Excel tables and PDF documents is maybe not the most effective way to pass the information to the various stakeholders as having the data scattered in different not-related-files we go directly against the principles listed above.

What we need is need a tool which would enable us to contain all of the diverse data in one structured database like file. The database centric architecture of the file, enables us to simply pass all the project-related information within a single file. This implies a significant simplification of the information sharing process between all the related project stakeholders.

Ideally this data-centric file has to contain:

• Diagrams, like P&ID‘s, Sequences of operations  (a kind of workflows)
• Datapoint information in accordance to the applied standards
• Device and cable lists with descriptions, data sheets and ordering information
• Derived information in form of various reports
• Other related data

It should also :

• Maintain relations between different information entities
• Be flexible and give us enough flexibility to be able to adapt to different circumstances and demands which may vary from project to project and even with time on the same project.

Ability to store relations between different information entities is crucial at this point. As those enable us to effectively search for needed information at the given point in time. They also enable all the needed automation for an effective work, like creation of reports, export of data for external elaboration and eventual import of the (elaborated) information.

Any questions, ideas or simply opinions about this article or the Database centric approach in general, are very welcome, so let me know by leaving a comment below. I am also reachable on linkedIn or twitter.