16 Attribute eines guten Datenverbindungsprotokolls / Sudo Null IT News

In diesem Text werde ich die Attribute eines guten und einfachen Master<->Slave-Link-Level-Protokolls für den Paketaustausch von Informationen zwischen Geräten auf gängigen Bussen wie RS485, CAN, LoRa, BLE, Lin oder UART, RS232-Punkt schreiben. to-point Verbindungen.

Trotz der Tatsache, dass es standardisierte Kanalprotokolle ModBus, DLMS, RDS, UBX, NEC, Pelco-D, yModem gibt, betreiben viele russische Unternehmen immer noch ihre eigenen internen Protokolle für die Interaktion zwischen elektronischen Karten.

Hier sind die gemeinsamen Attribute und Wünsche für solche selbst entwickelten Protokolle.

*1–M2M-Protokoll muss binär sein

Dadurch wird der Datenverkehr auf der Firmware-Seite kleiner und einfacher zu verarbeiten.

*2 – Muss eine Präambel haben

Die Präambel wird benötigt, damit die empfangende Zustandsmaschine Pakete aus dem Bytestrom schnappen kann.

*3 – Präambel muss parametrierbar sein

Die Präambel sollte parametriert werden, da es möglich sein sollte, Pakete des gleichen Protokolls zu tunneln. Matroschka von Paketen aus einem Protokoll. Dies ist besonders nützlich, wenn die Physik des Transceivers nur N Bytes gleichzeitig senden kann und das Paket selbst nur M Bytes senden kann. In diesem Fall ist N < M. Dabei wird ein großes Paket in kleinen Paketen als Bytestrom übertragen.

*4 – Muss eine Chargennummer sein

Dadurch kann die Empfängerseite den Verlust der Durchflusskontinuität bestimmen.

*5 – Es muss ein Feld geben, das für die Länge der Nutzdaten verantwortlich ist

Dadurch wird das Protokoll universell und ermöglicht die Übertragung von Daten unterschiedlicher Länge.

6 – Multibyte-Header-Felder in Big Endian übertragen (optional)

Dies erleichtert die Analyse von Rohpaketen mit Ihren Augen in einem HEX-Editor oder auf einem Oszilloskop. Selbst wenn der Mikrocontroller Little Endian ist, ist die Leistung moderner Mikrocontroller hoch genug, um Bytes für alle Typen im laufenden Betrieb zu invertieren.

*7 – Das Paket muss eine CRC-Prüfsumme enthalten

Dadurch wird überprüft, ob das Paket während der Übertragung nicht durch Funkstörungen oder Kontaktprellen beschädigt wurde.

*8–Die Prüfsumme muss am Ende des Pakets stehen

Dies erleichtert die Berechnung des CRC, indem sowohl die Daten als auch der Header erfasst werden.

9 – Muss eine Payload-Typkennung sein (optional)

Dadurch kann der Empfänger schneller verstehen, wie die Nutzlast innerhalb des Pakets zu interpretieren ist.

*10 – Das empfangene Paket muss bestätigt werden (Ack)

Der Master-Knoten (a) wird also verstehen, dass der Slave-Knoten (a) das Paket definitiv gegessen hat

*11 – Muss erneut gesendet werden, falls keine Bestätigung vorliegt (ReTx)

Dadurch wird die Zuverlässigkeit der Datenübertragung verbessert.

12–Der Header muss den TimeStamp des Sendens des Pakets mit Millisekunden-Präzision enthalten (optional)

Der Zeitstempel im Paket wird benötigt, um den Verlauf des Dialogs zu debuggen und die Verarbeitungsleistung zu bewerten. Es gibt Hardware-Möglichkeiten, den Datenverkehr in derselben RS485 abzuhören. Laut Protokoll müssen Sie in der Lage sein, die Timings zu analysieren. Chronologie sortieren, Pausen auswerten.

*13 – Die Protokollspezifikation sollte im allgemeinen Tabellenkalkulationsformat erfolgen

Das Erstellen von Protokollspezifikationen in *.doc oder *.pdf ist bereits archaisch. Tabellenkalkulationen sind ideal für die Darstellung der Paketstruktur. Tabellenkalkulationen scheinen darauf ausgelegt zu sein, Pakete darzustellen. Jedes Paket ist tatsächlich ein gewöhnliches Array. In Tabellenkalkulationen können Sie Pakete sortieren, schnell nach dem richtigen Paket suchen, Felder einfärben, auf Vollständigkeit prüfen, freie Identifikatoren finden und sogar automatisch C-Code-Parser generieren, um Pakete zu parsen.

*14–Muss verschlüsselte PayLoad(s) sein

Bei kritischen Aufgaben ist es sinnvoll, die Nutzlast des Pakets zu verschlüsseln, damit illegale Knoten den Betrieb des Systems nicht überwachen und ihre Spionagetelemetrie und darüber hinaus Telematik zur Sabotage an den gemeinsamen Bus anschließen können.

*15 – Die Paketsynchronisierung muss auf der Präambel erfolgen

Da die Präambel akzeptiert wurde und der CRC gültig ist, ist ein neues Paket eingetroffen. Die Firmware kann also Pakete aus dem Bytestrom im UART auswählen.

*16–Batch-Synchronisation muss von TimeOut(y) durchgeführt werden

Sie können auch eine Batch-Synchronisation mit TimeOut(y) durchführen. Das heißt, nach einer langen Stille auf dem Bus setzt der Empfänger einfach die Empfangszustandsmaschine in ihren ursprünglichen Zustand zurück und wartet auf eine neue Präambel von einem neuen Paket.

Fazit
Dies sind die Grundvoraussetzungen für die Auswahl der Kybernetik des nächsten binären Datenübertragungsprotokolls. Protokoll für M2M-Interaktionen. Im Allgemeinen besteht keine Notwendigkeit, ein weiteres proprietäres Protokoll zu erfinden. Verwenden Sie die Spezifikation eines beliebigen vorhandenen Kanalprotokolls. Wahrscheinlich werden ModBus, Can, DLMS, RDS, UBX, xModem, EtherCAT zu Ihnen passen. Ein standardisiertes Protokoll fügt Ihrem Gerät Kompatibilität mit anderer Hardware und Software hinzu. Es wird möglich sein, die Softwareimplementierung von GitHub zu nehmen und sie einfach mit Ihren Komponententests abzudecken.

Wenn Sie weitere spezielle Attribute eines guten Kanal-Datenübertragungsprotokolls kennen, dann schreiben Sie diese in die Kommentare.

Schreiben Sie auch über die standardisierten Kanalprotokolle, mit denen Sie sich auseinandersetzen mussten, und einen Teiler der Eindrücke aus der Arbeit mit verschiedenen Kanalschichtprotokollen.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *