Systemarchitektur

Ziel dieses Dokuments ist es, dem Leser die Ziele hinter dem Design der Software “KalibriWare” nahezubringen. Dazu wird zuerst ein Überblick über die gewünschten Funktionalitäten gegeben, anschließend wird aus diesen Funktionalitäten eine Systemarchitektur abgeleitet und die notwendigen Entscheidungen strukturiert erläutert.

Bisheriger Stand

Bisher werden Kalibrierungen im Kalibrierlabor der CTDI mittels der Software ‘KalibriScript’ durchgeführt, welche ihr Lebensende erreicht hat. KalibriScript führt den Nutzer durch den Kalibrierprozess diversester Messgeräte und archiviert die erzeugten Kalibrierprotokolle auf einem zentralen Datenspeicher. Weiterhin existieren mehrere andere kleine Softwareteile, u.A. zur Archivierung der Klimadaten, zur Erzeugung von Kalibrierscheinen passend zu den Kalibrierprotokollen und zur Kunden/Geräteverwaltung.

Systemarchitektur KalibriScript

Das u.g. Schaubild visualisiert die bisherige Systemarchitektur. Sichtbar ist der Single-Point-of-Failure am Server, wo die Datenbanken gespeichert sind und die Clients ohne Synchronisation auf die Datenbanken zugreifen. Weiterhin werden diverse Konfigurationen und Dateien über Windows-Shares (SMB) für die Kalibrierrechner bereitgestellt, was den Vendor-Lock-In auf veraltete Windows-Versionen verstärkt.

TODO: Image

Probleme im derzeitigen Stand

Alter der Software

KalibriScript wurde Ende der 1990er Jahre entwickelt und seitdem nur in geringem Maße angepasst. Im Vergleich zu heutigen Systemen und den Techniken des Software-Engineerings ist die Software nahezu unwartbar/erweiterbar. Die Software benutzt Schnittstellen und Hardwaretreiber, welche spezifisch für Windows 95/98/2000 sind und ist damit nicht zum Einsatz auf modernen Betriebssystemen geeignet. Die notwendigen Anpassungen dafür sind allerdings durch die fehlenden Tests und Dokumentation nicht zu leisten, sodass eine neue Software erstellt werden muss.

User-Workflow

KalibriScript besitzt eine grafische Oberfläche, jedoch ist durch die Fragmentierung des Kalibrierprozesses in viele kleinere Programmteile die Nutzerführung suboptimal. Das äußert sich u.A. darin, dass Nutzer die gleichen Daten mehrfach per Hand eingeben müssen, obwohl diese Daten bereits in maschinenlesbarer Form vorliegen. Die Nutzerführung beim eigentlichen Kalibrierprozess bleibt hinter heutigen Erwartungen zurück, da bedingt durch das Alter der Hard- & Software Bilder nur in sehr begrenztem Detailgrad benutzt werden können.

Kalibrierschein-/Protokollerstellung

Die Kalibrierprotokolle und Kalibrierscheine in KalibriScript sind ausschließlich zum Ausdruck erstellt. Die Erweiterbarkeit um diese Protokolle in einer maschinenlesbaren, verifiziertbaren (i.e. digital signierten) Form zu erstellen, ist nicht gegeben. Größere Kunden erwarten allerdings, dass die Protokolle im Falle eines Audits o.ä. digital zur Verfügung gestellt werden können.

Integration in die restlichen Unternehmensprozesse

KalibriScript arbeitet in einem vollständig isolierten Netzwerk und dementsprechend ist es von den verbleibenden Prozessen abgekoppelt. Aufträge werden in Papierform ausgedruckt und ins Kalibrierlabor verbracht, wo die Nutzer die Informationen wieder ins KalibriScript übertragen (siehe auch User-Workflow). Es gibt keine automatisierte Integration für die Rückrichtung, also nach beendeter Kalibrierung in den Logistikprozess von CTDI.

