vws4ls-subproject-results

TP12 – Produktkatalog mit der VWS

Im Teilprojekt 12 „Produktkatalog“ wurden auf Basis der in TP1 „Konzept, Informationsmodelle und Produktbeschreibung„ erarbeiteten Konzepte rund um das Informationsmodell und die Produktbeschreibung der Leitungssatzherstellung für die Automobilindustrie mittels Verwaltungsschalen (VWS), klare anwendungsorientierte Regeln für das Erzeugen und Verwalten von Typ-Verwaltungsschalen erarbeitet.

Zudem wurde ein Demonstrator erstellt, der einen beispielhaften herstellerübergreifenden Marktplatz basierend auf diesen Typ-Verwaltungsschalen abbildet. In diesem Kontext sollte auch untersucht werden, inwieweit die VWS zur Abwicklung der notwendigen eCommerce-Prozesse anwendbar ist.

Die VWS nach IEC 63278-1 bietet als Schlüsselkonzept der Industrie 4.0 eine standardisierte Struktur für die Beschreibung von Assets (z.B. Maschinen, Komponenten oder Software) in einer digitalen Umgebung. Damit wird ein effizienter Datenaustausch zwischen verschiedenen Systemen und Anbietern ermöglicht.

image
Abbildung 3-1: VWS im Beschaffungsprozess der Leitungssatz-Wertkette

In TP1 wurde daher basierend auf der VWS ein detailliertes und umfassendes Informationsmodell des Leitungssatzes spezifiziert, welches auch die Produktmodellierung des Leitungssatzes umfasst. Dies beinhaltet die detaillierten Anforderungen, die der Leitungssatz erfüllen muss.

Unverzichtbarer Startpunkt für das Arbeiten mit Verwaltungsschalen ist jedoch die Bereitstellung von Typ-Verwaltungsschalen mit digitalen Modellbeschreibungen für die im Leitungssatzkontext verwendeten Komponenten (siehe Spalte „Tier X“ in Abbildung 1-1). Im bisherigen Projektverlauf wurde dieses Thema nicht ausreichend detailliert behandelt und um die Einführungshürden für die betroffenen Unternehmen zu senken, widmete sich TP12 diesem Thema.

Das Teilprojekt wurde in Arbeitspakete aufgeteilt, die in den folgenden Kapiteln näher erläutert werden.

AP 1.1 - Anforderungsanalyse

Im AP1.1 „Anforderungsanalyse“ wurden Grundlagen definiert sowie Zielsetzung und Use Cases für das Teilprojekt geklärt. Zusammenfassend geht es darum, eine minimal notwendige Produktdatenqualität für die Datenmodellierung und ein Konzept zur Generierung eines Produktkatalog aus Produktdatenbanken zu definieren und im Demonstrator der AREN2036 sowie möglichst bei den Projektpartnern umzusetzen.

Ist-Situation

Produktinformationen werden oft ähnlich -aber uneinheitlich- in Online-Produktkatalogen dargestellt, die wesentlichen technischen Daten meist als HTML-Tabellen und zusätzliche Dokumente zum Download angeboten.

image
Abbildung 3-2: Typische Online-Produktkataloge

Derartige Bereitstellungen als HTML-Webseiten sowie PDFs sind jedoch nicht standardisiert maschinenlesbar oder -interpretierbar.

Eine semantische Identifizierbarkeit findet in der Regel nur auf Ebene der Produktkategorie statt, nicht auf Merkmalsebene, was unzureichend ist für die angestrebten typischen Anwendungsfälle.

Anwendungsfälle

Mittels eines VWS-basierten Produktkatalogs und semantischer Klassifizierung bis auf Merkmalsebene sollen die folgenden typischen Anwendungsfälle unterstützt werden:

image
Abbildung 3-3: Anwendungsfälle des VWS-basierten Produktkatalogs

Das TP12 widmet sich im Besonderen des Anwendungsfalls „Herstellerübergreifende maschinelle Produktauswahl (Vergleichsportale, Marktplätze)“. Angerissen wird dabei auch das Thema e-Commerce unter Anwendung der VWS.

Typen von Digitalen Zwillingen

Digitale Zwillinge werden üblicherweise in Untertypen unterteilt, zu denen der Digitale Zwillingsprototyp (DTP), die Digitale Zwillingsinstanz (DTI) und das Digitale Zwillingsaggregat (DTA) gehören. Der DTP besteht aus den Entwürfen, Analysen und Prozessen, d.h. Modellen, die ein physisches Produkt abbilden. Der DTP existiert, bevor es ein physisches Produkt gibt. Der DTI ist der digitale Zwilling jeder einzelnen Instanz des Produkts, sobald es hergestellt ist. Der DTI ist mit seinem physischen Gegenstück für die restliche Lebensdauer des physischen Gegenstücks verbunden. Der DTA ist die Zusammenfassung von DTIs, deren Daten und Informationen für Abfragen über das physische Produkt, Prognosen und Lernen verwendet werden können. Die spezifischen Informationen, die in den digitalen Zwillingen enthalten sind, werden durch Anwendungsfälle bestimmt. Der digitale Zwilling ist ein logisches Konstrukt, was bedeutet, dass die tatsächlichen Daten und Informationen in anderen Anwendungen enthalten sein können [1].

