Quo vadis NI DIAdem?müller+krahmer GmbH

Quo vadis NI DIAdem?

/in /by

Heute vor 30 Jahren war mein erster Arbeitstag bei der GfS mbH in Aachen und auch der erste Tag, an dem ich mit der Software DIAdem in Kontakt gekommen bin. Seitdem ist meine gesamte berufliche Tätigkeit aufs engste mit diesem Produkt verbunden, das seit mehr als 25 Jahren zum Ökosystem von NI gehört. All die Jahre habe ich kontinuierlich mit DIAdem gearbeitet, Anwender in der Nutzung der Software geschult und hie und da auch deren Weiterentwicklung beeinflußt.

Bis heute bin ich von der Idee begeistert, alle für die Prüfautomatisierung und die Datenanalyse notwendigen Funktionen in einem (!) Produkt zu vereinigen und dabei aufgabenorientiert zu gliedern. Und ich bin auch überzeugt, daß für die meisten Anwender der Ansatz richtig ist, benötigte Funktionalität nicht programmieren zu müssen, sondern einfach konfigurieren zu können.

Was mir in der täglichen Arbeit, vor allem aber bei den Schulungen auffällt, die ich sowohl im Auftrag von NI als auch im Namen von müller+krahmer halte, ist ein Entwicklungstau an vielen Stellen im Programm. Als Begründung dafür mußte oft der komplette Wechsel auf die 64-Bit-Plattform herhalten. Ob er technisch wirklich notwendig war, vermag ich nicht zu sagen (in LabVIEW arbeiten wir weiterhin ausschließlich mit der 32-bit-Version), aber daß an vielen Stellen Änderungsbedarf besteht, daran habe ich keinen Zweifel. Zu den Punkten, die mir sofort einfallen, gehören:

  • Das Modul NAVIGATOR erlaubt es, vielfältigste Datenformate zu handhaben. Daß aber bei der automatischen Erzeugung von DataPlugIns, die die Schnittstelle zu nahezu beliebigen Dateitypen bilden, kein anpaßbarer Programmcode herauskommt, ist schwer verständlich.
  • Die Darstellung des TDM-Datenmodells im DIAdem-Datenportal liefert eine umfassende Übersicht der in den Daten enthaltenen Informationen. Daß aber beim Laden mehrerer Dateien die globalen Informationen aller Dateien mit Ausnahme der ersten verlorengehen, ist schlicht nicht sinnvoll zu erklären.
  • Warum die Module VIEW und REPORT für die graphische Darstellung getrennt sind, ist eine Frage, die fast jeder DIAdem-Neuling stellt, zumal jedes Modul über Funktionen verfügt, die im jeweils anderen schmerzlich vermißt werden.
  • Das Modul ANALYSIS bietet im mathematischen Bereich alles, was man in der täglichen Arbeit benötigt und wurde zuletzt um außerordentlich hilfreiche Funktionen wie die Ereignissuche erweitert. Wenn aber KI die Zukunft der Datenanalyse ist, was heute oft noch an der praktischen Nutzbarkeit scheitert, dann benötigt DIAdem eine KI-Integration, die eine einfache Anwendung auf die Daten ermöglicht – ohne Programmierung und aufwendige Installation von zusätzlicher Software.
  • Die Module DAC und VISUAL erlauben trotz jahrzehntelanger Vernachlässigung immer noch die Lösung zahlreicher einfacher Meß-, Steuerungs- und Visualisierungsaufgaben und werden weiterhin von vielen Anwendern genutzt. Gerade hier könnte DIAdem den größten Sprung nach vorn machen. Eine wirklich intuitive und vor allem direkte Einbindung der NI-Hardware einschließlich Zugriff auf Echtzeitplattformen, verbunden mit dem Zugriff auf aktuelle Feldbusprotokolle, würde den Anwendungsbereich schlagartig erweitern. Eine zeitgemäße und flexible Visualisierung könnte sogar für SPS-Anwender interessant sein, die von der umständlichen Bedienung z.B. in TwinCAT HMI, abgeschreckt werden. Da zudem NI mit LabVIEW eine graphische Entwicklungsumgebung hat, lohnt es darüber nachzudenken, ob das Modul DAC nicht besser mit einer textbasierten Programmierung angeboten werden sollte, wie dem in der SPS-Welt etablierten und in IEC 61131-3 standardisierten Structured Text – und natürlich echtzeitfähig. Schließlich wäre zu prüfen, ob DIAdem DAC bei konsequenter Weiterentwicklung die oft kurzlebigen Entwicklungen für easy-to-use Meßsoftware bei NI – wie SignalExpress und FlexLogger – ersetzen könnte.
  • Das DIAdem-Modul SCRIPT erlaubt nicht nur die Automatisierung typischer Abläufe, sondern in Verbindung mit einem sehr flexiblen Dialogeditor die Erstellung kompletter Applikationen mit individuellen Oberflächen. Die Erfahrung aus den Schulungen lehrt aber, daß die objektorientierte Programmierung für viele Anwender zu kompliziert ist. Der typische DIAdem-Anwender ist kein Programmierer und tut sich mit den Konzepten, wie sie früher in DIAdem verfolgt wurden, leichter. Aber auch ihm könnte man ganz leicht helfen, indem man die unübersichtliche Objektstruktur von vorherein zusammenfaßt.

Trotz aller Kritikpunkte bin ich und sind wir bei müller+krahmer vom DIAdem-Grundkonzept überzeugt. Wir nutzen deshalb DIAdem für vielfältigste Kundenapplikationen. Wir haben viele Defizite durch eigene Erweiterungen kompensiert (so durch Busschnittstellen, eine Echtzeiterweiterungen, DataPlugIns zum Laden und Speichern von Daten, oder Funktionen zur dynamischen Visualisierung in den scriptbasierten Anwenderdialogen), sind aber überzeugt, daß solche Funktionen für alle DIAdem-Anwender relevant sind und in den Standard-Funktionsumfang gehören.

Um die Zukunft von NI DIAdem zu sichern, reicht es jedenfalls nicht, wenn die Roadmap für die Weiterentwicklung nur einige marginale Positionen für jede neue Version enthält. Das Produktmanagement ist gefordert, eine echte Zukunftsvision entwickeln und wahrscheinlich muß der Sprung so groß sein wie der Wechsel vor 30 Jahren vom textbasierten DIA/DAGO unter DOS zum graphischen DIAdem unter Windows.

KONTAKT:
Holger Müller
E-Mail: mueller@mueller-krahmer.de
Mobil: 0160 / 287 7294