Material- & Arbeitszeiterfassung

KalibriScript besitzt bisher keine Möglichkeit, Arbeitszeiten oder Material zu verbuchen. Um Material und/oder Arbeitszeiten zu buchen, ist bisher ein Systemwechsel ins SAP der CTDI notwendig, was die Produktivität bei der Kalibrierung/Reparatur weiter senkt.

Anforderungen an die neue Software

KalibriWare soll als sog. OLP (On-Line-Processing) ausgeführt werden. OLP-Systeme im Kontext der CTDI sind auf den jeweiligen Prozess spezialisierte Softwaresysteme, welche auf maximale Produktivität und Usability ausgelegt sind.

• Greenfield-Software (komplette Neuentwicklung)
• Übernahme bzw. Portierung der bestehenden Skripte für KalibriScript
• parallel zu KalibriScript interaktive Nutzerführung durch den Kalibrierprozess
• vollständig automatisierte Erstellung der Kalibrierprotokolle und zugehöriger Kalibrierscheine
• Schnittstelle zum Datenimport und Datenexport zum SAP System
• Einführung eines Berechtigungskonzepts sowie Audit-Logs für Zertifizierungen
• Nutzerauthentifizierung entweder über lokale Datenbank oder externer Single-Sign-On (SAML / LDAP)
• Skalierbares System, Messplatzhardware soll möglichst konfigurationsarm austauschbar sein (z.B. Rechner, Schnittstellenadapter)
• Möglichkeit zur Digitalen Signatur von Kalibrierscheinen
• Planung der aktuellen Kalibrieraufträge, Möglichkeit zur Übersichtlichen Anordnung und Sortierung nach Fälligkeitsdatum
• Möglichkeit zur Erstellung eines Reparaturauftrags
• Material- & Arbeitszeiterfassung für Reparaturaufträge, Einbindung von Reparaturaufträgen in den Datenexport
• Automatisierte CI/CD Pipeline, Aufbau eines Test/Entwicklungssystems parallel zum Produktivsystem

Konzeptionierung

Die folgenden Kapitel geben einen detaillierten Einblick in die geplante Systemarchitektur und liefern Erklärungen zu einzelnen Designentscheidungen. Das folgende Bild zeigt die beteiligten Rechner und deren Funktionen auf. Beim Design wurde darauf geachtet, keinen Single-Point-of-Failure einzubauen. Weiterhin werden die Daten zentralisiert, hochverfügbar auf dem Servercluster abgelegt.

Systemübersicht

Auf globaler Ebene wird die Orchestrierung durch Kubernetes implementiert. Das erlaubt es uns, Workloads deklarativ über mehrere Rechner zu verwalten. In der folgenden Grafik sind die Komponenten und deren Verbindung untereinander dargestellt.

Externe Software

KalibriWare baut auf diverser Standardsoftware auf, um Neuimplementierungen zu vermeiden. Die externen Standardsoftwares sind im folgenden aufgelistet und deren Funktion erklärt:

