Automatisierung: Unixoid vs proprietäre Software

schorsch_76

FreeBSD Fanboy
Hallo,

ich mach mir seit einiger Zeit Gedanken um Automatisierung. Auf Youtube gibt es Videos die zeigen wie der Mars Rover und die Orbiter Softwarestruktur grob aufgebaut ist. [1] Das sind im Prinzip Aktor ähnliche Systeme die unter VxWorks implementiert sind.

In der Automatisierung bin ich bisher nur ein paar Mal auf Firmen gestoßen die Qnx Neutrino eingesetzt haben. Die meisten Firmen nutzen bsp. Beckhoff, Siemens etc.

Was können Gründe sein, dass hier viele Firmen Systeme wie Beckhoff und Siemens TIA Portal einsetzen und (meiner Erfahrung nach) nur wenige Firmen unixoide Systeme.

Ich hab mir mal folgende Eckpunkte überlegt:
  • Komplexität
  • hohe Verfügbarkeit
  • hartes Realtime Verhalten
  • Lizenzkosten der Hardware und der Software (Entwicklungssystem + Laufzeitsystem)
  • Trennung der Softwareaktoren
  • Verfügbarkeit der Hardware
Kann es sein, das Firmen die auf unixoide Systeme setzen mehr aus dem universitären Umfeld kommen? Wie ist eure Erfahrung was Automatisierungssysteme betrifft?

Gruß
Georg

[1]
Um diese Inhalte anzuzeigen, benötigen wir die Zustimmung zum Setzen von Drittanbieter-Cookies.
Für weitere Informationen siehe die Seite Verwendung von Cookies.
 
Also zu dem was ich aus meinem bisherigen Studium mitgenommen habe ist es hauptsächlich die Realtime-Eigenschaften dieser Systeme. Niemand hat wirklich großartig Lust da mit so einem gigantischen Konstrukt wie Linux oder BSD zu arbeiten und dann auch noch mit Non-Mainline Patchsets die kaum jemand wirklich hart getestet hat.

Gerade im Bereich der Automatisierung ist Realtime-Verhalten wichtig, da das im "Fehlerfall" sonst Menschenleben kosten könnte.

Ein weiterer Punkt ist, wie angesprochen, die Größe. Wie es da jemand so schön ausgedrückt hat: Mit den Codezeilen in Linux, die für die Sicherheit da sind, kannst du einen Microkernel schreiben, der all die Probleme nicht hat.
 
Gerade im Bereich der Automatisierung ist Realtime-Verhalten wichtig, da das im "Fehlerfall" sonst Menschenleben kosten könnte.

Menschenleben müssen sowieso durch zertifizierte Lösungen abgesichert werden. Bsp. Pilz Notausschaltgeräte. Man "darf" zwar schon was eigenes machen, aber wenn was passiert ist man dran und muss beweisen daß die eigene Lösung sicher ist. Bei Pilz und Co kann man darauf verweisen das man sichere Systeme für die Sicherheit eingesetzt hat.

Gruß
Georg
 
Es geht mehr darum, wenn die systeminterne Sensorik irgendwas feststellt, was programmiertechnisch als Gefahr erkannt wird und im "sofort abschalten" enden sollte, dann sollte dieser Befehl auch in dem dafür vorgesehenen Zeitraum ankommen. Aber das ist auch nur ein Punkt. Es gibt noch genügend andere Punkte wo Reaktionen zeitkritisch sind, ohne jedoch eine Gefahr in dem Sinne zu sein. Also zeitkritisch nicht in dem Sinne "so schnell wie möglich", sondern eben in gewissen Intervallen.

Wegen all dem wurde das ganze Echtzeit-System ja entworfen und die großen Systeme wie Linux und BSD sind schlicht keine.
 
Das Buch "The Design and Implementation of the FreeBSD Operating System" [1] sagt auf Seite 28 dass FreeBSD einen Realtime Scheduler hat. Linux hat den PREEMPT_RT Patch und Linux hat auch RTAI.

Ich wollte zuhause mal den cyclictest von Linux compilieren aber der benötigt Linux abhängige Header. Daher werde ich einfach mal so ein Histogram Programm für die Timeslice/Jitterauswertung selbst schreiben. Evtl. kann ich auch den cyclictest aus Linux unter FreeBSD laufen lassen über den Linuxulator.

