Prüfstandsoftware in vernetzten Datenstrukturen
Fachwissen vom Fachmann für Fachleute
Armaturenprüfstände als Teil digitaler Prozessketten
Software für Armaturenprüfstände gibt es seit ca. 20 Jahren. Und obwohl seit geraumer Zeit jede dieser Softwareanwendungen eine Datenbank besitzt, sind sie meist Insellösungen. Auch zeigt unsere Erfahrung als Prüfstandhersteller, dass die große Mehrheit der Anwender die Prüfstandsoftware lediglich als digitale Anzeige nutzt. Mittels eines neuen Systemansatzes und Dank flexibler Web Technologien lassen sich Armaturenprüfstände heute mit geringem Aufwand in digitale Prozessketten einbinden. Vom marktführenden Armaturenhersteller bis zum kleinen Servicebetrieb maximiert die neue Technologie auf die Effizienz der Prüfarbeit.
1. Wunsch und Wirklichkeit
Prüfstandsoftware fungiert meist als digitale Anzeige. Das ist durchaus nützlich, da sie zusätzlich zu digitalen „Manometern“ mit hoher Genauigkeit leicht ablesbare, nummerische Werte anbietet. Auch lässt es sich zwischen Sensoren leichter hin-und-her schalten als zwischen klassischen Manometern oder Durchflusssensoren. Das entspricht jedoch nur einem kleinen Teil des Funktionsumfangs, den sich das Entwicklerteam ausgedacht hat. Im Jahre 2004 wurde der Kundenwunsch formuliert, eine Software ohne Diagramme zu liefern, die im Grunde genommen nur ein „schönes, großes Manometer“ auf den Bildschirm bringt. Dem gegenüber stehen spannende Softwareideen und Konzepte von Geschäfts- und Produktionsleitungen. Die Praxis zeigt jedoch, dass nur sehr wenig der geschaffenen Funktionen am Ende zum Einsatz kommen.
Der Grund für die eingeschränkte Nutzung von Prüfstandsoftware liegt in der Natur der eigentlichen Prüfung selbst. Gibt es keine Software, bekommt der Prüfer einen Laufzettel, in dem er die Ergebnisse einträgt. Moderne Armaturenhersteller bieten dem Prüfer anstelle eines Laufzettels eine Maske aus der Unternehmenssoftware an, in die er die Ergebnisse einträgt. In jedem Fall bedient der Prüfer ein Drittsystem, das Ihm einen minimalen Zusatzaufwand zum eigentlichen Prüfprozess abverlangt. Alles Weitere betrifft ihn nicht.
Der Einsatz nicht vernetzter Prüfstandsoftware verlagert einen signifikanten Verwaltungsaufwand an den Prüfstand. Der Prüfer soll jetzt die Daten der Armatur korrekt eingeben und am Ende einen sauberen, unterschriebenen Prüfbericht abliefern. Seine Aufgabe wird um ein Vielfaches komplexer, denn er ist jetzt Software Bediener. Der erhöhte Zeitaufwand erzeugt Kosten, die im Budget der Prüfung eigentlich nicht vorgesehen sind. Darüber hinaus hat der Prüfer jetzt eine zusätzliche, neue Verantwortung für Dokumente und deren korrekten Inhalt. Solange es parallel zur Prüfstandsoftware ein verbindliches Drittsystem (Laufzettel, ERP System) gibt, liegt es in der Natur des Menschen, den die Prüfstandsoftware lediglich als digitale Anzeige zu verwenden.
2. Zeit für eine neue Herangehensweise
Bisher orientierte sich Prüfstandsoftware vor allem am Funktionsumfang der messtechnischen Aufgabe – je mehr desto besser. Die Praxis zeigt, dass die angebotenen Funktionen im Prüfalltag keine Rolle spielen und typischerweise nur von Entwicklungsabteilungen und der Qualitätssicherung genutzt werden. Um eine maximalen Nutzen zu bietet, muss die Softwarelösung zusätzliche zur eigentlichen Prüfung die Anforderung unterschiedlicher Interessensgruppen im Unternehmen erfüllen.
Prüfstandbediener – weniger ist mehr – „so einfach wie eine Smartphone App“
1. Minimale Anzahl von Eingaben
2. Minimale Anzahl an Klicks
3. Minimale Anzahl von Entscheidungen
Kostenrechnung – minimale Kosten
4. Wenig Zeitverzögerung
5. Nutzung vorhandener Daten
6. Minimale Nacharbeit
Qualitätssicherung – Konkrete, belastbare Prozesse, wenig Freiheit für den Prüfer
7. Festlegung, wie das Ergebnis ermittelt wird
8. Festgelegte bestanden/durchgefallen Richtlinien
Dokumentenmanagement
9. Fertige Berichte für die Endkundendokumentation.
Netzwerke und Datenbanksysteme sind heute Stand der Technik. Die Informationen zum Prüfling liegen vor. Auch im Serviceumfeld liegen Excel Tabellen mit den Daten der Prüflinge vor. Den Prüfstand über seine Software in die digitale Prozesskette einzubinden, vorhandene Daten direkt zu nutzen und Ergebnisse und Prüfberichte der Prozesskette zurückzugeben, ist der logische nächste Schritt in der Entwicklung der Prüfstandsoftware. Damit dies gelingt und damit die Anforderungen der Interessensgruppen im Unternehmen erfüllt werden, sind drei Herausforderungen zu bewältigen.
I. Anbindung an vorhandene Datenquellen
II. Rückgabe fertiger, digitaler Berichte und relevanter Daten
III. Anpassung und Teilautomatisierung nach Kundenbedürfnis
3. Datenimport über Web Services
Beinahe alle Prüfstandsoftwarelösungen auf dem Markt beinhalten eine Datenbank. In vernetzten Datenstrukturen bestünde somit seit vielen Jahren die Möglichkeit, Daten zwischen der Prüfstandsoftware und der Unternehmensdatenbank auszutauschen. Der Grund, warum das nicht geschieht, liegt in der Komplexität der Inter-Datenbank-Kommunikation. Die hierzu notwendigen Technologien gehören zur Königsklasse der Programmierung und Administration. Die daraus resultierende Hürde ist für das Einsatzumfeld „Prüfstand“ meist zu hoch.
Umgangen wird diese Hürde durch die Implementierung der weitverbreiteten Internet Technologie „Web Services und XML“ als zusätzliche Möglichkeit für Datenzugriffe. METRUS CRS greift sowohl direkten auf die „eigene“ Datenbank zu als auch über Web Services auf „externen“ Unternehmensdatenbanken. Der Datenzugriff über Web Services läuft dabei folgendermaßen ab:
- Der Prüfer gibt z.B. Die Auftragsnummer oder Armaturen ID am Prüfstand ein und klickt auf den Button „XML Import“.
- Die METRUS CRS Software sendet diese Suchdaten an den Web Service.
- Der Web Service findet alle relevanten Details in der Unternehmensdatenbank
und gibt diese als XML Datei an die METRUS CRS Software zurück.
Die Datenzusammenstellung beinhaltet typischerweise Armaturenkenndaten, Grenzwerte, sowie zusätzliche Auftragsdaten für den Prüfbericht. Das Prinzip gleicht der Ausgabetheke einer Bibliothek. Der Leser (METRUS CRS) entscheidet, welches Buch er möchte und teilt dies dem Bibliothekar an der Theke (Web Service) mit. Der Bibliothekar kennt die endlosen Regale der Bibliothek, findet das Buch und überreicht es dem Leser an der Theke.
So wie der Leser an der Ausgabetheke das Ablagesystem der Bibliothek nicht kennt, so kennt auch die METRUS CRS Software die Unternehmensdatenbank nicht, aus der die Informationen bezogen werden. Gleichgültig aus welchem System die Daten auch stammen mögen, der Ablauf in der METRUS CRS ist immer gleich. Sprich, für die Anbindung der Prüfstandsoftware ist keine Anpassungsprogrammierung notwendig. Es genügt, an vorgesehener Stelle die Verbindungsdaten des Web Services einzutragen. Als schlanke Internettechnologie sind Web Service und XML prädestiniert für den Einsatz in weitverzweigten Unternehmensnetzwerken mit mehreren Standorten.
4. Der Web Service als Projekt des Administrators
Der Web Service selbst besteht aus zwei Teilen – einem Webserver und einem darauf ausgeführten PHP Script. Ein „Webserver“ ist eine kostenlose Software, die auf einem der Server des Unternehmens läuft. Das am weiten verbreitetste Server Betriebssystem „Windows Server“ beinhaltet immer den sog. „IIS – Internet Information Service“ als kostenlose Webserversoftware. Der Webserver ist somit vorhanden bzw. auch für jedes andere Server Betriebssystem kostenlos verfügbar.
Das PHP Script ist eine Textdatei die eine Liste von Befehlen und Anweisungen beinhaltet. Die Befehle und Anweisungen stellte der Webserver zur Verfügung. So wie z.B. ein MS Word Dokument zum Bearbeiten die Software MS Word benötigt, so benötigt das PHP Script zur Ausführung den Webserver. „PHP“ bezeichnet den Name der Scripting Sprache so wie beispielsweise „Java“ oder „Visual Basic“.
Einzige kundenspezifische Aufgabe ist es, das PHP Script zu erstellen das auf die Unternehmensdatenbank zugreift und aus den gefundenen Daten ein XML Dokument erzeugt. Nachdem das genaue Format der XML Datei durch METRUS CRS fest vorgegeben ist, reduziert sich die zu lösende Aufgabe auf das Auffinden der gewünschten Informationen in der Unternehmensdatenbank.
„PHP Script“ gehört zum Repertoire vieler Administratoren und ist das Einmaleins jedes Webdesigners. Das Fachwissen ist folglich im Unternehmen bereits vorhanden oder zu überschaubaren Kosten bei Webdesignern zu beziehen. Das Projekt „Datenbankanbindung des Prüfstandes“ reduziert sich somit auf ein Administrationsprojekt in Eigenregie.
5. Minimalismus als zweite Bedingung
Nach erfolgreicher Anbindung der Prüfstandsoftware an die Unternehmensdatenbank muss der Bediener keine Daten mehr eintippen. Das erspart in erster Linie Mühe (Zeit) und senkt somit Kosten. Die Komplexität der Aufgabe ist damit jedoch nur bedingt gemindert. Vergleichbar wichtig für die Akzeptanz einer Software ist deshalb die Einfachheit der Bedienung. Ziel ist es, die notwendige Anzahl der Klicks und vor allem die Anzahl der zu treffenden Entscheidungen zu minimieren. Die Software sollte lediglich die Funktionen und Entscheidungen umfassen, die für den individuellen Anwendungsfall tatsächlich notwendig sind – „weniger ist mehr“.
Eine klassische Prüfstandsoftware beinhaltet einen maximalen Funktionsumfang, aus dem sich der Benutzer die für ihn sinnvollen Funktionen herauspickt. Sonderwünsche machen kundenspezifische Softwareprojekte notwendig, die üblicherweise das Budget des Prüfstandes übersteigen. Der Wunsch nach sehr speziellen Funktionen einerseits und die Forderung einer „auf das Wesentliche reduzierten“ Software andererseits wird in METRUS CRS durch eine spezielle Architektur gelöst. Die Benutzeroberfläche und sämtliche Berechnungen sind durch Scripts realisiert und somit nicht in der „unveränderlichen“ exe-Datei festgelegt. Ein Skript ist eine Datei, die sich mit einem einfachen Texteditor öffnen und bearbeiten lässt. Die Anpassung von Berechnungen oder Funktionen erfordert somit kein eigenständige, kundespezifische Software, sondern lediglich eine geringfügig modifiziertes Script.
Bild 2 zeigt den Standardumfang der METRUS CRS als klassische Insellösung. Der Prüfer tippt alle Daten und Prüfparameter manuell ein, startet die Aufzeichnung und wertet nach Durchführung der Prüfung am Prüfstand das Diagramm manuell aus, bevor er den Datensatz speichert und abschließend eine PDF Datei erzeugt, die er gemäß Vereinbarung unter einem speziellen Dateinamen an geeignetem Ort speichert. Dabei bewegt er sich durch mehrere Auswahl- und Eingabemasken.
Bild 3 stellt den über Datenintegration und Scripting optimierten Ansatz dar. Der Prüfer gibt die Seriennummer der Armatur ein und klickt auf den XML Button. Er startet die Aufzeichnung und führt den Prüfvorgang am Prüfstand durch. Abschließend klickt er auf den PDF Button und ist fertig. Während des gesamten Vorganges bewegt er sich ausschließlich in einer Softwaremaske, tätigt eine Dateneingabe und bedient vier Buttons.
Über Web Services werden im ersten Schritt alle relevanten Details und Grenzwerte aus der Unternehmensdatenbank geladen und die Prüfparameter berechnet. Das „Script vor Beginn der Aufzeichnung“ ermittelt die Aufzeichnungsdauer. Das „Script nach Beendigung der Aufzeichnung“ setzt die Auswahlpunkte. Im Fall der Gehäuseprüfung z.B. den „Startpunkt“ auf den Maximalwert und den „Endpunkt“ auf den letzten Wert der Aufzeichnung. Der Klick auf den PDF Button löst ebenfalls ein Skript aus, das folgende Schritte im Hintergrund abarbeitet.
- Prüfen ob alle Prüfungen bestanden sind (wenn nicht mit Meldung abbrechen)
- PDF Prüfbericht erzeugen
- Dateinamen aus dem Inhalt einiger Datenfelder bilden
- PDF Datei in einem festgelegten Netzwerkpfad speichern
- Prüfdatensatzes als „Log“ in der lokalen Datenbank der METRUS CRS speichern
- Meldung „Bericht gespeichert“
Die hier zum Einsatz kommenden Scripts sind notwendige Bestandteile der Standardsoftware. Sie werden folglich nicht speziell für diese Lösung geschaffen, sie werden lediglich modifiziert.
6. PDF Prüfbericht als Teil der nachgeschalteten Prozesskette
Das digitale Endergebnis der Armaturenprüfung ist ein Bericht im PDF Format. Bei geeigneter Gestaltung ist dieser direkt Bestandteil der zu liefernden Armaturendokumentation. Die digitale Prozesskette ist damit jedoch nicht immer abgeschlossen. Je nach Komplexität der Anforderungen sind zwei weitere Schritte notwendig – Digitale Signatur und Rückgabe geeigneter Prüfdaten.
Viele Unternehmen drucken Prüfberichte auf Papier, um sie unterschrieben wieder einzuscannen. Der Prüfbericht hat Dokumentenstatus weshalb er erst durch die Unterschrift des Prüfers und ggf. das Gegenzeichnen eines Sachverständigen Gültigkeit erlangt. Damit die digitale Prozesskette hier nicht scheitert, beinhaltet METRUS CRS die Funktion der digitalen Signatur (siehe Bild 4).
Bei Verwendung dieser Funktion, öffnet sich unmittelbar vor dem Erzeugen der PDF Datei ein Fenster. Der Prüfer unterzeichnet auf dem „Signature Pad“ und bestätigt seine Eingabe. Für Sachverständige oder Kundenabnahmen steht ein zweites Unterschriftsfeld zur Verfügung. Das Ergebnis ist ein digital unterzeichneter Prüfbericht.
In umfangreichen Unternehmensdatenbanksystemen mit integriertem Dokumentenmanagement endet die digitale Prozesskette erst damit, dass dem System die erfolgreiche Durchführung der Prüfung „gemeldet“ wird. Wie bei der Datenübernahme kommt auch bei der Rückgabe von Daten ein Web Service zum Einsatz, den der Anwender nach eigenen Bedürfnissen gestaltet. Die METRUS CRS sendet ein XML Dokument an den Web Service, der die darin enthaltenen Informationen in die Unternehmensdatenbank schreibt. Relevant sind hierbei vor allem der Pfad zum PDF Prüfbericht in Kombination mit einer Armaturen ID, einer Auftragsnummer und dem Prüfdatum. Diese Daten schaffen einen direkten Zugriff auf den Prüfbericht aus der Unternehmenssoftware heraus.
7. Datenimport aus Excel – die „kleine“ Lösung
Ein Web Service ist dann effizient, wenn die Armaturen- und Auftragsdaten in einem Unternehmensdatenbanksystem vorhanden sind. Gerade im Service Umfeld ist dies nicht der Fall. Die Vorteile der Scripting Technologie und der Automatisierung vom Start der Prüfung bis zum fertigen Prüfbericht auf dem Server bieten hier jedoch dieselben Vorteile wie für große Unternehmen.
Die Datenimportsoftware FlowHeater bildet den erste Schritt der digitalen Prozesskette als manueller Vorgang ab. Dazu bringt die Arbeitsvorbereitung die verfügbaren Daten der Armaturen und ggf. die Kundenliste in ein geeignetes Excel Format und lädt sie anschließend über das Netzt in die METRUS CRS Datenbank. Die Eingabearbeit am Prüfstand reduziert sich jetzt auf das Auswählen von Armatur und Kunde aus jeweils einer Liste. Der weitere Ablauf ist anschließend derselbe wie bei zuvor beschriebener, direkter Datenbankanbindung über Web Services.
Die Vernetzung digitaler Systeme sichert mittel- und langfristige die Wettbewerbsfähigkeit jedes Unternehmens. Der Prüfstand als abschließender Schritt der Armaturenherstellung- und Wartung ist somit prädestiniert dafür, Bestandteil der digitalen Prozesskette zu sein.
Autor:
Johannes Junior
Geschäftsführer
Neugierig geworden? Noch Fragen? Kontaktieren Sie uns über unser Kontaktformular.