Erstellung Bauteilschlüssel / AKS Anlagenkennzeichenschlüssel

[antsche]

Hi Forum,

wie geht ihr denn mit geforderten Bauteilschlüsseln / Anlagenkennzeichenschlüsseln in Archicad um?
Ich gebe mal ein Beispiel wie das in einem Projekt gefordert wird:

Ergebnis soll also sein:

341_STB_OBT_240
Kostengruppe - Material - Identifikator - Maße.

Nun wäre vermutlich der Weg über eine berechnete Eigenschaft die das ganze verkettet. Das Problem daran ist jedoch das für jede dieser Eigenschaften ein Kürzel stehen muss. 
D.h 
Material Stahlbeton --> STB usw.
Es muss auch im IFC der normale Wert der Eigenschaft ausgeben werden. Also Stahlbeton.

Das Nummerierungstool funktioniert hier natürlich nur bedingt. Und das nachführen bei Änderungen ist ein unglaublicher Aufwand schon in einem kleineren Projekt. 
Hat hier jemand einen besseren Weg / Workflow? Ich habe gehört, das Dynamo eine gute Möglichkeit für so etwas ist weil man eben auch die "Übersetzungslisten" für die jeweiligen Kürzel anbinden kann. Nun ist das aber keine Lösung für AC. 

Gibt es hierfür auch eine Archicad Lösung? Python?

Wie stellt ihr das so an? 

[Stefan L_]

Ja, goßes Autsch'n!  - der erste Impuls ist immer "wegverhandeln"...

Die Kostengruppen werden bei mehrschichtigen Elementen besonders lustig, innerhalb von AC ist das nicht zu erreichen.

Solltest Du aber nur "einkostengruppige" Elemente haben, kann man das - je nach Modell-Schläue - über Eigenschaften regeln.

Wenn da was fehlt, muss man ggf. weitere anlegen und über Auswertungen bzw. Auswahl im 3D-Fenster prüfen/füllen.

---

@antsche  schrieb:

Das Problem daran ist jedoch das für jede dieser Eigenschaften ein Kürzel stehen muss. D.h Material Stahlbeton --> STB usw.

---

Das kann weitestgehend eine Eigenschaft berechnen.

Einkomponentige Elemente sind einfach; "WENN Baustoff = Stahlbeton DANN Kürzel = STB".

Bei mehrschichtigen/komplexen Elementen kann das Kürzel (und andere Infos!) schon im Namen des Mehrschicht-Aufbaus/Profils stecken. Die kann man ja munter umbenennnen...

[jonasm]

Ach schön, eine AIA die von einem Revit Nutzer geschrieben wurde 🙂

Das mit den Kostengruppen wird bei mehrschichtigen Bauteilen ein Problem. Eine Außenwand, womöglich mit innerer Bekleidung hat dann ja schon drei Kostengruppen in sich. Das ist nur bedingt sinnvoll umsetzbar. Wir hatten da in der Vergangenheit die Lösung, das die Wand dann einfach einer übergeordneten Kostengruppe zugeordnet wird, in diesem Fall nur 340. Ich habe das mal für ein Projekt als berechnete Eigenschaft gebaut, ist doch recht kompliziert. Generell waren hier die Logischen Filter Lage, Tragend und die Klassifizierung. Also nach dem Schema Wenn Innen und Tragend UND Wand, dann 330. Wird eine Lange Liste, aber funktioniert schon einigermaßen.

Abgesehen davon, ist der schnellste Weg für Wände/Decken/Stützen/Träger der Name des mehrschichtigen Bauteils / Profils. Wenn du tatsächlich den ausgeschriebenen und den Kurzen Typ brauchst, kannst du deine mehrschichtigen Bauteile/Profile so benennen:

"TragendeInnenwände_Stahlbeton_Ortbeton_240#341_STB_OBT_240"

Dann in einer berechneten Eigenschaft mit SPLITRIGHT und SPLITLEFT eine Eigenschaft die nur noch alles Rechts/Links des Trennzeichens "#" ausliest, also "TragendeInnenwände_Stahlbeton_Ortbeton_240" und  "341_STB_OBT_240". Diese Eigenschaften kannst du dann im IFC Übersetzer an die gewünschte Stelle mappen.

[antsche]

Die mehrschichtigen Bauteile gibt es nur für Trockenbau / Installationswände und Fußbodenaufbauten. Alles andere ist in einzelnen Schichten modelliert ab 5cm Schichtdicke. Vorgabe. 
Geht. Mit Umwegen, Mehrfachöffnungen usw. Das ist aber ein anderes Thema. 
Mir geht es wirklich um die Erstellung des Schlüssels selbst.

Ich habe es bisher teilweise gelöst bekommen indem ich Berechnete Eigenschaften für die Kürzel erstelle mit IF Formeln. Und diese dann verkette. Das funktioniert mit der Ausnahme des Materials relativ gut. Und den Schlüssel lasse ich dann über Python zusammenbauen und in die ID schreiben, da diese ja nicht als berechnete Eigenschaft verwendet werden kann oder gemapt. 