Das Echtzeitverhalten wird eigentlich immer für den zu überwachenden Prozess benötigt. bsp. syncronisierte Achsbewegungen. Mir geht es auch nicht so sehr um FreeBSD oder Linux(mit RT Patch) sondern ob ihr in eurer Laufbahn schon solche unixoiden Systeme wie Qnx/VxWorks oder eben Linux mit RT in Aktion gesehen habt. Wisst ihr warum sich jemand für dieses System (RTOS) entschieden hat? Sind diese RTOS Systeme eher auf dem amerikanischen Markt zu finden?

[1] https://www.amazon.de/Design-Implem...54461&sr=8-1-fkmr0&keywords=FreeBSD+internals
 
"jetzt fangen auch noch die Elektriker an, an der Schreibmaschine zu arbeiten" - war die spontane Aussage des Technischen Vorstandsmitgliedes einer
grossen deutschen AG, als er ( offensichtlich zum erstenmal ) einen Elekto-Ing. vor einem Simatik-Programmiergeraet sah.

Damals wurde S5 unter CP/M programmiert. Um ein paar Dateien von der HD auf Diskette zu kopieren, wurde damals schon der
IT'ler ( der sich eigentlich mit DEC PDP11 und VAX befasste ) gerufen, weil das Personal beim schlichten cp Ziel, Quelle schon
ueberfordert war, da die Reihenfolge am privaten PC unter DOS, Win etc. copy Quelle, Ziel lautete.

Warum damals nicht auf unixoide OS bei Siemens gesetzt wurde, erklaere ich (fuer mich) u.a. damit, dass bei vielen Professoren
an deutschen Unis der Geist von Vorgestern den Studenten eingepaukt wurde.
Konkret meine ich damit die damalige Ueberzeugung, dass Unix ein Time-Sharing OS sei ... und nur ein Multitasking-OS fuer den technischen
Bereich geeignet sei.
Aber vielleicht war auch die Idee von Siemens auch eine ganz andere ( immerhin hatte Siemens mit Sinix ja ein eigenens Unix)
--- man muss das im zeitlichen Kontext sehen, denn die S5 kam bereits 1979 auf dem Markt - also 2 Jahre vor Microsoft MS-DOS.

...
Gerade im Bereich der Automatisierung ist Realtime-Verhalten wichtig, da das im "Fehlerfall" sonst Menschenleben kosten könnte.
...

Damit hat das ueberhaupt nichts zu tun ... ein SPS Programm laeuft im Prinzip ( prozedural programmiert ) in einer
Endlossschleife. Aus einem Loop ergibt sich dann ein Zyklus, bzw. eine Zykluszeit - die natuerlich ueberwacht werden kann.
Es ist keine Hexerei, einen NOT-AUS Befehl, der nicht abgearbeitet wird, weil ploetzlich die Zykluszeit ueberschritten wird
( d.h. die SPS geht in STOPP-Zustand ) schaltungstechnisch abzufangen.

Und was die Real-Time-Anforderungen betrifft, die werden bei PLC"s ohnehin auf externe Baugruppen mit eigener CPU und OS
ausgelagert ( hochaufloesende Analogwertverarbeitung usw. )

In der Automatisierung bin ich bisher nur ein paar Mal auf Firmen gestoßen die Qnx Neutrino eingesetzt haben. Die meisten Firmen nutzen bsp. Beckhoff, Siemens etc.

Siemens stimmt schon - ausserhalb von den USA - denn dort ist immer noch Allen-Bradley Marktfuehrer.

Da hier auch Beckhoff genannt wurde - will ich es mal etwas polemisch formulieren:

Maschinen und Anlagen die mit Beckhoff, Omron usw. gesteuert werden, gehoeren bestenfalls in kleine Tischlereien usw. -
aber nicht in Industriebetriebe!

Nachtrag:
Warum in Tischlereien? Weil der im Fehlerfall gerufene oertliche "Elektromeister"
sehr oft mit jeder SPS ueberfordert ist - denn dann kann man auch ne Maschine mit ner
billigen Omron kaufen:-)
 
