RAN Data on Tag

RANDataonTag
Arbeitspaket 2 Daten und Datenstrukturen RAN Data on Tag
Inhalt
1 Änderungsindex
4 2 Einleitung und Motivation
5 3 Ansätze zur dezentralen Datenspeicherung
9 3.1 ISO 15961 / 15962
3.1.1 Beschreibung
3.1.2 Eignung für die Nutzung im RAN-Netzwerk
3.2 JAIF Global RFID Item Level Standard
9 9 11 11 3.2.1 Beschreibung
11 3.2.2 Eignung für die Nutzung im RAN-Netzwerk
12 3.3 VDA Empfehlung 5501 / 5510
12 3.3.1 Beschreibung
12 3.3.2 Eignung für die Nutzung im RAN-Netzwerk
13 3.4 GS1 EPC Tag Data Standard
13 3.4.1 Beschreibung
13 3.4.2 Eignung für die Nutzung im RAN-Netzwerk
14 3.5 SemProM Metaformat
15 3.5.1 Beschreibung
15 3.5.2 SemProM Metaformat/Binärformat
17 3.5.3 Eignung für die Nutzung im RAN-Netzwerk
21 3.6 Fazit
21 4 Prototypische Anwendung des SemProM-Formates für Data-onTag
23 4.1 Anwendungsbeispiel
23 4.2 Beschreibung des Datenformats
27 4.3 Nutzdatenblock „Attribute-Block“
29 5 Empfehlung
5.1 Kleine Datenmengen (bis ca. 300 Byte)
33 33 5.2 Mittlere bis große Datenmengen (ab ca. 300 Byte) sowie Zugriff mehrerer
Partner
33 2
RAN Data on Tag
6 Vorgehen zur Standardisierung
35 7 Quellenverzeichnis
36 3
RAN Data on Tag
1 Änderungsindex
Kapitel Änderung
Kurzbeschreibung
Wer
Wann Da- Status
Name
tum
E=Entwurf
F=Freigegeben
alle
Vorabversion Leitdokument er- M. Niehues
stellt
alle
Änderungen internes
eingearbeitet
alle
Leitdokument v0.1 erstellt
M. Niehues
08.11.2012 F
alle
Änderungen Review eingearbei- M. Niehues
tet
27.11.2012 E
29.08.2012 E
Review P.
Schulz, 07.11.2012 E
M. Niehues,
P.
Engelhardt
4
RAN Data on Tag
2 Einleitung und Motivation
Die Integration von RFID (Radio Frequency Identification) in Systeme zur Planung
und Steuerung von Produktions- und Logistikabläufen ermöglicht durch eine automatisierte Identifikation von Objekten (z. B. Produkte) die Verbesserung des Informationsmanagements innerhalb des Produktionsnetzwerkes. Somit können situative Entscheidungen auf inner- und überbetrieblicher Ebene getroffen werden. In einer sog.
RFID-basierten hybriden Steuerungsarchitektur werden der Planungs- und Steuerungsaufwand sowie die Entscheidungsfindung auf dezentrale und zentrale Steuerungselemente verteilt.
Zentrales Element in einer RFID-basierten hybriden Steuerungsarchitektur ist, neben
konventionellen Systemen zur Planung und Steuerung von Produktions- und Logistikabläufen, der in RAN entwickelte Infobroker. Dieser ermöglicht die schnelle Verteilung von auftragsspezifischen RFID-Leseereignissen innerhalb des Produktionsnetzwerkes. Ein solches RFID-Leseereignis gibt Auskunft über den Zeitpunkt, den
Ort und den Grund einer spezifischen Objektidentifikation und somit über den Fortschritt eines individuellen Auftrages.
Dezentrale Bestandteile sind intelligente Objekte (z. B. Produkte), die mit einem
RFID-Transponder ausgestattet sind. Organisatorische (z. B. Lieferdatum) und prozessuale (z. B. Qualitätsdaten) produktspezifische Daten können an diesen intelligenten Objekten mitgeführt werden und so aktiv lokale Steuerungsentscheidungen
beeinflussen.
Die Potenziale der Integration einer RFID-basierten hybriden Steuerungsarchitektur
sind abhängig von der Verfügbarkeit, schnellen Bereitstellung und Einbindung von
produkt- und auftragsspezifischen Informationen in Planungs- und Steuerungsentscheidungen. Es lassen sich dabei drei Potenzialklassen ableiten. Die erste Klasse
(Objektidentifikation) ermöglicht die Verknüpfung von intelligenten Objekten mit relevanten Auftragsdaten, wodurch sowohl Abläufe in der Produktion (z. B. Vermeidung
von Falschverbau) als auch in der Logistik (z. B. Pulkerfassung von Objekten auf einem Frachtträger) optimiert und abgesichert werden können. In der zweiten Potenzialklasse (Objektverfolgung) liegt der Fokus auf der schnellen Bereitstellung von
RFID-Leseereignissen über den Infobroker. Diese auftragsspezifischen Informationen ermöglichen die Überwachung von Aufträgen im Produktionsnetzwerk. Kritische
Situationen, wie bspw. Störungen in Produktions- und Logistikprozessen, können so
frühzeitig identifiziert werden. Die dritte Potenzialklasse (Objektkommunikation) fokussiert die Bereitstellung und Berücksichtigung produktspezifischer Informationen
über den RFID-Transponder am Objekt. Hierdurch kann eine Produkt-MaschineKommunikation realisiert werden, wodurch das Produkt den Produktionsprozess aktiv
beeinflusst. Die Berücksichtigung von produktspezifischen Qualitäts- und Toleranz-
5
RAN Data on Tag
daten im Produktionsprozess trägt bspw. zur Vermeidung von Ausschuss und Reduktion von Nacharbeitsumfängen bei.
Um die Potenziale einer RFID-basierten hybriden Steuerungsarchitektur voll ausnutzen zu können, ist es somit notwendig, Daten zum Objekt dezentral, also auf dem
Transponder (Data-on-Tag), mitzuführen.
Werden produktspezifische Daten direkt mit dem Produkt mitgeführt, wird von dezentraler Datenhaltung gesprochen. Ein klassisches Beispiel hierfür sind Qualitätsdaten, die den weiteren Prozessverlauf beeinflussen. Mit dem Produkt werden so auch
die Daten entlang der Lieferkette weitergegeben. Wie bereits erwähnt, ermöglicht es
die RFID-Technologie, die Daten direkt am Produkt zu speichern. Schnittstellen zwischen unterschiedlichen betrieblichen Planungs- und Informationssystemen können
entlastet werden, indem die notwendigen Daten über den RFID-Transponder ausgetauscht werden. Weiterhin ermöglicht die dezentrale Produktdatenhaltung eine
schnelle Bereitstellung und Speicherung von Daten, wodurch zentrale Systeme entlastet werden. Gleichzeitig können verpflichtend mitzuführende Papiere in elektronischer Form auf dem Transponder mitgeführt werden. Dies ermöglicht neben der automatischen Erfassung auch die Einsparung von Papier sowie die Reduzierung von
Papier- und damit Datenverlust. Die auf dem Produkt gespeicherten Daten können
auch zur dezentralen Ansteuerung von Produktionsanlagen eingesetzt werden. Bei
unerwarteten Ereignissen im Prozess, wie beispielsweise Qualitätsmängeln, kann
durch die zur Verfügung stehenden produktspezifischen Daten eine adaptive Anpassung des Prozesses ermöglicht werden. Der Data-on-Tag-Ansatz kann daher als Befähiger für die Selbststeuerung von Prozessen gesehen werden. Gleichzeitig bietet
das Mitführen von Daten auf dem RFID-Transponder die Möglichkeit, eine über den
Electronic Product Code (EPC) hinausgehende Spezifizierung des Objektes zu hinterlegen. So kann beispielsweise ein Objekt, das im EPC nur als Komponente bekannt ist, über weitere Informationen im User-Memory durch Farbe und Sonderausstattungen spezifiziert werden und somit eine exaktere Steuerung ermöglichen.
Neben den oben beschriebenen Vorteilen, die sich in einer Erhöhung der Flexibilität
zusammenfassen lassen, nimmt auch der Aufwand hinsichtlich notwendiger Hardware mit zunehmender Datenhaltung auf dem Tag ab. So kann beispielsweise auf
Datenautobahnen weitgehend verzichtet werden, wenn alle steuerungsrelevanten
Daten auf dem Tag hinterlegt sind und lediglich einzelne Punkte eingerichtet werden,
an denen die Daten entsprechend gesichert werden. In Abbildung 1 ist die Entwicklung zu zunehmender Datenspeicherung auf dem Tag dargestellt.
6
Aktueller Status
Stand der
Anwendung
ID on Tag
Speichern der Objekt-Identifikationsnummer auf dem Tag
• Verwendung von nicht wiederbeschreibbaren Tags mit geringer
Speicherkapazität
Piloten/ Einzelanwendungen
Speichern der Objekt-Identifikationsnummer und weitere Nutzdaten auf dem Tag, z.B.:
• Zielvorgaben
• Routinginformationen
• Objektspezifische Angaben für den Transport
Agent on Tag
Konzept
• Erweiterung der „Data-on-Tag“-Konzeption auf dem Transponder
gespeicherten ausführbaren Agenten
• D.h. der Agenten-Programmcode ist in Ausführungsumgebung
auf Schreib-/Lese-Gerät ablauffähig
Höhe der Flexibilität
Trend
Data on Tag
Minimalistische Hardwareanforderungen
RAN Data on Tag
Abbildung 1: Data-on-Tag als Konzept der Zukunft (Quelle: Günthner & ten Hompel
2010)
Zwar bietet der Data-on-Tag-Ansatz viele Vorteile und Potenziale, er bringt aber auch
neue Herausforderungen mit sich. Ein Löschen oder Überschreiben der Daten im
User Memory ist nach aktuellem Stand der Technik jederzeit und jedem möglich. Aus
diesem Grund ist die Sicherung der Daten in einem zentralen System beim Übergang
des getaggten Bauteils auf einen anderen Verantwortungsbereich zu empfehlen.
Weiterhin ist zu beachten, dass uncodierte, mitgeführte Daten auf dem Transponder
von nicht befugten Personen ausgelesen und interpretiert werden können. Das Thema Datensicherheit ist jedoch nicht Schwerpunkt dieser Leitlinie, da zum einen bereits etablierte Möglichkeiten und Methoden zur Codierung von Daten existieren, zum
anderen hier die Schaffung einer Struktur im Vordergrund steht.
Die Notwendigkeit des Mitführens von Nutzdaten auf dem Transponder wurde auch
von einigen Standardisierungsgremien (z.B. ISO, JAIF, VDA, GS1) und Forschungsprojekten erkannt und entsprechende Strukturierungsvorschläge erarbeitet, wie die
Daten auf einem RFID-Transponder abzulegen sind. Im Folgenden werden die Ansätze (kurz) vorgestellt und kritisch beleuchtet und am Ende bewertet. Darauf aufbauend soll der Handlungsbedarf abgeleitet und die Anforderungen definiert werden,
die eine dezentrale Datenstruktur erfüllen muss, um dem heutigen Einsatz der RFIDTechnologie in der Automobilindustrie zu genügen.
Für die in diesem Dokument genannten Speichergrößen von RFID-Tags gelten folgende Definitionen:
7
RAN Data on Tag

