Anyone who is occupied with the thought nowadays of obtaining a new EDP system for the planning and documentation of industrial plants and units or machinery will find themselves confronted with a variety of different system philosophies.

The following solutions are available in this market today:

1. Document-oriented solution

The method of working from the days of the drawing board were transferred to the computer world with the creation of the first CAD systems in the 1970‘s and 1980‘s. In this case we refer to the document-oriented processing of information. Here the classical methods of mechanical design that had been derived from the world of the production of drawings (such as for P&IDs or circuit diagrams) were taken over very quickly.

All the current CAD solutions such as Elektro CAD, Microstation or Autocad are based on this principle.

The corresponding drawings that could be evaluated later were created by using symbol libraries. This took into consideration the symbol attributes that were displayed in lists or other documents. ECAD systems in particular use these properties so as to generate plans, terminal plans or cable plans. Even today we can be sure that more than 90% of all documentation systems are set up on the basis of this methodology.

Disadvantages:

• Basically speaking, these involve detail tools that can only be used in a very late planning phase due to their architecture.
• It is always necessary to first make the changes in the drawing, since these concepts only function unidirectionally. Thus changes in the database have no effect, but instead tend to create inconsistencies.
• The actual planning process is not supported, since this involves a purely sequential processing of the work flows.
• Data and objects that are to be modeled in the course of the planning phases can easily be change en masse (i.e., in bulk).
• The system landscape is relate to a particular technical field, meaning that either it is not possible at all for the various technical disciplines to work together at an EDP level or else this can only be done through the complicated and tedious exporting and importing of data.

2. Database-oriented solution

Technical database systems that were set up to collect data based on alphanumeric information arose in parallel with the applications described above. For example, when using this method, apparatus or machinery could be described on the basis of its function and subsequently evaluated in lists or data sheet reports. On this basis major EPC’s or owner-operators then developed system landscapes of their own, but which then cost a great deal of money to maintain.

In the field of instrumentation and control planning, CAD systems with ready-made loop drawings (typicals) were linked to the databases by means of placeholders and documentation produced on this basis. This form of application is still very widely used today. But which of us does not cling to his or her beloved Excel spreadsheets or which company does not have a technical database system of some kind in use for the maintenance of object information?

Disadvantages:

• This solution is likewise unidirectional, meaning that it is basically necessary to make any changes in the database. Graphic changes bring about inconsistencies, which leaves a great deal of uncertainty as whether the information is really and truly up to date.
• It is extremely difficult to handle a networking of planning information across technical disciplines, since the setting up of fixed database relations is faced by the obstacle of the various planning and documentation methods used by customers.
• Database-oriented solutions only offer a documentation function to a limited extent. It is thus very difficult to envisage the complete production of P&ID drawings or electrical engineering documentation from an engineering database, since no 100% standard exists as of today.

3. Object-oriented solution

The object-oriented way of thinking has been known for a while now. Thus, for example, innotec was able to collect the first valuable experience back in the early 1990’s that has been developed as of today into a fully thought-out and future-oriented solution model.

Basically, the idea of objects is based on the question of reality. The basis of our considerations was the uniform and generally applicable description of a component that actually exists, such as a pump, and the associated subsequent illustration of it graphically, true to life. For example, a pump thus has many aspects that when viewed together produce the overall image PUMP. The various technical disciplines bring their own component view into the overall view. In this way a uniform component model covering all the fields is built up in the course of the planning phases. Sub-object structures thus make it possible to have a real illustration of the structure. The depth of the object model can be determined by the user himself. The graphic character of an object (for example, in a P&ID or a loop) and the alphanumeric character within the database form a common unit / object.

Advantages:

• Potentials for rationalization that had barely been conceivable before can now be set free by constructing power objects across technical disciplines.
• The object technology used makes it possible for the user to navigate from one object to any other object by right-clicking and there obtain further information.
• The bidirectional linking of graphics and database prevents any inconsistencies arising in the course of the project.
• Consistent data between the technical disciplines makes it possible to the amount of time required for projects and thus also hugely improve quality.
• Modules can be standardized without being specific to any one maker, saved as a company standard and reused later
• Owner-operators are thus put in a situation where they can set up uniform and all-embracing plant information system and be able to get the required information anywhere and at any time.