Damit hat das ueberhaupt nichts zu tun ... ein SPS Programm laeuft im Prinzip ( prozedural programmiert ) in einer Endlossschleife.

Den "Level" der "Automatisierung" meinte ich auch nicht. Es ging mir schon um die Zusammenarbeit mehrerer Maschinen in einem Netz und nicht um das kleine Programm X auf Maschine Y.
 
Aber vielleicht war auch die Idee von Siemens auch eine ganz andere ( immerhin hatte Siemens mit Sinix ja ein eigenens Unix)
--- man muss das im zeitlichen Kontext sehen, denn die S5 kam bereits 1979 auf dem Markt - also 2 Jahre vor Microsoft MS-DOS.
Ja, die Zeit ist da ein großer Faktor. Im kommerziellen Bereich erlebte Unix erst weit in den 80ern seinen Durchbruch, nachdem Bill Joy und seine Mitstreiter in Berkeley es soweit getreten hatten, dass es ausreichend bugfrei und stabil war. Zu dem Zeitpunkt waren die Grundsteine im Bereich Automatisierung (und auch andernorts) aber schon zehn bis 20 Jahre gelegt. Erschwerend kam dann noch hinzu, dass die Lizenzsituation im Bereich Unix bis weit in die 90er hinein problematisch war. Vielleicht nicht so sehr für die Endkunden, aber für die Anbieter.
 
ich kenne auch in Siemens Anlagen Beispiele für QNX-Neutrino.
Warum das dann dort genommen wird, anstatt evtl hauseigene Lösungen zu benutzen, kann ich nicht sagen. Mir drängt sich der alte Spruch auf: "wenn Siemens wüsste, was Siemens weiß..." Vielleicht ist das allgemein so, dass Entwickler zu Lösungen greifen, die ihnen bekannt oder auch nur irgendwie sympathisch sind, ohne dass tatsächlich alle Fürs und Widers technisch und kaufmännisch abgewogen werden.
 
Vielleicht ist das allgemein so, dass Entwickler zu Lösungen greifen, die ihnen bekannt oder auch nur irgendwie sympathisch sind, ohne dass tatsächlich alle Fürs und Widers technisch und kaufmännisch abgewogen werden.

Ich denke das wird ein wichtiger Punkt sein. Auch weil andere es auch so machen, muss es ja richtig sein. Also machen alle IEC 61131-3.
 
Ich denke das wird ein wichtiger Punkt sein. Auch weil andere es auch so machen, muss es ja richtig sein. Also machen alle IEC 61131-3.

..oder eben IEC61499 als Nachfolger oder Erweiterung von IEC 61131, denn bei dem in 61499 beschriebenen Kommunikationsmodell,
bekommen wir die Event-Kanaele, mit denen wir auch die Ausfuehrung von Funktionsbausteinen triggern koennen.
 
Hallo,

