RAW- und BCM-Sockets

Kayak benötigt für Zugriff auf einen CAN-Bus auf der socketcand-Seite einen CAN-Socket. Das kann entweder ein RAW-Socket oder ein BCM-Socket sein, die sich grundlegend durch ihr Verhalten unterscheiden.

RAW-Socket

  • kein Abonnement von IDs

  • keine Komfortfunktionen zum zyklischen Senden von Nachrichten

  • die eintreffenden Frames werden einfach weitergeleitet

BCM-Socket

  • ausschließlich Übertragung von IDs, die auch vorher abonniert wurden. Daher ist es bei einem CAN 2.0B mit 2^29 IDs nicht möglich, diese alle in absehbarer Zeit zu abonnieren

  • daher eignet sich der Socket nur für die Übertragung von bereits bekannten IDs

  • Filterung und Reduzierung der Datenrate möglich

  • automatisches zyklisches Senden von Frames ist möglich

Verschiedene Views in Kayak werden unterschiedlichen Zugriff auf die Daten benötigen. Eine Übersicht über alle auf dem Bus vorhandenen IDs benötigt logischerweise Informationen über jedes einzelne Frame auf dem Bus. Ein View, der den Inhalt einzelner Frames darstellt, kann auf diese Informationen verzichten und möchte nur den Inhalt von einzelnen Frames erhalten. Daher ist es nicht einfach möglich, einen RAW- oder BCM-Socket aufzumachen, durchzuleiten und gut. Es ergeben sich einige mögliche Szenarien, die sich im Bandbreitenbedarf und dem Verarbeitungsaufwand unterscheiden:

1. Ein RAW- und mehrere BCM-Sockets Für jede Verbindung zu einem CAN-Bus wird ein RAW-Socket weitergeleitet, den sich mehrere Views teilen müssen, die alle Frames erhalten wollen. Diese müssen dann selbstständig die relevanten Informationen extrahieren. Jeder View, der nur bestimmte Informationen benötigt, öffnet eine eigene Verbindung zu einem BCM-Socket und abonniert die für ihn relevanten Informationen. Ein sendender View kann ebenfalls einen BCM-Socket öffnen und die zyklischen Sendefunktionen von Socket CAN nutzen. Vorteile:

  • kein wesentlich größerer Bandbreitenbedarf als ein einzelner RAW-Socket

  • wenig Filteraufwand in Kayak, da der Kernel über die BCM-Sockets einen Großteil übernimmt

Nachteile:

  • Notwendigkeit einer zentralen Verwaltung, die Zugriff auf den einen geteilten RAW-Socket erteilt

2. Mehrere RAW-, reduzierte RAW- und BCM-Sockets Wie 1 nur dass jeder View, der alle Frames benötigt, einen eigenen RAW-Socket öffnet. Ein View, der nur an dem Auftreten von IDs, nicht aber deren Inhalt interessiert ist (das werden die meisten der Views mit RAW-Verbindungen sein) kann die Verbindung zu einem reduzierten RAW-Socket aufbauen. Über diese Verbindung werden keine Inhalte sondern lediglich die IDs (und vielleicht DLCs) der Frames übertragen um Bandbreite zu sparen. Vorteile:

  • jeder View ist für seine Daten selbst verantwortlich

  • keine zentrale Verwaltung notwendig

Nachteile:

  • wahrscheinlich geringster Bandbreitenbedarf durch reduzierte RAW-Sockets

  • Alle Frames werden nur mit Inhalt übertragen, falls ein View das wirklich benötigen sollte

3. Ein einziger RAW- und ein einziger BCM-Socket An zentraler Stelle wird die Verbindung zu einem BCM- und zu einem RAW-Socket hergestellt (ggf. sogar über die selbe Verbingung). Jeder View registriert sich mit den gewünschten Informationen, die er dann zugeteilt bekommt. Abonnements von bestimmten Frames werden an den BCM-Socket weitergeleitet. Vorteile:

  • geringer Bandbreitenbedarf durch Vermeidung von doppelten Übertragungen

Nachteile:

  • Aufwändige zentrale Verwaltung, die einige CPU-Last erzeugen könnte