Die Diskussion über „richtige“ und „falsche“ Anlagenkennzeichnungssysteme ist in vielen Kundenprojekten immer wieder interessant. Diese Kennzeichen sollen im CAFM System selbstverständlich alle Anlagen eindeutig kennzeichnen, alles beinhalten, sprechend sein, die Hierarchiestruktur der Gesamtanlage, das Gewerk und am besten auch gleich die Verortung der Anlage anzeigen. Dann muss dieses Kennzeichen natürlich eineindeutig sein und es soll auch gleichzeitig der Schlüssel für jegliche weitere Arbeit mit der Anlage sein.
Diese Wünsche sind alle gut zu verstehen – vor allem aus der Historie heraus – aber sind sie heute überhaupt noch sinnvoll?
Erst einmal sei gesagt, dass die Anlagenkennzeichungssystematik ursprünglich aus dem Kraftwerksbereich kam und dann in der DIN 6779-1 beschrieben wurde. Die DIN6779-1 beschreibt die „Grundlagen und Regeln zur Kennzeichnungssystematik und für den Aufbau und Inhalt von Kennzeichnungsblöcken für funktions- und ortsbezogene Kennzeichnung von technischen Produkten“. Letztmalig erschien diese Norm 1995, später wurde sie von der ISO Norm 16952 ersetzt, die wiederum vor allem Festlegungen für den Kraftwerksbereich beinhaltet.
Damals – vor der generellen Nutzung von Datenbanken – war das einheitliche Kennzeichnungssystem unumgänglich, da ansonsten eine wirklich gute Dokumentation nicht machbar war, denn welches Bauteil hängt denn unter welchem Bauteil und wo sind die Anlagen verortet? Aber wie sieht das heute aus? Mit der Nutzung von Datenbanken und einer entsprechend hierarchischen Abbildung der Anlagenstruktur, stellt sich die Frage, ob eine durchgängige Kennzeichnungssystematik so abgebildet werden muss.
Bei der Verortung wird es ebenfalls spannend: wenn man die Anlagen in CAD-Plänen bzw. im CAFM System grafisch abgebildet hat, wofür verschlüsselt man den Ort im Kennzeichen der Anlage? Dazu unten mehr.
Da die Kraftwerkskennzeichnungen normalerweise im CAFM für die meisten Anwender nicht relevant sind, wird für die Nomenklatur der Anlagen oft die DIN 276 herangezogen, die wiederum die Kostengruppen im Hochbau gliedert. Diese Kostengruppen sind für die meisten Anwendungsfälle wenigstens soweit relevant, als dass sich die typischen CAFM Anwender etwas unter den Kategorien vorstellen können. Diese DIN wird dann oft noch um spezifische Anlagen bzw. Bauteile ergänzt, da sich in den Kostengruppen nicht unbedingt alle wichtigen Anlagen und Bauteile finden lassen. Als nächstes stellt sich oft die Frage, wie weit hinunter man die Anlagen dokumentieren sollte – auf Bauteilebene oder eben 4, 6 oder 8 Hierarchien tiefer? Vielleicht ändert sich das auch von Anlage zu Anlage bzw. in Verbindung mit dem Instandhaltungsprozess auf der Anlage – wie geht man dann damit in einem einheitlichen Schlüssel um? Viele Lösungen sehen dann Freifelder oder entsprechend viele XX vor, um so etwas abzubilden. Schwierig wird so eine Vorgehensweise aber dann, wenn man zu einem späteren Zeitpunkt eine neue Anlagenhierarchiestufe benötigt, jetzt müssten ja alle anderen Bauteile neue XX bekommen…
Grundsätzlich ist das alles abbildbar – auch automatisiert: wenn also automatisch aufgrund von Gewerken und Hierarchien, etc. Schlüssel erzeugt werden sollen. Interessant wird es aber dann, wenn Anlagen aus mehreren Systeme zusammengefügt werden sollen und sich die AKS überschneiden – dann ist händische Nacharbeit gefragt.
Verortung der Anlage im Schlüssel: dies ist immer wieder Wunsch vieler Anwender. Klar kann das System speedikon C automatisch auch die Gebäude, Ebenen und Raumnummer (oder auch Name, Bezeichnung, Nutzungsbezeichnung, etc.) im AKS verschlüsseln. Dafür haben wir sogenannte Ausfüllhilfen, die Attribute aufgrund von anderen Merkmalen (auch von anderen, verbundenen Objekten – und somit auch von Standortbezügen) ausfüllen. Aber in der Praxis zeigt sich immer wieder: besonders sinnvoll ist das nur bedingt: Wie oft werden Raumnummern, Hierarchiestrukturen, Gebäudebezeichnungen oder gar Raumnutzungen geändert – und jedes Mal ändert sich der Schlüssel der Anlage?…?
Grundsätzlich kann man viel erreichen und speedikon C ist flexibel genug, diese Anforderungen zu erfüllen – auch wenn sie Datenbank-technisch heute nicht mehr unbedingt notwendig sind und sich der Trend davon wegbewegt: welcher Barcode- oder RfID Scanner kümmert sich denn um das AKS einer Anlage? Aber was wir in jedem Projekt ablehnen ist die Nutzung dieses Schlüssels als Identifikationsmerkmal für Schnittstellen, Export, Import, etc. Das System hat selbstverständlich eine eindeutige ID für jedes Objekt, die nicht sprechend ist (warum auch?) und der Scanner-Code hat mit dem AKS auch nichts zu tun. Das hat folgenden Grund:
Wie oben gesehen kann sich der Schlüssel gemäß AKS ändern – zum Beispiel wenn sich Umgebungen oder Hierarchien ändern aber das eindeutige Identifikationsmerkmal darf sich nie ändern, da man sonst das System zerstört – vor allem auch mit Hinblick auf die durchgängige Zeitschiene. Und Abgleiche müssen immer auf einem eindeutigen Identifikationsmerkmal stattfinden. Die beste Anforderung, die logisch nicht abbildbar ist, haben wir vor einiger Zeit in einem Projekt ablehnen müssen: Die Verortung einer Anlage soll führend im CAD stattfinden und der Anlagenkennzeichnungsschlüssel wird aus der CAD übernommen und enthält selbstverständlich auch die Raumnummer. Und natürlich soll das System erkennen, dass eine Anlage in einen anderen Raum umgezogen wurde. Falls ich mich in diesem Blog verständlich ausgedrückt habe, verstehen Sie, warum das leider von der Logik her gar nicht gehen wird.
Wir haben uns dann darauf geeinigt, dass der Import aus der CAD aufgrund einer eindeutigen ID basiert und der AKS „nur“ über die sogenannte Ausfüllhilfe erzeugt wird, um die gewohnte Arbeit der Mitarbeiter zu unterstützen. Ob diese Mitarbeiter für immer das AKS verwenden werden, sei einmal dahingestellt, wenn zukünftig mit mobilen Geräten und Barcodes gearbeitet wird….