Dieser Beitrag beschreibt das Vorgehen und die Ergebnisse im Forschungsprojekt AnGeWaNt (Arbeit an geeichten Waagen für hybride Wiegeleistungen an Nutzfahrzeugen), das an der Schnittstelle zwischen Forschung, Industrie und öffentlichen Dienstleistungen agiert und dabei konstruktive Ansätze in einer agilen Arbeitsweise entwickelt und umsetzt. Der Beitrag dokumentiert die erfolgreiche Vorgehensweise beispielhaft an den Anwendungsfällen des Digitalen Eichantrags und des Softwareupdate-Antrags, wie eine digitale Transformation papierbasierter Prozesse für den hoheitlichen Bereich geplant und umgesetzt werden kann. Die Plattform für metrologische Dienstleistungen schließt dabei die Lücke zwischen den hybriden Geschäftsmodellen der Privatwirtschaft und der digitalen Transformation der Prozesse in der öffentlichen Verwaltung. Darüber hinaus werden technische Designentscheidungen der entstandenen Plattform und deren Software-Implementation erläutert und besprochen.
6.1 Ausgangssituation
Dies ist eine Zusammenfassung und Erweiterung vorangegangener Publikationen [1‐5], die während der dreijährigen Projektlaufzeit den Projektfortschritt und Wissensstand begleitend dokumentiert haben. Dabei sind Texte und Bilder aus den Publikationen entnommen worden, um in diesem Kontext neu aufgelegt zu werden. Die Primärpublikationen sind dennoch lesenswert und können Teilaspekte besser vertiefen als es diese Zusammenfassung vermag.
Die Aufgabe der Physikalisch-Technischen Bundesanstalt (PTB) in dem Verbundprojekt AnGeWaNt besteht darin, die Prozesse im gesetzlichen Messwesen über einen geeigneten metrologischen Plattformdemonstrator digital zu optimieren. Dieser eröffnet die Möglichkeit, neue technologie- und datengestützte metrologische Dienstleistungen anzubieten. Die Kernaufgabe des gesetzlichen Messwesens besteht darin, Vertrauen in die Korrektheit der Messergebnisse bei allen Teilnehmern herzustellen. Die dazu notwendige institutionalisierte Vertrauensbildung soll über den genannten Plattformdemonstrator bei der PTB als Vertrauensanker erreicht werden, der als zentrale Ansprechstelle (Single-Point-of-Contact) für alle Stakeholder fungiert. Auf diese Weise wird eine digitale metrologische Qualitätsinfrastruktur zur Bereitstellung digitaler und virtualisierter metrologischer Dienstleistungen für das gesetzliche Messwesen etabliert. Für diese Infrastruktur sind Messgerätearchitekturen anzubieten, die den Herstellern Hilfestellungen bei der Ankopplung Ihrer Infrastrukturen und Messgeräte geben (Referenzarchitekturen). Im Einzelnen sind die bestehenden Prozesse zu modellieren, digital zu transformieren und dann prototypisch umzusetzen. Dabei wird die nationale Verbreitung der technischen Normen und Standards über die Arbeitsgemeinschaft Mess- und Eichwesen (AGME) in die Landeseichbehörden ebenso sichergestellt wie die Übertragbarkeit der nationalen Lösungen auf den europäischen Binnenmarkt.
Anzeige
Als Beispiel für die Integration eines hybriden, privatwirtschaftlichen Geschäftsmodells sei hier die Zusammenarbeit mit der Firma. PFREUNDT genannt, welche im Rahmen ihrer Unterstützungsleistungen auch die Eichanträge für ihre eichpflichtigen Geräte anbietet. Hierfür bietet es sich an, eine Schnittstelle zum digitalen Eichantrag der Eichbehörden zur Verfügung zu stellen und den Prozess der Antragstellung zu automatisieren.
6.1.1 Gesetzliches Messwesen
Das gesetzliche Messwesen ist allein in Deutschland für einen Umsatz von ca. 157 Mrd. € bzw. 4 % bis 6 % des Bruttoinlandsprodukts verantwortlich und umfasst 160 Mio. Messgeräte verteilt auf 150 Gerätearten. Die Hauptaufgabe des gesetzlichen Messwesens ist es, das Vertrauen in amtlich oder geschäftlich durchgeführten Messungen zu gewährleisten. Damit leistet das gesetzliche Messwesen einen essenziellen Beitrag für die Produktion qualitativ hochwertiger Messgeräte [6].
Per Gesetz ist eine benannte Stelle, wie z. B. die PTB in Deutschland, dazu verpflichtet, eine Konformitätsbewertung von Messgeräten vorzunehmen (siehe Abb. 6.1). Die grundlegenden Anforderungen der Messgeräterichtlinie (MID) [7], wie Reproduzierbarkeit, Wiederholbarkeit, Dauerhaftigkeit und Schutz vor Verfälschung von Messgeräten und Messungen, müssen vor dem Inverkehrbringen (Baumusterprüfung) erfüllt sein.
Abb. 6.1
Ablauf für das Inverkehrbringen eines Messgerätes in Deutschland
×
Der Hersteller eines Messgerätes erklärt nach erfolgreicher Baumusterprüfung, die Konformität mit den in Europa geltenden gesetzlichen Richtlinien. Dabei stellt dieser eine sogenannte Konformitätserklärung aus, die er jedem Messgerät beizulegen hat. Diese ersetzt die bisherige Ersteichung durch die Eichbehörden.
Anzeige
Die Markt- und Verwendungsüberwachung, z. B. die Eichbehörden in Deutschland, sind dazu verpflichtet, die Messgeräte nach dem Inverkehrbringen auf eventuelle Manipulationen und unbeabsichtigte Fehlbedienung zu überprüfen. Dabei richten sich die Eichbehörden nach der nationalen Umsetzung der Messgeräterichtlinie (Measuring Instrument Directive – MID), dem Mess- und Eichgesetz/-verordnung (vgl. Abb. 6.1). Nach einer zweijährigen Frist muss ein Messgerät nachgeeicht werden, um die Konformität mit den Richtlinien und die Einhaltung der festgelegten Fehlertoleranz zu überprüfen.
Die digitale Transformation hoheitlicher Prozesse ist die treibende Kraft, um die zugrunde liegenden Prozesse zu erneuern, zu optimieren und an diese veränderte Arbeitsumgebung anzupassen. Mit dem neuen Mess- und Eichgesetz [8] wurde 2015 erstmals der gesetzliche Rahmen für netzangebundene Messgeräte geschaffen. Damit wurde die Grundlage für Fernabfragen über beliebige Endgeräte aber auch netzangebundene bzw. aus der Ferne anstoßbare Prozesse ermöglicht.
6.1.2 Digitale Transformation hoheitlicher Aufgaben und Prozesse
Im Projekt AnGeWaNt wird der Begriff Digitale Transformation ganz bewusst verwendet, da damit eine nachhaltige und integrative Lösung angestrebt wird. Im Gegensatz zu Begriffen wie Digitalisierung oder digitalisieren, die ein analoges kontinuierliches Objekt in eine diskrete mathematische Menge abbilden, d. h. Einsen und Nullen. Anschaulich bedeutet dies, dass beispielsweise eine Karte digital abgebildet werden kann, jedoch damit noch kein Mehrwert erzielt worden ist. So ist man eventuell in der Lage, die Karten beliebig zu vergrößern oder zu verkleinern. Darüber hinaus gibt es keine weitergehende Dienstleistung oder keinen weiteren Mehrwert. Erst wenn man an bekannte Plattformen denkt, wie OpenStreet Map oder Google Maps, die eine Routenplanung anbieten und es ermöglichen, naheliegende Dienstleistung leicht aufzufinden, erschließt sich der Begriff der digitalen Transformation und hybride Dienstleistung in voller Gänze.
Bezogen auf das gesetzliche Messwesen bedeutet dies, dass die bisherigen analogen Aufgaben und Prozesse analysiert und die digital abbildbaren Schritte identifiziert werden müssen. Diese digitalen Unterstützungsleistungen können dann als Grundlagen und Konzepte für einen digitalen Mehrwert und hybride Dienstleistungen dienen. Dies reicht von der Verschlankung, d. h. Optimierung administrativer Abläufe von hoheitlichen Prozessen hin zu neuen datenbasierten Dienstleistungen, wie beispielsweise metrologische „digitale Repräsentationen“, die alle Daten über die Laufzeit eines Messgerätes erfassen und zur Verfügung stellen können.
Im Projekt AnGeWaNt sind die wesentlichen metrologischen Prozesse mit einer hohen Signalwirkung identifiziert worden. Dabei wurden entsprechende Vorarbeiten bei den verschiedenen Projektpartnern und den Eichbehörden berücksichtigt und wenn möglich wiederverwendet, sodass eine teure Neuentwicklung vermieden werden kann. Bei der Konzeption und Pilotumsetzung einer Zusammenführung verschiedener Infrastrukturen und Datenbanken ging es in erster Linie darum, die Synergien zu heben und eine eventuelle doppelt und dreifache Datenhaltung mit ihren Nachteilen, wie beispielsweise unvollständige Datensätze, zu vermeiden.
Als Ausgangssituation werden digitale Unterstützungsleistungen für einen digitalen Eichantrag und einen digitalen Softwareupdate-Antrag erarbeitet. Darüber hinaus wird eruiert, ob eine Möglichkeit besteht, diese Prozesse aus der Ferne (Remote) anzustoßen und auszuführen. Dabei werden Ideen und Konzepte entwickelt, wie Prozesse digital transformiert werden können, damit eine Verschlankung, Zusammenführung von Daten und eine zentrale Ansprechstelle etabliert werden kann, um gleichzeitig neue hybride Dienstleistungen der Privatwirtschaft zu unterstützen, beziehungsweise überhaupt zu ermöglichen. Die digitale Transformation unseres Wirtschaftssystems ist auf eine moderne und leistungsfähige öffentliche Verwaltung angewiesen. Diese Transformation mit neuen hybriden Dienstleistungen kann nur gelingen, wenn öffentliche Dienstleistungen sich der neuen technischen Möglichkeiten bedienen und diese kreativ im Rahmen der Gesetzgebung einsetzen.
Folgende Forschungsfragen haben die Ausgangslage dabei geschärft und das Projekt bei der Umsetzung begleitet:
1.
Wie können papiergestützte Prozesse im gesetzlichen Messwesen digital unterstützt und umgestaltet werden?
2.
Welche Prozesse und Prozessschritte können überhaupt digital transformiert werden?
3.
Wie kann ein rechtssicherer Austausch von Daten für alle Beteiligten im gesetzlichen Messwesen gewährleistet werden?
4.
Wie kann ein tragfähiges Konzept für eine administrative Hülle im Rahmen des gesetzlichen Messwesens gestaltet und implementiert werden?
5.
Wie können Datenhoheit, Datensicherheit und Vertrauenswürdigkeit in der digitalen Domäne für alle Beteiligten im gesetzlichen Messwesen gewährleistet werden?
6.1.3 European Metrology Cloud
Das Projekt AnGeWaNt kann als nationales Umsetzungsprojekt der European Metrology Cloud (EMC) betrachtet werden, das sich ausschließlich auf die Waagen als Messgeräteklasse fokussiert. Die EMC hingegen integriert 16 verschiedene Messgeräteklassen im internationalen europäischen Kontext mit europäischen Richtlinien. Eines der Hauptziele ist die Unterstützung und Förderung des einheitlichen digitalen Binnenmarkts, den die Europäische Kommission für ganz Europa anstrebt.
Folgende Ziele des AnGeWaNt-Projekts sind deckungsgleich mit der EMC: Die digitale Transformation des gesetzlichen Messwesens, die Schaffung einer Plattform (Single Point of Contact), die bestehende Infrastrukturen und Datenbanken miteinander verbindet (Vernetzung), sowie die Optimierung metrologischer Dienstleistungen [9]. Die EMC unterscheidet sich bei der konzeptionellen Herangehensweise, die auf die Verteilung von physischen Hardware-Nodes [10] bei den einzelnen Teilnehmern abzielt. Als Hardware-Node bezeichnet man einen physischen Rechner in der Infrastruktur des Teilnehmers. Wohingegen die entwickelte Plattform im AnGeWaNt-Projekt als Platform-as-a-Service (PaaS) fungiert und somit über beliebige PaaS-Anbieter hinweg gehostet, skaliert und verteilt werden kann. Das Konzept der European Metrology Cloud berücksichtigt die Grundsätze der europäischen Datenschutzgrundverordnung (DSGVO) [11].
6.1.4 GAIA-X-Projekt
Das GAIA-X-Projekt wurde 2019 als gemeinsame Initiative von Deutschland und Frankreich mit dem Ziel gestartet, ein souveränes, digitales europäisches Cloud-Ökosystem aufzubauen, das effizient, sicher und hochgradig verteilt ist. Die wichtigsten Merkmale sind Datensouveränität, Datenschutz durch die Einhaltung der Datenschutzgrundverordnung (DSGVO), Transparenz und Offenheit durch die Unterstützung von Open-Source-Prinzipien und Flexibilität durch den Aufbau einer modularen und hochgradig interoperablen Plattform für ein breites Spektrum von Industriepartnern. Dazu gehören kleine und mittlere Unternehmen (KMU) sowie staatliche Stellen [12].
Das geplante Portfolio an Diensten wird ein dynamisches Ökosystem ermöglichen, das alle Wirtschaftssektoren miteinander verbindet und den digitalen Wandel in der Europäischen Union beschleunigt. Das grundlegende Element des GAIA-X-Ökosystems wird der GAIA-X-Knoten sein, der voneinander abhängige Dienste anbieten wird [13].
Es wird ein föderiertes Identitätsmanagement mit (externen) Identitätsdatenanbietern beinhalten, ist aber nicht darauf beschränkt. Das Projekt European Metrology Cloud zielt darauf ab, mit den GAIA-X-Schnittstellen kompatibel zu sein. Das EMC-Projekt strebt eine nahtlose Integration in GAIA-X an, indem es die Vorteile des Identitätsmanagements nutzt und seine Dienste in dem geplanten Cloud-Ökosystem anbietet. Beide Projekte sind europäische Initiativen, die den Aufbau einer digitalen Qualitätsinfrastruktur anstreben [14].
6.2 Vorgehensweise zur Zielerreichung
Dieses Kapitel beschreibt die Vorgehensweise zur Zielerreichung für alle Vorhaben zur digitalen Transformation, die in der öffentlichen Verwaltung angesiedelt sind. Das Projekt AnGeWaNt ist dabei so strukturiert, dass die Arbeitspakete 1, 5 und 6 aufeinander aufbauen. In Abb. 6.2 wird anschaulich der Ablauf über 36 Monate der Arbeitspakete (AP) dargestellt.
Abb. 6.2
Ablauf und Struktur der Arbeitspakete im Projekt AnGeWaNt
×
In AP1 werden die hoheitlichen Prozesse analysiert und deren Abhängigkeiten, Bedarfe aller Teilnehmer und Voraussetzungen für die digitale Transformation aufgenommen. Diese Bestandaufnahme dient als wichtige Grundlage für ein erstes Grobkonzept für digitale Unterstützungsleistungen und wie diese eingesetzt werden können. Dabei sind wichtige Vorüberlegungen und Entwicklungen bezüglich metrologischer Methoden und Prozesse entstanden. Im Vordergrund standen dabei deren „Verschlankung“, also optimierten Abläufen, und Erstellung von Integrationskonzepten mit teilweise existierenden Vorarbeiten.
Die Zielsetzung des Arbeitspakets 5 ist die Konzeption einer digitalen Kooperationsplattform. Wichtige Bausteine sollten dabei die Vernetzung und Integration verschiedener (externer) Infrastrukturen und Datenbanken sein. Bereits zu Beginn des Projekts hat sich gezeigt, dass eine zentrale Plattform als Ansprechstelle für die Beteiligten wünschenswert ist. Jedoch wäre es eine unerfüllbare Aufgabe, wenn man die gewachsenen Infrastrukturen aller Beteiligten (Hersteller, Verwender, benannte Stelle (z. B. PTB), Markt- und Verwendungsüberwachung) im gesetzlichen Messwesen ignorieren würde und stattdessen eine neue Plattform mit neuen Diensten (Services) zu erstellen. An dieser Stelle kommen die Analyseergebnisse des Arbeitspakets 1 zum Tragen und geben einen Überblick auf bestehende und nutzbare Vorarbeiten der verschiedenen Stakeholder im gesetzlichen Messwesen. Außerdem sollten Konzepte und Grundlagen für neuartige datenbasierte Dienstleistungen erarbeitet werden. Zu nennen sind hier ein Konzept zur digitalen Repräsentation der Messgeräte und die zentrale Bereitstellung von Messgerätedaten über den gesamten Lebenszyklus des Messgerätes. Wichtig dabei zu betonen ist, dass das Messgerät Ausgangspunkt der Datenerhebung ist und damit erstmalig im Zentrum aller Dienste steht.
Die prototypische Umsetzung und Optimierung des Gesamtkonzepts hybrider Waagen obliegt dem Arbeitspaket 6. Dabei sollen alle entstandenen Überlegungen, Anforderungen und Konzepte aus den Arbeitspaketen 1 und 5 in die technische Umsetzung einfließen. Das Hauptanliegen hat sich dabei auf zwei hoheitliche Prozesse fokussiert: dem digitalen Eichantrag und dem digitalen Softwareupdateantrag. Alle weiteren notwendigen Komponenten zum Betreiben einer zentralen Softwareplattform sollten dabei zusätzlich entstehen, beispielsweise ein tragfähiges Rechte- und Rollenkonzept, digitale Datenablage und ein Konzept zur Wiederverwendung von Daten.
6.2.1 Anforderungen und Abläufe der hoheitlichen Prozesse
Das gesetzliche Messwesen und die hoheitlichen Prozesse werden im europäischen Kontext von der MID geregelt. In Deutschland wird die MID durch das Mess- und Eichgesetz (MessEG) und die Mess- und Eichverordnung (MessEV) umgesetzt. Dort finden sich auch die Anforderungen und Abläufe des Eichantrags und des Softwareupdateantrages. Abb. 6.3 gibt einen detaillierteren Aufbau der deutschen Vollzugsgrundlage. Dort werden die globalen Anforderungen der OIML (Organisation Internationale de Métrologie Légale) in die europäische Richtlinie und schließlich in nationales Recht umgesetzt werden. Die nationalen Gesetze bilden die Grundlage für Verordnungen und ermächtigen Verwaltungsvorschriften. Dabei kommen anerkannte Regeln der Technik, bspw. die PTB-Anforderungen, sowie Normen zum Einsatz.
Abb. 6.3
Rechtliche Vollzugsgrundlagen für das gesetzliche Messwesen
×
6.2.1.1 Allgemeine Anforderungen
Bei der Anforderungsanalyse der hoheitlichen Prozesse haben sich folgende allgemeine Anforderungen an zwei Use-Cases herauskristallisiert. Es gibt Prozesse, bei denen es ausreicht, ein Ergebnis, beispielsweise ein Maschinenlesbares XML wie die digitale Konformitätserklärung, über die Plattform verfügbar zu machen. Das heißt, es sollte eine einfache Möglichkeit zum Up- bzw. Download zur Verfügung stehen. Dieser erste Use-Case ist zwar zunächst isoliert und limitiert in der Prozessinteraktion, bietet aber die Grundlage für weitere Use-Cases und prozessübergreifende Verwendung der digital bereitgestellten Konformitätserklärungen. Generelle Anforderungen für dokumentgestützte Prozesse in der digitalen Transformation sind:
einfache Up-/Download-Möglichkeit von Dateien
Wiederverwendbarkeit der Daten
Validierung
Signierung
Zugriffsschutz
Maschinenlesbares Datenaustauschformat
Archivierung
Menschenlesbares Format
Der zweite, interaktivere Use-Case betrachtet digitale Antragstellungen, wie zum Beispiel den digitalen Eichantrag, den digitalen Softwareupdateantrag oder auch den digitalen Kalibrierauftrag. Hierbei werden existierende (externe) Infrastrukturen über eine einheitliche REST (REpresentational State Transfer)-Schnittstelle vernetzt und angesprochen. Dabei kommen die generellen Anforderungen aus dem ersten Use-Case zum Tragen und werden durch weitere, spezifische Anforderungen ergänzt:
Vernetzung mit externen Infrastrukturen
einheitliche Schnittstellen
formalisierter Prozessablauf
Vermeidung von Medienbrüchen
beschleunigtes Verfahren
transparente Prozesskette
Nutzung vorhandener Ressourcen (z. B. …)
intuitive Nutzung der Prozesse
Sichtbarkeit von Status und Ergebnis des Prozesses für den Benutzer
6.2.1.2 Digitaler Eichantrag
Durch die Neuordnung im gesetzlichen Messwesen im Jahr 2014 wurde die in Deutschland übliche Ersteichung bei Inverkehrbringen neuer Messgeräte durch eine Konformitätserklärung des Herstellers ersetzt. Diese Erklärung ist zwei Jahre lang gültig. Möchte der Verwender des Messgerätes das Gerät darüber hinaus benutzen, wird eine Nacheichung nötig. Diese kann beim zuständigen Eichamt beantragt werden. Genau hier setzt der digitale Eichantrag an. Die Eichbehörden haben dazu die digitale Infrastruktur „Digitaler Eichantrag Melden Online“ (DEMOL) geschaffen. Diese Webanwendung soll die Vereinheitlichung der Antragsstellung in Deutschland gewährleisten [15].
In [16] ist der vollständige Ablauf einer Eichung und deren Querverbindungen zu den beteiligten Akteuren im gesetzlichen Messwesen abgebildet. Es gibt dort drei Bahnen. Die oberste Bahn bildet die Rolle und Verantwortlichkeit des Herstellers ab. Darunter befindet sich der Verwender, der den Prozess des Eichantrags startet. Als unterste Bahn ist die Eichbehörde oder anerkannte Prüfstelle (nach § 21 Abs. 1 MessEV [17]) abgebildet. Die Erstellung dieses Flussdiagramms ermöglicht es, sehr einfach abzulesen, an welchen Stellen es möglich ist, den formalen Ablauf technisch zu unterstützen bzw. falls es notwendig sein sollte, den Ablauf zu ändern, damit dieser optimiert werden kann. Im Falle des Eichantrags sind technische Unterstützungsleistungen in mindestens drei Punkten zurzeit umsetzbar:
1.
Antragstellung und Übermittlung
2.
Ort und Eichtermin ermitteln
3.
Rechnungserstellung und –begleichung
Aufgrund der Vorarbeiten der Eichbehörden und deren technische Umsetzung Digitaler Eichantrag Melden Online (DEMOL) mussten von Projektseite keine weiteren Anforderungen an den formalen Ablauf erhoben werden. Es war sicherzustellen, dass die Fachanwendung in eine zukünftige zentrale Plattform für metrologische Dienstleistungen nahtlos eingebunden werden kann.
Im Rahmen des Forschungsprojektes AnGeWaNt wurde der metrologische Prozess analysiert und mithilfe von Ablaufdiagrammen dokumentiert (vgl. Abb. 6.5). Darauf aufbauend wurde eine REST-Schnittstelle implementiert, damit die Anbindung der externen DEMOL-Infrastruktur an die AnGeWaNt-Plattform (siehe Abschn. 6.3.5.3) gewährleistet werden kann. Dadurch wird für die Beteiligten im gesetzlichen Messwesen (Hersteller, Verwender, und Eichbehörden) eine harmonisierte Schnittstelle und ein einfacher Zugang zu digitalen Dienstleistungen geschaffen.
6.2.1.3 Softwareupdate-Antrag
Im gesetzlichen Messwesen wird bei der Software eines Messgerätes zwischen dem rechtlich relevanten und dem rechtlich nicht relevanten Teil unterschieden. Dabei umfasst der rechtlich relevante Teil alle Funktionen und Bereiche, die das direkte oder indirekte Beeinflussen des Messvorganges ermöglichen (§ 37(6) MessEG) [15].
Möchte der Verwender des Messgerätes ein Software-Update im rechtlich relevanten Teil vornehmen, so muss er dies bei der zuständigen Eichbehörde beantragen. Dabei gibt es für kritische Sicherheitslücken einen Eilantrag nach § 40(4) MessEV (siehe [18]) für alle übrigen Fälle gibt es das Standardverfahren nach § 40(3) MessEV.
Der Software-Updateantrag [19] ist ein sehr komplexer metrologischer Prozess (siehe Abschn. 6.3.4.4), der alle Beteiligten des gesetzlichen Messwesens (Hersteller, Verwender, benannte Stelle (PTB) und Eichbehörden) einschließt. Dies ist ideal für die prototypische digitale Transformierung, da viele Probleme und Herausforderungen in anderen metrologischen Prozessen teilweise erneut auftreten. Im Gegensatz zum digitalen Eichantrag kann auf keine Vorarbeit in diesem Bereich zurückgegriffen werden, sodass die technischen Unterstützungsleistungen komplett neu entwickelt werden müssen. Hier wird besonders darauf geachtet, dass die einzelnen Softwaremodule, wie z. B. bei der Antragsstellung, für andere metrologische Prozesse wiederverwendet werden können.
6.2.1.4 Anforderungen an eine verteilte Softwarearchitektur im gesetzlichen Messwesen
Im Rahmen des Projektes wird eine verteilte Softwarearchitektur entwickelt, die Rücksicht auf die Regularien und Anforderungen im gesetzlichen Messwesen nimmt ([7, 8, 17, 20 – 23]). Dabei fließen zusätzliche Erkenntnisse einer, an der PTB entwickelten, Cloud-Referenzarchitektur [24] mit ein. Außerdem sollen die bereits vorhandenen IT-Infrastrukturen der Hersteller und Verwender von Messgeräten sowie der Eichbehörden berücksichtigt und über standardisierte Schnittstellen nahtlos in die entworfene Softwarearchitektur eingebunden werden. Dabei wird Wert daraufgelegt, dass sich die Austauschformate auf standardisierte Dateiformate wie JSON oder XML abbilden lassen. Die Softwarearchitektur begreift sich selbst als ein Service-Hub, da sowohl hoheitliche Dienste angeboten werden als auch Dienste von Dritten eingebunden werden können und mithilfe der zuvor standardisierten Schnittstellen weitere innovative Workflows in Zukunft integriert werden sollen.
Bei der Abbildung der hoheitlichen Prozesse wird bereits bei der Entwicklung dasselbe Niveau an Sicherheit berücksichtigt, wie für die bisherigen papierbasierten Prozesse, um das Vertrauen in das gesetzliche Messwesen zu erhalten. Dabei ist bei der Digitalisierung metrologischer Prozesse besonders darauf zu achten, dass durch technische Unterstützungsleistungen der Arbeitsfluss gefördert und nicht mit Anforderungen (an den Nutzer?) überfrachtet wird. Ferner sollen die Sachbearbeiter durch die technischen Unterstützungsleistungen motiviert werden, bspw. durch eine bedarfsgerecht gestaltete Oberfläche, die sich leicht und intuitiv bedienen lässt, sodass sie im besten Fall die Produktivität steigert und mögliche Vorbehalte gegenüber technischen Unterstützungssystemen abgebaut werden.
Die AnGeWaNt-Plattform ist als verteilte Softwarearchitektur aufgebaut, die im Bereich des Cloud Computing als Platform as a Service (PaaS) angesiedelt ist. Die Plattform lässt sich als zentraler Service-Hub verstehen (siehe Abb. 6.4): Die Plattform selbst ist Mittler und zentrale Steuerung (grün, Mitte), welche alle relevanten Services anspricht. Diese umfassen den digitalen Eichantrag, den digitalen Softwareupdateantrag als hoheitliche digitalisierter Prozess, das digitale Kalibrierzertifikat, den Kalibrierauftrag und die Konformitätserklärung als weitere digitalisierte Prozesse, sowie die Gerätepässe, die Stammdaten und das Dokumentarchiv als prozessübergreifende Module, aus deren Daten die genannten Prozesse bedient werden.
Abb. 6.4
Metrologische Dienstleistungsplattform mit verfügbaren Dienstleistungen
×
6.2.1.5 Administrative Hülle
Ein Eckpfeiler der digitalen Transformation wird die „administrative Hülle“ darstellen. Dieses Konzept wird schrittweise entwickelt und erweitert, und umfasst zunächst die Geräte-Stammdaten und die Gerätepässe. Aus diesen heraus kann ein digitales Typenschild mit den eichrechtlich relevanten Informationen für das Gerät erzeugt werden, bspw. einschließlich der CE-Typgenehmigungsnummer und der Genauigkeitsklasse (bei Waagen) (vgl. Abb. 6.5). Das Ergebnis der administrativen Hülle wird ein rechts- und revisionssicherer Dokumentenspeicher sein, welcher alle Dokumente und Daten hinsichtlich des gesamten Lebenszyklus des Messgerätes enthält (siehe Abb. 6.6). Das Konzept der gesamten Plattform ist für Mehrmandantenfähigkeit ausgelegt, d. h. Benutzer sind mindestens einem Mandanten zugeordnet. Ein Mandant ist eine fachliche Gruppe, welche ihre eigenen Daten und Prozesse sehen darf, die anderer Mandanten jedoch nicht. Das Dokumentarchiv wird mit einer dokumentenbasierten Rechteverwaltung implementiert. Sie hat Ähnlichkeiten mit der UNIX-Dateizugriffsrechteverwaltung, sodass das Lesen, Schreiben und Freigeben für jedes Dokument unterschiedlich verwaltet werden kann und nicht nur von der Rolle eines Benutzers abhängt. Ferner wurden fünf verschiedene Arten relevanter Daten klassifiziert:
administrative Daten
Telekommunikationsdaten
metrologische Daten
spezifische Daten der unterschiedlichen Messgeräte
Messdaten (z. B. Masse, Volumen, …)
Jede dieser Arten von Daten ist in verschiedenen Richtlinien verankert und kann mehrere unterschiedliche Eigentumsverhältnisse haben, die auch eine zeitliche Dimension haben können. Die zeitliche Dimension ist für die Nachverfolgbarkeit von Änderungen sowie für die vorgeschriebene Vorhaltedauer (Archivarpflichten) relevant.
Abb. 6.5
Administrative Hülle als evolutionäres Konzept vom Gerätepass hin zum Dokumentarchiv
×
Es ist wichtig zu beachten, dass der Eigentümer der Daten berechtigt sein kann, die Zugriffsrechte zu verwalten, aber befugte Dritte sind gesetzlich berechtigt, bestimmte Informationen zu lesen, die ihnen jedoch nicht gehören, also auch nicht ändern oder weitergeben. Dies sind nur einige von vielen Besonderheiten, die bei der Gestaltung der administrative Hülle (auch digitale Verwaltungsschale genannt) zu beachten sind. Ein weiteres wichtiges Merkmal ist die Sicherstellung der Rückverfolgbarkeit, um die rechtlichen Anforderungen einzuhalten. So können vorhandene Daten nicht gelöscht werden. Falls die Daten geändert werden, müssen sie automatisch versioniert werden. Diese vorgesehene feinkörnige Verwaltung der Zugriffsrechte wird es allen Beteiligten ermöglichen, den Informationsfluss über die üblichen Grenzen hinweg zu unterstützen, ohne die Kontrolle und Sicherheit aufzugeben.
Abb. 6.6
Feinkonzept der Administrative Hülle
×
Die „Industrie 4.0 Plattform“ veröffentlichte kürzlich ein Konzept des digitalen Zwillings und der digitalen Verwaltungsschale [25]. Darüber hinaus hat die Plattform das Tool „AASX Explorer“ herausgegeben, um Verwaltungsschalen für verschiedene Anwendungsfälle zu erstellen. Im Rahmen von AnGeWaNt wird dieses Tool als Impulsgeber betrachtet, um eine digitale Verwaltungsschale zu implementieren, die mit dem Standard des „Plattform Industrie 4.0“-Konsortiums und des „Industrial Internet Consortium“ (IIC) kompatibel ist. Gleichzeitig werden die speziellen Anforderungen des gesetzlichen Messwesens erfüllt. Ziel ist es, eine standardisierte Datenstruktur für gesetzlich regulierte Messgeräte zu erhalten.
6.2.1.6 Gerätepässe
Gerätepässe sind die digitale Darstellung der physischen Typenschilder sowie zusätzlicher Informationen, die möglicherweise nicht auf ein physisches Typenschild passen. Die Verwaltungsschale (siehe Abschn. 6.2.1.5) eines Messgerätes verwendet den Gerätepass als gerätespezifische Informationsquelle (siehe Abb. 6.7). Einer der teilnehmenden Hersteller betreibt eine eigene Datenbank mit Gerätepässen. Die AnGeWaNt-Plattform kann Gerätepässe als JSON-strukturierte Daten unter Angabe eines herstellerspezifischen Geräteschlüssels abrufen. Der Dienst leitet derzeit die Informationen an das Web-Frontend weiter, das eine herunterladbare, sichere PDF-Datei erzeugt. In Zukunft wird dieser Dienst erweitert, um eine Verbindung zu anderen Herstellerdatenbanken zu verbinden und auch Gerätepässe aus dem Stammdaten-Service zu erzeugen.
Abb. 6.7
Konzept der graduellen Weiterentwicklung der Verwaltungsschale
×
6.2.1.7 Digitaler Kalibrierauftrag
Digitale Kalibrierzertifikate werden als standardisiertes XML-Format definiert. An der PTB gibt es das DCC (Digital Calibration Certificate) [26], dessen XSD (XML Schema Definition) für die Validierung hochgeladener Kalibrierzertifikate verwendet wird. Erst nach erfolgreicher Validierung gegen dieses Schema wird ein Kalibrierzertifikat in das Dokumentarchiv hochgeladen.
In der PTB-Arbeitsgruppe 7.54 wurde ein System zur Planung und Steuerung von Vakuum-Messgeräten entwickelt, welches Kalibrierzertifikate erzeugt, die dem oben genannten DCC entsprechen. Aus der AnGeWaNt-Plattform heraus kann man anhand der im Stammdaten-Service vorhandenen Gerätedaten Kalibrieraufträge für solche Geräte erstellen (siehe Abschn. 6.3.4.5) und an das System der AG 7.54 übermitteln. Die Statusrückmeldungen dieser Vorgänge sowie die dort erstellten Kalibrierzertifikate können automatisiert heruntergeladen und als Dokumente zu den jeweiligen Geräten archiviert werden.
6.2.1.8 Digitale Konformitätserklärung
Der Hauptzweck der EU-Konformitätserklärung im Sinne [27] besteht darin, zu dokumentieren, welche Rechtsvorschriften für ein bestimmtes Produkt gelten und die Erfüllung dieser Rechtsvorschriften. Die Konformitätserklärung muss vom Hersteller ausgestellt und unterzeichnet werden. Diese muss 10 Jahre ab dem Inverkehrbringen des Produkts archiviert werden. Obwohl dies formal nicht vorgeschrieben ist, ist es üblich, die Konformitätserklärung dem Endanwender zusammen mit dem betreffenden Produkt in der Regel in gedruckter Form zu übergeben. Die Konformitätserklärung enthält grundlegende Informationen über das Gerät. Die digitale Konformitätserklärung (Declaration of Conformity, DoC) ist ein gutes Beispiel für die digitale Transformation, da sie den Startpunkt des Lebenszyklus des Geräts kennzeichnet und grundlegende Informationen enthält. Die Anforderungen an einen DoC sind im „New Legislative Framework“ der Europäischen Union festgelegt. Für den behandelten Anwendungsfall einer nichtselbsttätigen Waage sind die Anforderungen in Artikel 14 der EU-Richtlinie 2014/31/EU („NAWID“) [28] spezifiziert.
Während des Lebenszyklus eines Messgeräts müssen die messtechnisch relevanten Informationen zwischen den beteiligten Partnern im gesetzlichen Messwesen ausgetauscht werden. Im häufigsten Fall sind relevante Daten in mindestens vier verschiedenen Datenbanken vorhanden, die sich auf die vier Phasen des Lebenszyklus beziehen:
die Datenbank des Geräteherstellers
die Datenbank der zugelassenen/zertifizierten Geräte bei der jeweiligen Behörde oder benannten Stelle
die Datenbank der Eich- und/oder Marktüberwachungsbehörden und schließlich
die Gerätedatenbank des Anwenders
In der derzeitigen Praxis werden die Daten ganz oder teilweise manuell von einer Datenbank in eine andere übertragen. Dies ist ein zeitaufwendiger und fehleranfälliger Prozess. Als wichtiger Schritt in Richtung Industrie 4.0 wird eine digitale Konformitätserklärung (DoC) diesen Prozess automatisieren und optimieren.
6.2.1.9 Digitales Archiv
Das digitale Archiv realisiert die revisions- und rechtssichere Speicherung elektronischer Dokumente. Dies beinhaltet die automatische Versionierung und die Möglichkeit der Hashwertbildung der aktuellen Version eines im Archiv gespeicherten Dokuments.
Der, innerhalb der AnGeWaNt-Plattform zu erstellende, Service soll bei Entgegennahme eines Dokuments prüfen, ob es sich um eine neue Version eines bestehenden Dokuments handelt. In diesem Fall wird die Versionsnummer um 1 erhöht und die neue Version gespeichert. Dabei wird eine Referenz zur Vorgängerversion an die aktuelle Version gehängt, sodass frühere Dokumentversionen nicht verloren gehen.
Um gespeicherte Dokumente vor Manipulation zu schützen, kann die verwendende Fachanwendung oder der verwendende Service einen Hashwert über die gegenwärtige Version des Dokuments anfordern und diesen lokal bei sich speichern. Beim Abruf des Dokuments kann erneut der Hashwert abgerufen und mit dem bereits gespeicherten verglichen werden. Bei Abweichung ist das abgerufene Dokument korrumpiert. So werden Dokument und Validierung getrennt aufbewahrt, Dokumente vor Manipulation geschützt und das Vertrauen der Nutzer in die elektronische Archivierung erhöht.
Perspektivisch soll die E-Akte als Dokumentenspeicher angebunden werden, um hier die Interoperabilität mit internen Aktenvorgängen einerseits zu ermöglichen und die Sicherheit der Dokumentenablage weiter zu erhöhen. Hierfür werden bei der Umsetzung der Dokumentenarchiv-Services in AnGeWaNt softwareseitig bereits Vorarbeiten geleistet, um diese Anbindung zu ermöglichen.
6.2.1.10 Stammdatenverwaltung
Der Stammdaten-Service verwaltet alle Daten von Herstellern, benannten Stellen, Behörden, Anwendern, Messgeräten und Gerätetypen, die in den Prozessen und Dokumenten verwendet werden können. Dieser Service trägt wesentlich zur Erleichterung der Datenaggregation bei. Dabei kann der Service unter anderem das intelligente Vorausfüllen von Formularen erleichtern. Die API (Application Programming Interface, Anwendungsprogrammierschnittstelle) für den Zugriff auf gemeinsame Stammdaten werden gemäß standardisierter Programmierrichtlinien entwickelt und über alle Datentypen hinweg harmonisiert.
In den Stammdaten vorhandene Entitäten sind:
Gerät
Geräte-Typ
Hersteller
Antragsteller
Landeseichbehörde
Person
Anschrift
Jedes Gerät ist n:1 einem Geräte-Typ zugeordnet. Jeder Geräte-Typ ist n:1 einem Hersteller zugeordnet. Jeder Hersteller, Antragsteller und jede Landeseichbehörde enthalten Personen und Anschriften. Ein Gerät kann als Standort eine Anschrift enthalten.
Für Anschriften gilt, dass sie mehrfach vorkommen können, auch wenn dies zunächst einmal der 3. Normalform im ER-Modell (Entity-Relationship-Modell) widerspricht. Es müssen Anschriften getrennt voneinander gespeichert werden, da beispielsweise ein Gerät am selben Standort stehen kann, welcher zunächst der Adresse des Antragstellers entspricht, jedoch das Gerät einen eigenen Standort besitzt und verlegt werden kann. Abb. 6.8 zeigt das Datenmodell in vereinfachter Form. Es sind nicht alle Tabellenspalten angegeben, um die grundlegenden Ideen des ER-Modells zu verdeutlichen.
Abb. 6.8
Vereinfachtes ER-Modell der Stammdaten
×
6.2.1.11 Anforderungen an einheitliche Schnittstellen
Jeder Dienst (Service) ist so entworfen und entwickelt worden, dass dieser unabhängig agiert und über standardisierte REST-Schnittstellen mit den übrigen Diensten kommunizieren kann. Durch diese lose Kopplung der Dienste wird eine hohe Flexibilität und Skalierbarkeit erreicht. Alle Dienste werden über ein gemeinsames Web-Frontend angebunden und dem Nutzer zur Verfügung gestellt. Dabei ist es unerheblich für den Nutzer, ob dieser Dienst sich intern (innerhalb der AnGeWaNt-Plattform) oder extern (außerhalb der AnGeWaNt-Plattform) befindet. Die Benutzeroberfläche bleibt konsistent.
Die gesamte Plattform setzt auf ein einheitliches Austauschformat JSON und bestimmte Schnittstellen unterstützen XML falls die Fachlichkeit des Service es erfordert. Die Fehlerbehandlung, bspw. mehrfache Absendung von gleichen „Requests“ (Anfragen?) sind ebenfalls Teil der Anforderungen der Schnittstellenbeschreibung.
Um die hohe Verfügbarkeit und Flexibilität als PaaS zu gewährleisten, wurde ein OpenID-basierter IAM-Server konfiguriert, der es ermöglicht, die jeweiligen Dienste über verschiedene Domänen zu verteilen und dabei die Sicherheit und Benutzerrechte zu gewährleisten. Dazu werden Zugriffstoken verwendet, um die Berechtigung des anfragenden Nutzers zu überprüfen und erteilen zu können. Diese werden bei jeder Anfrage an den jeweiligen Dienst übermittelt und ausgewertet. Die Tokens können auch für Zugriffe an externe Dienste geschickt werden, um dort die Berechtigung auf bestimmte Ressourcen freizugeben.
6.2.1.12 Anforderungen an ein Rechte und Rollenkonzept
Das Projekt zielt darauf ab, die Benutzer- und Geräteanmeldeinformationen sowie die Rechte- und Rollenverwaltung von der AnGeWaNt-Plattform zu trennen. Erstens kann die eingesetzte IAM-Lösung in anderen Projekten und Diensten wie der EMC wiederverwendet werden. Zweitens sind alle benutzerbezogenen Daten von jeder spezifischen Anwendung entkoppelt, was die Sicherheit der Plattform erhöht. Dadurch werden unter anderem die Sicherheitsanforderungen „Software Separation Requirement (S. 3)“, die im WELMEC 7.2 Software Guide [22] beschrieben sind, erfüllt.
Ein weiteres Entwurfsparadigma besteht darin, Sitzungen (Sessions) zu vermeiden, da sie nicht in einer hochgradig verteilten Architektur über potenziell unterschiedliche Domänen hinweg aufrechterhalten werden können. Stattdessen werden Tokens generiert und entweder einem Benutzer oder einem Gerät zugewiesen, die sich selbst oder einen Dienst authentifizieren.
Alle Authentifizierungs- und Rechteinformationen eines Benutzers oder eines Geräts sind im Token kodiert. Es ist ein JSON Web Token (JWT) und wird nach erfolgreicher Anmeldung durch den Identity Access Management (IAM) Server erzeugt. Diese bietet Single Sign-On (SSO) für alle autorisierten Anwendungen und Dienste innerhalb der AnGeWaNt-Plattform.
Eine IAM-Lösung für die AnGeWaNt-Plattform muss die folgenden Kriterien erfüllen:
Benutzer und Rollen müssen innerhalb von AnGeWaNt isoliert, jedoch über die gesamte Plattform differenziert und zentral verwaltet werden können.
Ein einzelner Benutzer soll sich nur einmal anmelden und damit Zugriff auf die ihm, mittels Rollen, zugeteilten Funktionen im Frontend und in den Backend-Services erhalten.
Aufgrund der stark entkoppelten, dezentralen Architektur der Plattform wird auf benutzerbasierte Sitzungen (Sessions) gänzlich verzichtet.
Es wird pro Benutzeranmeldung ein Token ausgestellt, welches weiterführende Informationen zum Benutzer, wie Rollen und die Gültigkeitsdauer des Tokens in verschlüsselter Form enthalten. So kann jede Anfrage an einen Backend-Service und jeder Bearbeitungsschritt in den jeweiligen Prozessen auf den auslösenden Benutzer zurückgeführt werden.
Die eingesetzte IAM-Lösung sollte zudem die folgenden Kriterien erfüllen:
Außer Benutzern sollten zukünftig auch Messgeräte und externe Services durch das IAM-System an der Plattform authentifiziert und autorisiert werden.
Die gewählte IAM-Lösung sollte Legacy-Systeme wie LDAP unterstützen, um die Integration bestehender Benutzerverzeichnisse und deren Berechtigungen sowie Rollen zu vereinfachen. D. h. bestehende Benutzer können, bspw. durch ihre Windows-Kennung, automatischen Zugriff auf die AnGeWaNt-Plattform erhalten.
Entwickler können sich durch den Einsatz einer standardkonformen OpenID-Connect IAM-Lösung auf die fachlichen Anforderungen und deren Implementation fokussieren, da keine IAM-Mechanismen mehr entwickelt werden müssen. Dies vereinfacht auch die Wartbarkeit der Plattform und ermöglicht ein vergleichsweise einfaches Austauschen der eingesetzten IAM-Lösung.
Es sollen weitere Identitätsserver fremder Organisationen autorisiert werden können (Federated ID), sodass deren Nutzer mit ihrer Organisations-ID sich direkt bei der Angewant-Plattform anmelden und deren Dienste nutzen können.
6.2.1.13 Metrologischer Administrator
Der metrologische Administrator kümmert sich um die Verwaltung der Prozessdaten, während die administrative Hülle (Abb. 6.5) den Zugriff auf gerätespezifische Informationen koordiniert. Der metrologische Administrator hat die Rechte für folgende Aufgaben.
Aufgaben:
Verwaltung metrologischer Prozesse wie z. B. Software-Update-Prozess
Bereitstellung von Vorlagen für Zugriffsrechte für Benutzer
Vorlagen für Zugriffsrechte auf Datenfelder
Vorlagen für neue digitale Zertifikate
Prozessüberwachung der E-Akte.
Der metrologische Administrator verkörpert die Rolle eines Prozessmanagers. Die Rolle gewährt ausschließlich Kontrolle über den Informationsfluss in den messtechnischen Prozessen sowie der prozessübergreifenden Kommunikation. Aufgrund von Sicherheitsbedenken hat die Rolle keinen direkten Zugriff auf die erzeugten Daten in der Verwaltungsschale.
6.3 Ergebnisse
Dieses Kapitel gibt Auskunft über die Implementierung der Softwareplattform als Ganzes und ihrer einzelnen Dienste. Dabei wird auf die Probleme und eingeschlagenen Lösungswege bei der praktischen Umsetzung eingegangen.
Jeder Dienst ist als ein eigener Anwendungscontainer implementiert, der die Modularisierung der Plattform und deren Dienste ermöglicht. Diese Vorgehensweise ermöglicht eine separate und unabhängige Bereitstellung der einzelnen Dienste sowie deren Wartung und Betrieb.
Ein weiterer Aspekt ist die Möglichkeit, die Plattform und jeden einzelnen Dienst an spezifische Konfigurationen anpassen zu können. Im Gegensatz zu einer monolithischen Architektur kann jeder Dienst unabhängig aktualisiert werden, ohne dass die gesamte Plattform offline genommen werden muss, um sie anschließend aktualisieren zu können. Bei der Implementierung wurden etablierte Praktiken von R. Martin [29] der modernen und verteilten Softwareentwicklung angewandt, beispielsweise „Separation of Concerns“ (Trennung von Zuständigkeiten). Diese haben die Wartbarkeit und die Erweiterbarkeit der Plattform immens gesteigert sowie verbessert. Die Implementierung erfolgt in Java. Es ist die gängigste und am häufigsten verwendete Programmiersprache für die Entwicklung von Client–Server-Geschäftsanwendungen. Insbesondere die verbreiteten und professionellen Anwendungs-Frameworks für Geschäftsanwendungen sind in dieser Sprache vorhanden.
6.3.1 Anwendungs-Framework
Spring Boot wird als zugrunde liegendes Anwendungs-Framework verwendet. Es bietet vorkonfigurierte und verwaltete Abhängigkeiten zur Vereinfachung der Build-Konfigurationen. Der erforderliche Code, um einen Anwendungscontainer aufzusetzen und zum Laufen zu bringen, ist bereits vorhanden. Das Framework ist leichtgewichtig und minimiert den Konfigurationsaufwand für die Entwicklung von Diensten. Spring Boot ist eines der am weit verbreitetsten Anwendungs-Frameworks weltweit, ist quelloffen (Open Source) und wird von einer globalen Entwicklergemeinde weiterentwickelt. Es ist der Quasi-Standard für verteilte und in Java geschriebene Anwendungen.
6.3.2 Datenabstraktionsschicht
Die zugrunde liegende Datenstruktur wird von Hibernate unter Verwendung von Jakarta Persistence API (JPA) realisiert. Der Datenzugriff erfolgt über JPA-Repositories. Sie bieten standardmäßig die CRUD-Operationen (Create, Read, Update, Delete) an und können als Interfaces über die Methodennamen um spezialisierte Abfragen erweitert werden. Sofern dies nicht ausreicht, kann auch mittels @Query-Annotation die Abfrage mittels spezieller, SQL-basierter, Hibernate-eigener Abfragesprache HQL (Hibernate Query Language) hereingereicht werden. Vorteilhaft für alle Dienste, die auf Persistenz-Funktionen angewiesen sind, ist die Unabhängigkeit von relationalen Datenbankmanagementsystemen. Weiterhin können Änderungen an der Datenstruktur vorgenommen und automatisch verarbeitet werden, ohne die Datenbank jedes Mal neu initialisieren zu müssen.
6.3.3 Benutzerfreundlichkeit der grafischen Benutzeroberfläche
Im AnGeWaNt-Projekt wurde ein Anwender-zentrierter Gestaltungsansatz gewählt. Das bedeutet, dass die Gestaltung der laufenden Prozesse stets aus der Sicht des Anwenders heraus evaluiert werden, was durch interne fachliche Abnahmen gewährleistet wird. Diese Evaluation führt zu zusätzlichen Vorteilen für die Anwender, wie Plausibilitätsprüfungen, sichere Übertragung und vorausgefüllte Formulare. Beim Entwurf der Prozessketten spielte die Transparenz der Antragsstellung eine große Rolle. Der Anwender sollte stets in der Lage sein, sich über den Status des laufenden Antragsprozesses zu informieren und den Status abrufen zu können.
Bei der Erstellung der Benutzerinteraktion ist es notwendig, die Benutzererfahrung so intuitiv wie möglich zu gestalten und dabei die domänenspezifische Genauigkeit der Prozesslogik zu gewährleisten. Dies gilt auch für anwendungsrelevante Daten, die anwendungsübergreifend genutzt werden können. Die grafische Benutzeroberfläche (GUI) von AnGeWaNt aggregiert so viele Informationen wie möglich, wie beispielsweise messgerätespezifische Daten. Auf diese Weise muss der Benutzer die Informationen nicht für jeden Antrag neu eingeben.
Um die Flexibilität, Verfügbarkeit und Benutzerfreundlichkeit zu erhöhen, wird eine webbasierte Benutzeroberfläche erstellt. Auf der Client-Seite wird lediglich ein Web-Browser benötigt, um auf die AnGeWaNt-Plattform zuzugreifen. Das gemeinsame Web-Frontend übernimmt die Authentifizierung und Benutzerinteraktion mit den angeschlossenen Diensten. Das Web-Frontend ist ein Spring Boot Container, der über REST mit den angeschlossenen Diensten kommuniziert. Für die Implementierung von GUI-Komponenten wurde das Framework Vaadin verwendet. Es ermöglicht eine vollständige Entwicklung des Frontends mit der Programmiersprache Java. Somit wurde die Komplexität der verwendeten Technologien bewusst reduziert und auf eine Frontend-spezifische Programmiersprache verzichtet.
Die GUI ist mit einem vertikalen Navigationsmenü auf der linken Seite gestaltet, das die Flexibilität in Bezug auf die Bildschirmauflösung erhöht. Das Navigationsmenü mit seinen Elementen verweist auf die einzelnen Dienstansichten. Der restliche Bildschirm wird für die Anzeige des Inhaltsbereichs verwendet.
6.3.4 Implementierung einer verteilten Softwarearchitektur
Die Architektur der Plattform ist nach Gesichtspunkten der Service-orientierten Architektur (SOA) konzipiert und umgesetzt worden. SOA ist ein Softwarearchitekturmodell, das Softwarekomponenten als Dienste klassifiziert. Diese Dienste sind eigenständige Einheiten, zustandslos, lose gekoppelt und können flexibel kombiniert werden (siehe Abb. 6.9). Die Einheiten kommunizieren über REST (REpresentational State Transfer, blaue Pfeile in Abb. 6.9). REST kann über HTTP oder HTTPS kommunizieren, ohne dass zusätzliche Protokolle hinzugefügt werden müssen. Der streng modulare Ansatz erlaubt es, neue Dienste mit geringem Aufwand hinzuzufügen. Um die Flexibilität zu erhöhen und die spätere Erweiterbarkeit zu erleichtern, strebt das Projekt nach standardisierten und harmonisierten Schnittstellen für alle Dienste.
Abb. 6.9
Konzeptuelle Ansicht der modularen Metrologischen Dienstleistungsplattform
×
Die verteilte Architektur ermöglicht die unabhängige Bereitstellung und den Betrieb der Dienste. Der Aufbau der Plattform (Abb. 6.9) besteht aus drei unabhängigen Modulen. Das Hauptmodul ist die AnGeWaNt-Plattform. Es bietet eine webbasierte Benutzeroberfläche und Dienste wie den Eichantrag und Software-Update-Antrag. Das Benutzerverwaltungsmodul (Identity-Access-Management mit Keycloak-Logo) besteht aus der Benutzerverwaltung mit Keycloak (eigener Server). Sie bietet eine sichere, zustandslose und flexible Authentifizierungs- und Autorisierungsschicht auf Basis des OpenID-Connect-Standards. Unter dem Hauptmodul sind Drittanbietersysteme als externe Infrastrukturmodule ebenfalls über REST an die AnGeWaNt Plattform angebunden. Dazu zählen Systeme wie DEMOL, um Eichanträge zu stellen oder Hersteller-Infrastrukturen, um instrumentenspezifische Gerätepässe abzurufen.
6.3.4.1 Implementierung eines Rollen- und Rechtekonzepts
Alle Dienste werden über ein gemeinsames Web-Frontend angebunden und dem Nutzer zur Verfügung gestellt. Dabei ist es unerheblich für den Nutzer, ob dieser Dienst sich intern oder extern befindet. Die Benutzeroberfläche bleibt konsistent (siehe Abb. 6.10).
Abb. 6.10
Zentrale Benutzeroberfläche für modulare Dienste
×
Um die hohe Verfügbarkeit und Flexibilität als PaaS zu gewährleisten, wurde als OpenID-Connect-konformes IAM-System Keycloak [4] integriert. Keycloak ermöglicht es, die jeweiligen Dienste über verschiedene Domänen zu verteilen und dabei die Sicherheit und Berechtigungssteuerung zu gewährleisten. Dazu werden Access-Tokens an den jeweiligen Dienst ausgeliefert, um die Berechtigung des anfragenden Nutzers zu überprüfen und erteilen zu können. Diese Tokens können auch für Zugriffe an externe Dienste geschickt werden, um dort die Berechtigung auf bestimmte Ressourcen freizugeben.
Keycloak verfolgt einen hierarchischen Aufbau seiner Berechtigungsstruktur, an dessen Spitze die Realms stehen. Ein Realm ist vergleichbar mit einer Anwendungsdomäne. Innerhalb eines Realms befinden sich Clients, Rollen und Benutzer. Diese können zwischen verschiedenen Realms nicht ausgetauscht werden. Innerhalb des AnGeWaNt-Realms befinden sich die Clients. Ein Client entspricht einem Dienst, z. B. „eichantrag-service“ oder „dcc-service“. Innerhalb des Realms befinden sich auch Rollen und Benutzer. Rollen können andere Rollen enthalten (diese heißen in Keycloak „composite roles“) und werden Benutzern zugeordnet. Ein Benutzer meldet sich mittels Benutzernamen und Passwort an, optional zusätzlich mit einem zweiten Faktor wie z. B. einem Einmalpasswort aus einer Authenticator-App eines Smartphones.
Die Absicherung der gesamten AnGeWaNt-Plattform geschieht auf zwei unterschiedlichen Wegen. Das AnGeWaNt-Frontend erhält von Keycloak einen Anmeldedialog, der Benutzername und Passwort verlangt und erst nach erfolgreicher Authentifikation den Benutzer anmeldet und zur Plattform zurückleitet. Jede Anfrage an die Backend-Services wird mittels eines Tokens (JWT-basiert) an Keycloak authentifiziert. Ist das Token gültig, wird die Anfrage im Auftrag des im Frontend angemeldeten Benutzers, zu dem das Token gehört, autorisiert und ausgeführt. Dazu gibt es in jedem Backend-Service einen OAuth 2.0-Client, der die Kommunikation mit Keycloak übernimmt. OAuth 2.0 ist das Standardprotokoll für Benutzerautorisierung bei Web- und Desktopanwendungen und die technische Grundlage für OpenID-Connect.
6.3.4.2 Implementierung der hoheitlichen Anwendungsfälle
In den folgenden zwei Abschnitten wird insbesondere auf die beiden hoheitlichen Anwendungsfälle eingegangen. Dabei ist es wichtig zu betonen, dass diese beiden Prozesse mit Vorbildfunktion ausgewählt wurden. Zum einen um vorhandene Fachanwendungen und Infrastrukturen nahtlos einzubinden, wie am Beispiel des Eichantrags nachvollzogen werden kann. Zum anderen sollte ein Prozess mit hoher Komplexität und hoher Interaktion zwischen allen Beteiligten im gesetzlichen Messwesen umgesetzt werden. Am Beispiel des Softwareupdateantrags sind die vielfältigen Herausforderungen direkt greifbar. Bei der Umsetzung sollte auf eine hohe Wiederverwendbarkeit der gefunden Lösungen Rücksicht genommen werden, um den größtmöglichen Nutzen zu erreichen.
6.3.4.3 Implementierung des Eichantrages
Digitale Eichanträge werden über die Benutzeroberfläche (vgl. Abb. 6.12) erstellt, wobei möglichst viele Information vorausgefüllt werden. Diese sind der Antragsteller, der anhand seiner Login-Daten zugeordnet werden kann, sowie die Gerätedaten nach Vorauswahl eines Geräte-Typs und nachfolgender Auswahl dazu passender, dem Antragsteller zugeordneter Geräte in der Liste. In den Gerätedaten sind, die für die Eichung notwendigen, Daten und Dokumente bereits verfügbar hinterlegt, sodass diese für den Antrag nicht erneut händisch eingegeben bzw. hinzugefügt werden müssen. Vor der Einreichung muss der Antrag in der Benutzeroberfläche aktiv validiert werden. Die Validierungsfunktion im Eichantrag-Service prüft dann, ob alle Pflichtfelder im Antrag befüllt sind. Ist die Validierung erfolgreich, kann der Antrag abgeschickt werden. Der genaue Prozessablauf ist in Abb. 6.11 zu sehen.
Abb. 6.11
Vereinfachter Prozessablauf des Eichantrags
×
Die bereits gestellten Eichanträge werden zunächst in einer Übersichtstabelle gezeigt, einschließlich des Status der Antragstellung. Hierbei wird in diesem Prozess zwischen „EINGEREICHT“ (an das DEMOL-System übermittelt), OK (Antrag verarbeitet, Eichung wird avisiert) oder „FEHLER“ (Antrag kann nicht weiterbearbeitet werden, wegen fehlender oder nicht plausibler Informationen darin) unterschieden.
DEMOL selbst stellt eine (im Rahmen des AnGeWaNt-Projekts hinzuentwickelte) REST-Schnittstelle bereit, an deren Endpunkt die Eichanträge geliefert und die Resultate der Einreichungen abgerufen werden. Noch zu implementieren ist die Archivierung gestellter Anträge im digitalen Dokumentarchiv.
Abb. 6.12
Bildschirmfoto des Eichantrags
×
6.3.4.4 Implementierung des Softwareupdateantrags
Das Hauptziel des Dienstes besteht darin, die Verteilung von Software-Updates an bestimmte Messgeräte im Feld zu koordinieren. Er verfügt über spezifizierte REST-Endpunkte für die Einreichung eines Antrags, Statusaktualisierung, Empfang und Platzierung einer Antwort auf eine Anhörung. Dies sind die einzigen Schritte im Antragsprozess, die eine Interaktion über die AnGeWaNt-Plattform nach [19] erfordern. Die Bearbeitung des Software-Update-Antrags erfolgt gemäß den Schritten in Abb. 6.13.
Abb. 6.13
Vereinfachter Prozessablauf des Softwareupdateantrags
×
Ein neuer Antrag wird gestellt und der Antragsteller sowie die adressierten Behörden werden über die erfolgreiche Einreichung benachrichtigt und die Eichbehörde legt den Ensemble-Test (mit dem Los der Messgeräte) für die Zulassung fest. Nach der Festlegung des Prüfloses können in einer Anhörung des Antragstellers durch die Behörde zusätzliche Informationen angefordert werden, die zur Durchführung der Zulassung notwendig sind. Danach wird der Antrag entweder genehmigt oder abgelehnt. Wird er genehmigt, wird das Los der gewählten Geräte für die Softwareaktualisierung durchgeführt. Schließlich werden die Ergebnisse der Aktualisierung veröffentlicht. Die Prozesstransparenz wird durch die Validierung von Statusaktualisierungen sichergestellt, die über den entsprechenden REST-Endpunkt ausgelöst werden können. Alle ausgegebenen Anträge können im Web-Frontend eingesehen werden (siehe Abb. 6.14).
Abb. 6.14
Bildschirmfoto des Softwareupdateantrags
×
6.3.4.5 Implementierung des digitalen Kalibrierauftrags
Innerhalb von AnGeWaNt werden digitale Kalibrierzertifikate (DCC) [26] von einem separaten Dienst gehandhabt, dem DCC-Dienst [3]. Er hat zwei Aufgaben: Zum einen ermöglicht er dem Benutzer das Hochladen von Zertifikaten als XML entsprechend der PTB-Dokumentendefinition für DCCs. Der Dienst validiert das hochgeladene XML-Dokument (vgl. Abb. 6.15) und speichert es nach erfolgreicher Validierung im von AnGeWaNt verwendeten Dokumentenarchiv. Zum anderen ermöglicht der Dienst die Erstellung von Kalibrieraufträgen für das Vakuumlabor. Er sammelt die verfügbaren Kundendaten aus dem Stammdaten-Service (Hersteller, Antragsteller und Verwender von Messgeräten) sowie ToDo-Definitionen des Vakuumkalibrierlabors. Ein ToDo identifiziert die Kalibrieraufgabe, die bei der Durchführung des Kalibrierauftrags zu erledigen ist.
Abb. 6.15
Digitaler Kalibrierschein als HTML und XML dargestellt
×
Der gesamte Anwendungsfall ist in Abb. 6.16 als Sequenzdiagramm dargestellt. Es zeigt das Zusammenspiel aller beteiligten AnGeWaNt-Dienste sowie des Vakuumkalibrierlabors.
Der DCC-Dienst generiert aus den abgerufenen Aufgaben (ToDos) die verfügbaren Gerätetypen, die ausgewählt werden können. Der Benutzer gibt Informationen über den Gerätetyp, den anfragenden Kunden, das gewünschte Kalibrierungsdatum und ob er an den eigentlichen Eichtermin erinnert werden möchte oder nicht, sowie weitere für die Anfrage notwendige Informationen ein. Nach dem Absenden des Auftrags konvertiert ihn der DCC-Dienst in das vereinbarte JSON-Format für das Vakuumkalibrierlabor und sendet ihn über die REST-Schnittstelle dorthin. Das Vakuumkalibrierlabor liefert eine Antwort nach erfolgreichem Empfang des Kalibrierauftrags. Während der Auftragsbearbeitung (vgl. Abb. 6.16) kann das Vakuumkalibrierlabor über REST mittels PUT-Statusaktualisierungen an den DCC-Dienst senden. Der bereitgestellte Statuscode wird in einen gültigen Status für die im PUT-Aufruf identifizierten Auftrag übersetzt. Sobald der Status einer Anfrage „CERTIFICATE ISSUED“ erreicht hat, was bedeutet, dass das Vakuumkalibrierlabor fertig ist und die Kalibrierungsanforderung erfolgreich durchgeführt hat, wird das fertige DCC als XML vom Vakuumkalibrierlabor durch den DCC-Dienst automatisch abgerufen. Nach erfolgreicher Validierung wird das DCC im Dokumentenarchiv gespeichert.
Abb. 6.16
Sequenzdiagramm: Prozessablauf für die Erstellung eines Kalibrierzertifikats
×
Abb. 6.17 stellt den Prozessablauf aufseiten des Vakuumlabors dar. Dort beginnt der Prozessablauf mit der Erstellung des Customer-Objekts und des ToDo-Objekts, welches an die AnGeWaNt-Plattformt geschickt wird. Kommt dann der Kalibrierauftrag aus der AnGeWaNt-Plattform, so generiert das Vakuumlabor ein Planungs- und Bürokratie-Objekt (pla, bur). Daraufhin starten die Messungen. Am Ende der Prozesskette steht das DCC-XML zur Verfügung und es wird der AnGeWaNt-Plattform zur Verfügung gestellt. Diese kann aus dem XML ein menschenlesbares HTML-Dokument generieren.
Abb. 6.17
Prozessablauf für die Erstellung eines Kalibrierzertifikats auf der Seite des Vakuumlabors
×
6.3.4.6 Implementierung der digitalen Konformitätserklärung
Die Konformitätserklärung legt der Hersteller bei der Inverkehrbringung des Messgerätes dem Gerät bei. Sie enthält alle wichtigen Normen und Richtlinien, die das Messgerät zu erfüllen hat. Um eine automatische Validierung für die Konformitätserklärung zu ermöglichen, wurde ein XML-Schema basierend auf dem DCC für die digitale Konformitätserklärung (DoC) erstellt (siehe Abb. 6.18). Unter dem komplexen Hauptelement „DeclarationOfConformity“ ist eine Folge von sieben Elementen definiert. Das Element „Manufacturer“ ist als komplexes Element definiert, das die gezielte Eingabe des Namens, der Adresse und der Telefonnummer eines Unternehmens als Zeichenfolge (String) ermöglicht. Das Element „Product“ wird verwendet, um Informationen über ein Gerät wie Modell und Typ bereitzustellen.
Abb. 6.18
Digitale Konformitätserklärung als HTML und XML dargestellt
×
Weitere relevante Produktinformationen können im Element „Description“ untergebracht werden. Die Identifikationsnummer eines Geräts wird im Element „ObjectOfDeclarationId“ als ganzzahliger Wert abgelegt. Das Element „ConformityDirective“ bezieht sich auf die Liste der gesetzgebenden Dokumente, wie z. B. NAWID [28]. Falls für ein Messgerät mehrere Richtlinien berücksichtigt werden müssen, kann das Element „ConformityDirective“ einfach in der XML-Datei wiederholt werden. Auf die gleiche Weise kann das Element Standard mehrfach im Dokument verwendet werden, um Informationen über die berücksichtigten Normen bereitzustellen. Das Element „NotifiedBody“ liefert Informationen über den Namen des Kalibrierungslabors und die Nummer des ausgestellten Zertifikats. Ein ausgearbeitetes Schema wurde zur Veranschaulichung des Konzepts entwickelt und umfasst nicht die gesamten in NAWID festgelegten Anforderungen. Für den realen Anwendungsfall sollte das Schema um die weiteren Elemente erweitert werden.
Das „Online-Konformitätserklärungssystem“, das in der AnGeWaNt-Plattform implementiert ist, hat folgende Funktionalitäten:
Über die AnGeWaNt-Plattform kann auf einen Service zugegriffen werden, der als DOC-Service bezeichnet wird.
Ein XML-basiertes Validierungsschema, wie oben beschrieben, das auf Frameworks der DoC basiert, wird im Dokumentenarchiv gespeichert.
Der Nutzer kann die vom Konformitätsbewertungssystem benötigten Geräteinformationen über XML-basierte Daten bereitstellen.
Der Service validiert die Daten anhand des DoC-Schemas und gibt dem Benutzer eine Erfolgs- oder Misserfolgsmeldung.
Im Falle einer erfolgreichen Validierung wird ein von Menschen lesbares Zertifikat ausgestellt, das die validierten Geräteinformationen enthält.
Durch die offene Architektur der AnGeWaNt-Plattform konnte schnell ein Prototyp erstellt werden, der alle Anforderungen des Arbeitspaketes des SmartCom-Projekts [30] erfüllt. SmartCom ist ein europäisches Digitalisierungsprojekt, das die Standardisierung digitaler Zertifikate erforscht. Durch die Zusammenarbeit konnte das SmartCom-Projekt schnell zeigen, wie ein Konformitätserklärungsprozess in einem metrologischen Service-Ökosystem für das gesetzliche Messwesen prinzipiell umgesetzt und genutzt werden kann. Die standardisierte Struktur des DoC und sein XML-Schema halfen bei der einfachen Integration in die Umgebung der AnGeWaNt-Plattform. Dies kann als Ausgangspunkt für künftige Forschungsprojekte zur Unterstützung technischer Standards betrachtet werden, um vernetzte und moderne Ökosysteme anstatt neue Datensilos zu errichten.
6.3.4.7 Implementierung des digitalen Dokumentenarchivs
Das digitale Dokumentarchiv (im Folgenden Archiv-Service genannt) ist einer der übergreifenden Dienste, wie z. B. der Stammdaten-Service, der AnGeWaNt-Plattform. Es erlaubt das revisionssichere Archivieren elektronischer Dokumente.
Bei der Archivierung wird durch die verwendende Fachanwendung ein fachlicher Dokumenttyp (z. B. Baumusterprüfbescheinigung, Bedienungsanleitung oder Konformitätserklärung) und ein technischer Dateityp (z. B. PDF, Word-Dokument oder JPEG-Bild) mitgegeben. Der Dienst selbst vergibt initial die Versionsnummer 1 für neue Dokumente und zählt für Aktualisierungen eines bestehenden Dokuments die Versionsnummer um 1 hoch, sofern ein, vor Aktualisierung erfolgter, Binärvergleich ergeben hat, dass der Inhalt sich unterscheidet.
Für jedes archivierte Dokument kann ein aktuell ermittelter Hashwert abgerufen werden, welcher bei der verwendenden Fachanwendung gehalten wird. So kann die Fachanwendung mittels eines Vergleichs des gespeicherten mit dem aktuell bestimmten Hashwert aus den Archiv-Service sicherstellen, dass es sich um die Originalversion des Dokuments handelt und dieses nicht manipuliert wurde.
Die, über die REST-Schnittstelle des Archiv-Services, bereitgestellten Operationen lauten:
Dokument speichern
Dokument abrufen (anhand seiner ID)
Dokumentliste abrufen (anhand eines fachlichen Dokumenttyps)
Hashwert abrufen (anhand der Dokument-ID)
Dokument löschen (anhand seiner ID, löscht auch alle Vorgängerversionen)
Geplant ist noch die Anbindung der E-Akte als Dokumentspeicher. Aktuell werden Dokumente in einer relationalen Datenbank abgelegt, einschließlich ihrer Binärdaten als BLOBs (Binary Large Objects, große Binärdaten in Datenbanktabellen). Dies mag für kleine Datenmengen ausreichend praktikabel sein, für größere Datenmengen jedoch skaliert dieser Weg eher schlecht. Zur Anbindung an die E-Akte ist ein separater, von AnGeWaNt unabhängiger Dienst in Vorbereitung, der die komplexe und sehr generische Schnittstelle der E-Akte, in die für den vorliegenden Anwendungsfall, kapselt und auf der AnGeWaNt-Seite wesentlich vereinfacht. Ziel dieser Trennung ist, die fachlichen Belange der E-Akte nicht mit den fachlichen Belangen von AnGeWaNt zu vermengen.
Im Archiv-Service selbst erfolgt die Handhabung des Ablegens und Auffindens der binären Daten gekapselt in einer Abbildungsklasse (Mapper) statt. Diese konvertiert zwischen Dokument (Entity in der Datenbank) und DokumentDto (Datentransferobjekt für ein Dokument) in beide Richtungen. Auf diese Weise „weiß“ der Archiv-Service sogar selbst nicht, ob er Dokumentdaten in seine eigene Datenbank schreibt oder diese in der E-Akte archiviert.
6.3.4.8 Implementierung des Gerätepasses
Der Service für die Gerätehersteller bindet externe Datenquellen der teilnehmenden Hersteller an. Einer der Hersteller betreibt eine eigene Datenbank mit Gerätepässen, aus der die AnGeWaNt-Plattform Gerätepässe als JSON-strukturierte Informationen durch Angabe eines herstellerspezifischen Geräteschlüssels abrufen kann. Aktuell ist die Herstellerdatenbank der Firma PFREUNDT angebunden. Der Dienst leitet derzeit die Informationen an das Web-Frontend weiter, das eine herunterladbare, sichere PDF-Datei erzeugt und die Daten parallel dazu anzeigt (vgl. Abb. 6.19). Der bezogene Gerätepass kann als neuer Geräte-Typ direkt in den Stammdaten-Service importiert und als Dokument im Dokumentarchiv an den neu angelegten Typ geheftet werden. Auch in diesem Dienst werden Daten sinnvoll importiert und ergänzt im Hinblick auf die digitale Verwaltungsschale.
Abb. 6.19
Benutzeroberfläche für den Abruf und die Darstellung eines Gerätepasses
×
In Zukunft wird dieser Dienst noch erweitert, um eine Verbindung zu anderen Herstellerdatenbanken zu erreichen und von dort ebenfalls Gerätepässe oder Gerätepass-ähnliche Daten zu importieren. Darüber hinaus wird im Rahmen der digitalen Verwaltungsschale eine gerätezentrierte Informationsbasis aufgebaut. Zu den Gerätepässen, die eichrelevante Daten wie Messbereiche und Genauigkeitsklassen und softwareupdaterelevante Daten wie Versionsnummern, Hashwerte und weitere Merkmale, insbesondere bei Softwaretrennung, enthalten, kommen dann noch Bedienungsanleitungen, bisherige Prüfbescheinigungen und/oder Zertifikate hinzu.
6.3.4.9 Implementierung der Softwareverifikation
Software, die rechtlich relevante Verfahren steuert und ermöglicht, muss in der Lage sein, sich selbst auf ihre Authentizität zu überprüfen, was den Anforderungen U2 (Software-Identifikation) und U8 (Software-Authentizität und Ergebnisdarstellung) des WELMEC 7.2 Software Guide [22] entspricht. Dazu gehören alle Dienste, die solche Verfahren durchführen, sowie das Web-Frontend, das eine grafische Benutzeroberfläche für diese Dienste bereitstellt [31].
Das NIST (National Institute of Standards and Technology, nationales Metrologieinstitut der USA) ermutigt die Entwickler von Anwendungen und Protokollen, mindestens SHA2-256 für alle Anwendungen von Hash-Funktionen zu implementieren, die Interoperabilität erfordern [32]. Die berechneten Hash-Werte jedes Dienstes, der rechtlich relevante Verfahren durchführt, sowie des AnGeWaNt-Frontends werden separat in einem geschützten Bereich (Vault) gespeichert. Der Zugriff auf diesen Tresor erfolgt ausschließlich durch den hierfür implementierten Verifikations-Service. Der Dienst speichert die Hash-Werte sicher und verifiziert die erwarteten Hash-Werte mit den tatsächlichen, ohne den erwarteten Hash-Wert offenzulegen.
Der Hash-Wert wird als SHA2-256-Hash aus der innerhalb des Application-Servers (bspw. Jetty oder Tomcat) geladenen und ausgeführten JAR-Dateicontainerdatei ermittelt. Da es pro Service und für das Frontend jeweils genau eine solche Datei gibt, lässt sich so über den gesamten binären Inhalt dieser Hash zur Laufzeit ermitteln. Daraus folgt auch, dass jegliche Modifikation am Code, ganz gleich ob durch programmatische Veränderung und Neukompilierung oder durch Manipulation des Bytecodes (Kompilat für die JVM) in der JAR-Datei direkt, zu einem anderen Hash-Wert führen und bei der Verifikation der Software zur Laufzeit sofort auffallen würde.
Abb. 6.20 gibt einen Überblick wie die beschriebene Funktionalität für den Anwender an die Benutzeroberfläche dargestellt wird. Dabei sind die SHA-256-Hashes für alle angebundenen Dienste in einer Liste unterhalb der Schnittstellendokumentation aufgelistet.
Abb. 6.20
Bildschirmfoto der Softwareverifikation/Verfügbarkeitsprüfung der Dienste
×
6.3.5 Dienstübergreifende Merkmale
Im folgenden Abschnitt werden die übergreifenden Merkmale der AnGeWaNt-Plattform beschrieben, welche die Designentscheidungen zur Artefakt-Struktur und zur API-Dokumentation umfassen. Des Weiteren wird auf die Build-Umgebung im Integrations- und im Staging-System eingegangen.
6.3.5.1 Artefakt-Struktur
Die lose Kopplung aller Services sowie des Frontends spiegelt sich auch in der Artefakt-Struktur wider. So werden alle nach außen erforderlichen Klassen in einem separaten Artefakt < name > -service-api verfügbar gemacht. Dies hat den Vorteil, dass nur die Klassen für die Schnittstelle eines Service nach außen gereicht werden, während die Funktionalität einschließlich der Datenhaltung und Geschäftslogik gekapselt im Artefakt < name > -service verbleiben. Das Frontend und andere Services inkludieren dann nur < name > -service-api als Abhängigkeit, um auf den zugehörigen Service zuzugreifen.
Im Artefakt service-commons befinden sich alle serviceunabhängigen Funktionalitäten wie z. B. REST-Controller für Versions- und Ressourcenabruf, Konfigurationsklassen, die unscharfe Suche für Datenbanktabellen, die Berechnung der Hash-Werte für die Softwareverifikation und die Komponenten für die Kommunikation mit dem IAM-Server. Letzteres umfasst insbesondere die Token-basierte Autorisierung der REST-Aufrufe der Services. service-commons-api enthält, analog zu den anderen < name > -service-api-Artefakten, die Klassen, welche als Teil der Schnittstellen für die genannte Funktionalität in service-commons nach außen gereicht werden.
Die beschriebene Trennung von service und service-api für jeden einzelnen Service ermöglicht und erfordert das Hereinreichen der Konfiguration der in service-api enthaltenen REST-Clients. Da jeder Service autark läuft und daher seinen eigenen Spring-Application-Kontext zur Laufzeit bereitstellt, muss auch in diesem Kontext eine Konfigurationsklasse vorhanden sein, die dem REST-Client den anzusteuernden REST-Endpunkt zur Laufzeit hereingereicht werden. Denn der verwendende Service oder das Frontend wissen per se nicht (und sollen es auch nicht wissen), wo die einzelnen angesprochenen Services laufen. Das müssen nur die jeweiligen REST-Clients wissen.
6.3.5.2 Schnittstellen-Dokumentation
Für die Dokumentation der Schnittstellen wird das Framework Swagger in der Version 3 verwendet (siehe Abb. 6.20). Es ist frei verfügbar und wird mittels einer zentralen Konfiguratonsklasse in service-commons initialisiert. Damit Swagger die im Browser abrufbare Dokumentation generieren kann, müssen in allen REST-Controllern sowie in den DTO-Klassen, die als JSON-Austauschformat verwendet werden, mit den Swagger-eigenen Annotationen versehen werden. Die verwendeten Annotationen sind
@Api für die Beschreibung der Controllerklassen,
@ApiOperation für die einzelnen Endpunkte innerhalb der Controllerklassen,
@ApiModel für die Beschreibung der Datenaustauschobjekte (DTO-Klassen) und
@ApiModelProperty für die einzelnen Felder in den Datenaustauschobjekten
6.3.5.3 Continuous-Integration-Umgebung
Als Buildmanager kommt Maven zum Einsatz. Dieser verwaltet Abhängigkeiten und erzeugt die Artefakte. Jenkins als Continuous-Integration (CI)-Umgebung verwendet Maven, um zeit- und änderungsgesteuert die Artefakte zentral zu bauen (vgl. Abb. 6.21). Maven lässt dabei auch alle Tests laufen und meldet, wenn Tests fehlschlagen oder der Buildvorgang aus anderen Gründen scheitert. Für die Verwaltung der Artefakte wird Nexus verwendet. Es ermöglicht die zentrale Bereitstellung der erzeugten Artefakte und spiegelt gleichzeitig die extern eingebundenen Frameworks und Bibliotheken. Sämtliche Artefakte der AnGeWaNt-Plattform werden konfigurationsunabhängig gebaut. Dies ermöglicht ein schnelles, einfaches und zielsystemunabhängiges Bereitstellen aller Services und des Frontends. Die Konfigurationen für alle zurzeit in der CI-Umgebung automatisch bestückten Zielsysteme (Integration, Staging, optional Entwicklermaschinen) werden in einem separaten Projekt gehalten und unterliegen damit auch der Versionskontrolle. Der einzige Nachteil dieser Trennung ist, dass man als Entwickler stets im Blick haben muss, eventuelle Konfigurationsanpassungen auch für die Zielsysteme in dem Projekt zu pflegen. Die genannten Vorteile überwiegen dies jedoch bei weitem.
Abb. 6.21
Continuous-Integration-Lebenszyklus
×
6.4 Lessons learned
Dieses Kapitel soll einen kurzen Überblick über die vorab beschriebenen, entscheidenden Schritte und Erfolgsfaktoren der digitalen Transformation des Projekts geben. Dies soll dabei helfen, branchenübergreifend voneinander zu lernen.
Am Anfang steht immer eine umfassende Anforderungsanalyse: In der idealen Welt haben die Partner bereits ein genaues Bild von dem Ziel und eine ungefähre Vorstellung wie sie dorthin gelangen möchten. In der Realität hingegen sieht es so aus wie in diesem Projekt. Es gibt keine eindeutigen Anforderungen. Es sind zwar Gesetze, Verordnungen und Richtlinien vorhanden, aber oft gibt es keinen formalisierten Prozessablauf. Solche formalisierten Abläufe zu erstellen und, beispielsweise in Form von Ablaufdiagrammen (Flowcharts), zu visualisieren hilft allen Beteiligten. Bei diesem Überblick können wichtige Abhängigkeiten aufgezeigt und bisherige informelle Abläufe der Mitarbeiter standardisiert werden.
Formalisierte Ablaufdiagramme für einen guten Überblick: Für IT-Architekten sind Ablaufdiagramme sehr wichtig, um zu klären, welche Teile einer Prozesskette mithilfe digitaler Unterstützungsleistungen optimiert werden können. Diese formalisierten Ablaufdiagramme helfen bei der Erstellung der Projektplanung und -steuerung sowie bei der Bestimmung von Systemgrenzen.
Partizipation und direkte Kommunikation: Häufig geben fachliche Mitarbeiter die besten Anregungen, um Prozessabläufe zu vereinfachen. Daher sollte man den Kontakt zu den Mitarbeitern suchen, die sich täglich mit den Prozessen auseinandersetzen. Man sollte, wenn möglich, mit allen Beteiligten direkt sprechen und deren Vorstellungen, Bedürfnisse und Anregungen versuchen zu verschriftlichen. Dieser Prozess führt automatisch zu einer ersten Abstraktion und verhilft häufig zu einem besseren Verständnis der Problemlage.
Agiles Projektmanagement: Hat man ein erstes Verständnis erlangt, dann ist die interne Kommunikation mit dem eigenen Team sehr wichtig. Hierbei geht es darum den kreativen Prozess zur Problemlösung iterativ zu gestalten und dabei das Team voll einzubinden. Im AnGeWaNt-Projekt hat sich eine agile Projektsteuerung sehr bewährt. Häufig stand das Team vor Herausforderungen mit unvollständigen Anforderungen, die Entscheidungen gefordert haben, ohne Funktionen und Aspekte bis zum Ende spezifizieren zu können. Das Rapid-Prototyping mit seinen iterativen Entwicklungszyklen (Entwickeln, Testen, Installieren) hat häufig das Team vor Stillstand und scheinbar unlösbaren Aufgaben bewahrt (vgl. Abb. 6.21).
Autonomie der Mitarbeitenden: Die Kreativität geht dabei Hand in Hand mit der Autonomie den Mitarbeitenden. Diese kann mithilfe von Ticket-Systemen oder Kanban-Boards strukturell gefördert werden. Dabei können sich die Mitarbeitenden die anstehenden Aufgaben selbst aussuchen und bearbeiten diese eigenständig. So sind die Mitarbeitenden idealerweise motivierter und können ihre individuellen Stärken besser in das Projektgeschehen einbringen. Vonseiten der Projektsteuerung kann direkt abgelesen werden, an welcher Stelle sich das Projekt befindet und wo noch Nachsteuerung benötigt wird.
Einheitliche Schnittstellen: Bei digitalen Transformationsprojekten steht sehr häufig die Vernetzung und der einheitliche Datenaustausch im Vordergrund. Dies gehört auch zur Kommunikation. Dennoch soll hierbei auf die Einheitlichkeit der Schnittstellen eingegangen werden. Im vorliegenden Projekt ist diese Anforderung sehr frühzeitig festgelegt worden und dabei war es wichtig, offene und verbreitete Standards zu unterstützen und einzusetzen. Aus technischer Sicht sind dabei REST-Schnittstellen zum Einsatz gekommen. Noch wichtiger als der technische Standard ist die Stringenz beim Einsatz durch das ganze Projekt sowie die Absprache mit den beteiligten Partnern.
Es muss nicht alles selbst programmiert werden: Diese Erkenntnis hat sich im Laufe des Projektes an mehreren Stellen herausgestellt. Oftmals ist die Zeit für eine grundlegende Marktrecherche für anstehende Probleme besser investiert, als das Rad neu zu erfinden. Zum einen bewahrt es das Team vor zusätzlicher Arbeit und erhöht das Tempo bei der Umsetzung. Zum anderen kann man idealerweise bestehende Standardprodukte einsetzen und fördert damit wiederum direkt offene Standards.
Anwendungsfälle mit hoher Relevanz aussuchen: Bei der technischen Umsetzung sollten Anwendungsfälle mit hoher Relevanz und Auswirkung für den anvisierten Bereich ausgesucht werden. Durch die hohe Relevanz kann die Aufmerksamkeit aller Beteiligten in dem Bereich erreicht und damit eine hohe Signalwirkung generiert werden. Zudem wirken diese Anwendungsfälle sehr motivierend auf das Team bei der Umsetzung, da ein großer Mehrwert dadurch entsteht. Ist die Umsetzung erfolgreich abgeschlossen worden, so können diese Anwendungsfälle als Vorlage für weitere digitale Umsetzungsprojekte dienen.
Open Access Dieses Kapitel wird unter der Creative Commons Namensnennung 4.0 International Lizenz (http://creativecommons.org/licenses/by/4.0/deed.de) veröffentlicht, welche die Nutzung, Vervielfältigung, Bearbeitung, Verbreitung und Wiedergabe in jeglichem Medium und Format erlaubt, sofern Sie den/die ursprünglichen Autor(en) und die Quelle ordnungsgemäß nennen, einen Link zur Creative Commons Lizenz beifügen und angeben, ob Änderungen vorgenommen wurden.
Die in diesem Kapitel enthaltenen Bilder und sonstiges Drittmaterial unterliegen ebenfalls der genannten Creative Commons Lizenz, sofern sich aus der Abbildungslegende nichts anderes ergibt. Sofern das betreffende Material nicht unter der genannten Creative Commons Lizenz steht und die betreffende Handlung nicht nach gesetzlichen Vorschriften erlaubt ist, ist für die oben aufgeführten Weiterverwendungen des Materials die Einwilligung des jeweiligen Rechteinhabers einzuholen.