Das Konzept des DTP wird im Folgenden durch die Typ-VWS umgesetzt werden. Der DTI beschreibt das Konzept der Instanz-VWS. Der DTA ist nicht im Scope dieses Teilprojekts.

Folgende Klassen von Typ-VWS sind bei der Entstehung von Leitungssätzen relevant:

Für diese Typ-VWS sind folgende Lebenszyklusphasen bzw. Anwendungsfälle relevant:

Im Folgenden soll die Zusammenstellung von Einzelkomponenten-VWSen zu Hersteller-Produktkatalogen betrachtet werden.

AP 1.2 - Datenmodellierung

Im AP 1.2 „Entwicklung von Informationsmodellen und Zuweisung der Daten“ wurde basierend auf den folgenden vorhandenen Standards die Datenmodellierung von Typ-Verwaltungsschalen für den VWS4LS-Kontext untersucht

Das Ergebnis der Analyse zielte darauf ab, Best-Practice-Ansätze für die Nutzung der Standard-VWS-Metadatenmodelle zu identifizieren und in einem Leitfaden wie folgt zu beschreiben.

Minimal-Inhalte der Typ-VWS

Die folgenden Submodelle werden als Minimalausstattung für die Typ-VWS von LS-Komponenten empfohlen.

SM Technical Data

IDTA 02003-1-2 TechnicalData [2] dient dazu, technische Datenblätter in maschinenlesbarer Form und unter Angabe definierte Semantiken zur Verfügung zu stellen. Der beabsichtigte Anwendungsfall ist, dass ein Hersteller sein Produkt, welches er auf den Markt bringt, mittels technischer Daten (Eigenschaften) beschreibt, die idealerweise mit Hilfe von Wörterbüchern wie ECLASS und IEC Common Data Dictionary (IEC CDD) interoperabel sind und von anderen Marktteilnehmern eindeutig verstanden werden.

image
Abbildung 3-4: IDTA 02003-1-2 TechnicalData

Es wird für Komponenten-VWS im Leitungssatzbereich empfohlen, die Inhalte der SMC TechnicalProperties möglichst weitgehend anhand der VEC-Ontologie zu definieren und mit den entsprechenden semantischen Referenzen zu versehen (siehe hierzu Kapitel 3.2.7).

Semantische Klassifikation

Für die SMC ProductClassification wird die Anwendung von ECLASS, VEC und IEC für die Produktidentifikation empfohlen, bspw. für eine elektrische Leitung wie folgt:

ClassificationSystem ClassificationSystemVersion ProductClassId
VEC 2.1.0 PrimaryPartType_Wire
ECLASS 15.0 (BASIC) 44040101 oder 44040201
IEC 2.0018.0002 0112/2///61360_4#AAA036

Tabelle 31: Inhalte für SMC ProductClassification

Komponenten von Leitungssätzen können Steckverbinder, Leitungen, Verbindungen, Isolierungen und vieles mehr sein. Diese Produktidentifikation muss eindeutig semantisch klassifiziert werden.

ECLASS [3] als weit verbreitetes Klassifikationssystem für Produkte und Dienstleistungen bietet einige Klassifizierungs-Kategorien für den Kfz-Leitungssatz:

Das „Common Data Dictionary“ der IEC [4] bietet ebenfalls tendenziell für den Leitungssatz verwendbare Klassifizierungen, z.B.

Um eine gezielte Produktsuche zu vereinfachen, wird empfohlen, Leitungssatzkomponenten in Produktkatalogen mit den oben aufgeführten Bezeichnern zu klassifizieren.

SM Handover Documentation

IDTA 02004-1-2 HandoverDocumentation [5] definiert ein standardisiertes Austauschformat für Dokumentationsartefakte zu einem bestimmten Asset. Die übergebenen Dokumente können Informationen enthalten, die z.B. für die korrekte Konstruktion, Installation, Inbetriebnahme, Ersatzteilbevorratung, Bedienung, Reinigung, Inspektion, Wartung und Reparatur erforderlich sind. Darüber hinaus gibt es gesetzliche Regelungen, die das Vorhandensein bestimmter Herstellerdokumente vorschreiben können, wie z.B. Konformitätserklärungen der Communauté Européenne (CE), Atmosphères Explosives (ATEX) Zertifikate oder Materialzertifikate.

Ein Bild, das Text, Screenshot, Schrift, parallel enthält. KI-generierte Inhalte können fehlerhaft sein.

Abbildung 3-6: SM HandoverDocumentation

Im Teilmodell HandoverDocumentation müssen relativ wenige relevante Properties beachtet werden, insbesondere die SMC DocumentVersion und DocumentClassification. Da DocumentId als mandatory deklariert ist, kann es nicht weggelassen werden.

Klassifizierungssysteme für Dokumente

