Die Druckversion wird nicht mehr unterstützt und kann Darstellungsfehler aufweisen. Bitte aktualisiere deine Browser-Lesezeichen und verwende stattdessen die Standard-Druckfunktion des Browsers.

aiMOOC

Industrielle Datenqualität und digitale Schnittstellen

QR-Code

Einleitung

Maschinen liefern Messwerte, aber ein Zahlenwert allein ist noch keine verlässliche Information. Erst mit eindeutiger Maschinenkennung, Messgröße, Einheit, Zeitbezug und Qualitätsstatus kann eine andere Anwendung die Daten sinnvoll nutzen. In diesem aiMOOC erarbeitest du einen JSON-Datenvertrag und ordnest dessen Felder einem Informationsmodell der Verwaltungsschale (Asset Administration Shell, AAS) zu.

Zielgruppe: Auszubildende, empfohlen im 2. Ausbildungsjahr. Voraussetzungen: Lernstufe Z1 oder vergleichbare KI- und Datenkompetenz sowie Grundwissen über Sensoren und physikalische Einheiten. Die vorhandene Grundlage dient zur kurzen Wiederholung; ihr Seiteninhalt war beim Quellenabruf nicht direkt verfügbar. Lernzeit: etwa 4 bis 6 Unterrichtseinheiten einschließlich Lernnachweis.

Dein Lernweg: Grundbegriffe aktivieren, ein geführtes Prüfbeispiel untersuchen, einen Vertrag formulieren und auf neue Modellmaschinen übertragen. Arbeite mit Texteditor und Papier; kostenpflichtige KI-Dienste, Internetzugang und reale Anlagen sind nicht nötig. Sämtliche Maschinen und Messreihen sind erfunden. Keine echte Maschinensteuerung, keine Sicherheitsfreigabe und keine produktive Anlagenanbindung. Das Angebot ist unabhängig und stellt keine offizielle Liebherr- oder IHK-Zertifizierung dar.

Kompetenzen: Du kannst Datenqualität entlang konkreter Kriterien beurteilen, JSON und CSV unterscheiden, Zeitstempel und Einheiten prüfen, fehlende Kennungen melden und maschinenlesbare Felder semantisch einer AAS zuordnen. Als anspruchsvolle Vertiefung untersuchst du Versionierung, Schemaänderungen und die Grenzen rein syntaktischer Interoperabilität.

Datenqualität als Voraussetzung für zuverlässige Aussagen

Kurze Aktivierung des Vorwissens

Ein Sensor wandelt eine physikalische Größe in ein Signal um. Wiederhole: Was ist der Unterschied zwischen Messwert, Einheit und Messzeitpunkt? Wie unterscheidet sich ein Fehler in einer Datenzeile von einer tatsächlichen Zustandsänderung? Notiere je einen Satz, bevor du weiterliest.

Begriffe: Ein Datensatz enthält zusammengehörende Felder. Metadaten beschreiben beispielsweise Herkunft, Einheit, Version und Messzeit. Datenqualität bezeichnet die Eignung von Daten für einen definierten Zweck. Ein numerisch plausibler Wert kann unbrauchbar sein, wenn die Einheit falsch ausgezeichnet wurde.

Sechs praktisch prüfbare Qualitätsmerkmale

Merkmal	Prüffrage	Folge bei Fehler
Vollständigkeit	Sind Maschinen-ID, Zeitstempel und Pflichtmesswerte vorhanden?	Meldung, Datensatz zurückstellen
Gültigkeit	Passen Format, Wertebereich und Zeitdarstellung zum Vertrag?	Ablehnen oder für Klärung markieren
Einheitentreue	Stimmt die ausgewiesene Einheit mit dem Messgrößenmodell überein?	Nicht stillschweigend umrechnen
Eindeutigkeit	Ist ein Ereignis mit ID und Zeit eindeutig identifizierbar?	Dubletten prüfen
Konsistenz	Stimmen Spaltenbeschreibung und tatsächlicher Inhalt überein?	Widerspruch dokumentieren
Aktualität und Herkunft	Wie alt ist der Wert und aus welcher Quelle stammt er?	Verwendbarkeit begrenzen

Merke: Fehlend ist nicht gleich null. Eine nicht gemessene Temperatur darf nicht als 0 °C in eine Statistik geraten. Ein Alarm über schlechte Datenqualität ist nicht automatisch ein Maschinenalarm.

Abbildung: Ebenen eines IIoT-Systems (englische Beschriftung). Quelle: Wikimedia Commons, Sujata Tilak, CC BY-SA 4.0. Ohne Bild: Daten werden an der Maschine erfasst, an einer Plattform verarbeitet und in Unternehmensanwendungen ausgewertet.

Dokumentation statt voreiliger Reparatur

