Skip to content

RUB-Informatik-im-Bauwesen/OpenBimRL

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

12 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

OpenBimRL

Schema: XSD
Current Version: 2023.07.1
First Publication Date: 10.06.2022
Autors: Marcel Stepien, André Vonthron
E-Mail: marcel.stepien@ruhr-uni-bochum.de
Licence: MIT (Java-Sources), CC-BY-4.0 (XSD Schema)


0. Vorwort

Das Schema wurde im Rahmen des Workshops/Konferenz der EG-ICE 2023 vorgestellt. Das in dem Kontext Veröffentlichung Paper stellt dabei ein Bezug zu weiterführende prototypischen Implementierungen dar. Diese da wären:

1. Beschreibung

Angelehnt an der graphenbasierten Programmierung (bspw. Dynamo und Grasshopper) beschreibt das OpenBimRL Format eine Regelsprache zur formellen und fachlichen Prüfung von Bauwerksmodellen. Das Format definiert eine dynamisch erweiterbare Schnittstelle, auf derer Basis Bausteine für einen graphenbasierten Prüfvorgang konstruiert und verknüpft werden können. Bei der Entwicklung wurde Wert auf Offenheit und Transparenz der Prüfungsdokumente gelegt. Im Gegensatz zu den meisten verfügbaren Regel- und Abfragesprachen ist es möglich sowohl Semantik als auch Geometrie zu prüfen, solange die verfügbare Engine die dazugehörigen Knoten und Kanten der Vorberechnung auflösen kann.

2. Aufbau des Schemas und der Komponenten

OpenBimRL Konzeptgrafik

Das OpenBimRL Konzept setzt sich aus mehreren Bausteinen zusammen, welche in Kombination das Schema des Formats darstellen.

2.0 OpenBimRL Root-Element

Das Root-Element von OpenBIMRL ist die OpenBIMRL-Komponente. Die Komponente Schachtelt eine Reihe von BIMRules, welche jeweils einen eigenen Prüfvorgang beschreiben.

Element.Attribut Beschreibung Beispiel
OpenBIMRL.schemaVersion Angabe der Version mit welcher die vorliegende Prüfung erzeugt wurde. 0.1

Übersetzt als XML-Instanz:

<OpenBIMRL schemaVersion="0.1" 
    xmlns="http://inf.bi.rub.de/OpenBimRL" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="https://github.com/RUB-Informatik-im-Bauwesen/OpenBimRL/blob/main/schema/OpenBimRL_Extension.xsd">

    <BIMRule ...> ... </BIMRule>
    <BIMRule ...> ... </BIMRule>
    ...

</OpenBIMRL>

Namespace URI
default http://inf.bi.rub.de/OpenBimRL
xsi http://www.w3.org/2001/XMLSchema-instance
schemaLocation https://github.com/RUB-Informatik-im-Bauwesen/OpenBimRL/blob/main/schema/OpenBimRL.xsd

2.1 OpenBimRL Schema

Die Hauptkomponente einer OpenBimRL Prüfregel nennt sich BIMRule, welche das Format der Regel vorgibt. Es handelt sich dabei um das umschließende Element im Prüfdokument. Folgende Angaben sind hierbei mindestens anzugeben:

Element.Attribut Beschreibung Beispiel
BIMRule.name Name des Regelsatzes. "Checking primary Escape Route"

Übersetzt als XML-Instanz:

<BIMRule name="Checking primary Escape Route">

    ...

</BIMRule>

2.2 Precalculations (Vorberechnung)

Die Vorberechnungen enthalten einen Graphen mit Funktionen (als Knoten) und eine Verbindung zwischen Ein- und Ausgängen (als Kanten). Der Graph bildet dabei einen Vorgang und/oder Algorithmus ab, dessen Teilergebnisse zwischengehalten werden können, um diese in den Regeln der Modellprüfung zu verwenden.

Übersetzt als XML-Instanz:

<BIMRule ...>

    <!-- Precalculations enthalten einen Graphen zur Vorberechnung von Teilmengen und Ergebnissen für die Prüfung. -->
    <Precalculations>

        <Node> ... </Node>
        <Node> ... </Node>
        <Node> ... </Node>

        <Edge ... />
        <Edge ... />
        <Edge ... />

    </Precalculations>

    ...

</BIMRule>
2.2.1 Knoten (Funktionen)

Jedes Knoten-Element enthält input und output-Elemente, dessen Attribute beschreiben, wie viele Ein- und Ausgänge vorhanden sind und wie diese benannt sind. Inputs und outputs sind jedoch nur optional. Ein nicht vorhanden sein dessen bedeutet, dass es keine Eingänge oder Ausgänge gibt für diesen Knoten. Ein Knoten definiert sich demnach wie folgt:

