Ist ein CAN Bus automatisch sicherer als ein RS485 Bus?

[Hannes (Gast)]

Hallo,

ich möchte für eine sicherheitsrelevante Anwendung einen Bus auswählen. 
Ich möchte eigentlich aus vielen praktischen Gründen einen RS485-Bus 
verwenden und ein eigenes Protokoll darüber schicken.
Meist wird für sicherheitsrelevante Sachen aber immer CAN erwähnt. So 
wie ich das sehe ist doch die physikalische Übertragung (fast) gleich. 
Wenn ich wenige Daten und Teilnehmer habe ist doch auch ein eigenes 
Protokoll überschaubar.
Der Zertifizierungsaufwand könnte allerdings höher sein. hat sich jemand 
mal mit dem Thema beschäftigt und kann mir ein paar Denkanstösse geben?

Gruß
Hannes

[H.Joachim S. (crazyhorse)]

Wenn dir die kleinere max. Datenrate und Leitungslänge reicht, nimm CAN.
Es nimmt dir jede Menge Arbeit ab, die du sonst umständlich zu Fuss 
programmieren musst (Busarbitrierung, Fehlerbehandlung). Beides ist bei 
CAN wirklich ausgereift gelöst.
Bei einer single-master-RS485 lässt sich das alles noch halbwegs einfach 
realisieren. Multimaster ist zum Haare raufen - diese Betriebsart füllt 
hier mehrere Seiten.
Preislich macht es inzwischen kaum noch einen Unterschied, es gibt 
ausreichend viele MCs mit internem CAN. Externe CAN-Controller kosten 
auch nicht die Welt. Transceiver auf etwa gleichem Niveau.

[Peter D. (peda)]

Hannes schrieb:
> ein eigenes Protokoll darüber schicken.

Ein eigenes Protokoll scheint nur für den Anfänger einfach, isses aber 
nicht.
Du mußt alle Arten von Störungen erkennen und korrigieren.

Beim CAN macht sehr vieles die Hardware, was man bei RS-485 umständlich 
und aufwendig in SW machen müßte.

Geschätzte Entwicklungszeit:
CAN: 2 Tage
RS-485 mit standard Protokoll: 14 Tage
RS-485 mit eigenem Protokoll: 3 Monate

[(prx) A. K. (prx)]

Sicherheitkritische Belange, also Verschlüsselung und Authentifizierung, 
implementieren dir von Haus aus weder RS485 noch CAN. Das musst du in 
jedem Fall selber oben drauf erledigen.

[Zac Hobson (Gast)]

Man sollte nicht vergessen, dass CAN ein Automobilbus ist. Und daher 
fuer schnelle Antwortzeiten bei super-kleinen Blockgroessen optimiert. 
Die Meldungslaenge ist auf 6 oder 8 byte limitiert. Also nicht geeignet 
fuer grossen datenbloecke, Filetransfer oder dergleichen. 
Moeglicherweise ist ein fester Timeout fuer kleine Kabellaengen 
eingebaut.

[Rainer S. (rsonline)]

Peter Dannegger schrieb:
> Du musst alle Arten von Störungen erkennen und korrigieren.

Prüfsumme.
Zeitüberschreitung.
Was noch?

Controller extra für CAN verkomplizieren die Angelegenheit.
Es ist ja nicht so, dass dann kein Programmieraufwand mehr da ist.
Bei einem freien Protokoll ist man auch frei. Man kann fast jeden 
Controller dafür nehmen. In die CAN Materie muss man sich auch 
einarbeiten. Es ist ja nicht so, dass das in 5 Minuten geht.

[Peter D. (peda)]

Zac Hobson schrieb:
> Die Meldungslaenge ist auf 6 oder 8 byte limitiert.

Was quatsch ist.
Ein Datensatz kann durchaus aus mehreren CAN-Paketen bestehen.
Man kann beim CAN beliebig viele Pakete hintereinander senden. Jeder 
CAN-Bootloader macht das.

[Martin L. (maveric00)]

Hallo,

unter der Voraussetzung, dass unter "sicherheitsrelevant" die 
funktionale Sicherheit im Sinne der IEC61508 gemeint ist:

Da hat CAN schon erhebliche Vorteile in der Entwicklung, da der 
Controller schon einiges eingebaut hat (Rücklesen des gerade gesendeten 
Bits und Erkennen, wenn Bit verfälscht wird, 15 Bit CRC, die 
prinzipielle Empfangbarkeit einer Nachricht wird von den anderen 
Busteilnehmern bestätigt, Fehler werden allen Busteilnehmern bekannt 
gegeben, Priorisierung von Nachrichten,...). Kann man natürlich auch 
alles mit RS485 machen, ist vom Aufwand her allerdings schon erheblich.

Das Argument mit den "kurzen" Leitungslängen ist auch relativ - die ist 
wie übrigens auch bei RS485 abhängig von der Übertragungsrate. Bei 125 
kBit/s sind es auch 500 m (bei RS485 bei 10 MBit/s auch nur 12 Meter).

Für wirklich sicherheitsrelevante Übertragungen sind aber auch beim CAN 
zusätzliche Maßnahmen (z.B. Checksummen, Nachrichtenzähler, 
Timeout-Erkennung) auf höheren Ebenen notwendig.

Wenn eine Zertifizierung notwendig/angestrebt ist, so sollten im Vorfeld 
die einschlägigen Normen gelesen und verstanden sein, da im Gegensatz 
z.B. zum EMV bei einer FuSi-Zertifizierung nicht nur das Produkt, 
sondern auch der Entwicklungsprozess betrachtet wird (man kann also 
praktisch nicht nachträglich zertifizieren). In den Normen sind dann 
auch Beispiele angegeben, welche Maßnahmen für welche Kritikalität 
einzuhalten sind.

Schöne Grüße,
Martin