Eigene Queries, Logging und ungewöhnliche Anwendungen

Eigene Funktion einbauen

Für eine eigene Funktion müssen die vorhandenen Master- oder Slave-Worker nicht verändert werden.

Eine zusätzliche Pipeline kann in freien Runtime-Slots angelegt werden:

custom_tx_query
      ↓
 custom_native
      ↓
custom_rx_query

Die vorhandene query.py kann dabei wiederverwendet werden. Neu implementiert wird nur der Worker in der Mitte.

Minimaler eigener Worker

BEIIS_API = 1

async def main(ctx):
    tx_peer = ctx.config["tx_peer"]
    rx_peer = ctx.config["rx_peer"]

    while True:
        source, channel, payload = await ctx.recv()

        if source != tx_peer:
            continue

        reply = b"reply:" + bytes(payload).upper()
        ctx.send_to(rx_peer, reply, channel)

Das Repository enthält dafür ein vollständiges Beispiel:

examples/runtime/custom_query_worker.py
examples/runtime/install_custom_query.py
examples/runtime/custom_query_client.py

Installation:

python examples/runtime/install_custom_query.py

Test:

python examples/runtime/custom_query_client.py "hello world"

Beispielantwort:

reply:HELLO WORLD

Logging

Die Standard-Runtime enthält bereits:

logging_tx_query
      ↓
 logging_native
      ↓
logging_rx_query

Der Logging-Worker kann angesprochen und auf seinen Status geprüft werden.

python examples/runtime/python_basic.py logging-ping
python examples/runtime/python_basic.py logging-status

Aktueller Stand

Die Logging-Pipeline ist vorbereitet, aber passives elektrisches LIN-Sniffing ist derzeit noch nicht implementiert.

Der Worker meldet deshalb bewusst:

passive RX unavailable

Die Schnittstelle ist bereits so angelegt, dass später eine native Receive-Queue hinter dieselbe Query-Pipeline gehängt werden kann.

Runtime-Taps

Ein tap ist etwas anderes als ein elektrischer Bus-Sniffer.

Ein Tap erhält eine Kopie von Host-/Application-Daten innerhalb der Runtime. Die Nachricht bleibt gleichzeitig beim aktiven Empfänger verfügbar.

Damit lassen sich beispielsweise:

• Protokollereignisse protokollieren,
• Statistiken sammeln,
• Debug-Ausgaben erzeugen,
• Test- und Diagnosepfade ergänzen.

Mögliche Anwendungen

Die Kombination aus Linux-Anwendung, MicroPython-Runtime und nativen C-Funktionen ermöglicht deutlich mehr als einen klassischen LIN-Adapter.

Steuergeräte-Simulator

Der Mikrocontroller kann definierte Slave-Antworten bereitstellen und auf bestimmte Requests reagieren. Damit lassen sich Sensoren, Aktoren oder Teile eines Steuergeräts für Entwicklung und Test simulieren.

Automatisierter Teststand

Eine Python- oder C-Anwendung kann LIN-Zustände setzen, ein Steuergerät stimulieren, Antworten prüfen und die Ergebnisse protokollieren.

Teile eines Prüfablaufs können zusätzlich in einen Runtime-Worker verlagert werden.

Gateway

LIN-Nachrichten können in einer Linux-Anwendung in andere Protokolle übersetzt werden, beispielsweise Ethernet, MQTT, Datenbanken oder kundenspezifische IPC-Schnittstellen.

Logik direkt auf dem Mikrocontroller

Wenn eine Reaktion ohne Linux-Roundtrip erfolgen soll, kann die Logik als Runtime-Worker auf dem Mikrocontroller ausgeführt werden und native Funktionen aufrufen.

Eigene Protokolle über LIN

Die Query-Schicht transportiert beliebige Binärdaten. Oberhalb der generischen LIN-Operationen kann deshalb ein eigenes Request-/Response-Protokoll aufgebaut werden.

Experiment: IP über LIN

Als Architekturtest wurde IPv4 über LIN fragmentiert und wieder zusammengesetzt. Dabei wurden reale Linux-Endpunkte mit ICMP, UDP und TCP verwendet.

Das Experiment zeigt die Offenheit der Runtime. Wegen der geringen LIN-Datenrate und des Protokoll-Overheads ist es kein allgemeiner Netzwerkersatz.

Grundprinzip

Die unteren Ebenen bleiben generisch:

Socket
  ↓
Query
  ↓
Worker
  ↓
Native Funktion

Die Bedeutung der Nutzdaten wird erst durch die jeweilige Anwendung festgelegt.

Damit kann dieselbe Hardware als einfacher LIN-Adapter, automatisierter Tester, Simulator oder spezialisiertes Gateway eingesetzt werden.