libFLARM
Einbettbarer Software-Stack zur Kollisionsvermeidung
libFLARM ist eine Software-Bibliothek, die einen Teil des FLARM-Kommunikations- und Kollisionsvermeidungs-Software-Stacks implementiert. Sie nimmt Navigations- und Zeitdaten als Eingabe entgegen, sendet und empfängt FLARM-Funkpakete, berechnet Kollisionsgefahren und gibt Luftfahrzeug- und Alarmdaten aus, die zur Ansteuerung eines Displays bereit sind.
Für die Embedded-Integration entwickelt
libFLARM ist vollständig hardwareunabhängig. Jeder Zugriff auf die Hardware wird hinter Gerätetreibern abstrahiert, die das Host-System implementiert – für den Funktransceiver, den GNSS-Empfänger und die Systemzeitbasis. So können Sie auf dem Mikrocontroller, dem Funkmodul und dem GNSS-Modul aufbauen, die am besten zu Ihrem Produkt passen.
Daten und Ereignisse fließen zwischen der Bibliothek und der Host-Anwendung über einen proprietären Publish/Subscribe-Message-Broker: Der Host veröffentlicht Navigations- und Zeitdaten und abonniert die von der Bibliothek erzeugten Informationen zu Luftverkehr und Alarmen.
Die Bibliothek verwendet ein speicherschonendes Modell, das für Geräte mit begrenzten Ressourcen geeignet ist. Sie benötigt kein Echtzeitbetriebssystem: Der gesamte Zustand wird intern verwaltet, und der Host ruft die Bibliothek einfach periodisch auf. Aufrufe blockieren nie bei der Ein-/Ausgabe und kehren schnell zurück. Es ist keine dynamische Speicherzuweisung erforderlich – der gesamte Speicher wird statisch oder bei der Initialisierung reserviert – und ein optionaler benutzerdefinierter Allokator lässt Sie genau bestimmen, wo der Zustand der Bibliothek gespeichert wird. Für energiebeschränkte Designs meldet die Bibliothek zudem, wann sie das nächste Mal ausgeführt werden muss, sodass der Host in der Zwischenzeit in Deep-Sleep-Zustände wechseln kann.
Möchten Sie FLARM in Ihre Avionik- oder Drohnen-Hardware integrieren? libFLARM ist für kommerzielle Projekte verfügbar. Kontaktieren Sie uns für weitere Informationen und Preise!
Produkt-Highlights
- Hardwareunabhängiges Design: Die Hardware-Interaktion ist vollständig von der Kernbibliothek entkoppelt. Alle Funk- und Systemperipheriegeräte werden über Treiberschnittstellen und Datenstrukturen abstrahiert, die vom Host-System implementiert werden.
- Kein RTOS erforderlich: Die Bibliothek arbeitet zustandsintern über ein opakes Handle und benötigt kein Echtzeitbetriebssystem. Das Host-System ruft libFLARM einfach periodisch auf, um Eingaben zu verarbeiten und Ausgaben zu erzeugen.
- Keine dynamische Speicherzuweisung: Der gesamte Speicher wird statisch oder während der Initialisierung zugewiesen. Zur Laufzeit ist keine Heap-Zuweisung erforderlich, Speicher wird von der Bibliothek nie freigegeben, und benutzerdefinierte Speicher-Allokatoren werden vollständig unterstützt, um den Zustand in bestimmten RAM-Bereichen abzulegen.
- Nicht-blockierende & deterministische Ausführung: Alle API-Aufrufe der Bibliothek werden schnell ausgeführt und blockieren nie bei der Ein-/Ausgabe. Sie umfasst eine anpassbare Schnittstelle für einen Zufallsgenerator, die eine wiederholbare, deterministische Ausführung für Software-in-the-Loop- (SIL) und Hardware-in-the-Loop-Tests (HIL) ermöglicht.
- Extrem geringer Ressourcenbedarf: Benötigt lediglich 20 kB Flash und 5,6 kB RAM. Für einfache Tracking-Beacons oder unbemannte Fahrzeuge, die nur Sendefunktionen (Broadcast) benötigen, ist eine reine Sende-Variante (TX-only) verfügbar, die den RAM-Bedarf auf 2,6 kB reduziert.
- Deep-Sleep-Energieverwaltung: Für energiebeschränkte Geräte entwickelt, stellt libFLARM einen «Deadline»-Zeitstempel bereit, der angibt, wann bei Abwesenheit externer Signale die nächste Ausführung erforderlich ist, sodass Host-Prozessoren zur Energieeinsparung im Deep-Sleep verbleiben können.
- Publish/Subscribe-Architektur: Verfügt über einen integrierten Publish/Subscribe-Message-Broker (Pub/Sub) für den entkoppelten Datenaustausch zwischen der Bibliothek und der Host-Anwendung, komplett mit FIFO-Pufferung zur Bewältigung von Latenzspitzen. Integrierte Extrapolation der Navigationslösung: Umfasst ein optionales CTRV-Modul (Constant Turn Rate and Velocity) zur Vorwärtsprojektion von Navigationslösungen, wenn die GNSS-Latenz das Einhalten strenger Echtzeitfenster verhindert.
Technische Spezifikationen & Anforderungen
-
CPU-Kern32-Bit-Architektur, Little-Endian-Speicherlayout
-
TaktfrequenzMindestens 20 MHz. Prozessoren ohne FPU werden unterstützt (können zusätzliche Taktzyklen erfordern)
-
Codegröße (Flash)~20 kB (Standard-Build)
-
RAM-Bedarf5,6 kB (Voll) / 2,6 kB (nur Senden) zzgl. Stack-Zuweisung
-
Toolchain
Standard-GCC für Cross-Compilation, z. B. arm-none-eabi-gcc für Embedded-Plattformen