Unterscheide drei Reaktionen: annehmen bei bestätigter Qualität, zurückweisen bei Regelverletzung und in Quarantäne prüfen bei ungeklärter Einheit oder Quelle. Die ursprüngliche fehlerhafte Zeile bleibt im Protokoll; eine Korrektur erfordert belegbare Herkunft und einen Änderungsvermerk.

Lernhilfe: Prüfe zuerst, ob der Wert überhaupt einer Maschine zugeordnet werden kann, danach seinen Zeitpunkt, die Einheit und schließlich die fachliche Plausibilität. Vertiefung: Datenqualität ist zweckabhängig: Für eine Unterrichtsauswertung kann eine verzögerte Messung reichen; für einen Echtzeitregler nicht. Unsere Aufgabe umfasst ausdrücklich keinen Regler.

Datenformate und digitale Schnittstellen verstehen

CSV und JSON im Vergleich

CSV speichert Tabellenzeilen mit Trennzeichen. Eine CSV-Datei kann kompakt sein, aber Einheiten, Datentypen und Pflichtfelder sind ohne zusätzliche Beschreibung oft nicht eindeutig. Dezimalkomma und Trennzeichen müssen festgelegt werden. JSON besitzt benannte Schlüssel und verschachtelte Objekte. JSON kennt beispielsweise Zahlen, Zeichenketten, Wahrheitswerte und null, aber keine eingebaute Einheitensemantik. Die Zeichenfolge eines Zeitstempels muss gesondert geprüft werden.

Beispiel einer eindeutigen tabellarischen Zeile, hier mit Semikolon als Separator:

machineId;timestamp;pressure;pressureUnit;loadPercent
M-01;2026-10-21T08:00:00Z;180;bar;40

Die gleiche Aussage als vereinfachtes JSON:

{
  "machineId":"M-01",
  "timestamp":"2026-10-21T08:00:00Z",
  "pressure":{"value":180,"unit":"bar"},
  "loadPercent":40
}

Wichtig: Ein gültig lesbarer JSON-Text kann fachlich falsche Daten enthalten. JSON ist ein Übertragungsformat und für sich allein kein Qualitäts- oder Kompatibilitätsnachweis.

JSON-Erkennungszeichen: Dateiseite Wikimedia Commons, Urheber Douglas Crockford; einfache Text-/Geometrieform, gemeinfrei (mögliche Zeichenrechte beachten). Ohne Bild: JSON steht für JavaScript Object Notation und überträgt Schlüssel-Wert-Strukturen.

Schnittstelle, Protokoll und Semantik

Eine digitale Schnittstelle ist eine vereinbarte Grenze, über die Systeme Daten austauschen. Eine API beschreibt zugängliche Operationen und Datenformen. Ein Protokoll regelt die technische Kommunikation. Ein Informationsmodell bestimmt, was ein Feld fachlich bedeutet. Interoperabilität entsteht erst, wenn die beteiligten Systeme Daten nicht nur transportieren, sondern auch korrekt interpretieren können.

OPC UA bietet hersteller- und plattformübergreifende Dienste und ein erweiterbares Informationsmodell; Authentisierung, Verschlüsselung und Zugriffskonzepte gehören zur Architektur. OPC UA löst aber nicht automatisch falsch gepflegte Quellmetadaten. Companion Specifications können einheitliche fachliche Strukturen bereitstellen.

Historisches Architektur-Schema, Stand 2014: Wikimedia Commons, Vshebordaev, CC BY-SA 3.0; keine vollständige Darstellung aktueller OPC-UA-Spezifikationen. Ohne Bild: Anwendungen verwenden standardisierte Dienste und Informationsmodelle auf einer Kommunikationsschicht.

Ergänzendes deutschsprachiges Video: DKE, „Industrie 4.0 – Eine Basis-Norm für Industrie 4.0 – OPC UA“, veröffentlicht 2015. Die Metadaten der Videoseite sind auffindbar; aktuelle Abspielbarkeit und historische Aktualität sind nicht garantiert. Textalternative: OPC UA koppelt Kommunikation mit durchsuchbaren Datenstrukturen; Rechte und fachliche Modelle müssen zusätzlich beachtet werden.

Vertiefung: Vergleiche Versionsänderungen: Das neue Feld "vibrationMmS" ist eine abwärtskompatible Ergänzung, solange alte Empfänger unbekannte Zusatzfelder ignorieren dürfen; eine geänderte Bedeutung von "pressure" unter gleichem Namen ist gefährlich. Entscheidend ist ein expliziter Vertrag, nicht allein der Dateiname.

Geführter Modellfall mit fehlerhaften Messreihen

Ausgangslage und Lastwechsel

