Cand Release status: stable [box doku]
Description	Labor-CANBus EIA-232 zu TCP Gateway Dienst
Author(s)	Joerg, Tixiv, Asklepios
Last Version	1.0 ⁽⁾
Platform	GNU/Linux
License	?
Download	SVN browse

Der Cand[y] ist der Daemon der auf unserem Intranet-Server läuft und die vom CAN-Bus ankommenden Nachrichten verarbeiten kann. Urspruenglich war er nur als zentrale Instanz fuer lapcontrol gedacht. Lapcontrol ist dabei die Clientsoftware die von jedem Rechner aus gestartet werden kann und via tcp/ip eine Verbindung zum Cand aufbaut.

Das auf der EIA-232 Schnittstelle gesprochene Protokoll ist auf der Seite des CAN-Gateway dokumentiert.

Netzaufbau

Genau genommen sieht es so aus, dass cand ein uart-tcp gateway ist. Damit fuegt er sich in die Struktur wie folgt ein:

+----------------+             +-------------------+                 +------------+              +---------------------+
|  CAN-Device  <-|-> CAN-Bus <-|->  CAN-Gateway  <-|->  EIA-232  <-|->  Cand  <-|->  tcp/ip  <-|->  lapcontrol + UI  | 
+----------------+             +-------------------+                 +------------+              +---------------------+

start des cand

Cand wird auf KVM (unser Intranet-Server) mit

start cand

gestartet resp mit

stop cand

gestoppt. Es ist davon abzuraten den cand von hand zu starten, da er unter einem spez benutzer laeuft der unter anderem schreibenden zugriff auf /var/log/cand hat. Aus sicherheitsgruenden sollte der cand auch nicht als benutzer root gestartet werden, was durch die start/stop-scripte sicher gestellt ist. Daher die obenstehenden commands nur als root ausfuehren

logging

Der cand loggt alles was auf dem Canbus (eigentlich ja auf der uart) passiert mit. Diese Datei befindet sich unter /var/log/cand/cand.log. Sie sollte einmal in der Woche von logrotate rotiert werden. Sie kann mit unter recht gross werden, wenn Geraete ueber den can-bus ein neues image erhalten.

scripting

Es ist moeglich den cand auf spez. events des can-bus reagieren zu lassen. Dafuer ist unter /etc/cand/ die datei cand.scripts gedacht. Diese hat ein recht eigenwilliges Format da hier kurz am beispiel der Uhrzeitanzeige des Laufschriftborgs beschrieben ist. Die beschreibende Zeile ist

0x24:0x30 0x00:0x30 0x01 -> /etc/cand/timeserv.sh

Das liesst sich wie folgt:

src_addr:src_port dst_addr:dst_port data_length -> command_to_call

wenn also ein packet auf dem bus ankommt, das die entsprechenden eigenschaften hat (src/dst/payloadlength) wird das entsprechenden Command ausgefuehrt. Diese command bekommt dabei als ARGV die daten mit. Ein entsprechendes Script saehe dann z.b. so aus:

#!/bin/bash
DATALENGHT=$1
FIRSTDATABYTE=$2
SECONDDATABYTE=$3
...
LASTDATABYTE=$n #entspricht n=$DATALENGTH+1 max(n)=9

Die uebergebenen Werte kommen alle als Hexwerte rein. Also z.b. '0xde' '0xeb'

uart

Der cand läuft in der aktuellen Version mit 115200 baud. Der CAN-Bus selbst laeuft mit 100000Bps. Die LAP-Pakete werden direkt an den Gateway gesendet. CAN-Pakete auf dem Bus sind dabei maximal 128Bit lang. Es ergibt sich 100000/16=6250 Bytes pro sekunde auf dem Canbus. In der Praxis liegt die reale CAN-Datenrate aufgrund von CAN Interframe Spaces und Bit-Stuffing etwas darunter.

listen

Der cand hört per default auf den Port 2342.

CAND-TCP Protokoll

Der CAND verwendet ein einfaches Protokoll, welches CAN-Frames übertragen kann. Es ist auf dem über die EIA-232 Schnittstelle gesprochenen Protokoll des CAN-Gateway aufgebaut. Es sind lediglich len und type vertauscht (CAND-TCP sendet len vor type, das Gateway-Protokoll umgekehrt) und enthält keine CRC16-Summe mehr. Weiterhin muss nicht jede implementierung alle Kommandos an das Gateway oder von diesem weiterleiten. Momentan gilt als gesichert, dass Pakete mit dem Kommando 0x11 immer weiter geleitet werden. Andere können aus gründen der Sicherheit und Bus-Stabilität ignoriert werden.

CAND-TCP Protokoll
+-------------+--------------+-------------------+ \| uint8_t len \| uint8_t type \| uint8_t[] payload \| +-------------+--------------+-------------------+
Feld	Bedeutung	Datentyp	Länge (Bytes)
len	Payload-Länge	unsigned byte	1
type	Payload-Typ	unsigned byte	1
payload	Daten	unsigned byte array	0-18

Maximale Gesamtlänge: 20 Bytes

LAP-Paket Typen
Paketname	Hex-Value	Bemerkung
LAP_RESET	0x00
LAP_CAN_SETFILTER	0x10
LAP_CAN_PKT	0x11	Einbetten von CAN-Paketen
LAP_CAN_SETMODE	0x12
LAP_CAN_ERROR	0x13
LAP_CAN_NOTIFY_RESET	0x14
LAP_RS232_PING_GATEWAY	0x15

source