Telemetrie-Pipelines vom
Gerät bis zur Entscheidung
Wir bauen die Schicht zwischen physischen Anlagen und den Menschen, die dafür verantwortlich sind: authentifizierte Geräteanbindung, Datenannahme, die schlechte Verbindungen übersteht, Stream Processing mit belastbarer Alarmsemantik und Speicher, der auch Jahre später abfragbar bleibt.
Plattform-Funktionen
Jede der folgenden Schichten läuft bereits produktiv — in Energiespeichern, Ladeinfrastruktur und Flottentelemetrie — und ist nicht für ein Angebot skizziert.
Geräteanbindung
MQTT-, HTTP- und WebSocket-Transporte sowie Protokolladapter für Gateways und Controller, die etwas anderes sprechen. Neue Gerätefamilien kommen als Adapter dazu, nicht als Fork des Kerns.
Geräteidentität und Zugriff
Zugangsdaten je Gerät, tokenbasierte Autorisierung und eingegrenzte Topics. Ein kompromittiertes Gateway kann außerhalb seiner eigenen Anlagen weder lesen noch publizieren.
Ausfallsichere Datenannahme
Pufferung, Retry mit Backoff und Deduplizierung auf Edge- und Serverseite. Geräte an instabilen Verbindungen liefern ihre Historie nach, statt sie zu verlieren.
Stream Processing
Filterung, Aggregation, Anreicherung und Anomalieerkennung auf dem Live-Stream. Schwellwert- und regelbasierte Automatisierung greift binnen Sekunden nach dem auslösenden Messwert.
Zeitreihen-Speicherung
Retention-Stufen, Downsampling und kontinuierliche Aggregate, damit ein Jahr Historie abfragbar bleibt, ohne jeden Rohwert vorzuhalten.
Sichtbarkeit für den Betrieb
Flotten- und Anlagenübersichten mit Status, Geoposition und Session-Verläufen, eigene Widgets und Drill-down, rollenbasiert getrennt für Betrieb, Support und Management.
Der Weg eines Messwerts
Sechs Stufen zwischen Sensor und Betreiber. Die meisten IoT-Plattformen scheitern an den Übergängen dazwischen — genau dort investieren wir die Entwurfsarbeit.
Edge und Gateway
Gerätefirmware oder Gateway-Agenten publizieren strukturierte Telemetrie. Payload-Schema und Topic-Struktur legen wir fest, bevor irgendetwas anderes gebaut wird.
Datenannahme
Broker oder HTTP-Endpunkt mit Authentifizierung, Rate Limiting, Pufferung und Deduplizierung. Fehlerhafte Payloads landen in Quarantäne und werden nie stillschweigend verworfen.
Normalisierung
Einheiten, Zeitstempel und Gerätemetadaten werden in ein kanonisches Modell überführt, damit nachgelagerter Code den Hersteller nie kennen muss.
Verarbeitung und Regeln
Aggregationsfenster, Anomalieerkennung und Alarmregeln werden auf dem Live-Stream ausgewertet — mit Schweregraden und Quellenangabe an jedem Ereignis.
Speicherung
Heiße Zeitreihen für Dashboards, verdichtete Aggregate für Trends, kaltes Archiv für die Compliance. Die Abfragemuster bestimmen das Layout.
Nutzung
Betreiber-Dashboards, Alarmkanäle, BI-Auszüge und Backoffice-Integrationen lesen alle dieselben normalisierten Daten.
Was unter der Haube läuft
Betreibbar in der Cloud, on-premise oder hybrid — ohne die Anwendungsschicht neu zu schreiben.
- MQTT
- HTTP
- WebSocket
- Protocol adapters
- Node.js
- Kafka
- RabbitMQ
- Rule engine
- TimescaleDB
- PostgreSQL
- ClickHouse
- Redis
- Docker
- Kubernetes
- OpenTelemetry
- Structured logging
Verwandte Expertise
Dashboards→
Die Bedienoberflächen, die aus dieser Telemetrie etwas machen, womit ein Team arbeiten kann.
BESS-Monitoring→
Dieselbe Pipeline für Batteriespeicher und PV-Wechselrichter über Modbus, IEC 61850 und SunSpec.
Cloud & On-Premise→
Wo die Plattform läuft: Cloud, on-premise oder hybrid — mit demselben Deployment-Modell.
Planen Sie eine Telemetrie-Plattform?
Nennen Sie uns Gerätefamilien, Nachrichtenrate und benötigte Aufbewahrungsdauer. Wir skizzieren eine Architektur für Annahme, Verarbeitung und Speicherung, die vom Piloten bis zur Produktion ohne Neuentwicklung mitwächst.