ich denke mal, daß es mehrere Gründe gibt
1. Bis in die 90er war für UNIX mindestens eine SPARC oder 68030 nötig
2. UNIX ist / war nicht direkt RT optimiert; QNX ist m.W. ein RT System mit POSIX Schnittstelle und nicht ein UNIX mit RT Anbau
3. Haben wir schon immer so gemacht (bloß nichts neues lernen; es gibt auch C Programmierer die von anderen Sprachen nichts hören wollen
4. Zumindest Siemens schafft es, daß das System in sich halbwegs funktioniert (z.B. die Drive Cliq Schnittstelle; O-Ton "Ich baue keinen Nicht-Siemens Umrichter ein, den muß ich dann parametrieren"
5. Es gab z.B. auch Steuerungen, die auf OS/2 aufsetzten; haben sich aber auch nicht durchgesetzt (wenig Programmierer, Kunde will das nicht, Management kennt das nicht).
6. Mgmt kennt das nicht -> also gibt's auch kein Geld
 
Bei uns in der Firma sagen sie immer "Muss es funktionieren oder darf es Siemens sein?"

Ich bin von den Siemens Steuerungen auch den letzten Systemen wie T3000 nicht sonderlich begeistert. Für mich wirkt das System sehr überladen und die Visualisierung (Java Client) äusserst träge.
Ich durfte bereits 2008 bei einem grossen Umbau auf T3000 dabei sein und musste feststellen, dass das System ein "gebastel" ist. Die Visualisierungsrechner mussten mehrmals täglich neu gestartet werden und man kann sich vorstellen, dass auch wenn die S7 dahinter ohne Probleme weiter läuft rasche Eingriffe des Betriebspersonals nicht mehr möglich sind. So wurden 100.000.- te Euros aus dem Fenster geschmissen...

So weit ich mich erinnere, hat ABB lange auf ein Linux System gesetzt ist aber mittlerweile auch auf Windows umgestiegen.

Nicht ohne Grund gibt es sehr wenige SCADA Systeme welche z.B. in Kernanlagen zertifiziert werden können.
 
Dann stelle ich mal (aus Eigeninteresse) die ketzerische Frage: Was nimmt man, wenn man es richtig machen will? Was wäre _der_ Gegenpol zu Siemens S7/SCADA?
 
Ich kann aus unserer Firma sagen, das sehr lange S7 eingesetzt wurde.
Aus folgenden Gründen wurde dann vor ca. 8 Jahren auf Beckhoff umgestellt:
  • Lizenzkosten pro Programmierer Laptop 7k+
  • jährliche Kosten für Softwareupdates der Programmierer Laptops
  • Kosten der Hardwarekomponenten
  • Performance der Hardware reichte nicht (schnelleste Tasks 250µs)
Mittlerweile hat Beckhoff bis auf ein paar Anlagen alle Steuerungen hier ersetzt. Es gibt auch ein paar Exoten die von externen Lieferanten kamen: AutomationX. Hier ist wohl das zugrundeliegende OS ein Linux mit RT Kernel [1].

Ich stelle für mich selbst nur immer alles in Frage und schau über den Tellerrand. Um den Bogen zum Ausgangspost zurück zu schlagen, schau ich eben wie es andere große Unternehmen und Projekte (MRL der Nasa) machen.

Um die Frage zu beantworten: Wie macht man es richtig? Wie ist "richtig" definiert? Was soll "richtig" sein?
  • Kosten der Hardware?
  • Kosten der Software?
  • Verfügbarkeit von Support?
  • Verfügbarkeit von Programmierern?
  • Freie Lizenzen?

Zu QNX: Das wurde afaik als QUNIX gestartet. [2]. QNX habe ich im Umfeld Medizinfertigung gesehen.

Gruß
Georg

[1] http://www.automationx.com/de/382/aXcontroller-A1600
[2] https://de.wikipedia.org/wiki/QNX
 
Ich kann aus unserer Firma sagen, das sehr lange S7 eingesetzt wurde.
Aus folgenden Gründen wurde dann vor ca. 8 Jahren auf Beckhoff umgestellt:
  • Lizenzkosten pro Programmierer Laptop 7k+
  • jährliche Kosten für Softwareupdates der Programmierer Laptops
  • Kosten der Hardwarekomponenten
  • Performance der Hardware reichte nicht (schnelleste Tasks 250µs)

man sagt zwar, dass Siemens ne Bank mit angeschlossener Elektroabteilung ist - aber 7k+ als Lizenzkosten fuer Step7 stimmt
so nun auch nicht ganz.

Sicher haben Beckhoff, Omron usw. ihre Existenzberechtigung - es kommt immer auf den Einzelfall an.

Zwar bekommen Entscheider mit kaufmaennischen Hintergrund immer ganz grosse Ohren,
wenn man denen erzaehlt was es fuer kostenguenstige
Alternativen im Automatisierungsbereich gibt ...
aber ihren eigenen Firmen Audi, BMW, Daimler wollen sie selbst dann auch nicht gegen nen Dacia oder Fiat tauschen!
 
man sagt zwar, dass Siemens ne Bank mit angeschlossener Elektroabteilung ist - aber 7k+ als Lizenzkosten fuer Step7 stimmt
so nun auch nicht ganz.

Wir hatten damals:
  • Step 7 Manager 5.x
  • Simotion Scout
  • HiGraph
  • Graph
  • Sirius (Die Siemens Safety)
  • FM3xx (Der Siemens Highspeed Prozessor)
  • und andere Siemens Software
 
Zurück
Oben