Labor Automation Protocol

Hier wollen wir uns das Protokoll auf dem CAN Bus überlegen, was uns zur Automatisierung des Labors dienen soll. Nachdem das alte Protokoll(nenen wir es mal V1.0) nichtmehr so richtig nach unseren Vorstellungen ist, wollen wir uns nun ein neues überlegen. Es darf total inkompatibel zum Alten sein, wir erstzen halt alle Firmwares mit neuen. Jeder darf hier mit Vorschlägen mitarbeiten, um unser neues Protokoll zu entwickeln. Dazu könnte auch das Diskussions-Feature des Wikis ganz sinnvoll sein.

Struktur des Can Identifiers

Bei V1.0 hat sich das Feature der source- und destination Ports als ziemlich unnützlich herausgestellt. Beide wurde eigentlich immer auf den gleichen Wert gesetzt, und sozusagen als Dienstkennung gebraucht. Desswegen sollten wir bei V2.0 diese Bits sofort als Dienstkennung, bzw. Kanal-Kennung Deklarieren. Dabei könnte es Sinn machen, eine Trennung in Channel und Subchannel vorzunhemen. Jeder Channel kann dann 4 Subchannel haben, die man für jeden Dienst nach Belieben belegen kann. z.B. Subchannel 0-> Signaling, Subchannel 1-> Data. Dann kann man die vollen 8 Datenbytes eines jeden Paketes auch für Daten benutzen.

Eine Source-Addresse brauchen wir, um sicherzustellen, dass jede Nachricht auf dem Bus eindeutig ist(es darf bei CAN niemals von 2 Geräten aus mit dem gleichen Identifier gesendet werden). Ausserdem ist das für die Identifizierung der Nachrichten sinnvoll. 8 Bit sollte für die Addressen genug sein, weil an einem CAN-Bus elektrisch sowieso nur max. 127 nodes hängen dürfen.

Eine Destination-Addresse dürfte auch für die allermeissten Dienste Sinn machen. Die kann man jedoch optional halten - jeder Dienst hat schliesslich über seine Channel-Kennung sozusagen einen eigenen Address-space.

Hier mal die Struktur für den Identifier:

CH = 9 bit(512) Channel SC = 2 bit(4) Subchannel SA = 8 bit(256) Source Address DA = 8 bit(256) Destination Address

  2 bit sind übrig. RFU?

Die Trennung in 11 und 18 bits wird hier vorgenommen, weil vom CAN Protokoll her diese beiden Bereiche unterschieden werden. Ansonsten hat die Trennung keine weitere Bedeutung. Die Nachrichten werden über den gesammten 29-Bit-Identifier priorisiert. Das vorderste Bit hat die höchste priorität, eine 0 gewinnt gegen eine 1. Die Nachricht mit dem niedrigsten Identifier hat also die höchste Priorität.

Die ersten 11 bits
SID10	SID9	SID8	SID7	SID6	SID5	SID4	SID3	SID2	SID1	SID0
CH8	CH7	CH6	CH5	CH4	CH3	CH2	CH1	CH0	SC1	SC0

Die hinteren 18 bits
EID17	EID16	EID15	EID14	EID13	EID12	EID11	EID10	EID9	EID8	EID7	EID6	EID5	EID4	EID3	EID2	EID1	EID0
RFU	RFU	SA7	SA6	SA5	SA4	SA3	SA2	SA1	SA0	DA7	DA6	DA5	DA4	DA3	DA2	DA1	DA0

Diese Zuordnung hat auch noch den Vorteil, dass sie wenigstens ein bisschen kompatibel mit LAP V1.0 ist. Die Addressen liegen an der gleichen Stelle, und die Channels ersetzen die Ports. Wenn wir erstmal bestimmte Channel bei der Vergabe aussparen, dann können V1.0 und V2.0 temporär gemeinsam auf einem Bus existieren. Wenn wir einen guten Grund dafür finden, können wir die Kompatibilität aber auch aufgeben.

Channels

Jeder Dienst bekommt einen eigenen Channel. Da die Nachrichten alle über den Channel priorisiert werden, entscheidet der Cahnnel auch über die Priorität des Dienstes. Dabei sollten wir also bei der Vergabe der Channelnummern nachdenken. Auf jedem Channel darf ein anderes Unterprotokoll gesprochen werden. Wir können uns also bei der Entwicklung jedes Dienstes was neues einfallen lassen, und sind nicht zu sehr eingeschränkt.

Dienste

Name

Dieser Dienst kann Namen für die Verschiedenen Geräte und deren Funktionen liefern. So kann ein Controlpannel z.B. den Namen für Channel16:Device5.Funktion3 nachfragen, und erhällt "Rauchmelder Waschküche". Auch eine Nachfrage in Gegenrichtung, also Name zu Addresse sollte möglich sein. Dieser Dienst soll auf roulette laufen, und es ermöglichen, dass die Microcontroller für die eigentlichen Dienste sich nicht viele Strings speichern müssen, und man trotzdem den Komfort hat, Namen für die Geräte abfragen zu können.