Das SM HandoverDocumentation erlaubt die Klassifizierung von Dokumenten unter Verwendung von Referenzsystemen, siehe hierzu auch „4.7.6 Klassifizierungssysteme für “.

Soweit vorhanden, wird empfohlen, die im folgenden aufgeführten Dokumenttypen in der VWS aufzuführen. Weiter wird empfohlen, die Dokumente nicht direkt in der VWS als Datei, sondern besser als Link auf einen Dokumentenserver bereitzustellen. Für die Preview-Files wird die Erstellung geeigneter Thumbnail-Bilddateien empfohlen, die für ganze Produktgruppen einheitlich genutzt werden können.

Als Mindestanforderung muss im SM HandoverDocumentation jedes Dokument nach VDI 2770 Blatt 1:2020-04 klassifiziert werden. Ergänzend kann nach „IEC 61355-1:2008“ klassifiziert werden.

Der Wert von „ClassificationSystem“ ist dazu auf „VDI2770 Blatt 1:2020“ oder „IEC 61355-1:2008“ zu setzen und der Wert von „ClassId“ auf den entsprechenden Code aus den nachstehenden Tabellen:

Datenblatt: Technische Beschreibung (TB)
ClassificationSystem ClassID ClassName (DE) ClassName (EN)
VDI2770 Blatt 1:2020 02-01 Technische Spezifikation Technical specification
IEC 61355-1:2008 DA Datenblätter Data sheets

Tabelle 32: Datenblatt: Inhalte für SMC DocumentClassification

VEC: Technische Beschreibung (TB)
ClassificationSystem ClassID ClassName (DE) ClassName (EN)
VDI2770 Blatt 1:2020 02-01 Technische Spezifikation Technical specification
IEC 61355-1:2008 EC Technische Spezifikations- / Anforderungsdokumente Technical specification / requirement documents

Tabelle 33: Technische Spezifikation: Inhalte für SMC DocumentClassification

Technische Zeichnung (TZ)
ClassificationSystem ClassID ClassName (DE) ClassName (EN)
VDI2770 Blatt 1:2020 02-02 Zeichnungen, Pläne Drawings, plans
IEC 61355-1:2008 ED Dimensionierungsdokumente Dimensioning documents

Tabelle 34: Technische Zeichnung: Inhalte für SMC DocumentClassification

Betriebsanleitung (BA)
ClassificationSystem ClassID ClassName (DE) ClassName (EN)
VDI2770 Blatt 1:2020 03-02 Bedienung Operation
IEC 61355-1:2008 DC Anleitungen und Handbücher Instructions and manuals

Tabelle 35: Betriebsanleitung: Inhalte für SMC DocumentClassification

Konformitätserklärung (KE)
ClassificationSystem ClassID ClassName (DE) ClassName (EN)
VDI2770 Blatt 1:2020 02-04 Zertifikate, Deklaration Certificates, Declaration
IEC 61355-1:2008 EB Normen und Richtlinien Standards and regulations

Tabelle 36: Konformitätserklärung: Inhalte für SMC DocumentClassification

SM Digital Nameplate

IDTA 02006-2-0 Digital Nameplate for Industrial Equipment [6] zielt darauf ab, den jeweiligen Verwaltungsschalen interoperable Informationen über Anlagenkennzeichen zur Verfügung zu stellen.

Ein Bild, das Text, Screenshot, Schrift, Reihe enthält. KI-generierte Inhalte können fehlerhaft sein.

Abbildung 3-7: SM DigitalNameplate

Das SM DigitalNameplate enthält einige instanzbezogene Properties. Diese und sonstige Nicht-sinnvolle Properties dürfen für die Anwendung in der Typ-VWS nicht befüllt oder sollten entfernt werden. Das betrifft vor allem SerialNumber, DateOfManufacture sowie FirmwareVersion, SoftwareVersion. Eine Ausnahme wird vorgeschlagen für URIOfTheProduct, wo der Link auf eine ausserhalb des VWS-Ökosystems vorhandenen Online-Produktkatalogseite eingebracht werden kann, um hierüber eine sinnvolle Informationsverlinkung herzustellen.

Bei einigen Properties im SM DigitalNameplate gibt es Redundanzen zum SM TechnicalData, die beachtet und konsistent gehalten werden müssen, bei ManufacturerName besteht eine gewisse Typinkonsistenz:

SM „Digital Nameplate“ SM „Technical Data“ Inhalt
ManufacturerName [MLP] ManufacturerName [Prop] Textueller Bezeichner ohne Sonderzeichen
ManufacturerProductDesignation [MLP] ManufacturerProductDesignation [MLP] Beschreibender Kurztext, sprachabhängig
ProductArticleNumberOfManufacturer [Prop] ManufacturerArticleNumber [Prop] Textueller Bezeichner ohne Sonderzeichen
OrderCodeOfManufacturer [Prop] ManufacturerOrderCode [Prop] Textueller Bezeichner ohne Sonderzeichen
CompanyLogo [File] ManufacturerLogo [File] Langzeitstabile URL auf Bilddatei oder angehängte Datei