Element.Attribut Beschreibung Beispiel
Node.id Eindeutiger identifier des Knotens (UUID). f2f87b48-108e-4f38-1328-7e8924d89738
Node.function Name und Pfad der Funktion, die dieser Knoten ausführt. ifc.filterByProperty
Node.alias Ein vom Nutzer definierter Text zur Beschreibung des Knotens. Example Text Here
Input.name Angezeige Name des Eingangs. PropertySetName
Output.name Angezeige Name des Ausgangs. IfcElement List
Output.value Nutzerdefinierter Wert des Ausgangs. Pset_WallCommon

Übersetzt als XML-Instanz:

<!-- Knoten ohne Eingang: -->
<Node id="25525f88-07e7-740b-7a79-d2294af8687a" function="input.textInput" 
    xPos="150" yPos="100">
    <Outputs>
        <Output name="text" value="NotwendigerFlur"/>
    </Outputs>
</Node>

<!-- Knoten mit Ein- und Ausgang: -->
<Node id="f3d898d8-b958-3d79-084c-cce953f4b168" function="ifc.filterByProperty" 
    alias="Example Text Here" xPos="150" yPos="100">  
    <Inputs>
        <Input name="IfcElement List"/>
        <Input name="PropertySet Name"/>
        <Input name="Property Name"/>
        <Input name="Value"/>
    </Inputs>
    <Outputs>
        <Output name="IfcElement List"/>
    </Outputs>
</Node>
2.2.2 Kanten (Verbindungen/Beziehungen)

Eine Kante verbindet immer einen Ausgang eines Knotens (Funktion) mit dem Eingang eines anderen Knotens (Funktion). Hierbei dürfen keine Zyklen definiert werden! Der Graph ist nur für gerichtete, nicht zyklische Definitionen gültig. Eine Kante wird wie folgt definiert:

Element.Attribut Beschreibung Beispiel
Edge.id Eindeutiger identifier der Kante (UUID). f2f87b48-108e-4f38-1328-7e8924d89738
Edge.source Eindeutiger Identifier des ausgehenden referenzierten Knotens (UUID). 25525f88-07e7-740b-7a79-d2294af8687a
Edge.sourceHandle Nummer des adressierten Ausgangs, angefangen bei 0. 2
Edge.target Eindeutiger identifier des eingehenden referenzierten Knotens (UUID). f3d898d8-b958-3d79-084c-cce953f4b168
Edge.targetHandle Nummer des adressierten Eingangs, angefangen bei 0. 1

Übersetzt als XML-Instanz:

<Edge 
    id="ba4d8538-209d-48a8-5165-6c813e164ba1" 
    source="25525f88-07e7-740b-7a79-d2294af8687a" 
    sourceHandle="0" 
    target="f3d898d8-b958-3d79-084c-cce953f4b168" 
    targetHandle="3"/>
2.2.3 Gruppen (Verschachteln von Knoten)

Eine Group verschachtelt Elemente aus dem Graphen der Vorberechnung (Precalculation-Komponente) und stellt diese im gemeinsamen Kontext dar. Diese Gruppierung ist dabei ein beschreibendes Objekt, indem es direkt auf die Komponenten der Graphen verweist und diese zusätzlich benennt.

Element.Attribut Beschreibung Beispiel
Group.label Benennung, bzw. Beschreibung der Gruppe. "Sub-Rountine of ..."
Group.id Eindeutiger Identifier des ausgehenden referenzierten Knotens (UUID). bc2a7431-9376-db5d-a12a-fdb5d83bddbh
Group.color Die Grundfarbe der Gruppe in Hexerdeximal-Schreibweise. #fcba03
Group.children Die liste der Knoten, welche zur Gruppe zugeordnet werden. ["db5d...", "db5d..."]

Übersetzt als XML-Instanz:

<Group id="ba4d8538-209d-48a8-5165-6c813e164ba1" label="Sub-Routine of ..." color="#fcba03">
    <children>25525f88-07e7-740b-7a79-d2294af8687a</children>
    <children>f3d898d8-b958-3d79-084c-cce953f4b168</children>
    ...
</Group>

2.3 ModelCheck (Modellprüfung)

Die ModelCheck-Komponente fasst alle Bedingungen und Erwartungswerte der Prüfregel zusammen. Die ModelCheck-Komponente selbst definiert über das Attribut name eine eindeutige und beschreibende Bezeichnung der Prüfregel. Ein ModelCheck setzt sich wiederum aus drei Sub-Komponenten zusammen, namentlich den RuleIdentifier, ModelSubCheck und ResultSet.