kleine Datenmengen bis ca. 300 Byte

mittlere Datenmengen ca. 300 Byte - 10 Kilobyte

große Datenmengen ab 10 Kilobyte bis einige Megabyte
8
RAN Data on Tag
3 Ansätze zur dezentralen Datenspeicherung
3.1 ISO 15961 / 15962
3.1.1 Beschreibung
Die Internationalen Normen ISO/IEC 15961 “Information technology - Radio frequency identification (RFID) for item management - Data protocol: application interface”
sowie ISO/IEC 15962 “Information technology - Radio frequency identification (RFID)
for item management - Data protocol: data encoding rules and logical memory functions” regeln eine Reihe von Datenprotokollen zum Austausch von Informationen in
einem RFID-System. Die Normen sind im Jahr 2004 herausgegeben worden (Ausgaben jeweils 2004-10-15) und waren während der Projektlaufzeit gültig. Während
die ISO/IEC 15961 den Datentransfer zu und von Applikationen regelt, beschreibt die
ISO/IEC 15962 die Abbildung der Daten auf dem Transponder sowie die Verarbeitung der Transponderdaten. Beide Normen sind aufeinander abgestimmt und ergänzen sich.
Innerhalb dieser Normen wird auch die mögliche Strukturierung von Daten auf dem
RFID-Transponder beschrieben. Dabei sind die Daten in einer sich wiederholenden
Sequenz von Precurser (Metastruktur von kodierter objectId und object), Länge der
objectId, objectId (Formatierung des object), Länge des object und object (kodierte
Daten) zu speichern. Dabei sind als Systeminformationen (system information, Abschnitt 7.1.2 in ISO 15961, Abschnitt 7.2 in ISO 15962) die Transponder-ID (tagId,
bis 256 Byte), die ApplicationFamiliyId (2x 4 Bits) sowie darauffolgend das Speicherformat, dass sich aus der accessMethod (2 Bits + 1 reserviertes Bit) sowie dem dataFormat (5 Bits) zusammensetzt. Für EPC Gen 2 Tag findet sich das Speicherformat in der Memory Bank 11 (MB11) auf den Bits 8 und 7 (accessMethod) sowie 5 bis
1 (dataFormat).
Die accessMethod beschreibt dabei die Struktur, wie Daten auf dem Transponder
gespeichert und gelesen werden können. Hierbei bietet die ISO 15961 folgende
Möglichkeiten zur Auswahl:
0
noDirectory
1
directory
2
selfMappingTag
3
Reserviert für zukünftige Definitionen
9
RAN Data on Tag
Die accessMethod noDirectory ist die einfachste Struktur des Speichers und ermöglicht eine kontinuierliche Aneinanderreihung von Daten, entsprechend Identifiern und
strukturellem Overhead. Ein Auffüllen der Daten beginnt hierbei von vorne nach hinten. Der gesamte Speicherinhalt ist hierbei komplett über die Luftschnittstelle zu
transferieren, um die benötigten Daten herauszufiltern.
Die accessMethod directory setzt hierauf an und beschreibt eine Erweiterung der
noDirectory-Datenstruktur. Während in den unteren Bytes des Speichers weiterhin
die Daten aneinandergereiht werden, wird von dem höchsten Speicherbereich abwärts aus ein Inhaltsverzeichnis geschrieben, welches die Speicherbereiche der einzelnen Datenblöcke angibt. Der Vorteil dieser Struktur liegt daran, dass das Inhaltsverzeichnis bei wachsendem Speicherinhalt nachträglich erweitert werden kann. Insbesondere bei größeren Speicherbereichen und einer größeren Anzahl von zu speicherenden Objekten wird diese Version empfohlen. Der unterschiedliche Aufbau zwischen noDirectory und directory ist in Abbildung 2 skizziert.
1. Datensatz (Precursor + objectID +
object) >>> 2. Datensatz (P + oID +
o) >>> 3. Datensatz (P + oID + o)
>>>……. >>> n. Datensatz (P + oID
+ o) >>>>>>>>>>>>>>>>>>>>>>>>
Freier Speicher, kann für zusätzliche
Datensätze genutzt werden
1. Datensatz (Precursor + objectID +
object) >>> 2. Datensatz (P + oID +
o) >>> 3. Datensatz (P + oID + o)
>>> ……. >>> n. Datensatz (P + oID
+ o) >>>>>>>>>>>>>>>>>>>>>>>>
Freier Speicher, kann für zusätzliche
Inhaltseinträge oder Datensätze
genutzt werden
Verweis n. Datenblock >>> …….
Verweis 3. Datenblock >>> Verweis
2. Datenblock >>> Verweis 1.
Datenblock >>> Inhaltsverzeichnis >
accessMethod 0:
noDirectory
accessMethod 1:
Directory
Abbildung 2: Unterschied zwischen accessMethod 0: noDirectory und 1: directory
Die dritte accessMethod selfMappingTags ist für Transponder mit eigener Speicherverwaltung vorgesehen, die ihre Datenstrukturierung selbstständig durchführen. Es
sind derzeit keine Transponder bekannt, die über diese Möglichkeit verfügen.
Darüber hinaus gibt es spezifische Datenformate (dataFormat), die bestimmte gespeicherte Objekttypen beschreiben. Neben Formattyp 0 „notFormattet“ gibt es auch
spezielle Formate für bestimmte Anwender, z.B. iata oder ean-ucc. Momentan sind
10
RAN Data on Tag
11 verschiedene Datenformate festgelegt, 21 weitere Definitionen sind noch offen.
Sofern keins der Datenformate dataFormat 1-11 verwendet wird, ist dataFormat 0
„notFormattet“ zu verwenden.
3.1.2 Eignung für die Nutzung im RAN-Netzwerk
Für die in ISO/IEC 15961 und 15962 beschriebenen Möglichkeiten der Datenstrukturierung existieren keine Beispiele mit Datensätzen, des Weiteren ist keine Umsetzung dieser Norm in der Praxis bekannt. Die accessMethod 2 „selfMappingTags“
eignet sich aufgrund komplexer, bisher noch nicht verfügbarer Transponder nicht für
die Anwendung im RAN-Kontext, da der unternehmensübergreifende Austausch von
Transpondern in der Regel einfache und kostengünstige Transponder erfordert. Die
accessMethod 0 „noDirectory“ eignet sich durch die reine Aneinanderreihung von
Daten nur für kleine Datenmengen. Die Tatsache, dass innerhalb des Datenblocks
keine Vorgaben bestehen, liefert dem Anwender große Freiräume zur Speicherung,
ohne die Norm-Konformität zu verletzten und bietet sich damit auch für die Integration einer RAN-eigenen Lösung an. Dagegen ist die accessMethod 1 „directory“ ebenfalls nur für kleine Datenmengen geeignet, da es innerhalb des Datenblocks keine
gegliederte Struktur gibt und insbesondere bei Änderungen im Datenblock ein komplettes Lesen und Neuspeichern der Transponder-Inhalte notwendig wird.
Die Möglichkeit der Angabe des Datenformats „dataFormat“ bietet innerhalb des
RAN-Netzwerkes keinen Mehrwert, da es die Definition bestimmter Datenformate
erfordert. Die Bandbreite der innerhalb des RAN-Konsortiums vorhandenen Ideen
gehen jedoch von reinen Nummern bis hin zu PDF- oder Bilddateien, die auf dem
Transponder abzulegen sind. Eine Definition von auszutauschenden Daten oder Datenformaten würde daher spätere Use-Cases mit neu auftretenden Datenformaten
ausschließen, so dass für das RAN-Netzwerk eine offene Definition und damit das
Datenformat 0 „notFormatted“ den größten Nutzen bringt. Die bestehenden ISONormen 15961 und 15962 werden zurzeit überarbeitet, so dass hier in Zukunft weitere Datenformate entstehen könnten.
3.2 JAIF Global RFID Item Level Standard
3.2.1 Beschreibung
Das Joint Automotive Industry Forum (JAIF) veröffentlichte im August 2011 den Global Radio Frequency Identification (RFID) Item Level Standard, eine Empfehlung von
Best Practices zur Objektkennzeichnung und -verfolgung innerhalb der automobilen
11
RAN Data on Tag
Supply Chain. Die Datenstruktur richtet sich dabei nach den ISO und EPC/GS1Standards. Innerhalb dieser Empfehlung ist ebenfalls Bezug auf die Datenspeicherung auf dem Transponder genommen worden. Aufgrund der Strukturierung der Memory Banks 00, 01 und 10 nach den Vorgaben seitens ISO und EPC/GS1, bezieht
sich die Empfehlung zur freien Datenspeicherung auf die Memory Bank 11, auch User Memory genannt. Im Gegensatz dazu bezieht sich die oben genannte ISO
15961/15962 auf jegliche Art der Speicherung von Nutzdaten auf dem Transponder.
Für das User Memory wird innerhalb des DSFID (Data Storage Format Identifier, erstes Byte in MB11) die accessMethod und das Datenformat, bezugnehmend auf die
oben beschriebenen Normen ISO/IEC 15961 und ISO/IEC 19562, spezifiziert. Dabei
wird seitens des JAIF die accessMethod 0 „noDirectory“ favorisiert (s. Abbildung 2
links). Als Datenformat gibt die Empfehlung der JAIF das dataFormat 3 „ISO/IEC
15434“, das die Kodierung bestimmter Zeichen in 6-Bit erlaubt. Ein weiteres empfohlenes Datenformat ist das dataFormat 13 „ISO/IEC 15961-2“, das in den bisher gültigen Normen bisher nicht als Datenformat eingepflegt wurde. Dabei werden zur Kodierung relative OID Data Identifier herangezogen. Die aktuell möglichen relativen
OID finden sich auf folgender Webseite:
http://www.autoid.org/ANSI_MH10/ansi_mh10sc8_wg2.htm (24.10.2012)
Zusammenfassend kann gesagt werden, dass die JAIF eine Datenspeicherung im
User Memory mittels Aneinanderreihung der Daten innerhalb vorgeschriebener Datenformate empfiehlt.
3.2.2 Eignung für die Nutzung im RAN-Netzwerk
Die JAIF-Empfehlung eignet sich für kleine Datenmengen und dem Speichern von
einzelnen Werten, Begriffen oder Ähnlichem. Damit orientiert sich die Empfehlung
am derzeitigen Stand der Technik und aktuellen Anwendungsfällen. Für größere Datenmengen, unternehmensübergreifende Datenweitergabe und -nutzung und größere Dateien ist diese Empfehlung zu unflexibel, da weder eine Strukturierung der Daten vorgesehen ist, noch eine hohe Flexibilität in den weiterzugebenden Datenformaten gegeben ist. Aus diesem Grund ist die JAIF-Empfehlung für die Nutzung im RANNetzwerk nicht ausreichend flexibel genug und eignet sich lediglich für kleinere Datenmengen.
3.3 VDA Empfehlung 5501 / 5510
3.3.1 Beschreibung
12
RAN Data on Tag
Die VDA-Empfehlungen 5501 “RFID im Behältermanagement der Supply Chain“ sowie 5510 „RFID zur Verfolgung von Teilen und Baugruppen in der Automobilindustrie“ nehmen ebenfalls Bezug zur Datenstruktur. Die Daten sind dabei analog zur
JAIF-Empfehlung in den strukturierten Speicherbereich der MB 00, 01 und 10 sowie
den User Memory in Bank 11 aufgeteilt, wobei die Nutzdaten auch hier im User Memory (MB11) gespeichert werden. Während die Struktur sich entweder an ISO/AFI
oder EPC/GS1 anlehnt, ist der User Memory nach der gleichen Empfehlung seitens
der JAIF gegeben, strukturiert. Somit ist hier ebenfalls eine Aneinanderreihung der
Daten vorgesehen. Genau wie in der JAIF-Empfehlung ist auch hier ein Bezug auf
die Normen ISO/IEC 15961 und ISO/IEC 19562 gegeben.
3.3.2 Eignung für die Nutzung im RAN-Netzwerk
Die VDA-Empfehlungen eignen sich ebenso wie die JAIF-Empfehlung für kleine Datenmengen und dem Speichern von einzelnen Werten, Begriffen oder Ähnlichem.
Genauso wie die JAIF-Empfehlung ist die VDA-Empfehlung daher für die Nutzung im
RAN-Netzwerk nicht ausreichend flexibel genug.
3.4 GS1 EPC Tag Data Standard
3.4.1 Beschreibung
Innerhalb des Electronic Produkt Code (EPC) der GS1 wird ebenfalls eine Empfehlung für die Strukturierung von Daten in der Memory Bank 11 (User Memory 11) ausgesprochen. Wie die vorangegangenen Empfehlungen nimmt auch die GS1Empfehlung Bezug auf die ISO/IEC 15961 und ISO/IEC 19562. Hinsichtlich der accessMethod wird hier die accessMethod 2 „packed objects“ empfohlen, die in der
GS1-Empfehlung weiter spezifiziert ist, aber weder in der gültigen ISO/IEC 15961
noch in der ISO/IEC 19562 zu finden ist. Sofern die „packed objects“-Methode nicht
genutzt wird, ist laut GS1-Empfehlung die accessMethod 0 noDirectory zu nutzen.
Die accessMethod „packed objects“ ermöglicht es, unterschiedliche Daten zu speichern und gleichzeitig Datenoverhead zu reduzieren. Dies geschieht durch die Zusammenfassung von Daten in sogenannten „packed objects“ sowie den dazugehörigen Verzeichnissen, ebenfalls in „packed objects“. Dabei können die „packed objects“ entweder Verzeichnisse oder Daten enthalten, nicht beides.
13
RAN Data on Tag
DSFID
Fülldaten
und/oder
Verweis
(optional)
1. Packed
Object
Fülldaten
und/oder
Verweis
(optional)
2. Packed
Object
…
1. Packed
Object
Fülldaten
und/oder
Verweis
(optional)
NullwertAbschluss
Abbildung 3: Datenstruktur der "Packed Objects"
Die Datenstruktur der „packed objects“ ist in Abbildung 3 dargestellt. Am Beginn steht
ein Data Storage Format Identifier (DSFID), der die Datenstruktur „packed objects“
angibt. Im Anschluss werden die Packed Objects hintereinander aufgelistet, dabei
können sie optional durch Fülldaten oder, was wahrscheinlicher ist, durch einen Verweis auf ein dazugehöriges Verzeichnis getrennt werden. Für die Strukturierung der
Packed Objects wird an dieser Stelle auf das dazugehörige Dokument von GS1 verwiesen, in denen eine ausführliche Beschreibung zur Nutzung beschrieben ist.
3.4.2 Eignung für die Nutzung im RAN-Netzwerk
Die Datenstruktur der „Packed Objects“ ist hinsichtlich der zu speichernden Daten
sehr flexibel. Die Datenstruktur hat hingegen keine klare Trennung zwischen Verzeichnissen und Daten. Da ebenfalls keine festen Speicherbereiche für die jeweiligen
Packed Objects zugewiesen wurden, muss immer der komplette Speicher ausgelesen werden, um die relevanten Daten zu bekommen. Auch ein unternehmensübergreifender Datenaustausch ist schwer umzusetzen, da bei einer Aneinanderreihung
der Packed Objects nur schwer bestehende Daten umgeschrieben, erweitert oder
gelöscht werden können. Da zudem keine Konformität zur gültigen ISO/IEC 15961
und ISO/IEC 15962 gegeben ist, ist dieses Datenformat für die RAN-Anforderungen
nicht empfehlenswert.
14
RAN Data on Tag
3.5 SemProM Metaformat
3.5.1 Beschreibung
Das in der Innovations-Allianz “Digital Product Memory” eingebettete BMBF-Projekt
SemProM hatte zum Ziel, Schlüsseltechnologien für das „Internet of Things“ zu entwickeln. Durch den Einsatz integrierter Sensorik wurden die Bedingungen im Produktionsprozess transparent und die Lieferkette sowie die Umweltbedingungen nachverfolgbar. Der Hersteller wird durch das Gedächtnis in der Produktion unterstützt und
der Endkunde wird besser über das Produkt informiert. Für die Ablage der unterschiedlichsten Produktdaten wurde ein Containerformat entwickelt, mit dem die Daten auf 2D-Matrix Codes, RFID-Transpondern und embedded Devices abgelegt werden können.
Durch das Konsortium wurden für das „Semantische Produktgedächtnis“ eine Reihe
von Anforderungen bzw. Randbedingungen festgelegt, wobei im Folgenden exemplarisch einige skizziert werden.