Tabelle 37: Redundante Properties in SM DigitalNameplate und SM TechnicalData

Produkthierarchie

Das SM DigitalNameplate enthält als wesentliche Informationsbestandteile für den Produktkatalog die Produkthierarchie, welche über die folgenden Properties abgebildet wird:

ManufacturerProductRoot top level of a 3-level manufacturer specific product hierarchy
ManufacturerProductFamily second level of a 3-level manufacturer specific product hierarchy
ManufacturerProductDesignation third or lowest level of a 3-level manufacturer specific product hierarchy
ManufacturerProductType characteristic to differentiate between different products of a product family or special variants

Tabelle 38: Properties für Produkthierarchie

Es wird empfohlen, dass jede Organisation für sich ein klar definiertes Konzept entwirft, wie diese Properties in der VWS konkret befüllt werden sollen. Siehe dazu auch Kapitel 3.3 „AP 1.3 - Extraktionslogik (ETL) entwickeln“.

Kennzeichen

Die SMC Markings soll Verweise auf relevante Conformance-Standards und -Organisationen enthalten, idealerweise mit einem geeigneten Logo zur grafischen Darstellung. In DesignationOfCertificateOrApproval sollte der jeweilige exakte Spezifikationsname verwendet werden, für MarkingName eine gängige Abkürzung.

Spezifikationen für Produktkonformität im Automotive-Umfeld sind bspw.:

LV216-2 Tabelle A.2 VDA-Standard für geschirmte Hochspannungsmantelleitungen für Kraftfahrzeuge und deren elektrische Antriebe
NaBMW GS 95007-6-2  
BMW 9 327 162.9  
Mercedes C51 / 12.14  
Daimler Truck A0025460501  
VW N 107 777  
VW N 108 888  

Tabelle 39: Automotive-Spezifikationen

Wenn kein zugehöriges Logo in Form einer Bilddatei vorhanden ist, wird aus Darstellungsgründen empfohlen, ein Logo generativ mit dem Text des Dokuments zu erzeugen, z.B.

Ein Bild, das Text, Schrift, Screenshot, Grafiken enthält. KI-generierte Inhalte können fehlerhaft sein.Ein Bild, das Kreis, Oval, Logo enthält. KI-generierte Inhalte können fehlerhaft sein.Ein Bild, das Text, Schrift, Screenshot, Design enthält. KI-generierte Inhalte können fehlerhaft sein.

Ein Bild, das Schwarz, Dunkelheit enthält. KI-generierte Inhalte können fehlerhaft sein.

Abbildung 3-8: SM Marking Logos

Benennung der VWS

Prägendes Element für die Benennung einer VWS ist die idShort. Es wird empfohlen, diese inhaltlich sprechend zu gestalten, dass der Herstellername, die Produktfamilie und die Artikelnummer enthalten ist. Bei AASX-Dateiausleitungen sollte die idShort die Basis für den Dateinamen bilden.

Im Folgenden ist detaillierter erklärt, welche Aspekte bei der ID-Bildung beachtet werden sollten.

ID-Bildung

Eine systematische ID-Definition ist relevant für die langfristige Wartbarkeit des VWS-Systems. Es wird eine methodische Vorgehensweise empfohlen, nach der VWS-Veröffentlicher bei der ID-Bildung vorgehen können.

Es gibt folgende Arten von Identifizierern:

VWS-Metadaten Inhalt
idShort Textueller Bezeichner ohne Leer- und Sonderzeichen, idealerweise identisch oder ähnlich der ProductArticleNumberOfManufacturer bzw. ManufacturerArticleNumber
VWSId URI/IRI
globalAssetId URI/IRI nach IEC 61406 (Identification Link), wird als QR-Code aufgebracht und fungiert als Digitales Typenschild.
semanticId GUID, IRDI, URI/IRI als Referenz auf einen semantischen Datensatz, z.B. im Concept Description Repository, der ECLASS-Datenbank oder dem IEC-CDD.

Tabelle 310: VWS Metadaten

Die Anwendung von Uniform Resource Identifier (URI)/ Internationalized Resource Identifier (IRIs) wird als bevorzugte Methode (vor IRDIs, GUIDs ) zur Bildung von global unverwechselbaren IDs empfohlen. Die VWS-Metamodell-Spezifikation [7] beschreibt dazu eine „Best Practice for Creating URI Identifiers“, basierend auf folgendem Grammatik-Schema:

Ein Bild, das Text, Screenshot, Schrift, Algebra enthält. Automatisch generierte Beschreibung

Abbildung 3-9: Grammatik für URI Identifier

Es wird empfohlen, diesen generischen Strukturvorschlag wie im Folgenden beschrieben in vereinfachter Form anzuwenden, ggf. im <path> auf die Elemente <domain> und <release> zu verzichten. Insbesondere <release> als Bestandteil der ID kann langfristig problematisch werden, sollte sich diese ändern. Im Falle der von Notwendigkeit von geänderten Versionsständen (die aus Wartbarkeitsgründen generell vermieden werden sollten) könnten diese besser per Query-Parameter abgefragt werden.