Übersetzt als XML-Instanz:

</tns:BIMRule>
    ...
    <tns:ModelCheck name="Formeller Pruefvorgang">
		<tns:RuleIdentifiers>
			<tns:RuleIdentifier label="propertyValue" source="85d5009c-f8dc-1ccf-66c8-ce610713793a" sourceHandle="0" xPos="150" yPos="100"/>
			<tns:RuleIdentifier label="ifcWallEntities" source="bc2a7431-9376-db5d-a12a-fe48e83bddbd" sourceHandle="0" xPos="150" yPos="100"/>
            ...
		</tns:RuleIdentifiers>
		<tns:ModelSubChecks>
			<tns:ModelSubCheck name="Check PropertySet by Values">
                <tns:Applicability> ... </tns:Applicability>
				<tns:Rules label="77dd6850-f1d7-4c13-81e0-2de33fbf06cc" operator="or">
					<tns:Rule label="check01" quantifier="exists" operator="equals" operand1="propertyValue" operand2="true"/>
					<tns:Rule label="check02" quantifier="exists" operator="equals" operand1="propertyValue" operand2="false"/>
				</tns:Rules>
			</tns:ModelSubCheck>
            ...
		</tns:ModelSubChecks>
		<tns:ResultSets>
			<tns:ResultSet name="PropertySet by Values [true]" elements="ifcWallEntities" filter="check01"/>
			<tns:ResultSet name="PropertySet by Values [false]" elements="ifcWallEntities" filter="check02"/>
            ...
		</tns:ResultSets>
	</tns:ModelCheck>
</tns:BIMRule>
2.3.1 RuleIdentifier zur Anknüpfung der Prüfung an die Vorberechnung

Ein RuleIdentifier stellt eine Verbindung zwischen dem Graphen der Vorberechnung (Precalculation-Komponente) und den darauf angewandten Regeln her. Es wird durch ein RuleIdentifier ein kalkuliertes Ergebnis aus dem Graphen zwischengespeichert, um diese durch Bedingungen verknüpft genauer zu untersuchen. Demnach müssen für einen RuleIdentifier die Quelle angegeben werden, explizit zur ausgewählten Ausgabe (eng. output).

Element.Attribut Beschreibung Beispiel
RuleIdentifier.label Eindeutige Bezeichnung, unter derer der RuleIdentifier in der Regelprüfung verwendet wird. ifcWallEntities
RuleIdentifier.source Eindeutiger Identifier des ausgehenden referenzierten Knotens (UUID). bc2a7431-9376-db5d-a12a-fe48e83bddbd
RuleIdentifier.sourceHandle Nummer des adressierten Ausgangs, angefangen bei 0. 0
2.3.2 ModelSubCheck zur Verschachtelung mehrerer Regeln und Bedingungen

Ein ModelSubCheck fasst eine Gruppe von individuellen Anforderungen zusammen und erlaubt es diese als eigenständige Prüfung zu evaluieren. Der Teilprüfung kann über das Attribut label ein vom Haupt-Prüfvorgang separater Name verliehen werden. Solch ein ModelSubCheck besteht aus zwei wesentlichen Teilen, der Applicability (de. Anwendbarkeit) und Rules (de. Regeln).

Bei der Applicability handelt es sich um eine optionale Komponente, welche selbst eine Kaskade von Rules und Rule Komponenten enthält. Durch die Applicability kann zum Ausdruck gebracht werden, ob und auf was eine Prüfung angewandt wird. Es beschreibt also einen Gültigkeitsbereich für untersuchte Elemente im Prüfprozess.

Bei den Rules- und Rule-Komponenten handelt es sich um eine kaskadierende Struktur von gruppierten Bedingungen. Einzelne Regeln (Rule-Komponente) und Gruppen von Regeln (Rules-Komponente) können verschachtelt werden, um komplexere Zusammenhänge zu prüfen. Dabei wird in der Regel immer eine Liste von Informationen (als operand1) gegen statische Werte getestet (als operand2). Dabei entsteht ein Prüfergebnis als Filtermaske, bestehend aus einer Liste True und False Werten, welche über eine Bezeichnung des Attributs label für die Darstellung in den ResultSets zwischengehalten werden kann. Über die Attribute quantifier und operator kann definiert werden, welche Mengen- und Prüfungsform gelten muss, damit die Prüfung erfolgreich abgeschlossen werden kann.