• Kubernetes, https://kubernetes.io, Containerverwaltung und -orchestrierung. Wird benutzt um die Jobs an die passenden Messplätze zu senden und um die Serversoftware-Teile dauerhaft auszuführen.
• MinIO, https://min.io, MinIO ist ein S3-kompatibler Object-Store, den wir benutzen um PDFs zu archivieren.
• Keycloak, https://keycloak.com, Keycloak wird als Identity- & Rollenprovider benutzt, um die Nutzer- und Rechteverwaltung zu vereinfachen
• Traefik, https://traefik.io, Traefik wird als sog. Ingress benutzt, um Anfragen von außen an die korrekte Backend-API weiterzuleiten
• PostgreSQL, [https://www.postgresql.org/)(https://www.postgresql.org/), PostgreSQL ist die Datenbank, die wir zur zentralen Datenspeicherung benutzen.
• gitea, https://gitea.io/en-us/, Gitea ist eine Quellcodeverwaltungssoftware basierend auf git, welche wir zur Versionierung der Skripte benutzen.
• coder, https://coder.com/, Coder ist eine webbasierte Entwicklungsumgebung basierend auf Microsoft VSCode, welche wir zur Weiterentwicklung der Skripte benutzen.

kalibri-api

Kalibri-API implementiert den zentralen Anlaufpunkt aller Anfragen. Die Backend-API selbst ist in NodeJS / Typescript geschrieben und eng mit den anderen Diensten verwoben. Das Backend verwaltet die folgenden Objekte, welche nun beschrieben werden:

• Werkstattaufträge
  • Ein Werkstattauftrag ist das oberste Element der Datenbankstruktur, jeder Werkstattauftrag beinhaltet eines oder mehrere Geräte welche zu einem Kunden zugeordnet sind. Ein Werkstattauftrag wird durch die Meldungsnummer identifiziert. Weiterhin beinhaltet der Werkstattauftrag das Service-Kennzeichen und die Deadline, also bis wann der Auftrag abgearbeitet werden muss.
• Kunden
  • Ein Kunde wird durch seine SAP-Kundennummer identifiziert. Typischerweise werden Kunden beim erstmaligen Auftreten durch die SAP-Schnittstelle unten angelegt, können aber auch manuell angelegt werden. Kundendaten beinhalten primär den Namen, die Addresse und optional die Firma des Kunden.
• Kalibrierungen
  • Eine Kalibrierung wird im Laufe des Kalibrierprozesses durch die API angelegt, genau dann, wenn die Kalibrierung eines Werkstattauftrags gestartet wird. Wenn eine neue Kalibrierung angelegt wird, sucht das Backend den Prüfling zum Auftrag aus der Datenbank, wählt danach einen der hinterlegten Messplätze aus und startet den Kalibrierjob auf diesem Messplatz, dabei wird der Container sowie abhängige Ressourcen (s.o.) erzeugt. Jede Kalibrierung hat eine eindeutige ID, welche systemweit eindeutig ist.
• Prüflinge
  • Ein Prüfling beschreibt wie im bisherigen Kalibriscript einen Gerätetyp, welcher Kalibriert werden kann, dabei wird der Prüfling durch seine SAP-Materialnummer identifiziert. Jedem Prüfling ist ein Kalibrierskript aus der Skriptverwaltung zugeordnet. Die Zuordnung erfolgt über den Dateipfad, z.B. scripts/olp5501j.
• Standards
  • Ein Standard beschreibt wie bisher ein Gerät, welches zur Kalibrierung benutzt wird. Identifiziert werden die Standards über eine eindeutige interne ID. Jedem Standard ist analog zu den Prüflingen ein Gerätetreiber aus der Skriptverwaltung zugeordnet, z.B. scripts/drivers/oms200. Ein Standard kann einem Messplatz und einer Geräteschnittstelle zugeordnet sein.
• Messplätze
  • Ein Messplatz beschreibt einen physischen Arbeitsplatz im Messlabor. Messplätze werden über eine eindeutige interne ID referenziert und können einem Rechner im Cluster zugeordnet werden. Das ermöglicht einen einfachen Austausch von defekten Rechnern an den Messplätzen. Messplätze werden vollständig zentralisiert mit Software versorgt, sofern eine Verbindung zum Server/-cluster besteht.
• Hardwareschnittstellen
  • Eine Hardwareschnittstelle beschreibt einen Adapter zwischen dem Messplatzrechner und Standards/Prüflingen. Jede Hardwareschnittstelle hat einen Typen, z.B. GPIB, RS232 oder GPIO. Eine Schnittstelle wird immer als Unterobjekt eines Messplatzes angelegt, bei der Anlage wird ein entsprechender Schnittstellentreiber auf dem Messplatzrechner automatisch durch das Backend gestartet.

Kalibri-API benutzt PostgreSQL als Persistenz und legt dieses Datenbankschema an:

kalibri-ui

Kalibri-UI implementiert die grafische Weboberfläche, welche den Nutzer durch die Kalibrierung leitet. Die Benutzerschnittstelle hat eine eigene Dokumentation, auf welche hier nur verwiesen wird.

Skriptentwicklung

Zur Entwicklung von Prüfskripten und Treibern für Standards existiert ebenfalls eine eigene Benutzer/Technikerdokumentation, welche unter Skriptentwicklung zu finden ist.

Architektur im Detail

Um die oben beschriebene Systemarchitektur besser zu verstehen, wird im folgenden ein Kalibrierauftrag vollständig durchgespielt. In der Regel wird durch das SAP-System der Auftrag an die SAP-Schnittstelle übergeben, welche zuerst prüft, ob der Auftrag und der zugehörige Kunde existieren und, falls nicht, diese im Kalibri-Backend anlegt. Dadurch wird ein fehlerfreier und vollautomatischer Datenaustausch mit dem SAP-System ermöglicht.

Bei der Auftragsanlage wird basierend auf dem Servicekennzeichen der nächste Schritt für den Auftrag geplant, dabei werden Reparaturen vor Kalibrierungen bevorzugt, sodass doppelte Arbeiten minimiert werden. Wenn das Gerät im Wareneingang angekommen ist, wird der Auftragsstatus wieder durch die SAP-Integration aktualisiert, sodass die Techniker vor Ort jederzeit eine Übersicht über die anstehenden Aufgaben haben.

Wenn ein Gerät kalibriert werden soll, wird in der Webseite der Start-Button geklickt, dabei werden im Backend einige Aktionen ausgelöst:

1. Das Backend erzeugt eine Kalibrierung für den Job
2. Das Backend erkennt, welche Messplätze für den Job geeignet sind und wählt einen Messplatz aus
3. Das Backend erzeugt den Messjob im Kubernetes und bereitet den Datenablageort vor
4. Kubernetes Scheduler erzeugt den Container auf dem korrekten, dem Messplatz zugeordneten Rechner
5. Das Backend erzeugt eine Regel im Kubernetes, welche die Schnittstelle zwischen GUI und Kalibrierskript nach außen legt.
6. Der Kalibrier-Container lädt die korrekten Kalibrierskripte aus dem git herunter
7. Der Kalibrier-Container startet, lädt das Skript und startet die Kalibrierung. 6.1. notwendige Verbindungen zu den Standards werden automatisch hergestellt
8. Benutzer kann Kalibrierung durchführen

Kalibrierung erfolgreich

Bei einer erfolgreichen Kalibrierung lädt der Kalibrier-Container am Ende die Kalibrier-Roh-Daten zum Backend. Daraufhin startet das Backend die Erzeugung des Kalibrierscheines und aktualisiert den Auftragsstatus.

Kalibrierung fehlgeschlagen

Bei einer fehlgeschlagenen Kalibrierung kann der Nutzer entscheiden ob das Gerät repariert werden muss oder die Kalibrierung neu versucht werden soll. In beiden Fällen wird die angelegte Kalibrierung als fehlgeschlagen im Backend markiert. Falls es einen neuen Versuch geben soll, verbleibt der Auftrag im Status “Kalibrierung”.

Kalibrierscheinerzeugung

Die Kalibrierscheinerzeugung erfolgt asynchron und im Hintergrund, da in der Regel der Kalibrierschein nicht direkt bereit sein muss. Bei erfolgreichem Abschluss eines Auftrags schreibt das Backend einen Job in die Task-Queue, welcher vom Kalibrierscheinerzeuger ausgelesen wird. Wenn der Job beendet wurde, lädt die Kalibrierscheinerzeugung das erstellte Dokument zum Backend, welches den Kalibrierschein dann zum Download anbietet.