Drei erfundene Modellmaschinen M-01, M-02 und M-03 liefern Druck, Temperatur und Last. Die Modellvorgabe lautet: Druck in bar, Temperatur in °C, Last in % und Zeit als ISO-8601-UTC-Zeitstempel mit Z. Druckwerte von 0 bis 250 bar und Lastwerte von 0 bis 100 % dienen nur als didaktische Testgrenzen dieser Simulation; sie sind keine Grenzwerte echter Maschinen.

Zeile	Maschinen-ID	UTC-Zeit	Last %	Druck	Einheit	Temperatur °C	Befund
A	M-01	2026-10-21T08:00:00Z	40	180	bar	39	Referenz
B	M-01	2026-10-21T08:01:00Z	75	205	bar	43	Lastwechsel
C	M-02	2026-10-21T08:00:00Z	35	180	kPa	37	Einheitenkonflikt
D	[fehlt]	2026-10-21T08:01:00Z	55	175	bar	38	Kennung fehlt
E	M-03	2026-10-21T08:61:00Z	60	190	bar	41	Ungültige Minute
F	M-02	2026-10-21T08:02:00Z	55	[fehlt]	bar	38	Datenlücke

Achtung: In C steht zwar die Zahl 180, aber "kPa" bedeutet nicht "bar". 180 kPa entsprechen 1,8 bar; ob Zahl oder Einheit falsch erfasst wurde, ist aus dieser Zeile nicht feststellbar. Korrigiere deshalb weder auf 180 bar noch auf 1,8 bar ohne Rückfrage an die fiktive Quelle. D kann keiner eindeutigen Maschine zugeordnet werden. In E ist Minute 61 ungültig; diese Zeichenfolge ist kein zulässiger Zeitpunkt.

Drei zwingende Prüfentscheidungen

Prüffall Einheit: Akzeptiere nur die Vertrags-Einheit "bar". Ergebnis bei C: unit_mismatch, sperren und Herkunft klären. Eine dokumentierte, bestätigte Quellumrechnung wäre ein eigener Verarbeitungsschritt.

Prüffall ID: Eine nichtleere, registrierte "machineId" ist Pflicht. Ergebnis bei D: missing_machine_id, zur Klärung abweisen. Die ID darf nicht aus dem vorhergehenden Datensatz geraten werden.

Prüffall Zeit: Prüfe striktes Datum und Uhrzeit einschließlich gültiger Minuten und UTC-Kennzeichnung. Ergebnis bei E: invalid_timestamp, abweisen. Ein syntaktisch ähnlich aussehender Text ist keine gültige Zeitangabe.

Prüffall Lücke: F ist kein Druck von 0 bar. Ergebnis: missing_required_value; für eine grafische Demonstration kann eine Lücke angezeigt werden, aber keine frei erfundene Messung.

Geführtes Vorgehen: Markiere in jeder Zeile zuerst Pflichtfelder, dann Wertebereich und Einheit, schließlich Zeitformat und fachliche Plausibilität. Erstelle eine neue Tabelle mit den Spalten Originalzeile, Prüfregel, Entscheidung, Begründung und mögliche Nacharbeit. A und B bleiben gültig; aus A nach B folgt im Modell ein Lastanstieg um 35 Prozentpunkte bei gleichzeitig 25 bar höherem Druck – keine Kausalitätsbehauptung.

Qualitätsprotokoll für Lernende

Fall	Ergebniscode	Nächster Schritt
C	unit_mismatch	Metadaten und Originaleinheit der erfundenen Quelle prüfen
D	missing_machine_id	Identität durch fiktives Quellregister bestätigen lassen
E	invalid_timestamp	Unveränderte Originalzeichenfolge archivieren und Zeitquelle klären
F	missing_required_value	Lücke markieren; keine Null ergänzen

Audiomaterial für eine Datenkritik:

Fehler beim Erstellen des Vorschaubildes:

Ton einer historischen Seilereimaschine, Wikimedia Commons, Work With Sounds / Konrad Gutkowski und Maike Buckemüller, CC BY 4.0. Die Aufnahme ist keine Sensorzeitreihe. Ohne Audio: Ein hörbares Maschinengeräusch erlaubt ohne Kennung, kalibrierte Messgröße und Zeitbezug keine quantitative Druckdiagnose. Beschreibe, welche Metadaten eine spätere Tonanalyse bräuchte.

Einen JSON-Datenvertrag als Lernprodukt erstellen

Pflichtfelder und feste Prüfregeln

Ein Datenvertrag ist die überprüfbare Vereinbarung zwischen Datenquelle und Empfänger. Er beschreibt Namen, Datentyp, zulässige Einheiten, Kennungen, Version, Pflichtstatus und Fehlerreaktionen. Ein Feld namens "temperature" ohne Einheit ist mehrdeutig. Der Vertrag für unser Modell besitzt die Version 1.0.0:

