Profibus Echtzeitfahigkeit

Dumme Frage:

Warum soll man bei einer zyklische Übertragung keine Echtzeitfähigkeit 
machen können?

Hi, Sascha,

> hätte mal kurz eine Frage. Ist Profibus eigentlich echtzeitfähig?
Antwort von Radio Eriwan: "Im Prinzip ja. Allerdings nicht mehr, wenn 
die Bezeichnung 'Echtzeit' ernst genommen wird."

Unter "CAN" und "Echtzeit" findet sich eine Flut an Beiträgen zu diesem 
Thema. Die Autobauer haben so hohe Anforderungen an die Echtzeit, wie 
die Verzögerung des Airbags auf fahrlässige Tötung hinausläuft.

> als Profibus DP V0 schon mal nicht, weil er nur zyklische Übertragung
> vorsieht.
Die Frage ist, ob die Zykluszeit klein genug gemacht werden kann, damit 
der Airbag noch rechtzeitig zündet. Deshalb gibt's im Auto ja auch 
mehrere CAN-Busse.

Ciao
Wolfgang Horn

Sascha M. schrieb:
> Also das ist halt keine Echtzeit mehr.
wo steht das?

eine CPU arbeitet auch Zyklisch und kann echtzeitfähig arbeiten.

Echtzeit sagt nichts darüber aus, wie schnell eine Reaktion erfolgen 
soll. Sie definiert eine Zeit bis wann eine Reaktion erfolgen muss.

Sascha M. schrieb:
> Hallo Peter, aber ist das dann nicht so, dass jedes Feldbus als
> echtzeitfähig bezeichnet werden kann? Was ich zum Beispiel sicher weiß,
> dass Ethernet und auch CAN-Bus als nicht echtzeitfähig gesehen werden,
> wegen CSMA/CA

bei CSMA kann es ja im schlimmsten fall passieren, das gar keine Infos 
mehr übertrage werde können, weil es nur noch Kollisionen gibt.

Wenn eine Übertragung Zyklisch ist, kann man doch genau vorhersagen bis 
wann die Daten übertragen werden.

Hallo,
du musst nur, die maximal erlaubte Verzögerung mit dem Vergleichen was 
du garantieren Kannst.
Z.B. wenn du mit 16m/h fährst du vor einer gegebenen Wand stehen bleiben 
willst und du noch 320m vor dir hast und bis zu 17m vor der Wand stehen 
bleiben darfst, langt dir eine Komminikation die bei einer 
Detektionsentfernung von 16m, die es irgendwie hinkriegt 1h zwischen dem 
Aufnehmen "Da ist eine Wand" bis "Steht" zu brauchen. Wenn du aber mit 
1600m/h fährst hast du nur noch 0,6min, wenn du 16000m/h dann hast du 
noch 0,3min und bei 160000 hast du noch 0,06min.
Eine Zyklischer Bus ist deutlich einfacher nachzuweisen, dass er 
Echtzeitfähig ist als ein asynchroner. Beim Asynchronen kann dir jeder 
reinspucken. Beim Zyklischen weist du wann die Daten wieder gelesen 
werden.
Zykluszeit 100ms (dann weist du dass alle 0,1s neue Daten anliegen)
Daher ganz einfach ist etwas so langsam dass dir die 0,1s (Sensor -> 
SPS) + Verarbeitung + 0,1s (SPS -> Aktor) < erlaubte Zeit dann bist du 
echtzeitfähig.

mfg
ich

Hi,
CAN CSMA/CA
Ethernet CSMA/CD

wenn ichs noch richtig weiß
Bei Ethernet werden die Daten zerstört auf dem Bus, bei CAN kommt die 
höchstpriore Nachricht durch.

Mfg
ich

wobei bei Ethernet mit Erfindung von Duplex und Switchs keine 
Kollisionen mehr möglich sein.

Hi, Sascha,

> Dann würde ich also antworten, dass sowohl Profibus DP in allen
> Ausführungen, als auch PA echtzeitfähig sind.
Dies pauschale Antwort ist leicht zu wiederlegen mit einer Anordnung, wo 
die Reaktion eben zu spät kommt.
Pack da also noch Weichmacher rein: "Für viele Anwenden" oder "Aussage 
kann erst nach Simulation anhand klarer Forderungen getroffen werden."

Ciao
Wolfgang Horn

