Ich habe das Gefühl, dass es im Vergleich zur Verbindung über Ethernet immer weniger neue Produkte gibt, die den CAN-Bus verwenden. Somit scheint sich der CAN-Bus auf einem absteigendem Ast zu befinden. Täuscht mein Eindruck, oder seht Ihr es ähnlich?
CAN ist immer noch mit großem Abstand Mittel der Wahl im Automobil. Auch FlexRay, obwohl es den schon ewig gibt, ist erst so nach und nach am Kommen. Mag sein dass in industriellen Anlagen der CAN schon abgelöst wird. Dafür wurde er aber auch nicht entwickelt.
Das kommt ja auch immer drauf an ob man damit leben kann und will jeden Teilnehmer an einen Switch anzuschließen. Wenn für die Aufgabe CAN geschwindigkeitsmäßig reicht und die Topologie der Verkabelung nicht stört, wird es sicher preiswerter sein als Ethernet. Insbesondere wenn die Teilnehmer klein sind hat CAN seine Vorteile. Ein LPC11C24 kosten 2-3€, da ist der CAN Transciver, ein ROM-Treiber, CAN-Open-Treiber und CAN-Bootloader schon mit dabei. Das kostet die Ethernetbuchse mit Übertragern drin fast alleine. Je größer und fetter die Teilnehmer werden, desto mehr kann Ethernet sinnvoller sein. Besonders wenn die Datenmengen relativ groß sind. Wenn größere SPS Einheiten mit Buserweiterungen oder PCs kommunizieren ist Ethernet sicher besser.
Der Vorteil eines CAN ist hier : Bus mit einem duzend oder so Teilnehmern, hartes Echtzeit Verhalten im einstelligen Megabit Bereich, fuer kleine Datenpackete. Stormsparend. Der Eigenschaftenvon Ethernet sind : Beliebig viele adressaten, kein hartes Echtzeit verhalten, Datenpackete bis 1.5kByte, mehr mit TCP, Routing, Geschwindigkeit bis GBit. Zieht Strom wie Sau. Die Verbeitung ist subjektiv wenn man keinen Einblick in die Maerkte hat.
In 2001 war ich auf einer "Info-Veranstalltung" der PNO, dort hieß es: die klassischen Bus-Systeme sterben aus - die Zukunft ist Ethernet. Heute in 2014, kann ich dies immer noch nicht bestätigen. Unser Verkaufsanteil von Ethernet basierten Geräten liegt bei 15-20% p.A. und es liegt definitiv nicht an den Verkäufern. Die Industrie schreit zwar nach ProfiNet, PowerLink, Ethernet/IP oder EtherCat. Gekauft wird aber weiterhin ProfiBus und CANopen. Aber als Anbieter muss man die Ethernet Systeme im Produkprofolio haben. Eigentlich gut, sichert mir meinen Entwickler-Job :-)
Ethernet kommt ins Auto: http://www.opensig.org/ Aber bis dahin ist es noch ein ziemlich langer Weg. Und die Hardware dazu ist recht komplex und teuer, kein Vergleich zu CAN. Alleine schon, dass das nur Punkt-zu-Punkt ist macht Ethernet unflexibel. Bestenfalls könnte man Ethernet mit MOST vergleichen. Wobei MOST auf breiter Front verliert. CAN hat zu dem oben genannten auch noch den Vorteil das die Software dazu erheblich einfacher ist. Die üblicherweise 500kBit stören nur bei Daten-intensiven Anwendungen wie dem Aktualisieren von Datenhungrigen Steuergeräten. Flexray nimmt so langsam Fahrt auf, das gibt es ja auch nur erst so zehn Jahre... Die 10MBit als Eigenschaft werden im Auto schlicht kaum gebraucht. CAN-FD wurde noch genannt, das halte ich für komplett überflüssig. Das erfordert neue Mikrocontroller, da kann man auch gleich Flexray benutzen. Oder anders, CAN-FD kommt einfach viel zu spät. Grösser ist der Markt sogar noch nach unten geworden, die Anzahl der LIN-Knoten im Fahrzeug hat sich in den letzten Jahren erhöht. Für ein Bedienfeld mit Beleuchtung braucht man keine Datenrate, aber nur noch drei Leitungen zu benötigen ist nett.
Rudolph schrieb: > Alleine schon, dass das nur Punkt-zu-Punkt ist macht Ethernet > unflexibel. ...und ergibt durch den Router eine wunderschönen single point of failure Rudolph schrieb: > Ethernet kommt ins Auto: http://www.opensig.org/ Zitat: Ethernet technology allows multiple in-vehicle systems (such as infotainment, automated driver assistance and on board-diagnostics)... Die zielen wohl eher auf die ganzen Bandbreitefresser bzw. Werkstattfunktionen ab und nicht unbedingt als vollständiger Ersatz für alle derzeit verwendeten Bussysteme (zumindest kann ich auf der von dir angeführten Seite keine Anspruch in dieser Richtung herrauslesen). Und bis Ethernet mit Redundanzen, eventuell speziellen Hardware-Transcivern und angepasster Software usw. und das alles noch unter Echtzeitbedingungen robust genug ist dürfte noch einiges an Entwicklungsjahren ins Land gehen bis das auch mal den Antriebs-CAN ersetzten könnte. Und vermutlich am viel zu Komplex/Teuer werden um damit einfach nur eine Relais zum Licht anschalten auszurüsten.
Hoo schrieb: > er Vorteil eines CAN ist hier : > Bus mit einem duzend oder so Teilnehmern, hartes Echtzeit Verhalten im > einstelligen Megabit Bereich CAN garantiert, dass die Nachricht ankommt aber nicht wann. Von daher ist das mit der harten Echtzeitfähigkeit so eine Sache. Aus meiner Sicht ist das keine Eigenschaft von CAN. Genausowenig wie Ethernet. Dort erreicht man die Echtzeitfähigkeit von anderen Protokollen wie Ethercat. Ethernet wird mit Sichert mehr und mehr Einzug im Automobilbereich, bei Land- und Baumaschinen halten aber der CAN wird in den nächsten 10 oder 20 Jahren bestimmt nicht wegfallen. Alleine schon wegen CANopen, J1939, Isobus. Gerade im Maschinenbau löst Ethernet, genauer gesagt Profinet und auch Ethercat, den Profibus ab. Die Avionik setzt schon länger auf ethernetbasierte Systeme.
Maxi schrieb: > CAN garantiert, dass die Nachricht ankommt aber nicht wann. CAN hat ein klares Prioritätsschema. Der höher priorisierte Frame kommt durch, verzögert nur durch die Dauer des laufenden Frames. Das würde ich schon Echtzeitfähigkeit nennen. Nur eben nicht für jeden Frame, sondern im Rahmen eines sauber geplanten Prioritätsschemas. Bei Ringbussen wie Arcnet und Token Ring gibt es eine klar definierte Obergrenze für die mögliche Verzögerung (Fehlerzustände stets aussen vor gelassen). Im Unterschied dazu lässt sich bei heutigem Ethernet üblicher Technik keine verallgemeinernde Aussage treffen, da das entsprechende Verhalten nicht von der Ethernet-Spezifikation bestimmt wird, sondern von der Implementierung der Infrastruktur-Komponenten, also der Switches.
:
Bearbeitet durch User
A. K. schrieb: > CAN hat ein klares Prioritätsschema. Der höher priorisierte Frame kommt > durch, verzögert nur durch die Dauer des laufenden Frames. Genau! A. K. schrieb: > Nur eben nicht für jeden Frame, sondern > im Rahmen eines sauber geplanten Prioritätsschemas. Und das ist der Knackpunkt. Für mich ist das kein hartes Echtzeitverhalten, da es nur für die ersten x IDs gilt. Aus diesem Grund fahren wir auch keine Regelung über den CAN. Wie gesagt meine Meinung ist, dass der CAN noch lange bestehen bleibt. Ethernet ist bei mobilen Applikationen denkbar in Sachen Kamera oder Anbindung an das mobile Internet. In Sachen Kommunikation zwischen Steuerungen wirds wohl auch noch lange beim CAN bleiben.
Ich arbeite bei einem Maschinenzulieferer der Sensoren mit unterschiedlichsten Schnittstellen anbietet. Profibus, CAN und SSI belegen hierbei zusammen gut 70% der gekauften Schnittstellen. Die Ethernetbasierenden Schnittstellen machen weniger als 15% aus, hierbei ist EtherCat von Beckhoff noch stärker vertreten als ProfiNet. Ethernet wird kommen, aber ich denke das dauert noch eine ganze Weile - Viele unserer Kunden würden gerne bei Profibus bleiben weil es funktioniert und günstig ist, es ist eher Siemens die die Kunden auf Profinet drängen.
Also der Trend geht m.E. in Richtung Ethernet, vor allem wenn man sieht das die Kunden immer mehr Diagnose wollen, da ist der CAN irgendwann am Ende. Die Problematik mit dem Single Point of Failure könnte man mit einer Ringstruktur und intergrierten Switches lösen. Macht die Sache nicht einfacher und billiger, aber geschenkt gibts halt leider nix....
Kommt drauf an, was du unter CAN und was unter Ethernet verstehst. Im industriellen Umfeld ist EtherCAT einer der Ethernet-basierten Feldbusse, der stark im kommen ist. Mit CoE (CAN over Ethercat) können vorhandene CANopen Implementiereungen leicht auf Ethercat portiert werden, was vielfach auch gemacht wird. Die obere Protokollschicht ist dann immer noch CANopen, auch wenn die Daten physikalisch über EtherCAT laufen. Mit freundlichen Grüßen Thorsten Ostermann
Kann man eigentlich Ethernet Kabel und Übertrager in einer Bus-Struktur verwenden, natürlich mit einem anderen Half-Duplex Übertragungsprotokoll? Etwa so:
1 | ---+---------------+----------------+------------- |
2 | ---|------+--------|------+---------|------+----- |
3 | | | | | | | |
4 | | | | | | | |
5 | +-xxxx-+ +-xxxx-+ +-xxxx-+ |
6 | ==== ==== ==== |
7 | +-xxxx-+ +-xxxx-+ +-xxxx-+ |
8 | | | | | | | |
9 | GND | GND wie links GND wie links |
10 | | |
11 | | |
12 | +---[===]----< Transmitter |
13 | | 50 Ohm |
14 | | |
15 | +------------> Receiver |
Mir ist gerade klar geworden, dass meine obige Frage blöd ist. Denn bei ISDN wird das Prinzip ja angewendet. Also: geht. Nur über die Position der Abschlusswiderstände muss ich nochmal nachdenken.
Das geht natuerlich nicht. Frueher bei 10Base-T, dh 10Megabit Ethernet ueber Koak ging das nich. Beim neuen Twisted Pair geht es nicht mehr. Eben wegen der abschlusswiderstaende.
Rudolph schrieb: > CAN-FD wurde noch genannt, das halte ich für komplett überflüssig. > Das erfordert neue Mikrocontroller, da kann man auch gleich Flexray > benutzen. > Oder anders, CAN-FD kommt einfach viel zu spät. Ich seh das nicht so. FleyRay mag nett sein für Automotive. In der Industrie wird sich das nicht durchsetzen bzw. nie verwendet werden da das Protokoll zum "zusammenstöpseln" einer unbekannten Anzahl von Teilnehmern nicht wirklich geeignet erscheint. Mit CAN(FD) ist das kein Problem. Ethernet ist von der benötigten Hardware doch ne Ecke heftiger als CAN(FD). Ethernet kommt hier sicher aber CAN wird, wie schon weiter oben geschrieben, noch viele Jahr(zehnt)e genutzt werden und hat mit CANFD eben auch einen recht schmerzfreien Updatepfad. Auch war dieses Jahr auf der Embedded recht viel von CANFD zu hören. Mehr als über FlexRay in allen Jahren vorher zusammen. Mein Gefühl sagt mir das CANFD zusammen mit Ethernet der Todesstoß für das bereits wenig genutzte FlexRay sein werden. Matthias
Ne ganz interessante Technologie ist auch BroadR-Reach. Hierbei handelt es sich um einen speziellen Ethernet PHY Standard, der mit einem verdrillten Kabel auskommt, wie CAN. Das wird von den Automobilisten getrieben um Ethernet (auch Echtzeitethernet z.B. EtherCAT) leichter im Auto einzusetzen. http://en.wikipedia.org/wiki/BroadR-Reach_Ethernet_standard
>Und das ist der Knackpunkt. Für mich ist das kein hartes >Echtzeitverhalten, CAN hat schon ein Echtzeitverhalten, denn (wie geschrieben), der höchstprio Frame kommt durch. Und danach ist der nächste Frame der höchstprio, der durchkommt. Wenn man also alle Frames kennt ist es definiert, wann der einzelne durchkommt. (das mehrere Frames gleichzeitig durchgehen sollten kann ja prinzipiell nicht funktionieren) >Ethernet kommt ins Auto: Ja, aber lange nicht für jede teil.Anwendung, weil (wie geschrieben) viel zu teuer. Zudem ist das Ethernet-Protokoll (ua mit grossem Wasserkopf und viel zu hoher Min.Nutzbitzahl) ja grade nicht für Steuerungs-Kommunikation entwickelt worden.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.