Composable Telematics

    Telematik als Plattform, auf der Sie aufbauen

    Navixy ist eine composable Plattform: ein Katalog von Fähigkeiten – von sofort nutzbarer Betriebstransparenz (Location Intelligence) über Datenorchestrierung (IoT Logic) und SQL-Zugriff auf Telemetrie (IoT Query) bis zum Produkt unter Ihrer eigenen Marke. Nehmen Sie den ganzen Baukasten oder einzelne Primitive und bauen Sie Ihr Produkt.

    Dokumentation Architektur mit einem Ingenieur besprechen
    Seit 2005 in der Telematik800K+ Online-AssetsKunden in 130+ Ländern
    IoT Logic · Telemetrie in Bewegung
    Eingang · Roh-Payload des Geräts
    { "adc1": 156, "din": 5, "lat": 43.238, "lng": 76.889 }
    Ausgang · normalisierte Telemetrie
    { "fuel_level": 62.4, "ignition": true, "location": ... }
    NavixyIhr MQTT-Broker
    Flow aktiv · dekodieren → transformieren → routen
    Jenseits des Monolithen

    Funktionen haben alle. Die Frage ist: Wessen Daten, wessen Roadmap

    Eine monolithische Plattform deckt die Standardaufgaben ab: Tracking, Berichte, Benachrichtigungen. Doch die Daten sind eingeschlossen, die API ist zweitrangig, und jede nicht standardmäßige Funktion ist ein Ticket an den Anbieter und Monate in einer fremden Roadmap. Solange Sie die Plattform eines anderen weiterverkaufen, ist Ihr Produkt dessen Produkt – mit Ihrem Logo in der Ecke.

      Kategoriedefinition

      Was Composable Telematics bedeutet

      Composable Telematics ist ein Ansatz, bei dem ein Telematikprodukt aus unabhängigen Plattformfähigkeiten mit dokumentierten Schnittstellen zusammengesetzt wird, statt es als geschlossenen Monolithen zu übernehmen. Jede Fähigkeit funktioniert eigenständig, verbindet sich über APIs mit den anderen und lässt sich austauschen, ohne den gesamten Stack neu zu schreiben. Die Telematik geht den Weg von White-Label über Headless zu Composable – und weiter zu Agent-ready, wenn nicht mehr nur Menschen, sondern auch KI-Agenten mit der Plattform arbeiten.

      • Jede Fähigkeit ist eigenständig: Location Intelligence, IoT Logic, IoT Query und die Anwendungsschicht funktionieren jeweils für sich. Es gibt keine Alles-oder-nichts-Abhängigkeiten.
      • Die Schnittstellen sind in beide Richtungen offen: Sie steigen mit Ihren eigenen Daten in jede Fähigkeit ein und leiten sie in Ihre eigenen Systeme aus – über API, SDK und MCP.
      • Der Katalog ist offen: Geräte- und OEM-Quellen, Zugriff für KI-Agenten und Integrationen erweitern den Kern. Die Liste der Fähigkeiten wächst, statt durch ein einzelnes Produkt begrenzt zu sein.

      Katalog der Plattformfähigkeiten

      Der Kern sind die vier Fähigkeiten unten; beginnen Sie mit sofort nutzbarer Betriebstransparenz oder steigen Sie hinab zu den Daten. Die Plattform reicht weiter: APIs und SDKs, Unterstützung für Geräte und OEM-Quellen sowie Zugriff für KI-Agenten über MCP.

      Location Intelligence

      Sofort nutzbare Betriebstransparenz: Live-Karte, Geofences, Ereignisregeln, Routen-Wiedergabe (Time Machine), Berichte und sichere Geo-Links. Aus dem Gerätesignal wird ein operatives Lagebild aus dem Feld – ohne Oberflächenentwicklung. DokumentationDokumentation

      IoT Logic

      Daten von Geräten und OEM-Quellen aufnehmen, Protokolle dekodieren, Datenströme anreichern und routen – in Ihre Systeme oder weiter durch den Stack. Neue Quellen und Verarbeitungsregeln konfigurieren Sie im Flow-Builder, ohne ein Plattform-Release. DokumentationIoT LogicOEM-Telematik

      IoT Query

      PostgreSQL-kompatibler SQL-Zugriff auf die Rohdaten der Telematik. BI-Dashboards, ML-Modelle, eigene Analysen – per direkter Abfrage statt CSV-Export. Verbindung einrichtenDatenschemaIoT Query

      Anwendungsschicht

      Web- und Mobile-Apps im White-Label: Domain, Logos und Farbthemen unter Ihrer eigenen Marke. Start ohne Frontend-Entwicklung. Wenn Sie eine eigene Oberfläche brauchen, stehen dieselben Daten headless über die API bereit. White-LabelHeadless

      Architektur

      An jeder Schicht andocken. Daten abgreifen, wo Sie sie brauchen

      Telemetrie fließt von unten nach oben: von den Geräten über IoT Logic zur Datenschicht, Location Intelligence und den Anwendungen. Aber Sie müssen nicht den gesamten Stack nutzen. Binden Sie Ihre eigene Quelle, Oberfläche oder Ihren eigenen Speicher dort ein, wo Ihre Architektur es braucht. LogikoperationenDatenzugriff

      • Tauschen Sie eine Schicht aus, statt den gesamten Stack zu migrieren.
      Agent-ready

      Ein KI-Agent ist genauso Plattform-Client wie Ihre Anwendung

      Der Navixy-MCP-Server öffnet Agenten den Zugang zu den Kontodaten: Telemetrie, Objekte, Regeln, Berichte. Der Agent authentifiziert sich, arbeitet im Rahmen der Kontoberechtigungen und braucht keine separate Integration. Fragen Sie den Agenten „Welche Fahrzeuge standen gestern länger als zwei Stunden still“ – und er führt die Abfrage selbst aus. Navixy MCP

        Navixy MCP · Agent-Konsole
        Agent: Welche Fahrzeuge standen gestern länger als zwei Stunden still?
        Navixy MCP → Authentifizierung: Konto-Token (User MCP)
        IoT Query: 7 Fahrzeuge mit Stillstand über 2 Stunden

        User MCP und Admin Panel MCP erfordern eine Konto-Authentifizierung; das Docs-MCP ist öffentlich. Der Agent handelt im Rahmen der Kontoberechtigungen.

        Für wen

        Eine Infrastruktur – verschiedene Produkte

        Die Infrastruktur ist für TSPs, Produktteams und Engineering-Abteilungen dieselbe – doch jede Gruppe nutzt sie auf ihre eigene Weise.

        • TSPs und Integratoren: Verkaufen Sie nicht länger die Plattform eines anderen weiter – bringen Sie ein Branchenprodukt heraus: Ihre Marke, Ihre Tarife, Ihre Logik auf einer fertigen Infrastruktur.
        • ISVs und vertikale Produkte: Telematik als Komponente: FSM, Versicherung, Kühlkette. Betten Sie Daten und Ereignisse über die API in Ihr Produkt ein, ohne die Telemetrieaufnahme von Grund auf zu bauen.
        • Enterprise-Engineering-Teams: Gerätedaten in Ihrem eigenen Data Warehouse und BI, per SQL-Abfrage. Ohne Anbieter-Dashboard, das niemand öffnet.
        Das Navixy-Team ist professionell, höflich und immer bereit zuzuhören. Großartiges Unternehmen und großartige Menschen. Dies ist die umfassendste Plattform, die ich je verwendet habe. Es war noch nie so einfach, neue Geräte zu integrieren.
        WM
        Warren M.
        Direktor · Informationstechnologie und Dienstleistungen, 11-50 Mitarbeiter
        10K+
        abgeschlossene Projekte
        800K+
        Online-Assets
        130+
        Kundenländer

        Bewertung aus dem Navixy-Kundenbewertungsprogramm, aus dem Englischen übersetzt.

        Häufige Fragen

        Fragen zu Composable Telematics

        Ist Composable Telematics ein Branchenstandard?
        Nein – es ist ein Architekturansatz, kein zertifizierter Standard. Das lässt sich leicht prüfen: Jede Fähigkeit hat eine öffentliche Dokumentation, die Fähigkeiten arbeiten unabhängig, und die Daten sind direkt zugänglich. Verlangt auch nur einer dieser drei Punkte „Sprechen Sie mit Ihrem Account Manager“, ist es nicht composable.
        Reicht eine API aus, damit eine Plattform composable ist?
        Nein. Die API eines Monolithen ist meist zweitrangig: Sie deckt einen Teil der Funktionen ab und lässt Sie nicht mit eigenen Daten in den Stack einsteigen. Composable bedeutet, dass die API die primäre Schnittstelle jeder Fähigkeit ist – und die Oberfläche der Plattform nur einer ihrer Konsumenten. Logikoperationen
        Sind Headless Telematics und Composable Telematics dasselbe?
        Headless ist ein Spezialfall: Daten und Logik ohne fertige Oberfläche. Composable ist breiter: Die Bausteine – einschließlich der fertigen White-Label-Oberfläche – lassen sich beliebig kombinieren. Ein Headless-Szenario ist in einem composable Stack immer möglich; umgekehrt gilt das nicht. Headless
        Ist White-Label-Telematik schon composable?
        Für sich genommen nicht. Bei einem typischen Anbieter ändert White-Label nur die Gestaltung, doch der Stack bleibt monolithisch: Daten, Logik und Oberfläche sind ein Ganzes. Composable ergänzt das Entscheidende – die Möglichkeit, die Daten mitzunehmen, eine Schicht zu ersetzen oder eine eigene einzubinden. Und White-Label bleibt ein legitimer Auslieferungsmodus: In einer composable Plattform ist es einer von mehreren Modi der Anwendungsschicht – nicht die Grenze, an die Sie stoßen. White-Label
        Wann lohnt es sich nicht, die Infrastruktur selbst zu bauen?
        Wenn Telematik für Sie kein Produkt ist, sondern eine Aufgabe: ein Dutzend Fahrzeuge verfolgen, Berichte abrufen. Dann ist eine fertige App günstiger als jede Architektur. Composable lohnt sich, wenn Sie ein Produkt für Ihre eigenen Kunden bauen oder Telemetrie in Ihre eigenen Systeme einbetten.
        Was bietet Location Intelligence über die Datenaufnahme hinaus?
        Sofort nutzbare Betriebstransparenz, ohne Oberflächenentwicklung. Live-Karte, Geofences, Ereignisregeln, Routen-Wiedergabe (Time Machine), Berichte und sichere Geo-Links funktionieren sofort. Es ist eine eigenständige Fähigkeit im Katalog: Schalten Sie sie über IoT Logic hinzu oder ersetzen Sie sie über die API durch eine eigene Oberfläche. DokumentationDokumentation
        Beseitigt Composable Telematics die Anbieterbindung?
        Sie verringert sie, beseitigt sie aber nicht. Eine Fähigkeit zu wechseln bleibt Arbeit, aber Arbeit von begrenztem Umfang: Sie ersetzen eine Schicht, nicht den gesamten Stack samt Datenmigration. Der entscheidende Test lautet: Können Sie all Ihre Daten auf einem regulären Weg exportieren? Bei Navixy ist das der SQL-Zugriff über IoT Query.
        Welche Nachweise sollten Sie beim Anbieter anfordern?
        Die öffentliche API-Dokumentation jeder Fähigkeit, das Datenschema, eine Beschreibung des vollständigen Datenexports, die Liste der unterstützten Geräteprotokolle und die Bedingungen, unter denen die Fähigkeiten einzeln funktionieren. Lautet die Antwort „Wir schicken Ihnen eine Präsentation“, ist die Schlussfolgerung offensichtlich.
        Lässt sich ein KI-Agent oder ein Entwicklerwerkzeug an Navixy anbinden?
        Ein Agent wird wie jede gewöhnliche Integration angebunden. User MCP und Admin Panel MCP arbeiten über die Konto-Authentifizierung; das Docs-MCP ist öffentlich. Der Agent erhält dieselben Rechte und dieselbe Zugriffskontrolle wie jede Anwendung. Navixy MCP

        Mit der Dokumentation beginnen

        Arbeiten Sie die Architektur selbst durch – oder in 30 Minuten mit einem Navixy-Ingenieur, an Ihrem eigenen Szenario.

        Dokumentation Mit einem Ingenieur sprechen

        Beginnen Sie mit einer einzelnen Fähigkeit oder stellen Sie den gesamten Stack für Ihr Szenario zusammen.