>> Object2Web - Übersicht über die Inventarverwaltung
Patent
Die Offenlegungsschrift vom 13.04.2017 ist die Erstveröffentlichung unserer Patentanmeldung ' Verfahren zur Verbindung analoger Objekte mit einer digitalen Speichereinheit'. Sie ist die Vorstufe zu der geprüften Patentschrift.DE 10 2015 013 001 A1
Lesen Sie hier die Offenlegungsschrift der DPMA
Wie funktionierts?
Ziel von Object2Web
Ziel von Object2Web ist, die Prozesse rund um die Verwaltung von Inventar zu optimieren. Das heißt die Daten des Objektes über den Lebenszyklus werden kostengünstig an der richtigen Stelle zur richtigen Zeit in sicherer und authentischer Form bereitzustellen. Object2Web ist dabei ein patentgeschütztes Verfahren zur Verbindung analoger Objekte mit einer digitalen Speichereinheit unabhängig der physischen Beschaffenheit des Objektes.
Das Verfahren hilft, die Verwaltung von Objekten zu vereinfachen. Dies geschieht, indem es Daten aus bestehenden Datenquellen zusammenführt/integriert und dem Benutzer einfach zur Verfügung stellt.
Das Verfahren Object2Web basiert auf nicht proprietären Datenbanklogiken.
Object2Web erweitert die bereits eingesetzten Techniken der SupplyChain und Inventarisierung insofern, dass Objekte mit einer oder mehreren dynamischen Speichereinheit(en) (z.B. SAP, Intranet) unter Nutzung einer GUID verbunden werden und diese Daten zur weiteren Verwendung bzw. Veränderung im Intra- und/oder Extranet bereitgestellt werden können.
Im Gegensatz zu Lösungen der GS1-DataMatrix oder des GS1-128-Strichcode (Anzeige einer Zahlenkolonne) stellt Object2Web systemisch dem Benutzer unbegrenzte Datenmengen zur Verfügung. (Anzeige von Daten. Die Anzeige kann im HTML-, XML, JSON, TXT oder jedem anderen Format sein.)
Im Gegensatz zur Lösung des GS1-128-Strichcodes stellt Object2Web auf kleinerer Fläche mehr Informationen zur Verfügung. Der Strichcode muss eine gewisse Größe haben, um von den Lesegeräten eindeutig erfassbar zu sein. Der Object2Web QR-Code ist mit einer Größe von 20mmx20mm kleiner und kann mit einem Smartphone (QR-Code Apps) oder mit QR-Code Scannern gelesen werden.
Durch Verfügbarkeit der QR-Code Scan API sind spezielle IOS, Windows und Android Apps ohne großen Aufwand zu realisieren.
Die Realisierung von Fat- oder ThinClients als Zugriffswerkzeuge ist ohne großen Aufwand zu realisieren.
Das System ist durch seine verteilte Systemarchitektur nicht Störungsanfällig und extrem skalierbar.
Die Einbindung und Nutzung von proprietären Systemen ist ohne weiteres möglich. Ob-ject2Web integriert Datenstrukturen jeglicher Art.
Das Verfahren wird in IMS-Software im Rahmen des OBMS verwendet.
Das Verfahren basiert auf den Erfahrungen der Konzeption der Industrie 4.0.
Einfache Nutzung und Integrationsplattform
Die Nutzung des Verfahrens ist für Anwender extrem einfach. Ein handelsübliches Smartphone reicht aus, um die Daten zum jeweilig gescannten QR-Code anzuschauen und ggf. zu ändern.
Sofern eine gültige Authentifizierung für den Benutzer, eine Schnittstelle zur WWS und eine aktive Webseite genutzt wird, können Daten vom Typ A, B oder C zum gescannten Inventar direkt eingegeben werden. Damit kann die transparente Sicht auf den Lebenszyklus gewährleistet werden. Jeder (autorisierte) kann Lebenzyklusinformationen zum Objekt speichern.
Je nach Integration des Verfahrens ist es möglich, Anwendungen z.B. zur Inventarisierungsunterstützung, Inventartracking, Inventarverkauf oder (Inventur)Terminerinnerungen, zu entwickeln.
Ebenso kann mit dem Verfahren die Datenpflege der Supply Chain ohne Medienbruch erweitert werden.
Umsetzung der Nutzung in prototypischer Form
Die Internetplattform https://www.moximo.de/inventar zeigt prototypisch die Umsetzung des Verfahrens.
Dabei werden zwei Arten von Zugriffen realisiert. Daten vom Typ B werden nur authentifizierten Benutzern angezeigt. Dies ist exemplarisch auf der Webseite: https://www.moximo.de/home/mustmaC/inventar realisiert für den Benutzer: mustmaC mit dem Passwort: xYtaQc4hdUHj
Zu sehen sind auf dieser Seite folgende Stamm- und Bewegungsdaten des Typ B. Die Stammdaten sind hier manuell erfasst. Ziel würde bei einer Implementierung sein, die Daten aus dem ersten Abschnitt aus der WWS zu erhalten, die Daten Allgemein, Maße und Gewichte, Zoll etc. vom Hersteller direkt oder mittelbar aus dem GS1-Datenpool zu erhalten.
Daten vom Typ C sind prototypisch auf folgender Seite zu sehen: https://www.moximo.de/inventar/Oeffentlich/0A907732-51DA-433E-AEEF-940FC78DD6C9.html
Allgemeine Problemstellung
Das Verfahren löst diverse Probleme im Zusammenhang mit der Verwaltung von Objekten. Die wichtigsten allgemeinen Problemstellungen dabei sind:
Es bestehen Schwierigkeiten (Identifikation des Objektes, Zugriff auf Inventarsoftware oder fehlende Hardware) bei der Verwaltung von Objekten, die selbst keine Möglichkeit haben, Daten digital zu speichern. Sind diese Daten letztendlich manuell (semiautomatisiert/GS1-Datenpool) erfasst, können diese oft nicht zentral, im Sinne von bewusst durch Freigabeinstanzen gesteuert, zur Verfügung gestellt werden.
Cyberphysikalische Systeme haben ebenfalls die Schwierigkeit, dass durch das Systems erstellte Daten oft nicht zentral zur Verfügung gestellt werden.
Die Informationsspeicherung auf Basis eines Strichcodes ist systemisch begrenzt. „Nur“ 13-stelliger Nummerncode, der nicht durch Menschen lesbar ist.
RFID Technologie ist als draht- und berührungslose Technik vorteilhaft aber ggf. mit hohen Investitions- und Betriebskosten behaftet. Ebenso ist die Funkübertragung schwer gegen unbefugte Zugriffe abzusichern. Bewegungsdaten sind sensible Daten, die zum einen Datenschutzrechtlichen Vorgaben folgen als auch spezielle Sicherheitsbedürfnisse des Dateninhabers unterliegen.
Erweiterte Problemstellung - Objektzustände
Zu den vorgenannten Problemen ergeben sich aus dem Lebenszyklus eines Objektes weitere Probleme, die eine Verwaltung komplexer machen. Diese Komplexität gilt es mit Assistenzsystemen, z.B. Object2Web, zu lösen.
Prozessual durchschreitet ein Objekt in seinem Lebenszyklus mind. vier Zustände. Das Objekt wird entwickelt, hergestellt, betrieben und nach dem Betrieb recycelt.
Diese Objektzustände müssen optimaler Weise bei der Inventarverwaltung dokumentiert werden.
Smarte Umsetzung mit Ihrem aktuellen System
Parallel zu einer Inventarnummer kann übergangsweise die, durch Freigabe durch das Verfahren, erzeugte weltweit eindeutige GUID im Warenwirtschaftssystem genutzt werden.
Dies kann auf zwei Wegen erfolgen:
- „Erfüllungshalbr:“ Die Inventarnummer der Bundeswehr wird auf den Systemen der moXimo gespeichert und eine dazugehörige GUID generiert und an das Warenwirt-schaftssystem des Anfragers zurückgegeben. Die WWS müsste entsprechend eine weitere Spalte zur Verfügung stellen.
- „Abansttt“: Das WWS generiert selbstständig eine GUID aus einem von moXimo zur Verfügung gestellten Pool an GUIDs und verwendet diese anstatt der heutigen Inventarnummer.
Aktuelle Inventarlösungen - Barcode oder DataMatrix
Die Darstellung beschreibt die Nutzung des Barcode. Dabei wird zur Datensicht ein Bar-codescanner (z.B. Hersteller Fa. Opticon) der zumeist fest (drahtgebunden) mit einem PC verbunden ist, und eine Verwaltungssoftware (z.B. Hersteller Fa. SAP) verwendet.
Diese Art der Datensicht benötigt:
- 13-stelligen Strichcode 128 oder Data Matrix (meist Lizenzpflichtig)
- Barcodescanner Hardware (Sonderhardware)
- PC/Laptop (Standardhardware), in der Nähe des Scanners
- Erfassungssoftware (Standardsoftware, meist Lizenzpflichtig
Erweiterte Inventarlösung durch Object2Web
Das Verfahren kann additiv zu einem bereits eingesetzten System implementiert werden und damit einzelne Schwächen der bereits genutzten Systeme kompensieren.
Dazu wird auf dem Objekt selbst, entweder zusätzlich oder alleinig, ein Hinweis in Form eines QR-Codes angebracht. Dieser QR-Code beinhalten Daten über einen digitalen Ablageort.
Der digitale Ablageort wird durch die Datenspeichereinheit definiert und ist durch die Verwendung einer GUID weltweit eindeutig. Damit kann JEDES einzelne Objekt mit nahezu unendlichen Datenmengen verknüpft werden.
Diese Art der Datensicht benötigt:
- 32-stelligen QR-Code (Patentiert durch Fa. Denso JP)
- QR-Codescanner Hardware (Standardhardware z.B. Smartphone, Tablet, Laptop)
- Intranetzugang (WLAN, WAN etc.)
Der QR-Code ermöglicht einem Benutzer durch einen QR-Scanner Kontakt mit dem weltweit eindeutigen digitalen Ablageort aufzunehmen. Dort sind die Daten des analogen Objektes zu sehen und ggf. zu bearbeiten.
Je nach Anwendung, werden die Daten am Ablageort in einem spezifischen Format vorgehalten. Dies können Daten im Format HTML, XML, CSV, JSON etc. sein.
Der Prozess der Sichtung und ggf. der Erfassung von Daten wird somit wesentlich vereinfacht, wobei eine evtl. bereits eingesetzte Barcode bzw. Data Matrix-Technik weiterhin genutzt werden könnte. Damit kann ein sukzessiver Umstieg realisiert werden und damit auf lange Sicht Kosten eingespart werden
Nutzung der Stammdaten aus der GTIN und Verknüpfung mit Object2Web
„GS1 Germany empfiehlt als Best Practice, Produktstammdaten über einen Datenpool auszutauschen. So müssen Sie Ihre Stammdaten nur einmal bereitstellen und aktualisieren. Alle angebundenen Handelspartner können jederzeit auf Ihre neuesten Produktstammdaten zugreifen.
Hierzu können Sie in Deutschland über 1WorldSync (bisher SA2 Worldsync/1SYNC) zentral Stammdaten austauschen und international darüber am Global Data Synchronization Network (GDSN®) teilnehmen.“
Stammdaten aus dem GS-1 Datenpool können im vorliegenden Verfahren 1:1 genutzt werden um das Inventarobjekt im eigenen System zu erfassen, es wird zu keiner Zeit in den EDI Ablauf eingegriffen.
Nach der Erfassung der Stammdaten und der Anreicherung der Stammdaten mit eigenen Daten im eigenen WWS System erfolgt noch die Verknüpfung des Stammdatensatz mit der Object2Web GUID.
Damit wird der Kreislauf geschlossen
Schutzstatus auf Attributebene für Daten Typ A, B und C
Die vorhandenen Stamm- und entstehenden Bewegungsdaten können auf Attributebene je nach Schutzstatus in mehrere Typenklassen eingeteilt werden. Die Einteilung kann beliebig erweitert werden.
Die folgende Klassifizierungsanwendung stellt ein Beispiel dar, wie die Geheimhaltungsstufen der Bundesrepublik Deutschland umgesetzt werden könnten.
Typ A Die Kenntnisnahme der Typ A-Daten durch Unbefugte kann den Bestand oder lebenswichtige Interessen der Bundesrepublik Deutschland oder eines ihrer Länder gefährden.
Typ B Die Kenntnisnahme durch Unbefugte kann für die Interessen der Bundesrepublik Deutschland oder eines ihrer Länder nachteilig sein.
Typ C Die Kenntnisnahme durch Andere ist für die Interessen der Bundesrepublik Deutschland oder eines ihrer Länder nicht beeinträchtigend
Zugriffsbeschränkung durch Segmentierung
Der digitale Ablageort kann sowohl ein geschütztes Intranet als auch ein semi geschütztes Extranet wie auch ein ungeschütztes Extranet sein. Diese „IT-galvanische“ Trennung hilft dabei, die zentral gespeicherten Daten, gesichert und dezentral, je nach Datentyp für Benutzer aufzubereiten.
Zur Vereinfachung der Nutzung ist eine Kaskadierung der vorgenannten Ablageorte in Form von IP-Netzen (Intra- und Extranet) wünschenswert.
Typischerweise „zeigt“ die GUID auf den am wenigsten schützenswerten Ablageort (Link Typ C). Dieser Einstiegspunkt kann dann, je nach Authentifizierung und Software, zu weiteren schützenswerteren Ablageorten verbinden. Damit kann erreicht werden, dass unterschiedliche Anwendungsfälle auf einfache, zentral zu verwaltende Weise abgedeckt werden können und nicht für jeden Anwendungsfall Berechtigungen erdacht und verwaltet werden.
Damit kann erreicht werden, dass unterschiedliche Anwendungsfälle auf einfache, zentral zu verwaltende Weise abgedeckt werden können und nicht für jeden Anwendungsfall Berechtigungen erdacht und verwaltet werden.
Anwendungsbeispiel als prototypisches Inventar Management System
- Daten werden auf Papier u.Ä. zu einem bestimmten Objekt erfasst (Einzelteil, Baugruppe, Gerät u.ä.). Object2Web kann bei diesem Anwendungsbeispiel analog einem Wartungsbuch eingesetzt werden.
- Objekte werden durch Um- und Einbauten modifiziert. Es treten Probleme bei Reparaturen und beim Recycling des Objektes auf. Das Verfahren bietet Möglichkeiten zentral zusammengehörigen Daten gleichzeitig zu be- und verarbeiten bzw. schlichtweg zu sehen.
- Neu entwickelte Objekte haben die Tendenz, in ihren Abmessungen immer kleiner und damit leichter verloren zu werden, Unachtsamkeit führt aber auch bei größeren Objekten zu Verlusten. Ebenso kann aufgrund ihrer Werthaltigkeit der Beisitzer durch verbotene Eigenmacht / Diebstahl gewechselt werden. Die Gefahr, diese Objekte nach einem Verlust nicht mehr zu erhalten steigt mit der Werthaltigkeit. Das Verfahren stellt sicher, wird das Objekt sichergestellt/gefunden, kann das Objekt direkt einem eineindeutigen Eigentümer und/oder Besitzer zugeordnet werden. In Verbindung mit einem Fotoarchiv sind zudem weitere Identifizierungsmöglichkeiten gegeben.
- Weiterhin können cyberphysikalische Systeme die automemoriae Funktionen zur Verfü-gung stellen, das Verfahren nutzen um die gespeicherten Informationen für authentifizierte Benutzer auf einfache Art zentral anzuzeigen. Diese Systeme erhalten dazu bereits eine Bundeswehr Inventarnummer und würden dann eine Object2Web GUID erhalten und damit gleichartig zu den analogen Objekten behandelt werden.
Um dies zur realisieren würden die digitalen Logbücher aus diesen Systemen über digitale Schnittstellen als Datenquelle analog der WWS, implementiert werden und diese Informationen auf der Webseite des Objektes mit angezeigt werden. Vgl. Abbildung 10 -> hier würde dann zusätzlich die digitalen Logbücher angezeigt werden. - Bei großen Objekten kann es Sinn machen, die exakten Einzelobjektdaten zu kennen. Dies kann z.B. bei Unfällen helfen, schnell die Arbeit der Unfallermittler zu unterstützen. Um dies zu realisieren, müssen selbstklebende Object2Web-Codes Bänder, die günstig in der Herstellung sind, bei der Herstellung des Objektes an den entsprechenden Stellen angebracht werden. br Weiterhin kann diese Art der Implementation ein effektives Recycling von Bauteilen unterschiedlichster Materialzusammensetzung ermöglichen. Dies kann funktionieren, wenn der Hersteller das System vorbereitet und der Wiederverwerter mit entsprechenden Lesesystemen ausgestattet ist.
- Mit der Implementation des Verfahrens wird es möglich, eine digitale transparente Dokumentation von
- Personen nach BGI/GUV-I 5166 u.Ä.
- Objekten nach DIN EN 15635 u.Ä.
moXimo Lebenszyklus
Object2Web basiert unter anderem auf der Annahme, dass die zeitliche Entwicklung eines Objekt in charakteristische Phasen unterteilt werden kann und einem glockenförmigen Verlauf folgt, d.h. es wird von einer begrenzten Existenz des Objekts ausgegangen.Das Produktlebenszykluskonzept (vgl. Gabler) der Wirkungsforschung betrachtet das Produktleben im Sinn einer Produktbiografie und differenziert dieses in verschiedene Phasen, wobei jedoch keine konsistente Aufteilung und Bezeichnung der einzelnen Phasen existiert.
Betrachtung des Lebenszyklus in einer Zustandsmatrix
Die moXimo Lebenszyklus Zustandsmatrix definiert in seiner Grundform für Objekte vier Phasen.Entwicklung: In der Phase der Entwicklung wird das Objekt entsprechend der Anforderungen konstruiert und gestaltet. Ziel der Entwicklung ist ein marktreifes Objekt zu kreieren.
Herstellung: In der Phase der Herstellung wird das Objekt in Einzel- oder Serienfertigung unter gegeben Qualitätsansprüchen erstellt. Ziel ist einem Abnehmer ein, seinen Ansprüchen und Anforderungen, entsprechendes Objekt zu liefern.
Betrieb: Während der Phase des Betriebs, in den meisten Fällen, die längste Phase, wird das Objekt gemäß seiner Zwecks eingesetzt, um den entsprechenden Nutzen zu stiften.
Recycling: Am Ende des Lebenszyklus steht das Recycling. Jedes physische Objekt wird in organisierter oder unorganisierter Form in den Rohstoffkreislauf zurückgeführt
Zustandsänderung
Den vier Grundphasen zugeordnet stehen einige Zustandsänderungen. Diese Zustände ergeben sich aus dem Effekt, dass nicht jedes Objekt dazu bestimmt ist, selbstständig Nutzen zu stiften.Standard Produkt 1 wird entwickelt, hergestellt, betrieben und recycelt. Das Objekt stiftet direkt, ohne weitere Zustandsänderung Nutzen bis zum Recycling. Dieser Zyklus wird auch bei einem defekten Objekt durchlaufen (Nutzen=0).
Einbau/Umbau während Betrieb Produkt 2 wird entwickelt, hergestellt, betrieben und während des Betriebs in das Produkt 3 überführt (eingebaut). Produkt 3 wird entwickelt, hergestellt, betrieben und während des Betriebs wird das Produkt 2 eingeführt (eingebaut). Am Ende des Lebenszyklus werden Produkt 2 und 3 gemeinsam recycelt.
Einbau/Umbau zur Inbetriebnahme und Einbau/Umbau während Betrieb Produkt 4 wird entwickelt, hergestellt, vor Inbetriebnahme Produkt 5 eingebaut, betrieben und während des Betriebs das Produkt 6 eingeführt (eingebaut) wird. Am Ende des Lebenszyklus werden Produkt 4, 5 und 6 gemeinsam recycelt. Produkt 5 wird entwickelt, hergestellt, vor Inbetriebnahme in Produkt 4 eingebaut. Produkt 6 wird entwickelt, hergestellt, mit Einführung (Einbau) in Produkt 4 in Betrieb genommen.
Umnutzung und Weiterbetrieb Produkt 7 wird entwickelt, hergestellt, betrieben. Während des Betriebs wird Produkt 8 eingeführt (eingebaut). Der Teil (Produkt 7a) der von Produkt 8 ersetzt wird, wird vor Inbetriebnahme in Produkt 9 eingebaut. Am Ende des Lebenszyklus werden Produkt 7 und 8 gemeinsam recycelt. Produkt 8 wird entwickelt, hergestellt, mit Einführung (Einbau) in Produkt 8 in Betrieb genommen. Produkt 9 wird entwickelt, hergestellt, vor Inbetriebnahme Produkt 7a eingeführt (eingebaut). Am Ende des Lebenszyklus werden Produkt 7a und 9 gemeinsam recycelt.