Feld	Typ	Pflichtregel	Bedeutung
schemaVersion	Zeichenkette	"1.0.0"	Vertragsversion
machineId	Zeichenkette	nicht leer; in Modellliste M-01 bis M-03	Eindeutige Quelle
timestamp	Zeichenkette	gültiger ISO-8601-Zeitpunkt in UTC mit Z	Messzeitpunkt
loadPercent	Zahl	0 bis 100	Simulierte Last
pressure.value	Zahl	0 bis 250	Simulierter Druck
pressure.unit	Zeichenkette	exakt "bar"	Deklarierte Druckeinheit
temperature.value	Zahl	plausibel dokumentiert	Simulierte Temperatur
temperature.unit	Zeichenkette	exakt "Cel" im Lernvertrag	Einheitencode nach UCUM für Grad Celsius
qualityStatus	Zeichenkette	"valid" oder "review"	Ergebnis der eigenen Prüfung

Lernvertrag als JSON-Beispiel für Zeile B (nicht mit dem offiziellen IDTA-AAS-JSON-Serialisierungsformat verwechseln):

{
  "schemaVersion": "1.0.0",
  "machineId": "M-01",
  "timestamp": "2026-10-21T08:01:00Z",
  "loadPercent": 75,
  "pressure": {"value": 205, "unit": "bar"},
  "temperature": {"value": 43, "unit": "Cel"},
  "qualityStatus": "valid"
}

Prüfschema in Worten: Wenn machineId fehlt, melde missing_machine_id. Sonst, wenn timestamp keinem tatsächlichen UTC-Zeitpunkt entspricht, melde invalid_timestamp. Sonst, wenn pressure.unit nicht "bar" ist, melde unit_mismatch. Erst nach diesen Prüfungen folgen Zahlentyp, Wertebereich, Vollständigkeit und Dublettenprüfung. Sammle mehrere Fehler, wenn du sie sicher voneinander unabhängig feststellen kannst. Protokolliere nicht nur "ungültig", sondern betroffene Zeile und Regel.

Wichtig zur Reihenfolge: Die Reihenfolge dient hier der nachvollziehbaren Diagnose. Ein reales System muss den Vertrag als Ganzes prüfen; Grenzwerte und Fehlercodes sind im Modell selbst definiert.

JSON-Datenvertrag und Verwaltungsschale zuordnen

Die Verwaltungsschale (AAS) beschreibt ein Asset durch seine Identität und durch Teilmodelle mit eindeutigen Eigenschaften. idShort ist ein menschenlesbarer lokaler Kurzname; semanticId verweist auf eine definierte fachliche Bedeutung. Dadurch können Anwendungen erkennen, ob zwei Datenfelder tatsächlich dieselbe Messgröße meinen. Ein Informationsmodell umfasst Datentypen, Beziehungen, Bezeichner und Semantik.

Lernvertrag	Modellzuordnung in AAS	Prüffrage zur Interoperabilität
machineId	Asset-Identität / AAS-Verweis auf identifiziertes Asset	Ist die Maschine stabil und eindeutig identifiziert?
pressure.value	Property "Pressure" im eigenen Teilmodell "OperationalMeasurements"	Ist der Werttyp als Zahl vereinbart?
pressure.unit	Einheit der Property bzw. der zugehörigen Datenspezifikation	Wird tatsächlich derselbe Druckmaßstab verwendet?
timestamp	Zeitbezug der Messung in der fachlichen Datenmodellierung	Ist die Zeitbasis eindeutig und validiert?
temperature.value	Property "Temperature"	Ist der Temperaturbegriff mit Semantik festgelegt?
schemaVersion	Metadatum des eigenen Datenvertrags	Welche Vertragsversion nutzt der Empfänger?

Achtung – Standards sauber trennen: "OperationalMeasurements", "Pressure" und die Feldnamen sind selbst gewählte Lernbezeichnungen, keine behaupteten standardisierten IDTA-Teilmodellkennungen. Eine produktiv standardkonforme AAS erfordert die aktuell geltenden IDTA-Metamodelle, Spezifikationen und geeignete semantische Referenzen. Der JSON-Datenvertrag ist ein vorgeschaltetes Lehrformat, kein unverändert veröffentlichbares AAS-JSON-Objekt. In einem echten Mapping müssen unter anderem AAS- und Asset-Identifikatoren, Teilmodell-IDs, idShort, valueType und Referenztypen gemäß der betreffenden Spezifikationsversion korrekt serialisiert werden.

Vertiefung: Vergleiche die IDTA-Teile 01001 Metamodell, 01002 API und 01003-b Einheiten. Die IDTA-Seite führt die Serie "Release 26-01" (Abruf 21.10.2026). Normbezüge sind editionsabhängig; überprüfe die jeweilige Dokumentversion, statt aus einer Downloadliste eine unveränderliche Implementationsregel abzuleiten.

