Benutzerhandbuch

Einleitung

Dieser IDS4ALL converter, entwickelt von Simon Fischer, Harald Urban, Konstantin Höbart und Christian Schranz vom Forschungsbereich Digitaler Bauprozess der TU Wien (https://www.tuwien.at/cee/ibb/zdb), überführt Informationsanforderungen aus einer Excel-Datei in eine IDS-Datei. In der Praxis werden Informationsanforderungen oft tabellarisch in Excel definiert. Dieses Tool soll helfen, diese einfach in IDS zu überführen und dabei die volle Funktionalität von IDS zu nutzen. Ziel ist es, eine Struktur der Excel-Datei zu verwenden, die den vorhandenen Strukturen für Informationsanforderungen ähnelt, um die Anpassung an IDS zu erleichtern.

Der Konverter wandelt Informationsanforderungen definiert nach der Vorlage „IDS4ALL-Template“ in eine IDS-Datei um.

Diese Vorlage enthält fünf Tabellenblätter:

IDS4ALL: Definiert allgemeine Informationen (Metadaten) der IDS-Datei. Dieses Tabellenblatt und seine Struktur ist vorgegeben und muss eingehalten werden.
Template: leere Vorlage mit allen möglichen Spalten ohne Spezifikationen
Example specifications: Enthält Beispiele für alle im Benutzerhandbuch beschriebenen Funktionalitäten des IDS4ALL-Konverters. Kann auch als Vorlagenblatt verwendet werden.
User manual: Erklärung/Anleitung auf Englisch
Benutzerhandbuch: Erklärung/Anleitung auf Deutsch

Im Folgenden wird die erforderliche Struktur mit Beispielen aus dem Tabellenblatt „Example specifications“ detailliert beschrieben.

Aufbau des Tabellenblattes „Example specifications“

Das Tabellenblatt „Example specifications“ führt einzelne Spalten für mögliche Einträge in einem IDS Facet ein. In einer klassischen oder traditionellen Informationsanforderungstabelle gibt es eine Spalte für die IFC-Entität, die die Applicability definiert, und Spalten für das PropertySet, den Property-Namen, den Datentyp und den Property-Wert, um die Requirements zu definieren. Auf die gleiche Weise werden Spalten für die anderen IDS Facets sowohl für die Applicability als auch für die Requirements eingeführt. Die Namen der Spalten sind vorgegeben und müssen eingehalten werden. Spalten für die Applicability beginnen mit „A“. Spalten für die Requirements beginnen mit „R“. Zusätzliche allgemeine Spalten (Phase, Role, Usecase, SpecificationCardinality) haben kein Präfix. Die Reihenfolge der Spalten in der Excel-Tabelle ist nicht vorgegeben. Ebenso müssen nicht alle Spalten vorhanden sein. Spalten von IDS Facets, die nicht erforderlich sind, können entfernt oder weggelassen werden, wodurch die Excel-Datei einfach gehalten werden kann. Dadurch kann der IDS4ALL-Konverter sowohl für einfache klassische Informationsanforderungen als auch für komplexere Anforderungen verwendet werden, die das volle Potenzial von IDS nutzen. Wenn ein Facet verwendet wird, muss jedoch sichergestellt werden, dass auch alle erforderlichen Spalten des Facets verwendet werden. Beispielsweise sind die Einträge „PropertySet“ und „Property“ für das Property Facet erforderlich. Wenn das Property Facet verwendet wird, müssen mindestens diese beiden Spalten ausgefüllt werden.

Die Definition von Spezifikationen erfolgt zeilenweise. Verschiedene Zeilen mit der gleichen Applicability werden zu einer Spezifikation zusammengefasst. Wenn die verschiedenen Zeilen unterschiedliche Requirements betreffen, werden sie mit einer „Und“-Logik zu einer Spezifikation zusammengefasst. Verschiedene Zeilen betreffen jedoch oft auch dieselben Requirements, z. B. werden Listen möglicher Eigenschaftswerte oft in separaten Zeilen aufgeführt. Daher können für die Spalten R.AttributeValue und R.PropertyValue auch verschiedene Zeilen verwendet werden, um verschiedene mögliche Werte aufzulisten. Wenn alle anderen Einträge in den Zeilen gleich sind, werden die Werte in den verschiedenen Zeilen mit einer „Oder“-Logik zu einer Liste möglicher Werte zusammengeführt (siehe „Example specifications“, Zeilen 12–21 und 22–31). Die zweite Möglichkeit, Listen von „Oder“-Werten zu definieren, ist die Verwendung des Trennzeichens | (siehe Beschreibung der Schlüsselwörter/-symbole).

Die Reihenfolge der Zeilen ist nicht vorgegeben. Auch leere Zeilen sind zulässig. Diese werden vom Konverter ignoriert (siehe „Example specifications“, Zeilen 55 und 61).

Im Allgemeinen ist die Zeilenstruktur nicht hierarchisch. Jede Zeile muss für sich allein stehen können. Das bedeutet, dass jede Zeile alle Informationen enthalten muss und keine Informationen aus vorherigen Zeilen übernommen werden. Es ist jedoch möglich, die Daten durch Überschriftszeilen für eine neue Entität oder ein neues PropertySet wie in den „Example specifications“ zu strukturieren. Eine Überschriftszeile in der Applicability (siehe „Example specifications“, Zeile 5) erstellt eine zusätzliche allgemeine Spezifikation, in der alle Informationen der spezifischeren Spezifikationen zusammengeführt werden. Sie ersetzt nicht die spezifischeren Spezifikation, sondern ist eine zusätzliche Spezifikation. Eine Überschirftszeile in den Requirements (siehe „Example specifications“, Zeile 6) erstellt keine neue Spezifikation. Stattdessen wird sie mit den detaillierteren Spezifikationen darunter zusammengeführt. Wenn Sie Ihre Daten jedoch mithilfe der allgemeinen Spalten in verschiedene IDS-Dateien aufteilen, stellen Sie sicher, dass die allgemeinen Spalten auch für diese Überschriftszeilen ausgefüllt werden (sollten mit den allgemeinen Daten einer spezifischeren Spezifikation übereinstimmen, wobei es unerheblich ist, mit welcher spezifischeren Spezifikation). Andernfalls werden die Zeilen nicht zusammengeführt und es werden unvollständige Facets generiert.

Nachfolgend finden Sie eine Liste der vordefinierten Spaltennamen, unterteilt in Applicability, Requirements und allgemeine Informationen, einschließlich einer Erklärung:

Spaltennamen Applicability	Spaltennamen Requirements	Spaltennamen Allgemein	Beschreibung	Erlaubte Schlüsselwörter/-symbole
A.Entity	R.Entity		Entity Facet: Definition der IFC-Entität und des PredefinedType in der Form „Entity.PredefinedType“. Vorsicht: Standardisierte PredefinedTypes müssen wie im IFC-Standard definiert, mit Großbuchstaben angegeben werden (siehe „Example specifications“, Zeile 33). Benutzerdefinierte Typen können klein geschrieben werden (siehe „Example specifications“, Zeile 34).	alle
	R.Description.Entity		Entity Facet: Beschreibung der IFC-Entität. Kann in Kombination mit dem Entity Facet in den Anforderungen verwendet werden, um allgemeine Informationen über eine Entität in den Instructions des Entity Facet zu speichern. Wird beispielsweise verwendet, um eine eindeutige Beschreibung aller Entitäten bereitzustellen, die in den Informationsanforderungen erscheinen. Zu diesem Zweck kann eine Spezifikation das Entity Facet in der Applicability und in den Requirements enthalten, wobei in den Requirements die Beschreibung hinzugefügt wird. (siehe „Example specifications“, Zeilen 3 und 4). Eine Beschreibung ist nur in den Requirements möglich, da das IDS-Schema keine Instructions im Facet erlaubt, wenn es in der Applicability verwendet wird.	\&
A.PropertySet	R.PropertySet		Property Facet: Definition des PropertySets	alle
A.Property	R.Property		Property Facet: Definition des Property-Namens. Dieser Wert wird in IDS unter dem baseName im Property Facet gespeichert.	alle
A.PropertyDatatype	R.PropertyDatatype		Property Facet: Definition des Datentyps der Eigenschaft (z. B. IfcLabel, IfcBoolean).	\&
A.PropertyValue	R.PropertyValue		Property Facet: Definition des Property-Werts	alle
	R.PropertyURI		Property Facet: Definition des URI (Uniform Resource Identifier) des Properties	\&
	R.Description.Property		Property Facet: Beschreibung des Properties. Kann in Kombination mit dem Property Facet in den Requirements verwendet werden, um allgemeine Informationen über ein Property in den Instructions des Property Facet zu speichern (siehe „Example specifications“, Zeile 9). Eine Beschreibung ist nur in den Requirements möglich, da das IDS-Schema keine Instructions im Facet erlaubt, wenn es in der Applicability verwendet wird.	\&
A.Material	R.Material		Material Facet: Definition des Materialnamens	alle
	R.MaterialURI		Material Facet: Definition des URI (Uniform Resource Identifier) des Materials	\&
A.Attribute	R.Attribute		Attribute Facet: Definition des Attributnamens	alle
A.AttributeValue	R.AttributeValue		Attribute Facet: Definition des Attributwerts	alle
A.Classification	R.Classification		Classification Facet: Definition des Klassifikationsnamens	alle
A.ClassificationSystem	R.ClassificationSystem		Classification Facet: Definition des Klassifikationssystems	alle
	R.ClassificationURI		Classification Facet: Definition des URI (Uniform Resource Identifier) der Klassifikation	\&
A.PartOfRelation	R.PartOfRelation		PartOf Facet: Definition der verwendeten Relation	alle
A.PartOfEntity	R.PartOfEntity		PartOf Facet: Definition der IFC-Entität, die über die angegebene Relation mit dem aktuellen Element verknüpft werden soll	alle
	R.Cardinality		Definition der Kardinalität eines Facets. Die Kardnialität eies Facets in den Requirements legt fest, ob die definierte Anforderung erfüllt werden muss (required), erfüllt wird darf (optional), oder nicht erfüllt werden darf (prohibited). Diese Spalte bezieht sich auf alle Facets in den Requirements. Werden also in einer Zeile mehrere verschiedene Facets verwendet und eine Kardinalität definiert, gilt diese für alle Facets dieser Zeile. Sollen die Facets verschiedene Kardinalitäten aufweisen, können sie auf mehrere Zeilen aufgeteilt werden, da mehrere Zeilen in einer Spezifikation mit und verknüpft werden (insofern die Applicability übereinstimmt). Diese Spalte ist optional. Wird sie nicht verwendet, bekommt jedes Facet den Standardwert required.	\&
		Phase	Angabe der Projektphasen, in denen die Spezifikation erforderlich ist. Diese Information wird im IDS in den Instructions der Spezifikation gespeichert und auch für die Aufteilung in einzelne IDS-Dateien verwendet (je nach Eintrag im IDS4ALL-Tabellenblatt).	\& und \| (haben die gleiche Bedeutung in dieser Spalte)
		Role	Angabe der Rolle(n) (z. B. Architektur, Tragwerksplanung), die für die Spezifikation verantwortlich ist (sind). Diese Information wird im IDS in den Instructions der Spezifikation gespeichert und dient auch zur Trennung einzelner IDS-Dateien (abhängig vom Eintrag im IDS4ALL-Tabellenblatt).	\& und \| (haben die gleiche Bedeutung in dieser Spalte)
		Usecase	Angabe der Anwendungsfälle, in denen die Spezifikation erforderlich ist. Diese Information wird im IDS in den Instructions der Spezifikation gespeichert und dient auch zur Trennung einzelner IDS-Dateien (abhängig vom Eintrag im IDS4ALL-Tabellenblatt).	\& und \| (haben die gleiche Bedeutung in dieser Spalte)
		SpecificationCardinality	Definition der Kardinalität einer Spezifikation. Die Kardinalität einer Spezifikation legt fest, ob die angegeben Elemente im Modell vorhanden sein müssen. In dieser Zeile sind drei verschiedene Werte gültig (required, optional, prohibited). Diese Werte werden in der Applicability einer Spezifikation gespeichert und in die „occurs“-Attribute des Attributteils eines IDS umgewandelt. – required: minOccurs = 1 maxOccurs = unbounded – optional: minOccurs = 0 maxOccurs = unbounded – pohibited: minOccurs = 0 maxOccurs = 0 Standardmäßig ist die Kardinalität der Spezifikationen optional, wenn die Spalte nicht verwendet wird.	keine
		SpecificationIfcVersion	Definition der IFC-Version für eine Spezifikation. Wird diese Spalte verwendet, überschreibt sie die IFC-Version aus dem Tabellenblatt IDS4ALL. In Zeilen, wo keine spezifische IFC-Versionen definiert werden, verbleiben die Standard-Versionen aus dem Tabellenblatt IDS4ALL. Erlaubte Werte: – IFC2X3 – IFC4 – IFC4X3_ADD2	\& und \| (haben die gleiche Bedeutung in dieser Spalte)

Spaltennamen Applicability

Spaltennamen Requirements

Spaltennamen Allgemein

Beschreibung

Erlaubte Schlüsselwörter/-symbole

A.Entity

R.Entity

Entity Facet: Definition der IFC-Entität und des PredefinedType in der Form „Entity.PredefinedType“. Vorsicht: Standardisierte PredefinedTypes müssen wie im IFC-Standard definiert, mit Großbuchstaben angegeben werden (siehe „Example specifications“, Zeile 33). Benutzerdefinierte Typen können klein geschrieben werden (siehe „Example specifications“, Zeile 34).

alle

R.Description.Entity

Entity Facet: Beschreibung der IFC-Entität. Kann in Kombination mit dem Entity Facet in den Anforderungen verwendet werden, um allgemeine Informationen über eine Entität in den Instructions des Entity Facet zu speichern. Wird beispielsweise verwendet, um eine eindeutige Beschreibung aller Entitäten bereitzustellen, die in den Informationsanforderungen erscheinen. Zu diesem Zweck kann eine Spezifikation das Entity Facet in der Applicability und in den Requirements enthalten, wobei in den Requirements die Beschreibung hinzugefügt wird. (siehe „Example specifications“, Zeilen 3 und 4). Eine Beschreibung ist nur in den Requirements möglich, da das IDS-Schema keine Instructions im Facet erlaubt, wenn es in der Applicability verwendet wird.

A.PropertySet

R.PropertySet

Property Facet: Definition des PropertySets

alle

A.Property

R.Property

Property Facet: Definition des Property-Namens. Dieser Wert wird in IDS unter dem baseName im Property Facet gespeichert.

alle

A.PropertyDatatype

R.PropertyDatatype

Property Facet: Definition des Datentyps der Eigenschaft (z. B. IfcLabel, IfcBoolean).

A.PropertyValue

R.PropertyValue

Property Facet: Definition des Property-Werts

alle

R.PropertyURI

Property Facet: Definition des URI (Uniform Resource Identifier) des Properties

R.Description.Property

Property Facet: Beschreibung des Properties. Kann in Kombination mit dem Property Facet in den Requirements verwendet werden, um allgemeine Informationen über ein Property in den Instructions des Property Facet zu speichern (siehe „Example specifications“, Zeile 9). Eine Beschreibung ist nur in den Requirements möglich, da das IDS-Schema keine Instructions im Facet erlaubt, wenn es in der Applicability verwendet wird.

A.Material

R.Material

Material Facet: Definition des Materialnamens

alle

R.MaterialURI

Material Facet: Definition des URI (Uniform Resource Identifier) des Materials

A.Attribute

R.Attribute

Attribute Facet: Definition des Attributnamens

alle

A.AttributeValue

R.AttributeValue

Attribute Facet: Definition des Attributwerts

alle

A.Classification

R.Classification

Classification Facet: Definition des Klassifikationsnamens

alle

A.ClassificationSystem

R.ClassificationSystem

Classification Facet: Definition des Klassifikationssystems

alle

R.ClassificationURI

Classification Facet: Definition des URI (Uniform Resource Identifier) der Klassifikation

A.PartOfRelation

R.PartOfRelation

PartOf Facet: Definition der verwendeten Relation

alle

A.PartOfEntity

R.PartOfEntity

PartOf Facet: Definition der IFC-Entität, die über die angegebene Relation mit dem aktuellen Element verknüpft werden soll

alle

R.Cardinality

Definition der Kardinalität eines Facets. Die Kardnialität eies Facets in den Requirements legt fest, ob die definierte Anforderung erfüllt werden muss (required), erfüllt wird darf (optional), oder nicht erfüllt werden darf (prohibited). Diese Spalte bezieht sich auf alle Facets in den Requirements. Werden also in einer Zeile mehrere verschiedene Facets verwendet und eine Kardinalität definiert, gilt diese für alle Facets dieser Zeile. Sollen die Facets verschiedene Kardinalitäten aufweisen, können sie auf mehrere Zeilen aufgeteilt werden, da mehrere Zeilen in einer Spezifikation mit und verknüpft werden (insofern die Applicability übereinstimmt). Diese Spalte ist optional. Wird sie nicht verwendet, bekommt jedes Facet den Standardwert required.

Phase

Angabe der Projektphasen, in denen die Spezifikation erforderlich ist. Diese Information wird im IDS in den Instructions der Spezifikation gespeichert und auch für die Aufteilung in einzelne IDS-Dateien verwendet (je nach Eintrag im IDS4ALL-Tabellenblatt).

\& und | (haben die gleiche Bedeutung in dieser Spalte)

Role

Angabe der Rolle(n) (z. B. Architektur, Tragwerksplanung), die für die Spezifikation verantwortlich ist (sind). Diese Information wird im IDS in den Instructions der Spezifikation gespeichert und dient auch zur Trennung einzelner IDS-Dateien (abhängig vom Eintrag im IDS4ALL-Tabellenblatt).

\& und | (haben die gleiche Bedeutung in dieser Spalte)

Usecase

Angabe der Anwendungsfälle, in denen die Spezifikation erforderlich ist. Diese Information wird im IDS in den Instructions der Spezifikation gespeichert und dient auch zur Trennung einzelner IDS-Dateien (abhängig vom Eintrag im IDS4ALL-Tabellenblatt).

\& und | (haben die gleiche Bedeutung in dieser Spalte)

SpecificationCardinality

Definition der Kardinalität einer Spezifikation. Die Kardinalität einer Spezifikation legt fest, ob die angegeben Elemente im Modell vorhanden sein müssen. In dieser Zeile sind drei verschiedene Werte gültig (required, optional, prohibited). Diese Werte werden in der Applicability einer Spezifikation gespeichert und in die „occurs“-Attribute des Attributteils eines IDS umgewandelt.
– required: minOccurs = 1 maxOccurs = unbounded
– optional: minOccurs = 0 maxOccurs = unbounded
– pohibited: minOccurs = 0 maxOccurs = 0
Standardmäßig ist die Kardinalität der Spezifikationen optional, wenn die Spalte nicht verwendet wird.

keine

SpecificationIfcVersion

Definition der IFC-Version für eine Spezifikation. Wird diese Spalte verwendet, überschreibt sie die IFC-Version aus dem Tabellenblatt IDS4ALL. In Zeilen, wo keine spezifische IFC-Versionen definiert werden, verbleiben die Standard-Versionen aus dem Tabellenblatt IDS4ALL. Erlaubte Werte:
– IFC2X3
– IFC4
– IFC4X3_ADD2

\& und | (haben die gleiche Bedeutung in dieser Spalte)

Schlüsselwörter/-symbole

Um in einzelnen Zellen mehr als nur einfache Werte zu definieren, sind Schlüsselwörter/-symbole erforderlich. Die Symbole weisen immer auf eine komplexe Einschränkung oder eine spezielle Verarbeitung der Werte in der Zelle hin. Daher sind sie als normaler Text nicht zulässig. Die Symbole sind nicht in jeder Spalte zulässig. Die obige Liste zeigt, welche Symbole in welcher Spalte zulässig sind.

Schlüsselwort/-symbol	Definition	Beschreibung
\|	Oder	Dieses Symbol trennt die Werte einer ‘Oder’-Liste innerhalb einer Zelle. Es wird verwendet, um eine Liste möglicher Werte in einer Zelle zu definieren. Das ‘Oder’-Symbol hat in den Requirements und in der Applicability unterschiedliche Funktionen. In den Requirements werden diese Werte in IDS als komplexe ‘Aufzählungs’-Einschränkung gespeichert (siehe ‘Example specifications’, Zeilen 47 und 48). In der Applicability wird eine solche Aufzählung verwendet, um mehrere Elemente zu beschreiben für die eine Anforderung gilt. Dies ist sehr gut geeignet, um die Applicability für allgemein gültige Werte zu definieren, die auch für Spezifikationen mit einer spezifischeren Applicability gelten (siehe ‘Example specifications’, Zeilen 10, 11, 46). Um die spezifischeren Werte zu den allgemeinen Werten hinzufügen zu können, wird eine solche Zeile in mehrere Spezifikationen aufgeteilt, je eine für die unterschiedlichen “Oder”-Werte. Dadurch entstehen aus der allgemeinen Spezifikation bereits Spezifikationen mit spezifischer Applicability, die mit den späteren spezifischen Spezifikationen vereint werden können. Sehen wir uns die Definition von FireRating in den ‘Example specifications’ an. Wir unterteilen die möglichen Feuerwiderstandswerte in Werte für tragende Wände (REI…) und nicht tragende Wände (EI…) unter Verwendung der Eigenschaft LoadBearing in der Applicability. Die allgemeinen Werte ND (nicht definiert) und NE (nicht erforderlich) gelten für beide Kategorien. Um zu vermeiden, dass sie in beide Listen aufgenommen werden müssen, erstellen wir eine separate Liste mit diesen beiden Werten und definieren ihre Applicability für LoadBearing True\|False. Diese beiden “Oder”-Werte werden in zwei einzelne Spezifiaktionen aufgeteilt, einmal für LoadBearing True und einmal für LoadBearing false, jeweils mit den FireRating-Werten ND\|NE. Die nächsten Zeilen haben anschließend die gleiche Applicability wie eine der bereits vorhandenen Spezifikationen und können vereinigt werden. Es resultieren zwei verschiedene Spezifikationen. Eine Ausnahme bildet die Verwendung der SpecificationCardinality “Required”. Wird mithilfe dieser Funktion die Existenz von Elementen im Modell gefordert, können die “Oder”-Werte nicht in einzelne Spezifikationen aufgeteilt werden, da dadurch die Logik verloren geht, dass nur eines der definierten Elemente im Modell enthalten sein muss. VORSICHT: Daher können spezifische und allgemeine Werte in Kombination mit SpecificationCardinality “Required” nicht zusammengefügt werden und unvollständige Auswahllisten können entstehen.
\&	Und	Dieses Symbol ermöglicht es, mehrere Werte mit einem ‘Und’ zu verknüpfen (siehe ‘Example specifications’, Zeile 49). Es wird verwendet, um mehrere Facets in einer Spezifikation zu kombinieren. Diese Logik bezieht sich immer auf alle Spalten, die zu einem Facet gehören. Es muss darauf geachtet werden, dass in allen Spalten des Facets die gleiche Anzahl von ‘Und’-Symbolen verwendet wird (z. B. PropertySet: Pset_WallCommon&Pset_WallCommon; Property: LoadBearing&Compartmentation; PropertyValue: True&False). Bei einem optionalen Parameter in IDS wie bei PropertyValue können Werte auch leer gelassen werden (z. B. True&). Dies bedeutet, dass der zweite Wert nicht definiert ist und die IDS-Spezifikation angibt, dass die Eigenschaft mit einem beliebigen Wert vorhanden sein muss. Verschiedene Facets in einer Zeile werden ebenfalls zu einer Spezifikation zusammengeführt. Darüber hinaus werden auch mehrere Zeilen mit derselben Applicability zu einer Spezifikation zusammengeführt.
pattern=	Regex-Muster	Definition eines Schemas für die Zeichenkette des Wertes (siehe ‘Example specifications’, Zeile 49). Wird durch reguläre Ausdrücke (regex) definiert.
length=	Genaue Länge eines Werts	Beschränkung der Anzahl der einzelnen Zeichen eines Werts
length>=	minimale Länge eines Werts	Beschränkung der Anzahl der einzelnen Zeichen eines Werts
length<=	maximale Länge eines Werts	Beschränkung der Anzahl der einzelnen Zeichen eines Werts (siehe Tabellenblatt ‘Example specifications’, Zeile 50)
<	kleiner	Beschränkung eines numerischen Werts
<=	kleiner gleich	Beschränkung eines numerischen Werts (see ‘Example specifications’, row 51)
>	größer	Beschränkung eines numerischen Werts
>=	größer gleich	Beschränkung eines numerischen Werts

Schlüsselwort/-symbol

Definition

Beschreibung

Oder

Dieses Symbol trennt die Werte einer ‘Oder’-Liste innerhalb einer Zelle. Es wird verwendet, um eine Liste möglicher Werte in einer Zelle zu definieren. Das ‘Oder’-Symbol hat in den Requirements und in der Applicability unterschiedliche Funktionen. In den Requirements werden diese Werte in IDS als komplexe ‘Aufzählungs’-Einschränkung gespeichert (siehe ‘Example specifications’, Zeilen 47 und 48).
In der Applicability wird eine solche Aufzählung verwendet, um mehrere Elemente zu beschreiben für die eine Anforderung gilt. Dies ist sehr gut geeignet, um die Applicability für allgemein gültige Werte zu definieren, die auch für Spezifikationen mit einer spezifischeren Applicability gelten (siehe ‘Example specifications’, Zeilen 10, 11, 46). Um die spezifischeren Werte zu den allgemeinen Werten hinzufügen zu können, wird eine solche Zeile in mehrere Spezifikationen aufgeteilt, je eine für die unterschiedlichen “Oder”-Werte. Dadurch entstehen aus der allgemeinen Spezifikation bereits Spezifikationen mit spezifischer Applicability, die mit den späteren spezifischen Spezifikationen vereint werden können. Sehen wir uns die Definition von FireRating in den ‘Example specifications’ an. Wir unterteilen die möglichen Feuerwiderstandswerte in Werte für tragende Wände (REI…) und nicht tragende Wände (EI…) unter Verwendung der Eigenschaft LoadBearing in der Applicability. Die allgemeinen Werte ND (nicht definiert) und NE (nicht erforderlich) gelten für beide Kategorien. Um zu vermeiden, dass sie in beide Listen aufgenommen werden müssen, erstellen wir eine separate Liste mit diesen beiden Werten und definieren ihre Applicability für LoadBearing True|False. Diese beiden “Oder”-Werte werden in zwei einzelne Spezifiaktionen aufgeteilt, einmal für LoadBearing True und einmal für LoadBearing false, jeweils mit den FireRating-Werten ND|NE. Die nächsten Zeilen haben anschließend die gleiche Applicability wie eine der bereits vorhandenen Spezifikationen und können vereinigt werden. Es resultieren zwei verschiedene Spezifikationen.
Eine Ausnahme bildet die Verwendung der SpecificationCardinality “Required”. Wird mithilfe dieser Funktion die Existenz von Elementen im Modell gefordert, können die “Oder”-Werte nicht in einzelne Spezifikationen aufgeteilt werden, da dadurch die Logik verloren geht, dass nur eines der definierten Elemente im Modell enthalten sein muss. VORSICHT: Daher können spezifische und allgemeine Werte in Kombination mit SpecificationCardinality “Required” nicht zusammengefügt werden und unvollständige Auswahllisten können entstehen.

Und

Dieses Symbol ermöglicht es, mehrere Werte mit einem ‘Und’ zu verknüpfen (siehe ‘Example specifications’, Zeile 49). Es wird verwendet, um mehrere Facets in einer Spezifikation zu kombinieren. Diese Logik bezieht sich immer auf alle Spalten, die zu einem Facet gehören. Es muss darauf geachtet werden, dass in allen Spalten des Facets die gleiche Anzahl von ‘Und’-Symbolen verwendet wird (z. B. PropertySet: Pset_WallCommon&Pset_WallCommon; Property: LoadBearing&Compartmentation; PropertyValue: True&False). Bei einem optionalen Parameter in IDS wie bei PropertyValue können Werte auch leer gelassen werden (z. B. True&). Dies bedeutet, dass der zweite Wert nicht definiert ist und die IDS-Spezifikation angibt, dass die Eigenschaft mit einem beliebigen Wert vorhanden sein muss.
Verschiedene Facets in einer Zeile werden ebenfalls zu einer Spezifikation zusammengeführt. Darüber hinaus werden auch mehrere Zeilen mit derselben Applicability zu einer Spezifikation zusammengeführt.

pattern=

Regex-Muster

Definition eines Schemas für die Zeichenkette des Wertes (siehe ‘Example specifications’, Zeile 49). Wird durch reguläre Ausdrücke (regex) definiert.

length=

Genaue Länge eines Werts

Beschränkung der Anzahl der einzelnen Zeichen eines Werts

length>=

minimale Länge eines Werts

Beschränkung der Anzahl der einzelnen Zeichen eines Werts

length<=

maximale Länge eines Werts

Beschränkung der Anzahl der einzelnen Zeichen eines Werts (siehe Tabellenblatt ‘Example specifications’, Zeile 50)

kleiner

Beschränkung eines numerischen Werts

kleiner gleich

Beschränkung eines numerischen Werts (see ‘Example specifications’, row 51)

größer

Beschränkung eines numerischen Werts

größer gleich

Beschränkung eines numerischen Werts

Einschränkungen

Das Dezimaltrennzeichen eines numerischen Werts muss ein Punkt oder ein Komma sein.

Der Name einer Spezifikation kann nicht benutzerdefiniert festgelegt werden. Er wird aus der IFC-Entität automatisch erzeugt.

Es ist nicht möglich, benutzerdefinierte Werte für den Purpose und den Milestone des IDS festzulegen. Diese Werte werden automatisch aus den allgemeinen Spalten generiert. Die Phasen werden als Milestone und die Kombination aus Rollen und Anwendungsfällen als Purpose gespeichert.

IDS4ALL Converter Dokumentation

Einleitung

Aufbau des Tabellenblattes „Example specifications“

Schlüsselwörter/-symbole

Einschränkungen