Es muss möglich sein, beliebige Binärdaten zu speichern

Modifizierende Zugriffe auf das Gedächtnis müssen mitprotokolliert werden
können

Eine einfache Suche nach Einträgen / Ereignissen muss möglich sein

Der Aufbau soll so flexibel sein, dass das Gedächtnis unterschiedlich detailliert
sein kann

Es muss möglich sein, jeden Eintrag alternativ als Verweis auf eine externe
Datenquelle zu realisieren
Dazu wurden in unterschiedlichen Applikationsfeldern neue Konzepte für die objektbezogene Modellierung und Speicherung von Daten entwickelt und erprobt. Ein Ergebnis dieser Arbeiten ist das in Abbildung 4 dargestellte Architekturbild, welches
eine geschichtete Architektur mit definierten Schnittstellen festlegt. Diese Architektur
entstand aus der Erkenntnis, dass einerseits die Applikationen im Projekt sehr stark
divergieren, andererseits aber auch die konkreten physikalischen Speichermöglichkeiten von Barcodes bis zu komplexen autonomen Systemen reichen.
15
RAN Data on Tag
Abbildung 4: SemProm Architekturbild
Eine wesentliche Schnittstelle in dieser Architektur stellt das Block Interface dar, welches von der konkreten physikalischen Ausprägung des zugrundeliegenden SemProMs abstrahiert. Dadurch können Applikationen, aber auch andere Komponenten,
einfach auf die Daten eines SemProMs zugreifen.
Für das Block Interface existieren bereits erprobte und sofort nutzbare Lösungen für
die Plattformen .Net Framework 3.5, .Net Compact Framework 3.5 sowie .Net Micro
Framework 3.0.
Zentraler Einstiegspunkt ist das Interface ISemProm, welches wiederum den Zugang
zu den schon bekannten und beschriebenen Interfaces IBlockMemory und IBlockSearch ermöglicht. In ISemProM selbst sind nun Informationen aus dem Binärformat
(MajorVersion, MinorVersion, …) sowie Daten über die Größe und den belegten /
freien Speicher direkt zugänglich.
-
ISemProm, IBlockMemory und IBlockSearch sind die wichtigen Interfaces
für das Gedächtnis.
-
IBlockInfo, IBlockMeta sind Interfaces für einzelne Facetten eines Blocks.
-
IHistoryInfo bietet eine Schnittstelle zu einem History-Element.
16
RAN Data on Tag
Abbildung 5: Interface-Hierarchie BlockInterface
3.5.2 SemProM Metaformat/Binärformat
Das SemProM-Format ist von der Konzeption her sehr flexibel ausgelegt und skaliert
von einfachen 2D-Codes bis hin zu embedded Systemen. Für RAN ist vor allem das
„Storage SemProM“ interessant. Dabei handelt es sich um die SemProMAusprägung für RFID-Transponder. Für die platzsparende Datenablage auf Transpondern wurde im Rahmen von SemProM ein Binärformat definiert. Der Zugriff erfolgt über das vorgestellte Block Interface.
Das Gedächtnis wird dabei in Blöcken strukturiert, deren mögliche Anzahl und Größe
vom Typ des unterlagerten SemProMs abhängig ist. Meta-Informationen beschreiben
allgemeinverständlich die Inhalte der Blöcke. Jeder Block besitzt einen spezifischen
unveränderlichen Blocktyp, der für bestimmte Inhalte vom SemProM-Konsortium
festgelegt wurde. Für proprietäre Inhalte ist der Blocktyp Custom vorgesehen. Neben
dem Blocktyp enthält jeder Block einen festen ContentType, der dem Internet-MIMEType entspricht. Bestimmte Ausprägungen eines SemProMs sind zusätzlich in der
Lage modifizierende Operationen auf das Gedächtnis automatisch mit aufzuzeichnen
(History).
17
RAN Data on Tag
Aufbau
 SemProM Header
 Mehrere SemProM-Blöcke