Die „aasId“ der VWS ist die global eineindeutige Identifikations-Zeichenketten zur Kennung der VWS in Form eines URI/IRI nach RFC 3987, wobei darauf zu achten, dass der verwendete Zeichensatz des Kennzeichnungssystems kompatibel zu RFC 3986 ist, d.h. aus sog. „unreserved characters“ besteht und prozentcodierte Bestandteile konsequent vermeidet.

Die „idShort“ ist ein optionaler kurzer textueller Bezeichner, der nur in diesem Kontext eindeutig sein muss. Die idShort darf keine Leerzeichen oder Sonderzeichen enthalten und nur Ziffern, Buchstaben und das „“-Symbol enthalten ([a-zA-Z][a-zA-Z0-9]). Zudem muss die erste Ziffer ein Buchstabe sein.

Sobald eine Asset Administration Shell für die Produktion oder den Betrieb “freigegeben” ist, sollte eine „globalAssetId“ als Zugriffslink zugewiesen werden. Diese Asset-ID kann z.B. über einen QR-Code auf dem Asset, über ein RFID für das Asset, aus der Firmware des Assets oder aus einer Asset-Datenbank abgerufen werden. Die IEC 61406 (früher DIN SPEC 91406) definiert das Format solcher Asset-IDs und es wird empfohlen den IdentificationLink nach IEC 61406-1 [8] als Basis sowohl für die id als auch für die globalAssetId zu verwenden. Die URI/IRI kann systematisch so aufgebaut werden, dass Sie gleichzeitig zur produktbezogenen Referenzierung und Verlinkung in den Digitale Produkttyp (DTP) und die Digitale Produktinstanz (DPI) definiert werden kann:

Der IdentificationLink könnte sich demnach nach einem der folgenden Beispiele systematisch zusammensetzen:

Würde man diese Typ-URI/IRI dann um bspw. die serialNumber erweitern, könnte man damit die URI/IRI für die Produktinstanz erzielen:

Alternativ kann auch eine Linkbildung nach IEC61406-2 [9] erfolgen, wobei dann die Identifikationsparameter nicht im URL-Pfad codiert sind, sondern als Query-Parameter mitgegeben werden.

Dieser Identification Link nach IEC 61406 [8] [9] verbindet ein Produkt nahtlos mit seinen Informationen im Internet – dem Digitalen Typenschild (Digital Nameplate, DNP) als Schlüsseltechnik für Industrie 4.0 -Anwendungen, wie bspw. den Digital Product Passport (DPP).

[8] [9]Best-Practice-Kochrezept

Hier eine zusammenfassende Übersicht der Empfehlungen zur ID-Definition:​

Ein Bild, das Text, Screenshot, Schrift, Diagramm enthält. KI-generierte Inhalte können fehlerhaft sein.

