Close

Installation Labelling Systems

Discussions with our clients regarding the ‚correct‘ or ‚incorrect‘ installation labelling systems are always an interesting part of our projects. Of course, this labelling should consider (at best) all relevant information. It must be uniquely recognisable, it should include the hierarchy structures of the complete installation + information about the maintenance group and the exact localisation of the installation.
It shall also be bijective and the key for all further processes regarding this labelled installation.
These requests are understandable (especially considering historical information) but are they still practical?

First of all, it is to be said that the installation labelling classification originated from the power plant sector and is described in the DIN 6779-1.
The DIN 6779-1 specifies the designation blocks for the clear identification and localisation of technical products, which are used for their labelling in the installation, for their designation in technical documents and for the designation of the technical documents.
The latest publication of this norm was in 1995 and was later replaced by the ISO Norm 16952, which primarily contains specifications regarding the power plant sector.

Back in the days (before the use of data bases) it was absolutely vital to administer a consistent labelling system. An accurate documentation was otherwise not possible. Gathering information regarding which component belonged to which installation and the localisation of this installation was, without a consistent labelling system, not feasible.
So, what is the scenario today?
Well, with the use of modern data bases and a respective hierarchal representation of the installation structure, a question arises:
Is a self-explanatory labelling system still necessary?

Another interesting point is the localisation. If an installation is represented graphically in CAD plans or CAFM / IWMS systems, why should the localisation be encrypted into the labelling of the installation? More about that below.

The power plant labelling classification is usually not applied within the CAFM / IWMS sector. The DIN 276, which categorises the cost groups within the building construction sector, is therefore used.
This cost group is more relevant for most application cases as typical CAFM / IWSM users can identify with the respective categorisation. The DIN is usually extended as not all important installations and components are usually found in it.
The next questions raised – which level should the installation be documented to? On component level or 4, 6 or even 8 hierarchies deeper? This could also vary from installation type or in connection with the maintenance process. How do you deal with a consistent labelling then? Many solutions use in these cases the methods of free entry fields or adding XX to the label. This will become rather tricky when a new hierarchy structure is needed. Then all other components must receive new XX too…

In principle, all this is realisable – even automatised: A label is created automatically based on its hierarchy and maintenance group information. It then becomes interesting when installations are imported from further systems and the labelling overlaps with each other – manual rework is required then.
A strong desire of many users is to have a localisation of the respective installation within the labelling. speedikon© C  enables an automatised labelling containing the building, levels and room numbers (or also name, designation, utilisation designation, etc.). Therefore, we have developed so called fill-in assistants. With these, characterisations are filled in based on further attributes (including further connected objects, and thus also from localisations).
Yet, the practice shows us again and again: this is not particularly sensible: How often are room numbers, hierarchy structures, building designations or even space utilisations changed? …and every time the labelling of the installation is changed too?

Generally speaking, much can be achieved and speedikon© C  is flexible enough to meet any needs – even if they are, data base-orientated not required. This is also represented by the ongoing trend-development: Which barcode or RFID scanner requires the labelling of the installation?
We do not, however, support any possibilities in the projects to use this labelling as an identification attribute for data interfaces, exports, imports, etc.
Of course the system generates a unique ID for every object. This, however, is not a descriptive number (why should it be?). The scanner code is also not linked to the labelling system with the following reason:
The labelling can vary (as read above) due to changes of localisations or hierarchies. The unique identification number should, for whatever reason, never be modified – otherwise the system will be destroyed, particularly regarding the consistent time line.

We received an interesting request in a project not long ago which we had to decline as it was logically not realisable:
The localisation of the installation should have been represented in the CAD and imported along with the installation labelling including the room number. The system then should automatically notice a relocation of an installation.
So, if I have expressed myself in this blog-post correctly, you would understand, that this is logically not realisable!
We later agreed to import the CAD based on a unique ID. The labelling system is generated by the so-called fill-in assistant, to support familiar tasks of the users.
Will these users still be using the labelling system in future when mobile devices and barcodes will take their term? Let´s wait and see!