Das Problem ist allerdings: ändert sich so eine "Liste" muss man das in der Eigenschaft nachführen. Und in Dynamo können Excel-Listen verknüpft werden. Gibt es so eine Funktion auch für Python?

[antsche]

Wegverhandeln wäre schön. Öffentliche Hand. Große Beratungsfirmen. Schwierig. 
Und dieser Schlüssel scheint noch relativ "einfach". Ich habe gestern in einem Vortrag von einem anderen BIM Projekt in Karlsruhe. Das hat noch eine ganz andere Dimension. 

Hier werden Anlagenkennzeichenschlüssel gefordert die noch viel mehr Eigenschaften verbinden. 
Der Schlüssel ist aus 15 Merkmalen zusammengesetzt. 

Hier wurde dafür eben Dynamo verwendet. 

So also die Anforderungen sind da und leider auch nicht nur in einem Projekt. Da sie scheinbar auch erfüllt werden können wird sich das vermutlich weiter etablieren. 
Nun ist daher die Frage was man hierzu in Archicad machen kann.

[Stefan L_]

Der Schlüssel selbst ist einfach. (Schlimm wäre, wenn z.B. die Stützen noch nach irgendeinem Theoretiker-Schema durchnummeriert sein müssten...)

Und wenn Ihr eh alles einschichtig modelliert habt kriegt man 'das' auch in AC hin.

'Das' bedeutet, dass man innerhalb AC aus den vorliegenden/verlangten Infos den Schlüssel zusammenbauen kann.

In die (von mir in diesem Kontext geschmähte) Element-ID kriegt man den Schlüssel nicht (automatisch/dynamisch), aber muss das denn sein?

Im IFC sollte das über ein Mapping zu lösen sein.

Mein Ansatz wäre:

- einschichtige Mehrschicht-Aufbauten mit klugen Namen für Wände/Decken

- wahrscheinlich lieber eine Eigenschaft für Stützen- oder Trägerprofile "STB 200 x 400", sonst 'komplexe' Profile

- berechnete Eigenschaften, die die verfügbaren Schnipsel verschiedener Werkzeuge in sich versammeln

- eine berechnete Eigenschaft, die die Schnipsel zusammenfügt

Ortbeton/Fertigteil? Muss man wissen und den passenden Wert vergeben - klar.

Kostengruppen? Da hatte ich mir auch mal eine (Halb)-Automatik gebaut - naja... Siehe unten - fragiler ProofOfConcept

Wenn 'die Dynamik raus ist', also gegen Ende LP5, tut man sich mit der händischen Vergabe wohl leichter.

Auswertungen helfen. Wer hat noch nicht, wer braucht noch was...

Grafische Überschreibungen helfen. Wer ist blass, wer rot, wer grün...

Unten:

 

 

[Frank Beister]

Wenn der Schlüssel wirklich so stumpf und starr zusammengebaut wird, würde ich das erst im Übersetzer machen. Nicht schon in einer berechneten Eigenschaft. Hirnlose Redundanz würde ich immer ganz ans Ende des Prozesses/Algorithmus schieben.

Ich würde mir ein Eigenschaftenset machen, wo alle Informationen für den Schlüssel per Berechnung auf "Form" gebracht werden. Das dann im Übersetzer verketten. Lässt sich auch per IFC-Manager oder im Elementdialog per IFC-Eigenschaft live ansehen.

Die Klassifizierung würde ich als eigenes Klassifizierungssystem, nicht als Eigenschaft zusätzlich an den Bauteilen mit pflegen.

Schade, wenn Bauherrn so groß oder so starr sind, dass man mit ihnen nicht die Sinnhaftigkeit besprechen kann. Das verbrennt viel von BIM-Bereitschaft. Da ist oft wenig von der ach so beschworenen Technologieoffenheit. Wir fokussieren bei unseren Anforderungen nur auf das Ziel, nicht auf den Weg. Diese Schlüsselgenerierung macht in jeder halbwegs guten Software das Zielprogramm selbst und müsste nicht geliefert werden.

BTW: Respekt, wenn ihr alles so "einzeln" modelliert. @GRAPHISOFT: Hier ist und bleibt eine fundamentale Baustelle!

[antsche]

Also den Schlüssel selbst zusammenzubauen ist garnicht das eigentliche Problem. Das funktioniert wie von euch beiden beschrieben über das Mapping oder eben eine berechnete Eigenschaft. Hier gibt es also Wege.
Das Problem ist, dass für jede Eigenschaft eine Abkürzung gefordert ist, die dann wieder im Bauteilschlüssel gefordert wird.

Tragende Innenwände --> wird zu --> 341
+
Stahlbeton ( Liste Material nach Ökobaudat ....) --> wird zu --> STB
+
Ortbeton ( Liste Identifikator mit Kreuzungsschema welche Elemente welchen Wertebereich enthalten dürfen) --> wird zu --> OTB
+
Maße ( für jeden Elementtyp eine eigene berechnete Eigenschaft ) um die richtigen Parameter so oder ähnlich darzustellen --> 250x500

