Changelog
Produkt-Meilensteine des V.A.D. IIoT-Ökosystems, Release für Release — neue Plattformmodule, Integrationen, Sprachen und Zuverlässigkeitsarbeit.
Monitoring, Rollen und neue Anbindungswege
Drei parallele Stränge: ein Monitoring-Dienst mit gemeinsamem Detektorverzeichnis und einer Ereignistabelle, ein Autorisierungsmodell auf Policy-Objekten sowie neue Wege, ein Gerät oder eine Region anzubinden — Proxy-Modus und ein regionales Compliance-Paket.
- Neu
Gemeinsames Detektorverzeichnis und eine Ereignistabelle
Problemereignisse kommen aus mehreren Quellen: Erfassungsdienst, Ingestionsmodul, geplante Prüfungen, KI-Analyse. Der Dienst führt sie auf zwei Entitäten zurück — ein Detektorverzeichnis, das festlegt, was als Problem gilt und zu welchem Dienst und welcher Bereitschaftsgruppe es gehört, und eine Ereignistabelle, in die jede Quelle schreibt. Dashboards, Filter und Berichte lesen sie direkt, sodass die Zahl offener Probleme überall dieselbe ist.
Mehr erfahren - Zuverlässigkeit
Marker für auffällige Sitzungen bereits bei der Übernahme
Eine Sitzung wird in dem Moment bewertet, in dem sie in die Datenbank geschrieben wird. Die Regeln sind Schwellwerte: Kontakt mehr als 15 Minuten vor Plan, Spannungsabfall der Telemetriebatterie um mehr als 0,1 V gegenüber der vorherigen Sitzung, der Metrologiebatterie um mehr als 0,05 V, auffällige Verbindungsdauer. Die Sitzung erhält einen Marker, und die Tagesübersicht entsteht aus Markern statt aus einem erneuten Archivdurchlauf — der Prüfaufwand wächst nicht mit dem Bestand.
- Sicherheit
Zugriffsregeln auf Policy-Objekten
Das Zugriffsmodell basiert auf Policy-Objekten: eine Klasse je Ressource, normale Methoden statt einer DSL. Eine Rolle wird als Satz benannter Berechtigungen mit Aktiv- und Standard-an-Flags beschrieben, sodass der Rechteumfang je Installation ohne neuen Build konfiguriert wird. Eine Policy bleibt ein gewöhnliches Objekt und wird per Unit-Test geprüft statt über einen End-to-End-Lauf im Web.
Mehr erfahren - Integration
API-Controller und -Views in den v3-Namensraum überführt
Der öffentliche Vertrag bekommt einen eigenen Namensraum: Controller und Repräsentationen ziehen nach v3 um, v1 bleibt als kompatibler Einstiegspunkt eingefroren. Brechende Änderungen passieren nur im neuen Namensraum, sodass sich die API weiterentwickeln kann, ohne mit jedem Integrator abzustimmen. Antworten sind lokalisiert — Verzeichnisse und Textbeschreibungen kommen in der Sprache des anfragenden Nutzers zurück.
Mehr erfahren - Integration
Ein dritter Betriebsmodus für Geräte — Proxying
Ein Gerät arbeitet mit zwei Servern: einem führenden und einem Standby. Ein dritter Modus ergänzt das Proxying — der Erfassungsdienst nimmt die Verbindung an und reicht die Daten weiter, bleibt für das Gerät aber transparent. Damit sind Standorte ohne direkte Route zur Plattform abgedeckt. Der Modus wird sowohl auf dem Erfassungsserver als auch in der Oberfläche angezeigt, sodass bei der Analyse einer Verbindung klar ist, welchen Weg die Daten genommen haben.
Mehr erfahren - Performance
Letzte Sitzung und Zählermodell im Telemetrie-Datensatz gecacht
Die letzte Kommunikationssitzung und ein Verweis auf das Zählermodell liegen im Cache neben dem Telemetrie-Datensatz — Batteriespannung, Sitzungsstatuscode, Maßeinheiten. Bestandsweite Listen und Filter bedient eine einzige Abfrage, statt für jeden Bildschirm ins Archiv zu greifen; die Antwortzeit bleibt damit unabhängig von der Tiefe der Historie. Der Cache wird bei der Datenübernahme aktualisiert, sein Verzug ist also durch die Kommunikationssitzung begrenzt, nicht durch ein Neuberechnungsfenster.
- Neu
MENA Compliance Pack
Die Anforderungen der Länder gehen auseinander, überschneiden sich aber in einem Kern: IoT-Regeln, Cybersicherheit, Schutz personenbezogener Daten, Vorgaben zum Cloud-Hosting, industrieller Betrieb. Das Paket fixiert diesen gemeinsamen Kern und verlagert die Unterschiede in Länderanhänge; die Installationskonfiguration verweist auf den passenden Anhang. Das Dokument beantwortet die Frage der Anwendbarkeit vor dem Pilotstart — adressiert an Kunden, lokale Partner, Systemintegratoren und Behörden.
Verlässliche und lesbare Gerätedaten
Gerätedaten werden gegen die Protokollspezifikation ausgewertet: Bitmasken werden bitweise dekodiert, Codes hexadezimal dargestellt und Archivbeschreibungen vom Anlagenzustand her formuliert. Das gesammelte Archiv wurde nach derselben Logik neu berechnet.
- Zuverlässigkeit
Bitweise Auswertung der Statusmasken in Ereignis- und Alarmjournalen
Die Ereignis- und Alarmstatusfelder des Type-M-Protokolls sind 16-Bit-Masken: Bit 1 steht für schwache Batterie, Bit 2 für schwaches GSM-Signal, Bit 15 (32768) für einen Geräteneustart. Die Auswertung geht die Bits durch und gleicht sie mit den Firmware-Schwellen ab: Das Ereignis „schwache Batterie“ wird unter 11,7 V gesetzt und über 12,0 V zurückgenommen, mit 300 mV Hysterese. Journalbeschreibungen entstehen aus den dekodierten Bits, und das gesammelte Archiv wurde nach derselben Logik neu berechnet — 7 872 Datensätze aktualisiert, 112 924 ergänzt.
- Verbessert
Neu geschriebene Reiterbeschriftungen und Ereignistexte in Gerätearchiven
Die Texte in den Archiv-Reitern gehen vom Anlagenzustand aus statt von den Paketfeldern: Eine Beschreibung sagt, was mit dem Gerät geschehen ist. Reiterbeschriftungen wiederholen nicht den Abschnittsnamen, und die Statusspalte heißt „Flags“ — passend zu ihrem Inhalt. Werte erscheinen in dicktengleicher Schrift, sodass die Spaltenbreite nicht von der Länge eines Werts abhängt.
Mehr erfahren - Verbessert
Alarm- und Ereigniscodes in Hexadezimaldarstellung
Alarm- und Ereigniscodes erscheinen hexadezimal: 0x8000, 0x0001, 0x0000 — mit führenden Nullen auf vier Stellen aufgefüllt. Eine dicktengleiche Schrift richtet die Stellen zeilenübergreifend vertikal aus, sodass das gesetzte Bit sofort ins Auge fällt und ohne Umrechnung aus dem Dezimalsystem mit der Protokollspezifikation abgeglichen werden kann.
- Verbessert
Tabellenzustand: Seitengröße, Einheiten und Wiederholungscodes
Datentabellen behalten ihren Zustand über die Navigation hinweg: Die gewählte Seitengröße bleibt erhalten. Einheiten sind aus dem Spaltenkopf zum Wert selbst gewandert — der Kopf bleibt kurz, die Einheit steht dort, wo die Zahl steht. Der Wiederholungszähler zeigt Anzahl der Versuche und Ursachencode, sodass sich die Verbindungsqualität direkt aus der Tabelle ablesen lässt.
- Performance
Profiling der Übernahme-Warteschlange im Hintergrundjob-Server
Die Hintergrund-Datenübernahme wurde stufenweise profiliert und über die Worker neu ausbalanciert. Ablesungen landen unmittelbar nach der Kommunikationssitzung im Archiv, und die Warteschlange hält mit wachsendem Bestand Schritt — Jobs werden schneller abgearbeitet, als sie eintreffen, und der Durchsatzspielraum ist im Übernahme-Log sichtbar.
Mehr erfahren
Industrieller Betrieb
Das erste Produktions-Release der dritten Generation: Ein Betreiber führt damit seinen laufenden Zählerbestand durchgängig — Erfassung, Speicherung, Weboberfläche, API und Analytik. Darüber läuft das Betriebszentrum, und die Sitzungsparameter sind in den gemeinsamen Archivspeicher umgezogen.
- Neu
Version 3.0: die erste industrielle Produktivumgebung
Die dritte Generation verlässt den Vorabstatus: Ein industrieller Betreiber betreibt darauf seinen laufenden Zählerbestand. Erfassungsdienst, Speicher, Weboberfläche, öffentliche API und Analytik arbeiten in einer Umgebung. Die Übergangsphase mit dem Parallelbetrieb zweier Generationen ist abgeschlossen.
Mehr erfahren - Neu
Betriebszentrum (OHM)
Ein Strom roher Alarme wird zu gesteuerten operativen Vorgängen. Detectors und kanonische Probleme fassen wiederkehrende Ereignisse zu einem Vorgang zusammen, die Korrelation ordnet ihm die Evidence zu, die Zustandsbewertung der Assets ordnet den Bestand nach Risiko, Prioritäten und SLA setzen die Reaktionsfrist, und die Arbeitswarteschlange hält die Arbeit bis zum Abschluss. Massive Incidents — ein Ausfall, der Hunderte Alarme auslöst — werden gesondert behandelt. Eine AI-Schicht schlägt den nächsten Schritt aus der gesammelten Historie ähnlicher Fälle vor.
Mehr erfahren - Verbessert
GSM-Signalpegel in einer einheitlichen dBm-Skala gespeichert und angezeigt
Der GSM-Signalpegel wird in einer einheitlichen dBm-Skala gehalten, unabhängig davon, in welcher Einheit ihn das Geräteprotokoll liefert — in Prozent, in relativen Einheiten oder bereits in dBm. Die Umrechnung liegt in den Übernahme-Treibern und läuft am Eingang, nicht bei der Anzeige, deshalb steht in Oberfläche, API und Berichten derselbe Wert. Die gesammelten Daten sind auf dieselbe Skala überführt, und der Abdeckungstrend lässt sich über die gesamte Bestandshistorie lesen.
- Zuverlässigkeit
Historische Kommunikationssitzungen in das v3-Schema überführt
Migrationsbefehle überführen die Historie der Kommunikationssitzungen in das Schema der dritten Generation. Die Übernahme läuft stufenweise: zuerst die eigenen Sitzungskanäle des Geräts, dann die gemeinsamen Kanäle der Telemetrieeinheit, dann die Angleichung an das Parameterschema. Die Befehle werden je Server einzeln gestartet und arbeiten in Portionen, sodass die Erfassung weiterläuft und Diagramme wie Berichte die gesamte Gerätehistorie abdecken.
- Performance
Sitzungsparameter in die gemeinsame Archivtabelle ausgelagert
Die Sitzungsköpfe bleiben in ihrer eigenen Tabelle, die Sitzungsparameter werden in die gemeinsame Archivtabelle geschrieben — dorthin, wohin auch die Ablesungen gehen. Welche Parameter das sind, deklariert das Protokoll: Type-M hat einen Kanalsatz, Type-J einen anderen, MQTT einen dritten. Ein neuer Gerätetyp entsteht durch Einträge im Kanalverzeichnis, ohne Migration des Datenbankschemas.
Mehr erfahren
Druck- und Temperatursensoren: der gesamte Weg
Eine neue Geräteklasse vom Protokoll bis zur Karte in der Oberfläche: Treiber, Datenmodell, Archivübernahme, Sensortyp-Verzeichnisse, Maßeinheiten. Dazu die Datenmodell-Verknüpfungen, auf denen Berichte, Filter und Zugriffsregeln beruhen.
- Neu
Druck- und Temperatursensoren: Treiber, Modell, Archive, Gerätekarte
Eine neue Geräteklasse wird auf dem gesamten Weg unterstützt. Im Erfassungsdienst steht ein Protokolltreiber: Identifikationspaket der autonomen Einheit, aktuelle Werte, Archive, Konfiguration. In der Anwendung stehen Datenmodell und Ablage: aktueller Druck und aktuelle Temperatur, Archivschnitte, Parameter der Kommunikationssitzung, Konfigurations-Snapshot. In der Weboberfläche erhält das Gerät eine eigene Karte mit einem auf den Sensor zugeschnittenen Feldsatz.
Mehr erfahren - Verbessert
Verzeichnis der Sensortypen und Kalibrierkoeffizienten des Sensors
Der Sensortyp stammt aus einem Verzeichnis von Messbereichen — Absolutdruck 0…160 kPa, 0…400 kPa, 0…600 kPa, 0…1,0 MPa, 0…1,6 MPa, 0…2,5 MPa und weiter laut Spezifikation —, das in dritter Normalform mit dem Gerätemodell verknüpft ist. Der Ablagetreiber bestimmt den Typ bei der Geräteidentifikation, sodass Messbereich und Einheiten dem System bekannt sind und nicht allein dem Monteur. Der Parameter-Reiter zeigt die Kalibrierkoeffizienten des verbauten Sensors.
Mehr erfahren - Verbessert
Gewählte Maßeinheiten in allen Darstellungen eines Werts
Die gewählte Maßeinheit wird auf der Darstellungsebene angewendet und gilt in allen Ansichten des Werts — Kachel des aktuellen Drucks, Diagramm, Datenjournal, Alarmjournal. Dazu gehört die Umrechnung von Absolut- in Überdruck: Ein Schalter aktiviert sie, und sie greift nur bei Sensoren mit absoluter Messung. Die Genauigkeit ergibt sich aus dem Sensor — Temperatur mit einer Nachkommastelle, Millimeter Quecksilbersäule ohne Nachkommastelle.
- Zuverlässigkeit
Vollständigkeitsprüfung des Konfigurationsarchivs vor dem Schreiben in die Datenbank
Die Verbindung zu einem Gerät kann mitten in der Übertragung abreißen, deshalb wird das Konfigurationsarchiv vor dem Schreiben in die Datenbank auf Vollständigkeit und Integrität geprüft. Ein nur teilweise eingesammelter Snapshot tritt nicht an die Stelle des bestehenden Stands. Neben den Ablesungen wird das Ereignisarchiv abgelegt. So hinterlässt selbst eine abgebrochene Kommunikationssitzung eine Spur für die Auswertung.
- Verbessert
Messeinheit und Versorgungsunternehmen als Beziehung auf Modellebene
Die Zugehörigkeit einer Messeinheit zu einem Versorgungsunternehmen ist als explizite Beziehung auf Ebene der Datenbank und der Datenmodelle festgeschrieben. Vorhandene Datensätze übernehmen Migrationsbefehle. An dieser Beziehung hängen Berichtsauswahlen, Facettenfilter und Zugriffsregeln. Sie entstehen unmittelbar aus der Organisationsstruktur, samt deren Änderungen bei Reorganisationen.
Mehr erfahren - Verbessert
Datumsfilter und Export auf dem Reiter der übertragenen Daten
Das Journal der übertragenen Daten erhält dieselbe Werkzeugleiste wie die übrigen Archiv-Reiter. Sie umfasst einen Zeitraumfilter und den Export als Datei. Eine Auswahl für das gewünschte Intervall geht direkt aus der Oberfläche an angrenzende Fachbereiche, ohne Umweg über die Datenbank.
Mehr erfahren - Zuverlässigkeit
Armaturenstellung synchron mit den Endlagensensoren des Antriebs
Die Stellungen „geschlossen“ und „offen“ werden von den Endlagensensoren des Antriebs eindeutig erfasst. Die Oberfläche zeigt genau die Stellung, die diese Sensoren bestätigen, und hält die Bedienung aktiv. Der Zustand wird nach der ersten Inbetriebnahme, nach manuellem Verstellen und nach Servicearbeiten abgeglichen — der Bediener sieht die tatsächliche Stellung in der Anlage.
Externe Abnahme und ein neu gebauter Datenkern
Die Plattform durchlief die externe Abnahme: Die Szenarien wurden von externen Fachleuten gefahren, ihre Befunde vor dem Release Candidate abgearbeitet. Parallel wurde der Datenkern entkoppelt — ein Verbraucher kann von mehreren Versorgern beliefert werden, und das Telemetriemodul wird unabhängig von der IMEI beschrieben.
- Neu
Umbau des Datenkerns: Verbraucher und Telemetriekanal
Der Datenkern ist auf die Aufgaben der dritten Generation zugeschnitten: Ein Verbraucher kann von mehreren Versorgungsunternehmen beliefert werden, und ein Telemetriemodul wird unabhängig von der IMEI beschrieben. Beide Entkopplungen liegen auf Schemaebene und sind gelegt, bevor die übrige Funktionalität darauf aufsetzt. Damit erhält die dritte Generation ein eigenes Datenmodell, ausgelegt auf Lieferantenwechsel und auf mehrere Energieträger bei einem Verbraucher.
Mehr erfahren - Integration
Telemetriemodul aus Kanaltyp und Identifikator
Ein Telemetriemodul wird über zwei Felder beschrieben: den Kanaltyp — GSM, Ethernet, MQTT, Datenkonzentrator, LoRaWAN — und einen Identifikator der passenden Art: IMEI, IP, MAC, client_id, DevEUI. Controller, Berichte, Exporte, Dienste und die API folgen dem erweiterten Modell. Ein neuer Übertragungsweg kommt damit als Wert einer Nachschlagetabelle hinzu, an einer einzigen Stelle des Schemas.
Mehr erfahren - Zuverlässigkeit
Eine Welle externer Abnahmetests der Plattform
Die Plattform durchlief eine externe Abnahmeprüfung auf einer Demo-Umgebung: Die Szenarien durchliefen nicht die Entwickler, sondern externe Fachleute. Anmerkungen zum Objektassistenten, zu den Formularen, den Facettenfiltern, den Zeitplänen und der Lokalisierung von Benachrichtigungen wurden aufgearbeitet und vor dem Release Candidate geschlossen. Die externe Abnahme ist als verbindliche Stufe vor jeder Auslieferung im Zyklus verankert.
- Verbessert
Bearbeitbare Betriebsintervalle der Steuereinheit des Antriebs
Die Betriebsintervalle der Steuereinheit des Antriebs werden aus der Oberfläche heraus bearbeitet. Die Voröffnungszeit liegt im Bereich 1–30 s, die Pause zur Druckstabilisierung bei 30–600 s, die volle Hubzeit richtet sich nach der Antriebsspezifikation. Die Werte werden in Sekunden mit einer Nachkommastelle erfasst und gegen diese Bereiche geprüft, sodass Einheit und Genauigkeit im Formular dem Datenblatt des Geräts entsprechen.
Mehr erfahren - Verbessert
Lösen des Geräts von der Messeinheit ohne Verlust der Historie
Ein Gerät wird von der Messeinheit gelöst und bleibt mit seinen Daten im System. Austausch, Umsetzung und Rückkehr aus der Reparatur werden als Buchungsereignisse erfasst. Die Historie der Messeinheit und die Historie des Geräts bleiben dadurch durchgängig und zugleich trennbar.
Mehr erfahren - Sicherheit
Statische Sicherheitsanalyse der Codebasis der Anwendung
Der Quellcode durchläuft eine statische Analyse auf die typischen Schwachstellenklassen von Webanwendungen. Jeder Treffer wird von Hand bewertet: Das Werkzeug kennt den Kontext nicht, ein Teil wird daher als Fehlalarm aussortiert, der Rest vor der Auslieferung geschlossen. Der Lauf ist in die Release-Prozedur eingebettet und wiederholt sich bei jedem Build.
Mehr erfahren - Sprachen
Plattform und Geräte in 13 Sprachen
Die Dokumentation der Plattform v3, die IIoT-Gerätepalette und die gesamte Portaloberfläche erscheinen in 13 Sprachen. Arabisch und Persisch sind mit Rechts-nach-links-Schrift eingebunden: Gespiegelt wird das komplette Layout, nicht nur die Textrichtung. Eine Seite, die noch in der Übersetzungsschlange steht, wird unter ihrer lokalisierten URL auf Englisch ausgeliefert und mit noindex gekennzeichnet, sodass der Sprachwechsel stets auf eine vorhandene Seite führt.
Mehr erfahren - Integration
Auto-Registrierung der dritten Generation für die gesamte unterstützte Palette
Die Auto-Registrierung der dritten Generation deckt die gesamte unterstützte Palette ab, einschließlich der über MQTT gesteuerten Absperrarmaturen. Ein am Objekt eingeschaltetes Gerät legt seine Messeinheit selbst an und steht sofort zum Auslesen und Steuern bereit. Die Kennung reist im Gerätepaket mit, sodass die Montage plattformseitig ohne manuelle Eingabe auskommt.
Mehr erfahren
Der V3-Stack im Industrieumfeld
Erfassungsdienst und Datenspeicher der dritten Generation wurden beim ersten Industriekunden ausgerollt und nahmen Live-Ablesungen entgegen. Die öffentliche API wurde gegen das neue Datenmodell geprüft, und das Dokumentationsportal ging online.
- Neu
AI Analytics: 22 Berichte mit offener Methodik und Formeln
Das Modul AI-Analytik: 22 Berichte zu einzelnen Knoten und zur Flotte als Ganzes — Bilanzen, Druckanomalien, Prognose der Batterielebensdauer, Aufspüren von Zählerumgehungen, Fehleratlas. Methodik und Formeln jedes Berichts sind veröffentlicht: Es ist ersichtlich, auf welchen Feldern und Annahmen eine Aussage beruht, und der Wert lässt sich von Hand nachrechnen. Damit taugt ein Bericht für die Besprechung mit dem Kunden und für die Aufnahme in die Regeldokumentation.
Mehr erfahren - Neu
Illustriertes Benutzerhandbuch mit echten Screenshots in hellem und dunklem Design
Eine Schritt-für-Schritt-Anleitung zur Arbeit mit der Plattform auf echten Oberflächen-Screenshots im hellen und im dunklen Design. Beide Serien sind aus ein und demselben Datenstand aufgenommen, damit die Schritte in beiden Designs übereinstimmen. Die Daten auf den Screenshots sind anonymisiert, deshalb lässt sich die Anleitung ohne gesonderte Freigabe nach außen geben.
Mehr erfahren - Neu
IIoT-Plattform v3: Architektur, Skalierung und Konformität mit EU-Richtlinien
Ein Major-Release der Dokumentation: Architektur, Skalierung und Konformität mit den EU-Richtlinien sind für die dritte Generation beschrieben. Version 3 ist die aktuelle, und die Root-Weiterleitungen führen dorthin. Die zweite Generation bleibt über direkte Links und den Versionsumschalter erreichbar.
Mehr erfahren - Performance
Register der Messeinheiten: Tabelle, kaskadierende Filter, gespeicherte Auswahlen
Das Register der Messeinheiten ist auf einen Bestand von Tausenden Einträgen ausgelegt: paginierte Tabelle mit Aktionsleiste, kaskadierende Facettenfilter und gespeicherte Benutzerfilter. Die Wahl eines Werts in einer Facette berechnet die zulässigen Werte in den übrigen neu, sodass keine Kombination in einer leeren Auswahl endet. Die Seite einer Einheit ist aus zwei Panels mit Reitern und Karten aufgebaut.
Mehr erfahren - Verbessert
Einheitliches Dokumentationsportal für Plattform, API und IIoT-Geräte
Die Dokumentation der Plattform, der API und der IIoT-Geräte ist in einem Portal zusammengeführt: ein statischer Build, ein gemeinsames Glossar und ein AI-Assistent über den Inhalten. Die Volltextsuche läuft clientseitig, ohne externen Dienst und ohne Schlüssel. Jede Seite wird zusätzlich als Markdown-Quelle ausgeliefert — für alle, die sie nicht mit den Augen, sondern mit einem Werkzeug lesen.
- Neu
Öffentliche REST-API für Messeinheiten, Ablesearchive und Kommunikationssitzungen
Die Plattform stellt eine öffentliche REST-API über Messeinheiten und ihre Kenndaten, Ablesearchive, Geräteereignisse und -meldungen, Kommunikationssitzungen und Stammdaten bereit. Die Referenz ist endpunktweise aufgebaut: Methode, Parameter, Antwortformat, Fehlercodes. Ein Integrator baut die gesamte Anbindung direkt aus der Seite heraus, ohne Begleitung durch unser Team.
Mehr erfahren - Integration
Prüfung der öffentlichen API am V3-Datenmodell
Jeder Endpunkt der öffentlichen API wird einzeln gegen das Datenmodell der dritten Generation geprüft. Pfade und Verträge bleiben genau dort, wo Integratoren sie erwarten, sodass bestehende Anbindungen ohne Änderungen weiterlaufen. Die Antwort des Konfigurationsarchivs führt konsolidierte metrologische Parameter mit — minimaler und maximaler Durchfluss, Eichdatum, Seriennummer —, die sonst mehrere Anfragen kosten würden.
Mehr erfahren - Neu
Protokolltreiber für Druck- und Temperatursensoren im Erfassungsdienst
Der Erfassungsdienst erhält einen Treiber für ein neues Protokoll: das Identifikationspaket eines autonomen Blocks, aktuelle Druck- und Temperaturwerte, die Archive und einen Konfigurationsschnappschuss. Er liegt innerhalb derselben Protokollfamilie neben der Verarbeitung der Absperrarmatur und nutzt deren Sitzungsteil-Parsing mit. Einen Monat später ruht das vollständige Modul auf diesem Fundament — vom Datenmodell bis zur Gerätekarte.
Mehr erfahren - Verbessert
AI-Berichte auf jeder Ebene der Unternehmenshierarchie
Die Einbettung der Berichte ist auf jeder Ebene des Unternehmensbaums verdrahtet: Hauptorganisation, Niederlassung und Untereinheit öffnen jeweils ihren eigenen Satz analytischer Berichte. Jeder Knoten berichtet über seinen eigenen Umfang, gleich in welcher Tiefe des Baums er liegt. Der eingebettete Block trägt keine eigene Überschrift, denn der Abschnittsname steht bereits in der Navigation.
Mehr erfahren - Zuverlässigkeit
Zeitzonen-Versatz in den Logs der Erfassungsdienste
Erfassungsdienste laufen in verschiedenen Ländern und Zeitzonen, deshalb trägt jede Logzeile einen expliziten Versatz — das Format lautet 2026-05-27 14:43:43 +03:00. Einträge verschiedener Standorte reihen sich auf einer einzigen Skala, sobald man sie nebeneinanderlegt. Bei der Rekonstruktion eines Vorfalls ist die Reihenfolge der Ereignisse über den gesamten Park hinweg eindeutig.
Mehr erfahren - Integration
Stack der MQTT-Absperrarmatur auf dem V3-Erfassungsserver
Der Stack der über MQTT gesteuerten Absperrarmatur läuft auf dem Erfassungsserver der dritten Generation: Datenaustausch, Befehlszustellung, Datenablage und das an den V3-Algorithmus angepasste Auto-Registrierungsmodul. Eine am Objekt angeschlossene Armatur meldet sich selbst an: Sie legt ihre Messeinheit an und nimmt sofort Befehle entgegen. Ein einziger Server trägt damit den gesamten Antriebspark neben den Messgeräten.
Mehr erfahren - Neu
Kompletter V3-Erfassungs- und Speicher-Stack beim ersten Industriekunden
Der Erfassungsdienst und das Erfassungs- und Speichersystem der dritten Generation sind beim ersten Industriekunden als vollständiger Satz ausgerollt und nehmen Live-Ablesungen auf. Von diesem Punkt an läuft die Entwicklung am realen Strom: Archive, Stammdaten und Datenmengen entsprechen dem industriellen Betrieb. Die Analytik wird an echten Felddaten geprüft, nicht an einem Testabzug.
Mehr erfahren
Telemetrie jenseits von GSM
In den Bestand kamen Geräte, die die Plattform nicht nur ausliest, sondern auch ansteuert: MQTT-Absperrarmaturen. Das Register der Messeinheiten wurde um Status und Geodaten neu aufgebaut — tauglich für Karte und Außendienst.
- Integration
Treiber für über MQTT gesteuerte Absperrarmaturen
Die erste Geräteklasse, die die Plattform nicht nur ausliest, sondern auch ansteuert. Ein eigener Treiber deckt den MQTT-Austausch, die Kommandozustellung und die Ablage der Armaturendaten ab. Der Steuerpfad läuft auf demselben Stack wie die Messung — Aktoren brauchen kein eigenes Subsystem.
Mehr erfahren - Verbessert
Ein einheitliches Geokoordinatenformat für den gesamten Bestand
Die Geokoordinaten des Bestands liegen in einem einheitlichen Format vor: über achthundert Messeinheiten, davon 761 programmgesteuert und 48 manuell bearbeitet — dort, wo die Bezeichnungen eine Sichtprüfung verlangten. Anschließend wurde die Haupttabelle revidiert: fünf Einheiten ohne Koordinaten, drei davon Testeinträge. Das Register eignet sich damit für Karte, Clustering und die Routenplanung der Außendienstteams.
- Verbessert
Die vier Betriebsstatus einer Messeinheit
Eine Messeinheit führt vier Betriebsstatus: in Betrieb, abgeschaltet, neu, in Reparatur. Jeder davon entspricht einer konkreten Handlung des Betreibers. Für das Dashboard sind die Status gruppiert, sodass sich die Bestandsübersicht ohne Aufklappen der vollständigen Liste lesen lässt.
Mehr erfahren
Die Hülle der neuen Oberfläche
Der Startpunkt der dritten Generation: eine einheitliche Seitenvorlage, eine funktionierende globale Suche, ein Theme-Manager und ein Dashboard auf dem produktiven Datenmodell. Die Lokalisierung steckt von Tag eins in den Komponenten statt später ergänzt zu werden.
- Sprachen
Lokalisierung in den Komponenten der neuen Oberfläche verankert
Die Lokalisierung liegt im Fundament der neuen Oberfläche: Jede Komponente der Hülle bringt ihre Texte als ausgelagerte Zeichenketten mit, nicht als Text im Markup. Der Sprachumfang eines Servers wird beim Deployment über Umgebungsvariablen festgelegt — Lokalisierungsschema und Liste der Locales. Eine Installation für einen anderen Markt kommt damit ohne Neubau des Images aus.
- Neu
Dashboard auf dem produktiven Datenmodell
Die Widgets des Dashboards sind an das produktive Datenmodell angeschlossen: Bestandsabdeckung, Zustand der Kommunikationssitzungen und Gerätezustände auf einem Bildschirm. Es ist die erste Bewährungsprobe der neuen Oberfläche an realen Datenmengen und an der realen Lückenhaftigkeit der Felddaten. Layout und Abfragen arbeiten auf einem industriellen Datenbestand, nicht auf Fixtures.
Mehr erfahren - Neu
Hülle der Oberfläche: Seitenvorlage, Panels, Theme-Manager
Das Frontend ist auf einer einheitlichen Seitenvorlage aufgebaut: Kopf- und Fußzeile, linkes und rechtes Panel, ein Theme-Manager mit hellem und dunklem Erscheinungsbild. Die globale Suche greift auf Objekte, Ausrüstung und Verbraucher zu und springt direkt zum gefundenen Datensatz. Alle Bereiche der dritten Generation entstehen aus dieser Vorlage, was Navigation und Zustände einheitlich hält.
Mehr erfahren