Peter II schrieb:
> bei CSMA kann es ja im schlimmsten fall passieren, das gar keine Infos
> mehr übertrage werde können, weil es nur noch Kollisionen gibt.

ich schrieb:
> Hi,
> CAN CSMA/CA
> Ethernet CSMA/CD
>
> wenn ichs noch richtig weiß
> Bei Ethernet werden die Daten zerstört auf dem Bus, bei CAN kommt die
> höchstpriore Nachricht durch.

Ob etwas ein Bussystem echtzeitfähig hängt nicht mit der physikalischen 
Methode zusammen.

Peter II schrieb:
> Wenn eine Übertragung Zyklisch ist, kann man doch genau vorhersagen bis
> wann die Daten übertragen werden.

Wenn die maximale Zykluszeit für diese Anwendung ausreicht, dann ist 
dieser Bus für diesen Fall echtzeitfähig.


Echtzeitfähigkeit von Bussystemen ist nur durch eine einzige Größe 
definiert. Diese Größe ist die maximale Zeit, welche ein Sender braucht 
um einem Empfänger etwas mitzuteilen. Es gibt Bussysteme, da kann man 
die maximale Zeit nicht eindeutig berechnen (z.B. Standard CAN) und es 
gibt Bussysteme, bei denen kann man die maximale Zeit eindeutig 
berechnen. Alle diese  Bussysteme, bei denen bei der maximalen Zeit ein 
eindeutiger Zahlenwert rauskommt sind erstmal echtzeitfähig. Jetzt muss 
man aus diesen Bussystemn nur noch eins aussuchen, welches für die 
gewünschte Anwendung schnell genug ist.

1234567890 schrieb:
> maximale Zeit nicht eindeutig berechnen (z.B. Standard CAN)

Nachtrag:
Für CAN gibt es nur einen einzigen Identifier, bei dem diese maximale 
Zeit berechnet werden könnte. Bei allen anderen Identifiern steht in den 
Sternen, wann die Nachricht ankommt, da der Zeitraum von allen Sendern, 
welche Nachrichten mit niederwertigeren Identifiern verschicken, 
abhängt.

1234567890 schrieb:
> Nachtrag:
> Für CAN gibt es nur einen einzigen Identifier, bei dem diese maximale
> Zeit berechnet werden könnte.

was passiert wenn alle Geräte gleichzeitig mit dem Identifier senden? 
Oder muss das "per Software" ausgeschlossen werden?

Oh, den Fall habe ich ganz vergessen! Dann gewinnt die Nachricht mit den 
niederwertigsten Daten! :-)
Wie man sehen kann, ist es nicht sinnvoll CAN in Echtzeitanwendungen 
einzusetzen.
Dafür gibt es eine Sonderform von CAN und die heißt glaube ich CAN-TT.

Jürgen D. schrieb:
> Deshalb wählt man bei CAN den Identifier ja auch nach der Wichtigkeit
> der Nachricht.
> Also eine Notbremsung sollte da schon eine deutlich höhere Wichtigkeit
> gegenüber der Sitzheizung haben :)

Und damit ist der Identifier und der Inhalt der Nachricht für die 
Notbremsung eindeutig definiert: Alles Nullen. Und was machen wir mit 
dem Airbag?
Nochmal: CAN ist nicht echtzeitfähig.
Nachrichten mit einem niederwertigeren Identifier kommen früher an, als 
Nachrichten mit einem höherwertigem Identifier. Aber wann kommen sie 
denn spätestens an?

Jürgen D. schrieb:
> Na der Airbag bekommt die Nummer 1. Dann ist seine Anforderung
> spätestens nach einer Notbremsanforderung dran.
> Das lässt sich ja wieder berechnen.

Das kommt drauf an, wie oft deine Notbremsanforderung gesendet wird.
Wird sie maximal einmal gesendet? Kann sie nur von einem Teilnehmer 
gesendet werden? Usw.

CAN ist ein Nicht-Deterministisches System. Das heißt, man kann die 
maximale Reaktionszeit nicht berechnen und damit ist das System nicht 
echtzeitfähig.
Man muss ziehmlich viel Klimmzüge machen, dass einzelne Nachrichten mit 
großer Wahrscheinlichkeit innerhalb einer bestimmten Zeit ankommen.
Das aufgrund statistischer Ermittlungen die Reaktionszeit in 99% 
ausreicht, ist eine andere Sache.