Hier übrigens für alle die mit so etwas arbeiten --> Vorsicht --> Der Schlüssel ist ein einzelnes Attribut im LOIN. Da kann man sich dann mit dem Bauherr über die Richtigkeit von verketteten Attributen unterhalten. Und Mehraufwand oder nicht. Wenn man dann noch freie Attribute im AIA stehen hat kann man da im nachhinein noch richtig viel reinpacken.

So nun zu den einzelnen Berechneten Eigenschaften.

Kostengruppe
Tragende Innenwände --> zu ner Kostengruppe als Zahl ist als IF machbar. 

Material
Materialien nach Ökobaudat benannt --> Berechnete Eigenschaft als IF für das Kürzel.

Eigentlich kein Problem --> Die Probleme entstehen aber wenn neue Materialien hinzugefügt werden. Denn dann muss man die berechnete Eigenschaft umpflegen. Bei der Menge an einträgen so einer Liste ist die berechnete Eigenschaft dann wirklich ein Albtraum. 
dar.

Deswegen und auch im Hinblick auf einen Stand wäre das ganze eben über Dynomo oder Python mit den Listen besser. Dann muss man nur die Excel erweitern und kann es zentral verwalten. Und hier liegt auch mein Problem mit Python. Daher der Post. 

Weiteres Problem --> Baustoffe in Archicad. Mehrschichtige und vorallem auch Fenster und Türen... denn da gibt es diesen einfach nicht. Das überschreiben wir in der Eigenschaft dann manuell. 

Identifikator ( Liste Identifikator mit Kreuzungsschema welche Elemente welchen Wertebereich enthalten dürfen)
Identifikator nach Liste --> Berechnete Eigenschaft als IF für das Kürzel. Selbes Spiel wie bei dem Material.

Maße
( für jeden Elementtyp eine eigene berechnete Eigenschaft ) um die richtigen Parameter so oder ähnlich darzustellen.

Warum in der IDführen? Die ID wird eben in den Programmen als Name geführt.
Hier ein Screenshot aus BIMcollab. 
Warum man darauf keine berechnete Eigenschaft mappen kann ist mir eh ein Rätsel. 

Nur ein Beispiel - anderer Schlüssel:

 

 

[Stefan L_]

---

@antsche  schrieb:

Warum in der IDführen? Die ID wird eben in den Programmen als Name geführt....
Warum man darauf keine berechnete Eigenschaft mappen kann ist mir eh ein Rätsel. 

---

Doch, auf der Ebene IfcElement geht das:

---

@antsche  schrieb:

Material
Materialien nach Ökobaudat benannt --> Berechnete Eigenschaft als IF für das Kürzel.
Eigentlich kein Problem --> Die Probleme entstehen aber wenn neue Materialien hinzugefügt werden. Denn dann muss man die berechnete Eigenschaft umpflegen. Bei der Menge an einträgen so einer Liste ist die berechnete Eigenschaft dann wirklich ein Albtraum. 
dar.

---

Heißt das, dass Du den genauen Namen im Baustoff liefern musst, z.B. "1.3.02. Mauerziegel (mit Polystyrol gefüllt) "?!

Örks!

Kannst Du den Baustoff/Materialnamen nicht in AC ergänzen z.B. zu "MW - 1.3.02. Mauerziegel (mit Polystyrol gefüllt) " und das Kürzel per

SPLIT ( {Property:PropGruppe/Baustoffname}; " - "; 1 )

(vulgo: gib mit alle Zeichen vor meinem Trenner " - ")

wieder hervorzaubern?

Was die Menge angeht:

Ich habe mal - mehr als Test - eine berechnete Eigenschaft (anbei) gebastelt, die aus dem NC-Code für Räume den Langtext macht.

In AC mit einem "IFS" angefangen > XML-Export, dann ein bisschen Excel mit 831 Zeilen nach dem "IFS", ein bisschen Notepad++ > XML Import.

Die Berechnung selbst ist in ACs Eigenschaften-Manager gar nicht mehr sichtbar, funktioniert aber tadellos und (Lob an GS! Von mir!?) sehr performant.

[jonasm]

Alles als Einzelschichten? Aufwändig in der Modellierung, aber dann kannst du da doch recht genau die Informationen ausgeben.

Muss es zwingend in die ID? Da hast du Recht, das es nervig ist das manuell zu führen.

Du kannst doch eine berechnete Eigenschaft zusammensetzen und die im IFC Übersetzer da hin mappen, wo sie gefordert wird, vermutlich als Name?

Der Syntax für die berechneten Eigenschaften wäre dann:

CONCAT( Eigenschaft1; Eigenschaft2; Eigenschaft3; ...)

Oder du fügst die EInzelteile des Types direkt im IFC Übersetzer zusammen:

Das doppelte Mapping (STB und Stahlbeton) kannst du dann entweder über berechnete Eigenschaften, händisch oder im Zweifelsfall Python machen. Berechnete Eigenschaften haben natürlich den Vorteil, das sie "live" sind und nicht manuell aktualisiert werden müssen.