Geführte Erstellung und eigener Transfer

Schritt A – Vorlage: Übernimm die acht Vertragsfelder aus der Tabelle und prüfe anhand der Zeile B die Datentypen und Einheiten. Schritt B – Fehlersuche: Formuliere für C, D und E je eine dokumentierte Ablehnungsentscheidung. Schritt C – Mapping: Zeichne für M-01 eine AAS mit einem eigenen Teilmodell "OperationalMeasurements"; ergänze je eine Property zu Druck, Temperatur und Last und kennzeichne sie mit Werttyp und Einheit. Schritt D – Transfer: Erstelle einen zweiten, fiktiven Sender "M-04" mit gleicher Semantik, aber anderem ursprünglichen Spaltennamen, und beschreibe dessen regelgeleitete Zuordnung. Erweiterungen sind nur nach dokumentierter Vertragsversion zulässig.

Hilfekarte: Unterscheide stets "Was bedeutet der Messwert?" von "Wie wird er kodiert?" und "Wie kommt er zur Gegenstelle?". Für den Einstieg reichen Ausdrucke; eine lokale JSON-Prüfung mit einem freien Offline-Texteditor ist optional.

Interoperabilität nachweisbar prüfen

Drei Ebenen der Zusammenarbeit

Technisch: Kann eine Nachricht übertragen und gelesen werden? Syntaktisch: Stimmen Felder und Datentypen mit dem JSON-Vertrag überein? Semantisch: Bedeutet zum Beispiel "pressure" auf beiden Seiten denselben physikalischen Druck mit derselben Einheit, Bezugsgröße und fachlichen Definition? Eine JSON-Datei kann formal korrekt und trotzdem semantisch inkompatibel sein.

Prüfmatrix: Empfänger A lehnt ein Datenpaket ohne machineId ab. Empfänger B meldet bei timestamp "2026-10-21T08:61:00Z" einen Fehler statt die Zeichenfolge unbemerkt zu speichern. Empfänger C sperrt "180 kPa", solange der Vertrag "bar" fordert und die Quelle nicht geklärt ist. Erst ein erfolgreich durchlaufener Satz solcher Positiv- und Negativtests belegt die Prüfbarkeit der Schnittstelle im Modell.

Vergleichende Tests und Auswertung

Test	Synthetischer Input	Erwartetes Ergebnis	Nachweis
Positivtest	M-01, 08:01:00Z, 205 bar	annehmen	Alle Pflichtfelder und Regeln erfüllt
Negativtest Einheit	M-02, 180 kPa	unit_mismatch	Vertragsverletzung protokolliert
Negativtest Identität	leere Maschinenkennung	missing_machine_id	Keine ungesicherte Zuordnung
Negativtest Zeit	Minutenfeld 61	invalid_timestamp	Ungültiger Zeitpunkt ausgeschlossen
Negativtest Lücke	pressure.value fehlt	missing_required_value	Null nicht vorgetäuscht

Zukunftsakzent: Prüfbare Informationsmodelle machen Bedeutung und Struktur explizit, sodass automatisierte Konformitätstests möglich werden. Sie garantieren jedoch keine Messgenauigkeit; dafür sind zusätzlich Sensorkalibrierung, Herkunftsprüfung, Betriebskontext und Qualitätsmanagement nötig. Eine verlässliche interoperable Datenkette braucht beides: technische Schnittstellen und nachvollziehbare Semantik.

Selbstkontrolle: Begründe schriftlich, warum im Negativtest mit kPa selbst eine rechnerisch mögliche Umrechnung ohne Kenntnis der Quelle nicht als stille Korrektur ausreicht. Erkläre zusätzlich, warum eine bloße Kennung wie "M-01" ohne definierte Identitätsdomäne global nicht eindeutig wäre.

Interaktive Aufgaben

Quiz: Daten und Schnittstellen beurteilen

Beantworte zehn Fragen. Entscheide jeweils anhand der gelernten Regeln; die Rückmeldungen geben einen Denkhinweis und ersetzen keine Begründung.

Welche Information darf bei einer Messreihe nicht fehlen, wenn sie einer bestimmten Modellmaschine zugeordnet werden soll? (Eine eindeutige Maschinenkennung) (!Die Farbe der Maschinenverkleidung) (!Die Länge der Tabellenüberschrift) (!Der Name des Tabellenkalkulationsprogramms)

Rückmeldung zum Prüfen: Prüfe, ob derselbe Datensatz eindeutig einer Quelle zugeordnet werden kann.

Was ist der sachgerechte erste Umgang mit 180 kPa, wenn der Vertrag bar vorschreibt? (Einheitenkonflikt melden und Quellangabe prüfen) (!Wert unverändert als 180 bar veröffentlichen) (!Einheitenfeld kommentarlos löschen) (!Druck grundsätzlich als null behandeln)