SemProM-Block
 Block-Header
 werden direkt hinter den SemProMHeader geschrieben
 Beinhalten Verwaltungs- und MetaInformationen
 Block-Data
 Wachsen von der unteren
Speichergrenze
 Beinhalten die eigentlichen Nutzdaten
Abbildung 6: Struktur des Storage SemProM
Im nachfolgenden wird das Binärformat in Kürze vorgestellt. Detaillierte Informationen über das Binärformat sind der offiziellen Spezifikation „SemProM-Metaformat
V1.0“ [SemProM 2010] zu entnehmen.
Abbildung 7: Aufbau des SemProM-Header
SemProM-Header
Der kompakte SemProM-Header (siehe Abbildung 7) besteht aus einem kurzen Identifier, gefolgt von Attributen, die eine saubere Versionierung des Daten-Formats er-
18
RAN Data on Tag
lauben. Das Feld Overall-Length gibt die Gesamtgröße des SemProMs an, das Feld
Index-Length die Länge aller Header-Blöcke. Damit können in nur einem Lesevorgang sämtliche Header-Blöcke vom Schreib-/Lesegerät ausgelesen und anschließend interpretiert werden. Ist der gewünschte Daten-Block gefunden, kann dieser mit
einem zweiten Lesevorgang gezielt ausgelesen werden. Durch diese Technik muss
nicht der komplette RFID-Speicher ausgelesen werden, was gerade bei größeren
Speicherbereichen unabdingbar ist.
Block-Header
Für jeden Datenblock existiert ein zugehöriger Block-Header. Ein Block-Header besteht minimal aus 27 Bytes. Die Attribute des Block-Headers werden in Abbildung 8
symbolisch dargestellt. Über das Block Interface ist ein komfortabeler Zugriff auf den
einzelnen Attributen gegeben.
Abbildung 8: Struktur des Block-Header
Die BlockID ist für die interne Speicherverwaltung die eindeutige Kennung des
Blocks. Über das Feld HeaderLength wird die Länge des Header-Blocks definiert.
Die Attribute DataLength und DataAddress sind Verwaltungsinformationen und definieren die genaue Position und Größe des zugehörigen Daten-Blocks. Über BlockTye und ContentType kann das Datenformat des Daten-Blocks angegeben werden.
19
RAN Data on Tag
Über MetaTags können verschiedene Meta-Informationen über den Inhalt bekannt
gegeben werden. Die Felder Created und Modified bestehen aus einem Zeitstempel, der das Erstell- bzw. Änderungsdatum des Blocks angibt sowie aus Informationen über den Blockautor. Damit die Echtheit des Datenfelds gewährleistet werden
kann, existiert das Signature-Feld, in dem die Signatur über den kompletten Block
abgelegt werden kann.
Abbildung 9 zeigt den Speicher eines 112 Byte großen HF-Transponders. Hier sind
nach dem beschriebenen Format zwei verschiedene Blöcke abgelegt. Die graue
Schattierung zeigt den SemProM-Header, die orange Schattierung die beiden BlockHeader und im unteren Bereich die blaue Schattierung schließlich die beiden DatenBlöcke.
Das Beispiel zeigt, dass bereits ab einer Speichergröße von 112 Byte das Binärformat sinnvoll eingesetzt werden kann. Die wesentlichen Vorteile dieses dynamischen
Formats kommen jedoch erst bei wachsender Speichergröße (ab ca. 500 Bytes) richtig zum Tragen, da hier das Verhältnis zwischen Header-Daten und Nutz-Daten akzeptabel ausgewogen ist.
Abbildung 9: Nach dem SemProM-Storage-Format strukturierter HF-Transponder
(112 Byte)
20
RAN Data on Tag
3.5.3 Eignung für die Nutzung im RAN-Netzwerk
Das im Projekt SemProM entwickelte Containerformat kann zur universellen Datenablage in mittelgroßen bis großen Speichern ohne eigenes Dateisystem universell
eingesetzt werden. Die integrierte Speicherverwaltung übernimmt dabei ähnlich wie
ein Dateisystem die wesentlichen Funktionen zur Speicherorganisation, dem schnellen Auffinden sowie Suchen nach den gewünschten Informationen.
Das Format bietet folgende Vorteile

