Einleitung

Kafka wird als Standard-Message-Broker bei Railnova für Server-zu-Server-Datenströme eingesetzt. Railnova bietet allen Geschäftskunden eine generische Kafka-Streaming-API zu den folgenden Bedingungen an.

Warum Kafka?

Im Vergleich zu den meisten Nachrichtenübermittlungssystemen wie AMQP und MQTT verfügt Kafka über einen besseren Datenfluss, integrierte Partitionierung, Replikation und Fehlertoleranz, was das System zu einer geeigneten Lösung für umfangreiche, hochverfügbare Anwendungen zur Nachrichtenverarbeitung macht. In der Vergangenheit sind wir sowohl bei MQTT als auch bei AMQP (in einer Server-zu-Server-Umgebung) auf Leistungsengpässe und fehlende Redundanz bei MQTT- und AMQP-Einzelknotenarchitekturen gestoßen.

Ein weiteres Hauptmerkmal von Kafka ist die Möglichkeit, Nachrichten aufzubewahren, so dass der Verbraucher die Nachricht bei Bedarf (innerhalb des Aufbewahrungszeitraums) abrufen kann, und auch die Möglichkeit, bestimmte Nachrichten mehrmals abzurufen, falls das System ausfällt oder um sie erneut abzuspielen.

Kafka ist ein Open-Source-Protokoll und hängt nicht von einem bestimmten Cloud-Anbieter ab. Kafka-Nachrichten können sehr einfach von Azure Event Hubs, AWS Kinesis oder GCP Dataflow abgerufen werden. Darüber hinaus besteht auch die Möglichkeit, einen Kafka-Dienst direkt in deiner eigenen Cloud-Umgebung von Confluent oder dem Dienstanbieter Aiven zu hosten. Die Kafka-Dokumentation findest du hier, und einen Überblick über Kafka-Clients in deiner bevorzugten Programmiersprache erhältst du hier.

Preisgestaltung der Allgemeine Kafka-Streaming-API

Die Preisgestaltung des allgemeinen Kafka-Streaming-API-Dienstes hängt vom Datenvolumen und den verbrauchten Serverressourcen ab. Wenn du ein Angebot für die allgemeine Kafka-Streaming-API für deine Flottendaten benötigst, kontaktiere bitte unser Sales Team.

Falls du andere Servicebedingungen als die allgemeinen Bedingungen haben möchtest, bieten wir auch benutzerdefinierte APIs mit benutzerdefinierten SLAs und Integrationsplänen an, die einer speziellen Geschäftsvereinbarung unterliegen. Bitte wende dich an unser Sales Team, wenn du Fragen zu den Bedingungen für kundenspezifische APIs hast.

Broker Information und Verbindung

Unser Kafka-Broker ist für alle Railnova Enterprise-Kunden über das öffentliche Internet zugänglich. Die Authentifizierung erfolgt über das SASL-Protokoll. Wir stellen eine Testumgebung neben der Produktionsumgebung zur Verfügung. Den Host und das Passwort kannst du auf Anfrage erhalten. Für weitere Informationen kontaktiere bitte support@railnova.eu.

	Testumgebung	Produktionsumgebung
Broker-Host	Wird separat zugeschickt	Wird separat zugeschickt
Benutzer (für SASL)	Dein Firmenname	Dein Firmenname
Passwort (für SASL)	Wird separat zugeschickt	Wird separat zugeschickt
Schema-Register-Host	Wird separat zugeschickt	Wird separat zugeschickt
Authentifizierungsprotokoll	SASL SCRAM oder SASL Plain	SASL SCRAM oder SASL Plain
Topic-Name	output-sharing-benutzername	output-sharing-benutzername
Speicherung von Topics auf dem allgemeinen Kafka-Dienst	Standardmäßig 24 Stunden	Standardmäßig 24 Stunden

Das CA-Zertifikat (erforderlich für die SASL-Authentifizierung) wird ebenfalls separat übermittelt.

Die Daten stehen in einem einzigen Topic zur Verfügung, das nach Asset-Nummer (Lokomotive oder Triebzug) unterteilt ist. Die Daten sollten jeweils mit einer einzigen Verbrauchergruppe konsumiert werden.

Nachrichtenformat und Schema

Die Schemas können direkt aus unserer Schemaregistrierung mit demselben Benutzer und Passwort wie für den Broker abgerufen oder auf Anfrage auch zugesandt werden.

Die Nachrichten werden mit Avro kodiert und mit zstd komprimiert.

compression.codec	zstd
Avro schema namespace	eu.railnova.supernova.analyst
Avro key schema name	AnalystKey
Avro value schema name	AnalystValue