Rückmeldung zum Prüfen: Zahl und Einheit sind gemeinsam zu prüfen; ohne bestätigte Quelle ist keine stillschweigende Umdeutung zulässig.

Welche Zeitangabe muss die Validierung verwerfen? (2026-10-21T08:61:00Z) (!2026-10-21T08:01:00Z) (!2026-10-21T09:30:00Z) (!2026-10-21T00:00:00Z)

Rückmeldung zum Prüfen: Achte auf gültige Bereiche der Uhrzeit und nicht nur auf das Zeichenmuster.

Welche Aussage über ein fehlendes Druckfeld trifft zu? (Eine fehlende Messung darf nicht ohne Nachweis als Nullwert ersetzt werden) (!Fehlende Messungen bedeuten immer Druckfreiheit) (!Jede Lücke ist zwingend ein Sensorbruch) (!Eine Lücke ändert automatisch die Maschinenkennung)

Rückmeldung zum Prüfen: Eine Datenlücke unterscheidet sich von einer physikalisch gemessenen Null.

Wozu dient schemaVersion in einem Datenvertrag? (Zur eindeutigen Kennzeichnung der vereinbarten Feldregeln) (!Zur Messung des aktuellen Drucks) (!Zur Berechnung der Maschinenleistung) (!Zum Ersatz eines Zeitstempels)

Rückmeldung zum Prüfen: Überlege, wie Sender und Empfänger erkennen, nach welchen Regeln sie prüfen sollen.

Welche Aussage über JSON ist richtig? (Es kann strukturierte Schlüssel und Werte übertragen, definiert aber keine physikalischen Einheiten von selbst) (!Es sichert automatisch die Kalibrierung jeder Maschine) (!Es verhindert jedes ungültige Datum ohne Zusatzregeln) (!Es garantiert gleiche Semantik bei allen Herstellern)

Rückmeldung zum Prüfen: Unterscheide das Dateiformat von fachlichen Vereinbarungen und Validierungsregeln.

Welche Funktion hat semanticId im Kontext eines AAS-Informationsmodells? (Es verweist auf die fachlich definierte Bedeutung eines Modellsymbols) (!Es ist immer die IP-Adresse des Sensors) (!Es ersetzt alle gemessenen Werte) (!Es ist ausschließlich ein Farbcode der Bedienoberfläche)

Rückmeldung zum Prüfen: Die Bezeichnung allein genügt oft nicht, um fachliche Gleichheit sicherzustellen.

Was ist bei einer neuen Datenquelle mit anderer Spaltenbezeichnung besonders wichtig? (Eine dokumentierte Abbildung auf dieselbe fachliche Messgröße) (!Automatisches Löschen aller Quellmetadaten) (!Umbenennen aller Maschinen auf dieselbe ID) (!Verzicht auf Zeitbezug)

Rückmeldung zum Prüfen: Die technische Schreibweise darf sich unterscheiden, sofern Bedeutung und Transformation geprüft sind.

Welcher Fall zeigt syntaktische, aber keine gesicherte semantische Interoperabilität? (JSON ist lesbar, aber die Druckeinheit der Quelle ist ungeklärt) (!Die Maschine besitzt eine geklärte Einheit und geprüfte Zeit) (!Ein Modell prüft Pflichtfelder mit Erfolg) (!Empfänger und Sender nutzen dieselbe definierte Semantik)

Rückmeldung zum Prüfen: Eine gültige Nachricht ist noch kein Beleg für inhaltliche Gleichheit.

Wie lässt sich die Vertragsprüfung im Modell am besten nachweisen? (Mit dokumentierten gültigen und absichtlich fehlerhaften Testfällen samt erwartetem Ergebnis) (!Mit einem Screenshot ohne Datenfelder) (!Durch bloße Angabe des Dateinamens) (!Durch eine mündliche Vermutung über die Maschine)

Rückmeldung zum Prüfen: Ein Prüfnachweis braucht reproduzierbare Eingaben, erwartete Ergebnisse und nachvollziehbare Begründungen.

Memory: Fachbegriffe und Bedeutung

Ordne jedem Begriff genau eine passende Erklärung zu.

Zeitstempel	Kodierter Bezug auf den Messzeitpunkt
Datenvertrag	Vereinbarte Feldtypen und Prüfregeln
Semantik	Fachliche Bedeutung einer Information
Verwaltungsschale	Digitales Strukturmodell eines Assets mit Teilmodellen
Einheit	Maßangabe für einen Zahlenwert
Maschinenkennung	Identifikator zur Zuordnung der Datenquelle

Drag and Drop: Fehlerarten zuordnen

