Moinmoin !
@PatrickB
Genau so wie Du den Bus beschreibst beschreibst ist der auch. Aber ich will ganz was anderes.
Man Nehme einen Mikroprozessor mit 2 CAN interfaces, Interface A und B
Wenn am Port A eine x-bliebige Nachricht empfangen wird, dann wird sie zum Port B gesendet und andersherum.
Das ist die Funktion einer Bridge, das gleiche wie bei z.B. einem Netzwerk-Switch.
Natürlich kann das Mikroprozessorsystem dazwischen die Nachricht z.B. auch nicht weiterleiten oder verändern, um zu sehen, was passiert. Außerdem sollte dieser Mikroprozessor Verbindung z.B. zu einem PC haben, damit man sehen kann, welche Pakete laufen und damit man im laufenden Betrieb Nachrichten von A nach B, B nach A oder in beide Richtungen abfangen und modifizieren kann.
Wenn z.B. beim Nicht-Weiterleiten einer bestimmten Nachricht von A nach B dieselbe Nachricht immer öfter an A auftritt, dann weiß man, daß ein Gerät an A versucht die Nachricht zu Wiederholen weil ja die Antwort ausgeblieben ist. Und die ist ausgeblieben, weil die Fragenachricht ja garnicht durch den Filter kam
So kann man dann, indem man seine Filter/Bridge vor verschiedene Geräte desselben Busses hängt, sehen welche Nachricht woher kommt.
Beispiel:
Code:
Tankgeber ---- CAN ---- [PORTA (Bridge) PORTB ] -- CAN ----+------ [Tachoeinsatz]
\----- [Temperaturgeber]
Wenn eine Nachricht (z.B. vom Tachoeinsatz "Wieviel Sprit im Tank ?" ) am Port B ankommt, wird sie auch auf den Port A kopiert.
Der Tankgeber antwortet (kommt an A an derr Bridge an) und die Antwort landet auf Port B , wo der Tachoeinsatz sie liest als wäre nix gewesen.
Aber wir wissen, weil links an Port A nix außer dem Tankgeber dran ist, daß das eine Nachricht vom Tankgeber ist. Sonst wäre sie ja zuerst auf PORT B an der Bridge gewesen.
Nachrichten zwischen Tachoeinsatz und Temperaturgeber sehen wir nur auf Port B und kopieren sie auf Port A. Wenn wir das nicht mehr machen, dann passiert nix aufregendes, weil der Tankgeber die Nachrichten vom und zum Temperaturgeber sowieso immer ignoriert hat.
So kriegen wir raus, welche "Fragepakete" wir an z.B. den Tankgeber stellen müssen damit er loslegt und uns erzählt, wie sein Meßwert ist.
Denn wennn wir ein Paket ausfiltern, daß für den Tankgeber wichtig gewesen wäre, dann antwortet der nicht mehr und das merken wir, weil es an Port A plötzlich recht ruhig wird
Dann schnell den Filter wieder aus der Bridge raus, bevor der Tachoeinsatz die Inspektionslampe anmacht (weil der Tankgeber ausgefallen sei) und gut ist. Wir können dann probehalber daselbe selber Fragepaket auf den Port A unserer Bridge kopieren und mal gucken, ob wir eine Antwort bekommen.
Ich habe gerade mal naiv etwas rumgegoogelt eine Bridge ist z.B. die hier:
http://www.geitmann.de/ProductTree.php?CategoryID=923&PPP=&SP=0
(nur als Stütze für meine Erläuterungen) ob gerade dieses Ding nun aber so filtern kann, wie man es als KFZ Hacker im o.A Szenario braucht, ist was anderes. Es gibt aber inzwischen jede Menge Microcontroller von AVR und Microchip, Infinieon, ST und allen anderen die x CAN Module im Chip verbaut haben.
Infineons TS1115 hat locker 4 Stück und ein Winzling wie der dsPIC33FJ64GP706 von Microchip immerhin noch 2 CAN Ports. Damit könnte man sowas bauen.
Die Daten kann der Microkontroller dann ja fertig zur Analyse an 2 schnellen COM Ports rausbraten, wenn der Bus nicht zu schnell ist oder zur Not per Parallel Port an einen zweiten Controller weitergeben, der daß dann per USB oder Ethernet an einen PC absetzt. Damit währe 1 Mbit Analysefunktion schnell gemacht. Und schneller kann CAN nicht
Mein Ansatz mit der Filter/Bridge ist natürlch total Banane von einem herkömmlichem Standpunkt aus. Denn wenn Du die IDs kennst, mit denen dieses oder jenes gesteuert wird, dann muß man nurnoch die Nachrichten IDs den Zielgeräten zuordnen und dann weiß man welches Gerät was tun soll. Und mit wlcher ID das Gerät antwortet ist nach einem Blick in die hausinterne Gerätedoku auch klar. Die Nachrichten dazu kann man sich dann aus dem Analyseprotokoll holen.
Da ein Entwickler bei Firma XYZ die IDs normalerweise kennt, muß er sich nicht von grund auf im System orientieren um rauszukriegen, was woher kommt und wohin geht.
MfG
Martin