Abbildung 3-10: Basic URL Structure

  1. Protocol (scheme) „https://“ (nicht „http://“) verwenden wegen Linkfähigkeit
  2. Domain-Name (authority) des Komponentenherstellers verwenden
  3. Möglichst kurze Root Domain
  4. Subdomain oder Subdirectory „VWS“ wird empfohlen für ID
  5. Subdomain oder Subdirectory „asset“ wird empfohlen für globalAssetId
  6. Im Pfad Sonderzeichen und Leerzeichen vermeiden (RFC 3986)
  7. Keine Sprachabhängigkeiten im Pfad (z.B. „/en/“, „/de/“)
  8. Zufallsstrings (z.B. UUIDs) als ID-Bestandteil vermeiden!
  9. Pfadbestandteile ohne semantischen Informationsgehalt vermeiden
  10. Auf bestehendem ID-System aufsetzen, bspw. Artikelnummern (z.B. „https://aas.kostal.com/10142491“)
  11. Passendes gleichförmiges Schema für Submodell-IDs verwenden (z.B. „https://aas.kostal.com/sm/nameplate/10142491“)
  12. IdShort: menschenlesbarer kurzer String, ohne Sonderzeichen, ggf. nach dem Schema „{ManufacturerName}{M*anufacturerProductFamily*}{ManufacturerArticleNumber}“ aufbauen, (z.B. KOSTAL_PLK14_10142491)
  13. Ggf. IdShort als ID-Bestandteil im URI/IRI-Pfad verwenden (z.B. „https://VWS.kostal.com/KOSTAL_PLK14_10142491“)
  14. Analog gleichförmiges Schema für Dateinamen anwenden, z.B. „KOSTAL_PLK14_10142491_v10.aasx“

Benennung der Submodelle

Es wird empfohlen, die Benennung der IDTA-Submodelle möglichst nicht zu verändern. In untergeordneten Strukturen werden bspw. für SMC-Listenelemente menschenlesbare Benennungen empfohlen, anstelle der in den SMT-Spezifikationen manchmal empfohlenen fortlaufenden Nummerierungen (siehe Abbildung 3-11).

Abbildung 3-11: Benennung der Submodell-Elemente

Versionierung

Die Versionierung einer VWS erfolgt über die administrativen Metadaten (Version, Revision, Creator) und sollte entsprechend der unternehmensinternen Prozesse gepflegt werden.

Ein Bild, das Text, Screenshot, Schrift, Zahl enthält. KI-generierte Inhalte können fehlerhaft sein.

Abbildung 3-12: Versionierung

Es muss darauf hingewiesen werden, dass im VWS-Metamodell derzeit immer noch keine Metadaten für die Historieninformation verfügbar sind, was die praktische Nutzbarkeit der VWS-Technologie stark einschränkt. Siehe dazu auch AdministrativeInformation: New properties “createdAt” and “lastModified” · Issue #520 · admin-shell-io/aas-specs-metamodel5.

Semantische Referenzierung in der VWS

Semantische Referenzierung stellt sicher, dass Daten in der Verwaltungsschale nicht nur Werte enthalten, sondern auch deren Bedeutung klar definiert ist. Dies ermöglicht Interoperabilität zwischen Systemen, da die Daten kontextbezogen interpretiert werden können. Beispielsweise wird eine Eigenschaft wie “Temperatur” nicht nur als Zahl (z. B. 25) dargestellt, sondern mit einer eindeutigen Definition verknüpft (z. B. “Temperatur in Grad Celsius”).

Dies geschieht hauptsächlich durch die semanticId und die Concept Description. Die semanticId verweist auf eine Definition (extern oder intern), während die ConceptDescription als eigenständiges Element in der Verwaltungsschale eine detaillierte semantische Beschreibung eines Konzepts (z. B. einer Eigenschaft, Einheit oder eines Objekts) bereitstellt.

Andere Systeme können die semanticId auswerten, die referenzierte Definition nachschlagen (entweder direkt oder über die ConceptDescription) und die Bedeutung der Daten verstehen. Diese grundsätzlichen Arten der Referenzierung werden unterschieden:

{
  "modelType": "ConceptDescription",
  "id": "http://example.com/concept/diameter",
  "idShort": "diameter",
  "displayName": [
    {
      "language": "en",
      "text": "diameter"
    }
  ],
  "embeddedDataSpecifications": [
    {
      "dataSpecification": {
        "type": "ExternalReference",
        "keys": [
          {
            "type": "GlobalReference",
            "value": "http://admin-shell.io/DataSpecificationTemplates/DataSpecificationIEC61360/3/0"
          }
        ]
      },
      "dataSpecificationContent": {
        "preferredName": [
          {
            "language": "en",
            "text": "diameter"
          },
          {
            "language": "de",
            "text": "Durchmesser"
          }
        ],
        "unit": "mm",
        "unitId": {
          "type": "ExternalReference",
          "keys": [
            {
              "type": "GlobalReference",
              "value": "0173-1#05-AAA480#004"
            }
          ]
        },
        "dataType": "REAL_MEASURE",
        "definition": [
          {
            "language": "en",
            "text": "extension, measured as spacing..."
          },
          {
            "language": "de",
            "text": "Ausdehnung, gemessen als Abstand..."
          }
        ],
        "modelType": "DataSpecificationIec61360"
      }
    }
  ]
}

Eine ConceptDescription fungiert als Metadaten-Container und enthält Informationen wie:

Die semanticId und die ConceptDescription zusammen ermöglichen eine vollständige semantische Referenzierung innerhalb des VWS-Ökosystems.

Data Specification IEC 61360

Eine Concept Description ist anhand des Templates „DataSpecificationIec61360“ aufgebaut (Abbildung 3-13), welches spezifische Attribute wie preferredName, unit, dataType und definition enthält. Siehe hierzu auch IDTA-01003-3-0: Specification Asset Administration Shell – Part 3a: Data Specification IEC 613606 und IDTA_Tutorial_VWS-Specification_Part3a_DataSpec_IEC61360.pdf7.

Ein Bild, das Text, Screenshot, Schrift, Dokument enthält. KI-generierte Inhalte können fehlerhaft sein.

Abbildung 3-13: DataSpecification nach IEC61360

Ein Bild, das Text, Screenshot, Software, Zahl enthält. KI-generierte Inhalte können fehlerhaft sein.

Abbildung 3-14: AASPE Beispiel DataSpecification nach IEC61360

Einheitendeklaration in der Concept Description

Die IDTA GUIDELINE: How to transport ECLASS in the Asset Administration Shell [10] beschreibt die Anwendung von ECLASS und Einheitendefinitionen über ConceptDescriptions. Es wird allerdings empfohlen, auch die in dem Dokument nicht berücksichtigte property symbol zu belegen, damit Viewer Tools sicher anzeigen können.

Ein Bild, das Text, Screenshot, Schrift, Reihe enthält. KI-generierte Inhalte können fehlerhaft sein.

Abbildung 3-15: Beispiel zur Einheitendefinition mittels einer Concept Description

Alternativ zu ECLASS (welches ohnehin auf IEC 62720 referenziert) wird empfohlen, direkt auf Einheitendefinitionen in IEC 62720 zu verweisen, und zwar mittels URI-Referenzen über http://qudt.orq, da diese Lösung gleichzeitig eine attraktive Onlinedarstellung bereitstellt (siehe z.B. https://qudt.org/vocab/unit/MilliM):

Ein Bild, das Text, Screenshot, Software, Display enthält. KI-generierte Inhalte können fehlerhaft sein.

Abbildung 3-16: QUDT-Onlinedarstellung

Siehe zu diesem Thema auch Kapitel „4.7.6 Klassifizierungssysteme für Einheiten“.

Anwendung des VEC

VEC [11] ist das führende Modellierungssystem der Leitungssatzbranche und stellt präzise semantische Definitionen für Komponentenmerkmale und Datentypen bereit. Um Inkonsistenzen im Produktlebenszyklus zu vermeiden, wird empfohlen, in Produktkatalogen und Datenblättern nur Merkmale aufzuführen, die auch im VEC-Standard definiert sind. In der VWS sind diese mit einer mit einer entsprechenden semantischen Referenz auf die VEC-Definition zu versehen, um die maschinelle Interpretierbarkeit sicherzustellen. Im Idealfall erstellt bereits der Komponentenhersteller ergänzend eine komplette VEC-Spezifikation für seine jeweilige Komponente und fügt diese der VWS als Dateianhang hinzu.

Ein Bild, das Text, Screenshot, Software, Design enthält. Automatisch generierte Beschreibung

Abbildung 3-17: Vehicle Electric Container (VEC)

Für die Produktklassifizierung über den VEC eignet sich die Klasse PrimaryPartType8.

Ein Bild, das Text, Screenshot, Schrift, Diagramm enthält. Automatisch generierte Beschreibung

Abbildung 3-18: VEC-Datenmodell: Description of Parts

Es liegt nahe, für leitungssatzspezifische Properties in Produktkatalogen auf die Definitionen des VEC zurückzugreifen und entsprechend im Submodel „TechnicalData“ [2] in der SMC TechnicalProperties darauf zu verweisen.

Unter https://ecad.prostep.org/ontologies/2024/03/vec wird eine Ontologie in „RDF 1.1 Turtle“-Syntax bereitgestellt. Deren Anwendung ist in Kapitel 4.7.5.3 VEC erläutert.

A diagram of a machine Description automatically generated

Abbildung 3-19: Beispiel VEC Terminal Datamodell (Quelle: VEC Recommendation V2.1)

Sowohl in der OPC UA Companion Spec. „OPC 40570: OPC UA for the Wire Harness Manufacturing Industry“ [12] als auch der DIN 72036 [13] wird als semantische Referenzierung auf die Ontologie des VEC verwiesen.

Als bevorzugte Lösung wäre es daher wünschenswert, dass Komponentenlieferanten grundsätzlich ein vollständiges VEC-Modell als Handover-Dokumentation zu Ihrer Komponente bereitstellen. Unabhängig davon wird der im Folgenden beschriebene Ansatz als Migrationspfad empfohlen, um eine Angleichung der Datenmodelle zwischen Produktkatalog und VEC zu erreichen:

Im Sinne konsistenter Datendefinitionen über den Produktlebenszyklus hinweg wurde versucht, auch die im Online-Katalog dargestellten Produktdaten (im Submodell TechnicalData enthalten) auf dem VEC-Datenmodell basierend zu definieren, um eine semantische Kompatibilität der im klassischen Produktdatenblatt eines Online-Katalog dargestellten Informationen zur VEC-Ontologie zu erreichen.

In Kapitel 4.7.5.3 ist das Prinzip der Referenzenbildung zur VEC-Ontologie erläutert.

NumericalValue (VEC) als Property (VWS) modellieren

Modellierung eines VEC-NumericalValue durch verschiedene VWS-Konzepte und deren Bewertung

Variante 1: Definition der Einheit in der Konzeptbeschreibung

{

“idShort”: “vec_terminalTypeNominalSize”,

“description”: [

{

“language”: “en”,

“text”: “Specifies the nominal size of terminals that fit into the cavity. (e.g. 2x4).”

}

],

“id”: “http://www.prostep.org/ontologies/ecad/2024/03/vec#terminalTypeNominalSize”,

“embeddedDataSpecifications”: [

{

“dataSpecificationContent”: {

“preferredName”: [

{

“language”: “en”,

“text”: “ Terminal Size”

}

],

“unit”: “Millimeter”,

“sourceOfDefinition”: “http://qudt.org/vocab/unit/MilliM”,

“symbol”: “mm”,

“dataType”: “REAL_MEASURE”,

“definition”: [

{

“language”: “en”,

“text”: “Specifies the nominal size of terminals that fit into the cavity. (e.g. 2x4).”

},

{

“language”: “de”,

“text”: “Gibt die Nenngröße der Klemmen an, die in den Hohlraum passen. (z. B. 2x4).”

}

],

“modelType”: “DataSpecificationIec61360”

},

“dataSpecification”: {

“type”: “ExternalReference”,

“keys”: [

{

“type”: “GlobalReference”,

“value”: “http://admin-shell.io/DataSpecificationTemplates/DataSpecificationIEC61360/3/0”

}

]

}

}

],

“modelType”: “ConceptDescription”

}

Ein Bild, das Text, Screenshot, Schrift, Reihe enthält. KI-generierte Inhalte können fehlerhaft sein.

Abbildung 3-20: Einheitendefinition in der Concept Description für ein VEC NumericalValue

Problem:

- Die Einheit (z.B. in m, mm, Zoll) ist damit global für die referenzierte VEC-Eigenschaft für alle VWS auf dem VWS-Server definiert.

- Bei Einheitenwechsel aus einer nativen Quelle kann eine Konvertierung mit Rundungsfehlern auftreten, da es im Kontext Einheiten gibt, die nicht direkt umrechenbar sind (z.B. Leitungsquerschnitte in mm² vs. AWG analog wie zöllige und metrische Gewinde). Die meisten CAD-Formate (bspw. STEP oder JT sind Einheiten agnostisch).

Betrachtung des folgenden Szenarios: Hersteller X gibt seine Daten frei (in Inches) und will seine Daten in einem zentralen VWS Marketplace einstellen. Dort werden jetzt die Inches in Meter umgerechnet. Falls nun diese digitalen Daten auch für digitale Verhandlungsprozesse genutzt werden und dann auch Vertragsgrundlage sind, wer verantwortet es, wenn die Daten aufgrund von Rundungsfehlern bei der Umrechnung nicht stimmen? Der Hoster des Marketplace? Der Einsteller der Daten, weil er das, was umgerechnet wurde, nicht nochmal geprüft hat, der Datenempfänger, weil er sich auf die Daten verlassen hat, oder der Hersteller der VWS-Repository Service?

Variante 2: Erstellen einer Konzeptbeschreibung für jede Einheit-Eigenschafts-Kombination, z. B.

Problem: Der semantische Bezug zwischen den Konzeptbeschreibung und der VEC-Spezifikation würde verloren gehen.

Variante 3: Definition der Einheit in der eingebetteten Datenspezifikation jedes VEC Properties

Ein Bild, das Text, Screenshot, Software, Zahl enthält. KI-generierte Inhalte können fehlerhaft sein.

Abbildung 3-21: Definition der Einheit in der eingebetteten Datenspezifikation der Property

Problem: Erzeugt potentielle Redundanz.

Basierend auf der dargestellten Analyse wird für metrische Einheiten die Anwendung der Variante 1 als Standard empfohlen, für andere Einheitensysteme die Anwendung der Variante 3, um das Risiko von Rundungsfehlern bei der Einheitenkonvertierung in der Verantwortung des Datenempfängers zu belassen.

VEC als VWS-Submodell

Für die OSS Harness Lib wurde seitens 4Soft ein „experimental“ Modul „vec-VWS-conversion“9 erstellt, um einen VEC verlustfrei in ein VWS-Submodell konvertieren zu können. Dabei wurden Modellierungsschwächen im Bereich der VWS-Properties offenbart, insbesondere zur Definition von Bereichswerten und Toleranzen.

Die Behebung dieser Modellierungsschwächen wurde daraufhin bei der IDTA in die Wege geleitet.

Den Ansatz der verlustlosen Transformation des VEC in ein VWS-Submodell wurde daraufhin nicht weiterverfolgt, da der VEC als formal definierte Spezifikation vorliegt und als solcher im Originalformat an die VWS angehängt werden kann.

VEC als HandoverDocumentation

Als praktikabelste Lösung wurde schließlich die Einbindung der VEC-Datei als HandoverDocument angesehen und auch zur Anwendung empfohlen.

  1. https://industrialdigitaltwin.org/use-cases/collaborative-engineering-die-technologische-grundlage-zur-digitalisierten-wertschoepfungskette ↩

  2. https://cdd.iec.ch/cdd/iec61360/iec61360.nsf/TU0/0112-2---61360_4%23AAA548 ↩

  3. https://cdd.iec.ch/cdd/iec61360/iec61360.nsf/classes/0112-2---61360_4%23AAA036 ↩

  4. https://cdd.iec.ch/cdd/iec61360/iec61360.nsf/TU0/0112-2---61360_4%23AAA611 ↩

  5. https://github.com/admin-shell-io/aas-specs-metamodel/issues/520 ↩

  6. https://industrialdigitaltwin.io/aas-specifications/IDTA-01003-a/v3.1/index.html ↩

  7. https://www.industrialdigitaltwin.org/en/wp-content/uploads/sites/2/2023/09/2023-09-28_IDTA_Tutorial_VWS-Specification_Part3a_DataSpec_IEC61360.pdf ↩

  8. http://www.prostep.org/ontologies/ecad/2024/03/vec#PrimaryPartType ↩

  9. https://github.com/4Soft-de/harness-model/pull/313 ↩

This site is open source. Improve this page.