Gesuchter Prüfbegriff	Beobachtung
Einheitenfehler	Druck als kPa statt gefordertem bar beschriftet
Fehlende Kennung	Datenzeile ohne Maschinen-ID
Zeitfehler	Zeitstempel mit ungültigem Minutenfeld
Datenlücke	Messwert im geforderten Feld fehlt
Versionskonflikt	Sender und Empfänger vereinbaren verschiedene Feldregeln

Kreuzworträtsel: Schlüsselfachbegriffe

Zeitstempel	Welcher Fachbegriff nennt den kodierten Zeitpunkt eines Ereignisses?
Semantik	Wie heißt die fachliche Bedeutung eines Datenfeldes?
Einheit	Was gehört neben dem Zahlenwert zu einer physikalischen Messung?
Metadaten	Wie heißen beschreibende Angaben über Quelle und Struktur?
Validierung	Wie heißt die systematische Prüfung vereinbarter Regeln?
Schema	Wie nennt man die formale Strukturvorgabe für Datenfelder?

LearningApps: Ergänzende Übungen

Die Suchseite bietet möglicherweise noch keine genau zu diesem Datenvertrag passende LernApp. Prüfe Angebote auf fachliche Richtigkeit und nutze als gleichwertige Offline-Alternative die Zuordnungstabelle oben.

Lückentext: Das Datenmodell präzisieren

Offene Aufgaben

Leicht

Sensor und Messgröße: Beschreibe an zwei selbst erfundenen Datenzeilen jeweils Wert, Einheit, Maschinenkennung und Zeitpunkt.
Datenqualität prüfen: Markiere im Modellfall die fehlende ID und begründe, weshalb du sie nicht aus der Nachbarzeile übernimmst.
Zeitstempel untersuchen: Schreibe zwei gültige UTC-Zeitpunkte und einen absichtlich ungültigen; erkläre deine Entscheidung.
Einheit unterscheiden: Erkläre anhand von bar und kPa, warum dieselbe Zahl nicht dieselbe Messgröße garantiert.

Standard

JSON schreiben: Übertrage Zeile A des Modellfalls in den festgelegten JSON-Vertrag und notiere die Prüfentscheidungen.
Datenbereinigung planen: Erstelle ein Fehlerprotokoll zu C, D, E und F mit Originalfeld, Code, Maßnahme und Begründung.
Datenformat vergleichen: Übersetze einen synthetischen Drei-Zeilen-Datensatz aus CSV in JSON und dokumentiere Trennzeichen sowie Datentypen.
Digitale Schnittstelle testen: Lege einen Positivtest und drei Negativtests an und vergleiche tatsächliche und erwartete Ergebnisse auf Papier.

Schwer

Asset Administration Shell modellieren: Zeichne ein fiktives Teilmodell mit drei Properties, idShort, Werttyp, Einheit und erklärter semanticId-Strategie.
Interoperabilität analysieren: Vergleiche die Schnittstellen zweier erfundener Hersteller und entwirf nachvollziehbare Transformationsregeln ohne Informationsverlust.
Versionsverwaltung gestalten: Definiere Version 1.1 eines Vertrags mit neuem optionalem Feld und diskutiere Kompatibilität zu Version 1.0.
Datenvalidierung argumentieren: Entwirf einen absichtlich mehrdeutigen Einheitenfall, entscheide über Annahme, Ablehnung oder Quarantäne und verteidige die Entscheidung schriftlich.

Lernkontrolle

Bearbeite die folgenden Prüfaufträge schriftlich. Notiere immer Eingabe, Regel, Entscheidung und Begründung.

Datenqualität im Zusammenhang: Warum reicht ein plausibler Messwert ohne Kennung und Zeitbezug für die M-02-Auswertung nicht aus?
Einheitenumrechnung beurteilen: Vergleiche 180 bar mit 180 kPa und erkläre, weshalb ein unbestätigter Quellfehler nicht einfach korrigiert werden darf.
Zeitformat validieren: Begründe die Ablehnung von 2026-10-21T08:61:00Z und erkläre, was eine gültige UTC-Angabe leisten muss.
JSON als Vertrag: Nenne fünf Pflichtfelder, die zugehörigen Typen und je einen reproduzierbaren Negativtest.
Verwaltungsschale zuordnen: Skizziere Asset-Identität, ein Teilmodell und mindestens drei Properties mit fachlicher Bedeutung.
Interoperabilität übertragen: Wie kannst du zwei syntaktisch verschiedene, aber semantisch gleiche Druckfelder regelgeleitet zusammenführen?
Datenprovenienz begründen: Warum benötigt eine nachträgliche Einheitenkorrektur einen nachvollziehbaren Herkunfts- und Änderungsnachweis?

Lernnachweis