Nachrichtenumschlag

Der Nachrichtenumschlag wird durch das Schema AnalystValue definiert, und darin befinden sich der Name und die Beschreibung des Top-Level-Schlüssels.

Schlüssel-Name	Typ des Wertes	Beschreibung
type	string	Nachrichtentyp (telematic, fault-code, …)
timestamp	string	ISO 8601 kodierte Datumszeit in der UTC/Zulu-Zeitzone
asset	integer	Asset ID in Railnova
asset_uic	string	UIC des Assets, wie im Railnova Admin-Menü hinterlegt.
device	integer	Gerät-ID in Railnova (kann Null sein, wenn die Daten nicht aus einem Railster stammen)
is_open	bool	Für den Status von Fehlercodes und Meldungen verwendet
content	string	Die Payload der Nachricht. Im internen Railnova-Format. Sie ist in JSON kodiert und wird unten beschrieben.

Die Zuordnung von asset und asset_uic zum Asset-Namen sowie zusätzliche Daten können über unsere API am Asset-Endpunkt abgerufen werden.

Der Payload Inhalt

Der Schlüssel Content enthält ein JSON-kodiertes Objekt, das die Nutzlast der Nachricht darstellt, spezifisch für jeden Nachrichtentyp.

Dieser Content der Payload innerhalb eines Content-Feldes kann sich in Zukunft ändern, da er von den empfangenen Daten von konfigurierbaren IoT-Geräten wie dem Railster oder Daten von Drittanbietern abhängig ist. Die generische Kafka-Streaming-API bietet keine Garantie für die Kontinuität des Schemas der Content-Payloads.

Der Content Payload kann über die Seite "Telematikdaten" auf https://one.railnova.eu/telematics/#/ abgefragt werden.

Hier ist ein Beispiel, was man typischerweise von einer Nachricht des Typs "Position" für den Inhalt erwarten kann.

{
"gps_time": "2020-06-15 00:00:07",
"fix": 1,
"longitude": 5021011,
"course": 310,
"location": "Bièvre",
"period_km": 1.165,
"latitude": 49946116,
"speed": 101
}

Hier ist ein weiteres Beispiel für eine Nachricht der eingebetteten Railster-Rule-Engine:

{
"ZSG_Catenary_Voltage": 1.6,
"ZSG_IW_HB_Druck": 8.6,
"ZSG_IW_HLDruck": 4.92,
"ZSG_IW_IFahrSumme_scaled_A": 21.90234375,
"ZSG_IW_IFahrdr_1_scaled_A": 0,
"ZSG_IW_IFahrdr_scaled_A": 22.90234375,
"ZSG_IW_Weg": 31019,
"ZSG_IW_ZBK_Gesamt": 0,
"ZSG_IW_ZBK_eigene_Lok": 0,
"ZSG_IW_Zugnummer": 953,
… a hundred more symbols
}

Hier ist ein weiteres Beispiel für eine Meldung der eingebetteten Railster-Rule-Engine:

{
"name": "Tueren auf Seite Rechts wurden Freigegeben bei Befehl Freigabe links",
}

Abkündigungsrichtlinien der Allgemeinen Kafka-Streaming-API

Unter den Bedingungen der Allgemeinen Kafka Streaming API möchten wir sicherstellen, dass unsere Kunden informiert werden und Zeit haben, ihre Systeme vor den Änderungen zu aktualisieren, während wir gleichzeitig die normalen Arbeitsabläufe der Feature- und Produktentwicklung bei Railnova ermöglichen.

Bei der Veröffentlichung einer neuen Version können bestimmte Funktionen aus früheren Versionen veraltet sein ("eine signifikante Änderung"). Bei der Freigabe von "Bruchänderungen" werden wir Benutzer vor dem Freigabedatum der "Bruchänderungen" benachrichtigen und die Rückwärtskompatibilität für 6 Monate sicherstellen.

Änderungen, die im Rahmen der allgemeinen Kafka-API als "brechend" gelten, sind:

Ändern oder Entfernen bestehender Felder in der Umschlagstruktur (AnalystValue-Schema),
Entfernung eines bestehenden message_type

Code-Beispiel

Wir stellen ein Open-Source-Codebeispiel in Python zur Verfügung, mit dem du deine erste Nachricht über unser Kafka abrufen kannst, nachdem du der README.md auf GitHub gefolgt hast.

Support

Hast du noch Fragen? Dann geh auf die Railnova-Plattform und klick auf "Kontakt", um Hilfe zu erhalten!

Verwandte Artikel

Railnova - Allgemeines HTTP REST API