Universelles Containerformat mit integrierter Speicherverwaltung

Sofort nutzbar und im SemProM-Konsortium bereits weitläufig erprobt

Standardisierung (W3C) ist angestoßen

Breite und skalierbare Einsatzmöglichkeit

Bei den Block-Header handelt es sich nicht ausschließlich um Verwaltungsinformationen, zusätzlich werden zahlreiche Meta-Informationen über den eigentlichen Datenblock bereitgestellt

Format zielt auf hohe Skalierbarkeit für unterschiedliche Gedächtnisklassen,
dies ist nicht zwingend in RAN erforderlich, aber:
o Nicht benötigte Attribute (Speicherplatz) können unter genau nachvollziehbarem Wegfall von Funktionalität eingespart werden, wie z.B. Änderungshistorie, etc.
3.6 Fazit
Nach Analyse der bestehenden Normen und Empfehlungen zur Datenstrukturierung
auf dem RFID-Transponder haben sich vor dem Hintergrund der Notwendigkeit, unternehmensübergreifend Daten lesen, schreiben und verändern zu können sowie der
in Zukunft steigenden Speichergrößen auf RFID-Transpondern, die folgenden Ergebnisse gegeben:
-
Die ISO/IEC-Normen 15961 und 15962 beinhalten Empfehlungen, die lediglich für kleine Speichergrößen handhabbar sind. Die Notwendigkeit eines Verzeichnisses für größere Datenmengen und unterschiedliche Formate wird
zwar erkannt, aber keine hinreichend geeignete Lösung bereitgestellt. Die Datenformate engen die zu speichernden Daten ebenfalls ein, so dass hier in
erster Linie das Datenformattyp 0 notFormattet zum Tragen kommen muss.
21
RAN Data on Tag
-
Die VDA/JAIF-Empfehlungen sind ebenfalls nur für kleine Datenmengen, wie
sie bereits heute ausgetauscht werden, geeignet. Für diese Daten ist es ein
geeignetes Format. Eine zukunftsweisende Lösung muss jedoch auch mit
größeren Datenmengen umgehen können.
-
Die GS1/EPC-Empfehlung der „packed objects“ greift die Idee auf, ähnliche
Daten in einem Objekt zusammenzufassen, allerdings ist die Struktur durch
die Verweise auf Verzeichnisse, die ebenfalls in „packed objects“ stehen, nicht
transparent und erschwert ein gezieltes Arbeiten mit unterschiedlichen Daten.
Da dieses Format zusätzlich nicht mit der gültigen ISO-Norm konform ist, ist
eine Anwendung im RAN-Kontext nicht weiterzuempfehlen.
-
Das SemProM-Metaformat weist durch das Containerformat mit integrierter
Speicherverwaltung die Möglichkeit auf, jegliche Art von Daten auf dem
Transponder zu speichern. Ebenfalls ist es möglich, dass verschiedene Partner der automobilen Lieferkette ihre Daten dort speichern, verwalten und gegenseitig nutzen.
Für die aktuellen und zukünftig zu erwartenden Erfordernisse des unternehmensübergreifenden Datenaustauschs über den Transponder eignet sich somit das
SemProM-Format am besten. Um dieses Format in der Praxis zu erproben, wurde es innerhalb eines Testcases umgesetzt. Im folgenden Kapitel erfolgt die
Beschreibung dieses Testcases.
22
RAN Data on Tag
4 Prototypische Anwendung des SemProM-Formates für
Data-on-Tag
Das vorgestellte SemProM-Binärformat wurde speziell für die Speichergrößen von
RFID-Transponder entwickelt und stellt daher für RAN ein gutes Containerformat dar.
Das wesentliche Merkmal vom Metaformat ist, dass mehrere Datenblöcke unabhängig voneinander im physikalisch gleichen Speicher abgelegt werden können. Die
Anwender müssen dabei kein Wissen über die bereits existierenden Blöcke verfügen.
Dies ist für RAN eine notwendige Eigenschaft, da dadurch alle beteiligten Partner
entlang der Wertschöpfungskette ihre eigenen Daten ablegen können, ohne in Gefahr zu laufen, bereits existierende Daten zu überschreiben oder versehentlich zu
manipulieren. Im Folgenden wird die prototypische Anwendung des SemProMFormates innerhalb eines Anwendungsbeispiels aufgezeigt.
4.1 Anwendungsbeispiel
Ausgangssituation
In der Ausgangsituation des Anwendungsbeispiels werden für einen OEM Fahrzeugsitze im Rahmen eines JIS-Konzeptes bei einem Zulieferer (1st-Tier) gefertigt und an
das Montageband des OEMs geliefert. Der OEM sendet hierfür täglich eine Vorschau
der am nächsten Tag zu produzierenden Fahrzeugsitze mit den individuellen Konfigurationen an den Zulieferer. Dabei wird keine eindeutige Materialnummer bestellt
sondern ein Basissitz mit Optionen (z.B. Sitzheizung). Diese Informationen werden
von den Mitarbeiterinnen und -mitarbeitern der Produktionsplanung und -steuerung
(PPS) genutzt, um die Montageaufträge für die Fahrzeugsitze anzulegen. Im Anschluss an die Auftragserzeugung erfolgt die Bildung der Montagereihenfolge in Abhängigkeit der Komplexität der jeweiligen Fahrzeugsitzvariante und mit Hilfe von definierten Kriterien (z. B. Limitierung von aufeinanderfolgenden Montageaufträgen, die
den Verbau einer Sitzheizung erfordern). Ziel dabei ist eine gleichmäßige Auslastung
der Montagemitarbeiterinnen und Mitarbeiter bei konstanter Taktzeit und somit die
termingerechte Auslieferung der bestellten Fahrzeugsitze an den Kunden. Nach abgeschlossener Reihenfolgebildung werden Produktionslabel für die jeweiligen Montageaufträge ausgedruckt und an die Montagelinien für die Fahrzeugsitzmontage
versandt. Das Produktionslabel begleitet den dazugehörigen Sitz durch die gesamte
Montage und enthält die genaue Konfiguration des vom Kunden bestellten Sitzes.
Auf dem Label erfolgt die Darstellung der produktionsrelevanten Informationen neben
einer textuellen Form auch als Barcode, welcher an den einzelnen Montagestationen
ausgelesen werden kann. Nach abgeschlossener Montage mit erfolgreicher Qualitätssicherung erfolgt die kurzfristige Einlagerung in einem Hochregellager. Nach dem
finalen Lieferabruf durch den OEM werden die Fahrzeugsitze in gewünschter Se-
23
RAN Data on Tag
quenz in das OEM-Werk geliefert und an der Fahrzeug-Montagelinie zum anschließenden Verbau im Fahrzeug bereitgestellt.
Die beschriebene Wertschöpfungskette weist aufgrund der hohen Wichtigkeit der
Termintreue, der geringen Bestands- und Zeitreserven sowie der fehlenden Informationstransparenz über den aktuellen Produktzustand, die oben beschriebenen hohen
Anforderungen an die Produktions- und Logistiksteuerung auf. Sie bietet dadurch bei
unvorhergesehenen Ereignissen nur geringen Handlungsspielraum für adäquate Gegenmaßnahmen. Aus diesem Grund eignet sich dieses Szenario, um die technische
Machbarkeit und die Potenziale einer RFID-basierten Produktionssteuerung und ereignisbasierten Absicherung der Lieferkette zu evaluieren und aufzuzeigen.
Abbildung 10: Partner im Testcases sowie deren Funktion
Beteiligte RAN-Partner am Testcase
Die in Abbildung 10 dargestellten Unternehmen haben sich innerhalb des Forschungsprojektes RAN zusammengeschlossen, um aufbauend auf dem beschriebenen Szenario die Datengenerierung und den Echtzeit-Datenaustausch aller für den
oben beschriebenen Ansatz notwendigen Informationen prototypisch im produktiven,
automobilen Umfeld zu implementieren und zu testen. Das Ziel dieses Testcases ist
somit die Erzeugung und Bereitstellung qualitativer sowie quantitativer Ereignisdaten
24
RAN Data on Tag
und, über den beschriebenen Ansatz hinausgehend, produktspezifischer Informationen, die vom intelligenten Produkt dezentral bereitgestellt werden.
Technische Realisierung
Grundlage der Implementierung einer RFID-basierten Steuerung und ereignisbasierten Absicherung der Wertschöpfungskette ist die Installation mehrerer RFIDReadpoints an charakteristischen Positionen entlang des Produktionsablaufs und die
Ausstattung von Fahrzeugsitzen mit RFID-Transpondern. Ein RFID-Readpoint besteht in diesem Fall aus einer oder mehreren RFID-Antennen, die an einem RFIDReader angeschlossen sind. Der Readpoint wird zum Lesen und Beschreiben der
RFID-Transponder genutzt. Im Rahmen dieses Testcases wurden fünf Readpoints
entlang der Wertschöpfungskette installiert. Sie sind zur prototypischen Umsetzung
in ausgewählte Produktionsabläufe eingebettet, die für die unternehmensübergreifende Auftragsabwicklung von besonderer Bedeutung sind. Gemäß dem Leitfanden
„RAN Erfassungsklassen“ sind alle Readpoints der Erfassungsklasse 2 „SingleReadpoint“ zuzuordnen. Im Folgenden werden beispielhaft zwei der umgesetzten
Readpoints beschrieben und hinsichtlich der generierten steuerungsrelevanten Daten spezifiziert. Grundsätzlich dient die Anbringung des Transponders am Fahrzeugsitz der Bereitstellung von produktions- bzw. steuerungsrelevanten Daten, die, wie in
der Ausgangssituation des Anwendungsbeispiels beschrieben, aktuell über das Produktionslabel bereitgestellt werden.
Der erste Readpoint innerhalb des Testcases ist im Bereich der finalen Montagebzw. Qualitätssicherungsstation für die Fahrzeugsitze des Zulieferers installiert. Bei
der eingesetzten Hardware handelt es sich um Antennen und Schreib-/Lesegeräte
der Fa. Siemens AG. Der RFID-Transponder (Label) des Sitzes wird bereits zuvor,
bei der Montage einer seitlichen Kunststoffblende, in welche der Transponder eingeklebt wird, an den rechten Vordersitz angebracht (vgl. Abbildung 11).
25
RAN Data on Tag
Abbildung 11: Eingesetzte Hardware im Testcase
Nachdem der Ladungsträger mit den Fahrzeugsitzen die letzte Montage- bzw. Qualitätssicherungsstation erreicht hat, erfolgt zunächst ein Scan des sich auf dem Produktionslabel befindlichen Barcodes. Das Scannen des Barcodes ist einerseits Trigger für den Lese- und Schreibvorgang des RFID-Readers, andererseits lassen sich
auf diese Weise die relevanten Informationen des Produktes (z. B. Materialnummer,
Optionscode) aus den betrieblichen Planungs- und Informationssystemen abrufen
(vgl. Abbildung x3 und x4). Im EPC ist dabei lediglich die Objektklasse des Basissitzes verschlüsselt, die Sitz-Variante selbst wird hingegen nur durch die Auflistung der
Optionen deutlich. Aus diesem Grund ist der EPC selber nicht aussagekräftig genug,
um den Sitz für den OEM hinreichend genug zu beschreiben. Aus diesem Grund ist
der Optionscode notwendig. Im Anschluss an den Scanvorgang erfolgt die Initialisierung des Sitz-Transponders mit den relevanten produktspezifischen Informationen.
Neben der Identifikationsnummer, der EPC (Electronic Product Code), können sowohl organisatorische (z. B. Produktionsdatum) als auch prozessuale Daten (z. B.
Drehmoment) auf dem Transponder gespeichert werden. Darüber hinaus werden an
diesem Readpoint qualitative Ereignisinformationen generiert. Wesentlich ist dabei
das sog. Produktionsende-Event, welches Informationen (z. B. Zeitpunkt) zum erfolgreichen Abschluss der Fahrzeugsitzmontage zusammenfasst. Durch den oben beschriebenen Infobroker-Standard können diese Informationen schnell zwischen den
Partnern der Wertschöpfungskette ausgetauscht werden.
26
RAN Data on Tag
Der zweite Readpoint, der vorgestellt werden soll, ist im Bereich der Montagestation
des OEM installiert, an der der Fahrzeugsitz in das Fahrzeug verbaut wird. Im Gegensatz zum ersten vorgestellten Readpoint erfolgt an dieser Stelle der Verbau von
zwei intelligenten Produkten, denn sowohl der Fahrzeugsitz als auch die Fahrzeugkarosse sind mit einem RFID-Transponder ausgestattet, welcher produktionsrelevante Informationen enthält. Der Transponder an der Fahrzeugkarosse ist dabei an der
Fahrzeugkarosse in der für das jeweilige Modell spezifizierten Position (im Beispiel
vorne am Aufprallbegrenzer) befestigt. Dieser Readpoint ist mit zwei Antennen ausgestattet, da eine Antenne den Sitztransponder und die andere den Fahrzeugtransponder lesen soll. Aus den gewonnenen Daten wird das sog. Montage-Event generiert, welches die zeitlich bestimmte Information enthält, dass der Fahrzeugsitz im
Fahrzeug verbaut wurde. Darüber hinaus sind in diesem Event, dem oben beschriebenen Datenmodell folgend, das produktspezifische Drehmoment und Drehwinkel als
quantitative Informationen gespeichert, sodass eine ereignisbasierte Abbildung des
Produktzustandes realisiert werden konnte. Diese Informationen werden ebenfalls
auf dem Transponder des intelligenten Fahrzeugsitzes gespeichert und somit dezentral mitgeführt.
Da der Speicherplatz auf den für den Testcase verfügbaren Transpondern auf 64
Bytes beschränkt war, wurde im Rahmen des Testcases eine Datenstruktur entwickelt, die einerseits abzuspeichernde Attribute platzsparend binär codiert und darüber hinaus einen schnellen Zugriff und ein einfaches Verändern, Hinzufügen bzw.
Löschen von Attributen ermöglicht. Diese Datenstruktur kann als Nutzdatenblock auf
einen SemProM abgelegt werden.
4.2 Beschreibung des Datenformats
Das nachfolgende Beispiel zeigt den exemplarischen Einsatz von Data-on-Tag für
den Austausch von Informationen zwischen dem Zulieferer und dem OEM am Beispiel des Testcases Sitzeinbau (Abbildung 12). Hierbei ist zu beachten, dass bei der
Umsetzung im Testcase, wie in Abschnitt 4.1 beschrieben, aufgrund mangelnder
Speichergröße eine platzsparendere Datenstruktur eingesetzt wurde.
27
RAN Data on Tag
Abbildung 12: Übersicht des Szenarios "Sitzeinbau" inkl. der Verwendung von Dataon-Tag
1. Vom Zulieferer werden insgesamt 110 Bytes teilespezifische Informationen auf
dem am Sitz verbauten Transponder geschrieben. Diese Informationen wurden in einem eigenen Block vom Zulieferer abgelegt.
2. Beim OEM wird gezielt der Block des Zulieferers ausgelesen und der Datensatz zur Montage genutzt
3. Anschließend erstellt der OEM einen eigenen Datenblock im Transponder zur
Ablage von Qualitätsinformationen. (exemplarisch 41 Bytes groß)
4. An einen möglichen Nacharbeitsplatz könnten wiederum durch gezieltes Auslesen des OEM-Blocks die Qualitätsinformationen ausgelesen werden, eine
eventuelle Nacharbeitung angestoßen werden und anschließen dieser Qualitäts-Block aktualisiert werden
Für die beiden Datenblöcke gibt das SemProM-Format sowohl dem Zulieferer als
auch dem OEM die Möglichkeit, über zusätzliche Metainformationen die Datenblöcke
zu beschreiben.
28
RAN Data on Tag
4.3 Nutzdatenblock „Attribute-Block“
Das vorgestellte SemProM-Format ist mit einem Dateisystem für den Transponder
vergleichbar in dem sich beliebige Binärformate ablegen lassen, siehe Abbildung unten. Für den Austausch von Informationen zwischen den Partnern ist allerdings ein
gemeinsames Datenformat notwendig mit dem die eigentlich auszutauschenden
Nutzinformationen entsprechend binär codiert werden und als Nutzdatenblock im
SemProM abgelegt werden. Da für einfach typisierte Werte kein platzsparendes Binärformat existiert, wurde von Siemens der „Attribute-Block“ geschaffen, ein Datenformat das genau diesen Anforderungen genügt. Für die Erzeugung bzw. Interpretation wurden eine einfach zu nutzende .NET Bibliothek zur Verfügung gestellt. Die
nachfolgende Abbildung zeigt, dass der Nutzdatenblock 1 vom Format AttributeBlock ist. Dank des SemProM-Formats können auch noch weitere SemProM-Blöcke
mit anderen Dateiformaten im gleichen Transponder existieren.
SemProM Header
Block-Header 1
Block-Header 2
Block-Header 3
Block-Data 3 {PDF}
Block-Data 2 {JPG}
Block-Data 1 {AttributeBlock}
Abbildung 13: Ablage unterschiedlich formatierter Nutzdatenblöcke im SemProM
(Quelle: Siemens AG)
Das Format zeigt einen dynamischen Aufbau. Im Header sind lediglich ein einfacher
Identifier und die aktuelle Anzahl der Attribute hinterlegt. Gefolgt wird der Header von
den aneinandergereihten Attributen. Jedes Attribut-Feld besteht aus einem Key, der
angibt, wie viele Bytes der eigentliche Wert groß ist und schließlich dem Attribut-Wert
selbst.
29
RAN Data on Tag
Aufbau dynamisches Datenformat
Feldname
Länge in Bytes
Startkennung
2
immer "RF"
Anzahl Attribute
1
Attribut_1
Key
1
ENUM_KEY
Value_Length
1
Value
Attribut_n
Key
1
ENUM_KEY
Value_Length
1
Value
Abbildung 14: Struktur des Attribute-Blocks
Für den partnerübergreifenden Datenaustausch zwischen dem Zulieferer und dem
OEM sollten die in der Tabelle ENUM_KEY aufgelisteten Informationen per Transponder ausgetauscht werden. Durch die Definition der Keys mit dem zugehörigen
Datentyp und der maximalen Größe in Bytes (siehe Abbildung) konnte das oben beschriebene Nutzdatenformat sofort verwendet werden.
0x00
0x01
0x02
0x03
0x04
0x05
0x06
0x07
0x08
0x00
0x01
0x02
0x03
0x10
0x11
0x12
0x13
ENUM_KEY
Status
Produktionsdatum
Location
PA_Nummer
Drehmoment
Drehwinkel
Drehmoment_2
Drehweinkel_2
Option
Verknüpfter Datentyp für Value
Byte
UTC Zeitspempel
ENUM_LOCATION
STRING
Float
Float
Float
Float
STRING
Größe
1
4
1
1-8
4
4
4
4
1-9
ENUM_LOCATION
Nacharbeit
Versandlager
Produktionslinie_Opel1
Produktionslinie_Opel2
Werk
Anlage
Station
Linie
Abbildung 15: Definition der ENUM-Keys
30
RAN Data on Tag
In der nächsten Abbildung ist exemplarisch ein solcher Attribute-Block bestehend aus
den Attributen „PA-Nummer“ und „Option“ dargestellt.
Beispiel für 2 enthaltene Attribute: PA-Nummer + Option
Byte
Value
1
0x52
R
Header
2
0x46
F
Anzahl Attribute
3
0x02
2
4
0x03
PA-Nummer
Key_Attribut_1
5
0x07
7
Länge_Attribut_1
6
0x41
A
7
0x42
B
8
0x43
C
9
0x44
D
Value_Attribut_1
10
0x45
E
11
0x46
F
12
0x47
G
13
0x08
Option
Key_Attribut_2
14
0x03
9
Länge_Attribut_2
15
0x41
A
16
0x42
B
17
0x43
C
18
0x44
D
19
0x45
E
Value_Attribut_2
20
0x46
F
21
0x47
G
22
0x48
H
23
0x49
I
Abbildung 16: Beispielhaft beschriebener Attribute-Block
31
RAN Data on Tag
Verwendete Block-Metainformationen für Zulieferer und OEM
BlockType
ContentType
MetaTags
Created
BlockType
ContentType
MetaTags
Created
Zusätzliche Metadaten
0xFF
Custom
0x6A
Application Octett-Stream
0x01 0x02
Phase Of Product Lifecycle = Production
0x02 0x05
Vertical Market = Automotive
0x05 0x01
FLAGs = Safety Relevant Information
0x4E733250
TimeStamp
0xFF
AuthorType = Custom
0x4B656970657220476D6248 Keiper GmbH
0xFF
0x6A
0x01 0x02
0x02 0x05
0x05 0x01
0x4E733250
0xFF
0x4F70656C204147
Custom
Application Octett-Stream
Phase Of Product Lifecycle = Production
Vertical Market = Automotive
FLAGs = Safety Relevant Information
TimeStamp
AuthorType = Custom
Opel AG
Abbildung 17: Beispiel für Meta-Daten des Zulieferers und des OEMs
Die nachfolgende Grafik zeigt die Struktur des SemProMs nach dem beschriebenen
Szenario
SemProM-Header
12 Byte
Block-Header
(Zulieferer) 45 Byte
Block-Header (OEM)
41 Byte
FREIER BEREICH
81 Byte
Nutzdaten/
OEM-Daten
Speichergröße RFID-Tag: 384 Byte
95 Byte
Nutzdaten/
Zulieferer-Daten
110 Byte
Abbildung 18: Speicherblöcke im SemProM nach dem Szenario
32
RAN Data on Tag
5 Empfehlung
Im Rahmen der Arbeitsgruppe Data-on-Tag wurde die in diesem Kapitel vorgestellte
Empfehlung für die Strukturierung von Daten im User-Memory erarbeitet.
Bezüglich des Anwendungsfalls dieser Leitlinie wird bezugnehmend auf die VDAEmpfehlung 5510 zunächst der Einsatz für Teile und Baugruppen der Automobilindustrie empfohlen. Hierfür bestehen konkrete Anwendungsfälle und somit ein Bedarf,
für den durch Data-on-Tag ein erheblicher Mehrwert geschaffen werden kann.
Für den Einsatz von Data-on-Tag im Behältermanagement der Supply Chain gemäß
VDA-Empfehlung 5501 ist bisher noch kein Anwendungsfall bekannt, so dass hier
keine ausdrückliche Empfehlung gegeben wird. Weiterhin existieren Vorbehalte aus
der Logistikbranche, insbesondere in Verbindung mit getaggten Objekten außerhalb
der Automobilindustrie. Die empfohlenen Datenstrukturen gemäß ISO 15961/15962
und SemProM würden aus technischer Sicht jedoch auch im Behältermanagement
eingesetzt werden können.
5.1 Kleine Datenmengen (bis ca. 300 Byte)
Bei kleineren Datenformaten bis ca. 300 Byte ist eine Orientierung an den Empfehlungen von VDA 5501/5510 sowie des JAIF Global RFID Item Level Standard sinnvoll, da so auf einen großen Datenoverhead verzichtet wird und ein volles Auslesen
des Transponders keinen großen Zeitverlust darstellt. Aufgrund der bestehenden
Empfehlung seitens VDA und JAIF ist bereits eine hohe Verbreitung in der Automobilindustrie sichergestellt, so dass bei einem geeigneten Einsatzfeld keine andere
Lösung parallel betrieben sollte. Sofern aber die auf dem Transponder zu speichernden Datenmengen nicht mehr für den Einsatzzweck dieser Datenstruktur geeignet
ist, sollte auf ein neues, zukunftsfähigeres Datenformat gesetzt werden.
5.2 Mittlere bis große Datenmengen (ab ca. 300 Byte) sowie
Zugriff mehrerer Partner
Ab einer Speichergröße von 112 Byte kann das SemProM-Binärformat bereits eingesetzt werden. Empfehlenswert ist es jedoch, das Format erst ab einer Größe von
mehreren hundert Bytes zu verwenden, da ab dieser Größe das Verhältnis zwischen
Header-Informationen und Nutzdaten effizient ist.
Wichtig ist festzuhalten, dass es sich bei dem Block-Header nicht ausschließlich um
Verwaltungsinformationen handelt, sondern zahlreiche Meta-Informationen über den
33
RAN Data on Tag
eigentlichen Datenblock bereitgestellt werden. Eine solche semantische Beschreibung der Daten bietet keines der anderen untersuchten Formate.
Bei Transpondern ab einer Speichergröße von mehreren hundert Bytes ist es aus
zeitlicher Sicht ratsam, nur die tatsachlich notwendigen Speicherbereiche auszulesen. Das gezielte „wahlfreie“ Auslesen von Informationen wird ebenfalls durch das
SemProM-Format ermöglicht.
Da es sich beim SemProM-Format um ein Binärformat handelt, können auch beliebige Binärdaten ohne vorherige Konvertierung einfach und effizient abgelegt werden.
Das beschriebene Binärformat stellt quasi das „Dateisystem“ des Transponders dar.
Damit ist es bereits möglich, dass mehrere Partner ihre eigenen Datenblöcke ablegen können. Sobald mehrere Partner Informationen untereinander austauschen wollen, greifen sie auf dem gleichen Datenblock zu. Dies setzt voraus, dass beide Partner das Format der Nutzdaten interpretieren können. Über die Meta-Informationen
des SemProM-Formats kann dazu definiert werden, um welches Nutzdatenformat es
sich im Block handelt. Dazu könnte beispielsweise das Attribut Content-Typ verwendet werden.
Im Rahmen des RAN-Projekts wurde die Erfahrung gemacht, dass oftmals nur einfache Key-Value-Wert-Paare zwischen den Partnern ausgetauscht werden sollen. Da
dafür kein geeignetes, freies und kompaktes Binärformat existiert, wurde im Rahmen
des Testcases von Siemens ein Attribut-Block-Format erstellt und implementiert (siehe Beschreibung in Kapitel 4). Mit Hilfe dieses Formats lassen sich diese Key-ValueWert-Paare typisiert innerhalb des SemProM-Formats austauschen.
34
RAN Data on Tag
6 Vorgehen zur Standardisierung
Um eine umfassende Verbreitung dieser Empfehlung sicherzustellen, ist eine Aufnahme des SemProM-Formats in die bestehenden Standards zu empfehlen. Insbesondere vor dem Hintergrund wachsender Speichergrößen der RFID-Transponder
sind neue Datenstrukturen in den bestehenden Normen notwendig, so dass dieser
Schritt in Zukunft zwangsläufig notwendig sein wird.
Eine erste Möglichkeit wäre die Aufnahme der SemProM-Empfehlung für große Datenspeicher in die VDA-Empfehlung 5510 (sowie gegebenenfalls 5501), um zunächst
die Verbreitung innerhalb des RAN-Netzwerks sicherzustellen. Ebenfalls ist die Dataon-Tag-Thematik in einer entstehenden VDA-Empfehlung zum RAN-Netzwerk notwendig.
Ein weiterer Schritt wäre die Ausweitung dieser Norm innerhalb der JAIF sowie die
Aufnahme in die ISO 15961 oder 15962. Empfehlenswert wäre hier eine Aufnahme
des SemProM-Formates als eigenständige accessMethod, mit der unter Verwendung
von dataFormat 0 keine Einschränkungen der abzulegenden Daten getroffen werden. Eine weitere Möglichkeit besteht in der Aufweitung der AccessMethod 1 „directory“ um die Möglichkeit, die Daten auch nach der SemProM-Struktur abzulegen.
Dabei sollte zumindest vorgegeben werden, dass die Nutzdaten in einem Containerformat vom hinteren Speicherbereich nach vorne abgelegt werden, während vom
vorderen Speicherbereich ausgehend, zunächst die Metadaten als Inhaltsverzeichnis
geschrieben werden.
35
RAN Data on Tag
7 Quellenverzeichnis
Günthner & ten Hompel 2010: Günthner, W.; ten Hompel, M.: Internet der Dinge.
Berlin: Springer 2010.
Finkenzeller 2008: Finkenzeller, K.: RFID-Handbuch. 5., aktualis. u. erw Aufl. München: Hanser 2008.
ISO/IEC 15961:
Information technology - Radio frequency identification (RFID) for
item management - Data protocol: application interface. Ausgabe
15.10.2004 (ISO/IEC 15961:2004(E)).
ISO/IEC 15962:
Information technology - Radio frequency identification (RFID) for
item management - Data protocol: data encoding rules and logical memory functions. Ausgabe 15.10.2004 (ISO/IEC
15962:2004(E)).
JAIF 2011:
Automotive Industry Action Group: JAIF Global Radio Frequency
Identification (RFID) Item Level Standard. Final Draft 10.08.2011.
VDA 5501:
VDA-Empfehlung 5501 RFID-Behältermanagement in der Supply
Chain. Version 1.2, 10.2011.
VDA 5510:
VDA-Empfehlung 5510 RFID zur Verfolgung von Teilen und
Baugruppen in der Automobilindustrie. Version 1.1, 11.2011.
GS1 2011:
GS1 EPC Tag Data Standard 1.6. 09.09.2011.
SemProM 2010:
SemProM Metaformat
SemProM container format Version 1.0, 24.06.2010
http://www.semprom.org
W3C:
http://www.w3.org/2005/Incubator/omm/wiki/SemProM_Containe
r_Format_Version_1.0#Meta_Format_overview
RAN 2012
RFID-based Automotive Network: Leitfaden: RAN Erfassungsklassen (Leitfaden_AP4_V0_0.3, Stand: 09.10.2012.
36