Abgabeprodukt: Ein selbstständig verfasster JSON-Datenvertrag (Version, Pflichtfelder, Typen, Einheiten, Zeitregeln, Fehlerreaktionen), ein AAS-Zuordnungsblatt und ein Testprotokoll mit mindestens einem gültigen und vier ungültigen synthetischen Datensätzen. Begründe die Entscheidungen unit_mismatch, missing_machine_id und invalid_timestamp jeweils mit der beobachteten Eingabe, der verletzten Vertragsregel und einer zulässigen nächsten Handlung. Füge einen begründeten Fehlerfall zu einer Datenlücke hinzu.

Bewertungsraster: 30 % fachlich vollständiger und konsistenter Vertrag; 25 % korrekte Prüfentscheidung und Begründung; 20 % präzise AAS-Zuordnung bei sauberer Trennung vom offiziellen AAS-Format; 15 % gelungener Transfer auf einen neuen Sender; 10 % verständliche Quellen- und Versionsdokumentation. Prüfe deine Arbeit mit einem ausgedruckten Beispiel oder einem lokalen freien Texteditor. Keine echten Zugänge oder personenbezogenen Datensätze einreichen.

Eigenständigkeit: Kennzeichne alle erfundenen Messwerte als synthetisch. Erkläre an einem Fehlerfall, was du zunächst nicht weißt und welche Information vor einer eventuellen Korrektur erforderlich wäre. Ein positives Lernergebnis bedeutet ausschließlich, dass du den Modellfall beurteilen kannst; es erteilt keine technische Freigabe.

OER und Wikipedia

Primärquellen und Stand: Die nachstehenden Seiten wurden für den Kurs am 21.10.2026 als Rechercheeinstieg überprüft. Die Version der verwendeten Lernbeispiele ist 1.0.0 (synthetisch, erstellt für diesen Kurs). Die IDTA listet Release 26-01 der AAS-Spezifikationen; bei Implementationen sind Einzelversion und Normtext des jeweiligen Teils zu prüfen. Die OPC-Foundation-Übersichtsseite beschreibt eine plattformunabhängige serviceorientierte OPC-UA-Architektur, nicht die Prüfregeln des hier frei entworfenen JSON-Vertrags. Zukünftige Fassungen können Details verändern.

Industrial Digital Twin Association – Downloads und AAS-Spezifikationen, Release 26-01: Metamodell, API, semantische Daten und Einheiten; die Dokumentversion vor fachlicher Umsetzung nachsehen.
IDTA 01001 – Metamodell: erklärt Identität, Teilmodelle und Abbildung auf Übertragungsformate; keine direkte allgemeine Maschinensteuerungsanweisung.
OPC Foundation – OPC Unified Architecture: technische Architektur und Informationsmodell, auf Englisch.
Wikipedia – Verwaltungsschale und Wikipedia – JSON: ergänzende frei zugängliche Einstiege, Änderungen und Qualität jeweils prüfen.
Vorhandenes Grundlagen-Lernprodukt: zum Wiederholen gedacht; sein genauer Text war in diesem Abruf nicht einsehbar.

Freie Medien und Lizenzen – Dateiseiten sind zugleich Nachweise für Vorschaubild, Autorenschaft, Lizenz und zugängliche Originaldatei:

Medium	Verifizierte Dateiseite / Quelle	Urheberschaft	Lizenz und Hinweis
File:IIoT System Building Blocks.jpg	Commons-Dateiseite	Sujata Tilak	CC BY-SA 4.0, englisches historisches Systembild
File:JSON vector logo.svg	Commons-Dateiseite	Douglas Crockford	Gemeinfreie einfache geometrische Text-/Logoform; Markenrechte gegebenenfalls prüfen
File:OPC UA Application Layers.svg	Commons-Dateiseite	Vshebordaev	CC BY-SA 3.0, grafisches Modell von 2014
File:WWS Ropemakingmachine.ogg	Commons-Dateiseite	Work With Sounds / Konrad Gutkowski und Maike Buckemüller	CC BY 4.0, historische Audioaufnahme
https://www.youtube.com/watch?v=xDNsg_9U2qQ	DKE-Video „Eine Basis-Norm für Industrie 4.0“	DKE, Vortrag mit Matthias Damm	Rechte verbleiben beim Videoanbieter; Online-Wiedergabe kann sich ändern; keine behauptete CC-Freigabe

Barrierearme Alternativen: Jede Abbildung ist im Bildaufruf mit einem Alternativtext versehen; die Bildunterschriften erläutern ihren Aussagegehalt. Das Audio kann durch die textliche Beschreibung ersetzt werden. Der Videokern ist im Schnittstellen-Kapitel zusammengefasst. Sämtliche Übungsdaten und Prüfentscheidungen stehen unmittelbar im Text und funktionieren ohne externe Medien. Für die Einbettung ist die Verfügbarkeit fremder Medien nicht garantiert.