Der Comm-Treiber (Kommunikationstreiber) nimmt die eingetroffenen Telegramme/Botschaften entgegen, verarbeitet diese und schickt ggf. Antwortbotschaften ab. Die Quelle oder das Ziel von Botschaften kann hierbei z.B. CAN, Zigbee oder „Loopback“ sein. Loopback ist ein Kunstgriff, um lokal zuzustellende Botschaften ebenfalls einfach und sauber abhandeln zu können, ohne eine Sonderbehandlung für lokale Botschaften implementieren zu müssen.

Eingehende Botschaften werden sortiert nach Botschaftstypen in separaten Warteschlangen eingereiht. Diese Trennung oder Pufferung ist notwendig, da das Einreihen selbst meist noch im Interruptkontext stattfindet (z.B. bei CAN-Daten; nicht aber bei Zigbee) und somit schnell erledigt werden muss. Sind die Daten im Puffer angekommen, so können diese in einem zyklischen Task „in aller Ruhe“ ausgewertet werden. (Entkopplung der Daten und Verarbeitung).

Routing

Bevor die Daten aber tatsächlich in die Warteschlangen eingereiht werden, durchlaufen diese eine Prüfung, ob der betrachtete Botschaftstyp über das gemeldete Interface überhaupt für die Weiterverarbeitung akzeptiert werden soll. (Praktische Umsetzung über Konfigurationsstruktur InFilterConfig[]).

Beispiele: Falls der Knoten ein Zigbeeinterface bedient, ist es hier von Interesse, ob er die ZigbeeSlave-Rolle oder die ZigbeeGateway-Rolle einnimmt. Ein ZigbeeSlave soll sich z.B. nicht für eintreffende NMOs interessieren, dafür aber DDOs verarbeiten. Ein ZigbeeSlave z.B. soll grundsätzlich nicht routen.
Ein anderer Knoten mit CAN-Interface und ZigbeeInterface (in der Rolle als ZigbeeGateway) soll z.B. DDOs von CAN nach Zigbee durchrouten (und umgekehrt), aber z.B. keine BOs nach Zigbee durchlassen.

Verarbeitung

Wurden die eingetroffenen Daten für die weitere Verarbeitung durchgelassen, so landen diese in den Botschaftsspezifischen Warteschlangen. Jede Warteschlange ist so ausgelegt, dass nicht mehr Telegramme eintreffen können, wie in der Zeit zwischen zwei Verarbeitungsdurchläufen verarbeitet werden können. Bei einer Übertragungsrate von 100kBit benötigt das Versenden für das kürzeste Telegramm (DLC=0) mind. 0,47ms (47Bitzeiten). Das längste mögliche Telegramm besteht inkl. Bitstuffing aus 135Bitzeiten und entspricht 1,35ms. Das führt zu einer gewählten Pufferanzahl von 10Puffern (Verarbeitung aller eingehenden Botschaften im 10ms-Task).

Diagramm: Datenflussmodell Firmware

In der zyklischen Verarbeitung (sprich im 10ms-Task) kümmert sich dann je eine Funktion im die Warteschlangen für NMO-, BO- und DDO-Botschaften.

Zu sendende Daten werden dann dem Routingmodul zum Versand übergeben. Dieses entscheidet dann nach den konfigurierten Regeln, ob und auf welches Interface die Botschaft geroutet werden soll. So muss z.B. die übergeordnete Instanz zum Versand der NMO-Botschaften nicht wissen, dass sie auf einem Zigbeeknoten läuft und dort keine NMO-Sendebotschaften gewünscht werden…

NMO-Verarbeitung (NetzwerkManagementObjekte)

In der Comm_TaskRxNetworkManagementObject-Funktion wird typischerweise nur geprüft, ob überhaupt NMOs eingehen. Daraus wird dann geschlossen, ob der Knoten mit dem CAN-Bus verbunden ist oder ob er sich im Notlauf (keine CAN-Verbindung) befinden soll.
In Comm_TaskTxNetworkManagementObject werden die Daten der NMO-Botschaft zusammengestellt und dem Routingmodul zum Versand übergeben.

BO-Verarbeitung (BroadcastObjekte)

In Comm_TaskRxBroadcastObject wird geprüft, ob die zu verarbeitende Botschaft Informationen trägt, die von der Applikation erwartet werden. Hierzu füllt die Applikation im Startup die BO-Filterdaten aus, die jetzt auf Übereinstimmung geprüft werden.
Die Filterung ist nach Absendeknoten, BoTyp, BoIndex möglich. (z.B. „alle Temperaturinformationen einsammeln“ oder „Rolladendaten von Rolladen an Knoten 10 empfangen“). Die Daten, die durch den Filter durchgehen werden in einen Applikationspuffer umkopiert, damit die Applikation dann in ihrem Task darauf zugreifen kann.

Neben den Daten, die von der Applikation erwartet werden, müssen auch noch Daten ausgefiltert werden, die von „Nebenbedingungen“ oder vom „BoDdoKonverter/BDK“ verarbeitet werden sollen. Die Filterung hierfür geschieht auf dieselbe Weise.

In Comm_TaskTxBroadcastObject werden die BoDaten aller Applikationen versendet. Der Comm-Treiber kümmert sich um die Zeitsteuerung. Ist der Sendezeitpunkt erreicht, so holt er sich von der jeweiligen Applikation (über eine Callback-Funktion) die Nutzdaten, die das BO versenden soll. Anschliessend werden die zusammengestellten Daten dem Routingmodul zum Versand übergeben.

Ddo/Dor-Verarbeitung (DirectDataObjekte)

In Comm_TaskRxDirectDataObject werden die eingetroffenen DDOs (DdoWrite und DdoRead) nach DoTyp getrennt und per softwaretypspezifischer Funktion Appl_ProcessDDO der Applikation zur weiteren Auswertung übergeben. Denn nur diese kennt die genaue Zusammenstellung der Applikationen. So muss der Comm-Treiber nicht wissen, ob die Software eine Relais-Applikation überhaupt unterstützt und falls ja, wer für die Verarbeitung der DDO-Daten zuständig ist.

In Comm_TaskRxDataObjectResponses werden eingetroffene Antworten (DORs) auf zuvor versandte DdoRead-Anfragen verarbeitet. Auch hier werden die Antworten ähnlich gefiltert, wie die BoDaten (siehe oben) – es sollen ja nur die DORs durchkommen, die zuvor auch angefragt wurden und somit erwartet werden.

Eine epxlizite Ddo-Sendefunktion gibt es nicht. Zu sendende DDOs werden an der Stelle an der sie entstehen direkt dem Routingmodul zum Versand übergeben. Eine nochmalige Pufferung im Comm-Treiber bächte keinen Vorteil.

(In diesem Abschnitt wurden folgende Komponenten angesprochen: drv_comm)