Element.Attribut Beschreibung Beispiel
Rule.label Eine eindeutige Bezeichnung, unter dessen Referenz die Filtermaske in den Resultsets verwendet wird. filterMaskA
Rule.quantifier Der anzuwendende Quantor zur Steuerung des Prüfvorgangs. all, exists, notexists
Rule.operator Der anzuwendende Operator zur Steuerung des Prüfvorgangs. equals, includes, notincludes
Rule.operator1 Eine Liste von Werten, welche über die RuleIdentifier in die Prüfung injekted werden. propertyValue
Rule.operator2 Ein statischer Wert, gegen den geprüft werden soll. feuerbeständig
Rule2.operator Der anzuwendende Operator für Boolsche-Operationen, zur Verknüpfung der Teilergebnisse. or, and, xor
2.3.3 ResultSet zur Darstellung erwarteter Teilergebnisse

Ein ResultSet ermöglicht es Elemente aus der Vorberechnung mit Teil-Ergebnissen der Prüfung zu filtern, wodurch Ansichten (Model Views) auf erfolgreich und nicht erfolgreich geprüfte Elemente erzeugt werden können. Dies wird möglich durch die Anwendung von Filtermasken auf eine Menge von prüfbaren Elementen, wodurch diese gefiltert wird. Ein ResultSet benötigt drei Attribute zur Definition, welche da wären einen name, elements und filter.

Element.Attribut Beschreibung Beispiel
ResultSet.name Eindeutige Bezeichnung, unter derer die Ergebnisse der Prüfung zu verstehen sind. Erfolgreich geprüfte Elemente nach XYZ
ResultSet.elements Die Liste von prüfbaren Elementen aus der Vorberechnung. ifcWallEntities
ResultSet.filter Die Referenz auf die anzuwendende Filtermaske aus dem Prüfvorgang. filterMaskA

3. Begriffe und Definitionen

Abfragesprache ist ein aus der Aussagenlogik und Grammatik entsprungenes Sprachkonstrukt, welche die Grundlage für die deklarative Programmierung bilden. In einer Abfragesprache werden Beziehungen von Informationen abgebildet und deren Schlussfolgerungen gemäß vorliegender Fakten abgeleitet. Eine Abfrage operiert auf einer Datengrundlage (Datenbank). Ihre Ausführung erzeugt dabei Teilmengen (Sichten, Selektionen) von Objekten und Informationen aus der Datengrundlage.

Regelsprache ist die logische Erweiterung von Abfragesprachen und ermöglichen es, eine Aussage zu einem eindeutigen Ergebnis von Wahr oder Falsch abzuleiten. Im Kern der Regelsprachen befinden sich demnach immer Fragestellungen, die zu einem eindeutigen Zustand abgeleitet werden können.

Graphen sind aus Knoten und Kanten bestehende Konstrukte, welche in Kombination ein Netzwerk an Informationen und Informationsflüssen abbilden. Hier wird dabei von gerichteten Graphen, nicht zyklischen gesprochen, welche eindeutige Werte für den Eingang erwarten und eine Ausgabe erzeugen.

Die formale Prüfung bezeichnet die ordnungsmäßige Attribuierung eines Modells nach vorliegender Norm. Dazu zählen die Typisierung und Existenz von Eigenschaften am Modell, nach den Vorgaben von Richtlinien und Normen.

Bei der fachlichen Prüfung gilt es, die Informationslieferung des vorhandenen und ordnungsmäßig modellierten Modells nachzuweisen. Die fachlichen Vorgaben der Normen und Richtlinien werden algorithmisch umgesetzt und deren Ergebnisse gegen die Angaben im Modell abgeglichen. Oftmals ist hierfür eine komplexe Verkettung von Informationen notwendig (siehe Definition von Graphen).

Bauwerksmodelle sind im Kontext von OpenBimRL immer BIM-basierte Modelle im Format der Industry Foundation Classes (IFC). Bei IFC handelt es sich wiederum um ein Konstrukt von Klassen zur Definition eines digitalen Bauwerks.

Als Semantik werden beschreibende Informationen zu einem Bauteil verstanden, welche überwiegend auf die textuelle Definition einzelner Informationen abzielt. Semantische Informationen sind jedoch nicht zwingend an ein Objekt gebunden, so können strukturelle Vorgaben (Gebäude > Etage > Raum) ebenfalls als semantische Information interpretiert werden.

Bei der Geometrie handelt es sich um die Darstellung und Position eines Objekts im global betrachteten Raum. Hierbei können auch geometrische Verzerrungen, Transformationen und Operatoren genutzt werden, um Aussagen aus der Menge zu erzeugen (bspw. Intersection/Verschnitt zwischen zwei oder mehr Objekten = Kollision). Meistens wird die Geometrie genutzt, um Kenngrößen aus ihrer Darstellung abzuleiten.