Android versus SPS

standroid

Level-1
Beiträge
11
Reaktionspunkte
1
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Forums-Mitglieder.

Ich versuche seit kurzem heraus zu finden, ob sich Steuerungen in Sachen Entwicklung/Implementierung/Wartung modernisieren lassen.
Dazu habe ich unter standroid.de eine Weiterleitung zu einem Blog eingerichtet, in dem ich dieser Angelegenheit nachgehe.
Es geht dabei nicht um ein fertiges Produkt.
Viel mehr wuensche ich mir dort einige Meinungen von Euch, um heraus zu finden, ob das Vorhaben Sinn macht.


Mit Gruss
D. Steuten
 
Hallo,

ich möchte hier nicht den Miesmacher spielen, aber:

Passt der Vergleich? Das ist für mich wie "Elektroantrieb versus Auto"

Auf der einen Seite haben wir eine Komponente (das Betriebssystem),
auf der anderen Seite ein Komplettsystem aus Hardware, Runtime,
Kommunikationstechnologie und Engineeringtools.

Natürlich spricht grundsätzlich nichts dagegen, die Möglichkeiten
von Android in der Automation auszuloten, keine Frage.

Was wären den die Vorteile von Android als Steuerung?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Herr Bäurle.
die erste Reaktion und die auch schon am frühen Morgen. Niemand ist für michein miesmacher, da ich ja eben das Interesse dazu erfahren möchte.
Im allgemeinen werden beide Begriffe als Synonyme für die Dreifaltigkeit aus Hardware, Software und Entwicklung verwendet. Ein Titel wie: Speicherprogrammierbare Steuerung in der konventionellen Ausführung gegen Speicherprogrammierbare Steuerung in der Ausführung: Android-gerät, ioio-board, Android-sdk und eclipse.
das fand ich aber wenig griffig.

die Vorteile habe ich versucht in dem Blog darzulegen.
 
Also ich habe mir deinen Blog gerade durchgelesen.

In ähnlicher Form findest du das hier alle 14 Tage.
Ich kenne diese Diskussionen um die Ablösung der SPS seit Ende der 1980er.

Am ehesten haben sich SPS-Systeme auf PC-Hardware durchgesetzt (z.B. Beckhoff).
Die ganzen Versuche die SPS als solches, also zyklische Programmbearbeitung und Programmiersprachen KOP,FUP,AWL, abzulösen sind gescheitert und werden auch weiterhin scheitern.
Im Gegenteil:
Du beschreibst in deinem Blog die Vorzüge der Eventbearbeitung im Gegensatz zur klassischen zyklischen Bearbeitung.
Tja hier sieht die Wirklichkeit anders aus. Eventbearbeitung ist im Bereich Gebäudetechnik stark vertreten. Doch immer mehr Systeme werden hier durch SPS abgelöst.
Ab einer bestimmten Anzahl von Events, die auf einen Prozess / Vorgang einwirken, wird das ganze System extrem unübersichtlich. Hier ist eine klassische SPS mit zyklischer Bearbeitung und simpler Verknüpfungslogik deutlich besser.

Und selbes gilt genauso für die Programmiersprachen.
Die Vielzahl von Aufgaben, die heute mit einer SPS gelöst werden müssen, kann man nicht sinnvoll mit einer Sprache abdecken!
Du benötigst für jede Aufgabenstellung das richtige Werkzeug / die richtige Sprache.
Anstelle von weniger Sprachen werden es - glücklicherweise - sogar mehr.
Gab es früher nur KOP, FUP, AWL, so kann ich heute z.B. Schrittketten in Graph / AS, Datenbearbeitung in SCL / ST und Reglungen in CFC programmieren.
Wo soll der Vorteil sein, dies alles in Java zu tun?


Mein Fazit:
Android ist ein schönes System und ich freue mich auf schöne HMI-Systeme auf Android-Basis, aber die klassische SPS werd ich noch bis zur Rente (in max. 20 Jahren) programmieren können.

Gruß
Dieter
 
Ich habe es mir auch durchgelesen und muss sagen, dass viele der vermeintlichen Vor- oder Nachteile entweder faktisch nicht vorhanden sind (die Sicherheit der SPS gegen Virenangriffe ist wahrscheinlich höher ist definitiv höher als bei Android, da es deutlich weniger Interesse daran und deutlich weniger Menschen mit dem entsprechenden Wissen gibt) oder Vorteile zu Nachteilen uminterpretiert werden ("sequentielle" (zyklische) Programmbearbeitung.)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Namenvetter!

Frei nach Kaestner: "Es gibt nicht Gutes, außer man tut es.", kann ich die Frustration verstehen, die Ensteht, etwas Neues vorzustellen und dieses nie zu verwenden. Die Abloeseversuche der SPS seit Ende der 80er ist ein gutes Beispiel dazu.
Dass sich dies doch ein wenig auf PC-Basis durchgesetzt hat, kann verschiedene Gruende haben. Es macht aber mehr her, wenn kein vollwertiger PC fuer Steuerungsaufgaben abgestellt werden muss. Daher kann ich die schwache Marktdurchdringung schon verstehen. Ein 30Dollar, USB-Stick grosser Android-Computer koennte das ganze auch wieder anders aussehen lassen!

Ebenso verstehe ich den Reiz mittels simpler Verknuepfungslogik grosse Gedankenkonstrukte zu implementieren. Aber von Eventbearbeitung war bei mir nicht die Rede. - Im Gegenteil: Die klassische zyklische Bearbeitung laesst sich auch mittels der Objektorientierten Architektur realisieren. Ein Ablauf waere dann ein Thread von Vielen. Den Vorteil, einen einzelnen Prozess der nach dem zyklischen Dogma bearbeitet wird, kann ich bei dem heutigen Stand der Technik leider nicht erkennen.

Ich wuerde mir wuenschen, wenn du ein Beispiel fuer die Behauptung:
"Ab einer bestimmten Anzahl von Events, die auf einen Prozess / Vorgang einwirken, wird das ganze System extrem unübersichtlich. Hier ist eine klassische SPS mit zyklischer Bearbeitung und simpler Verknüpfungslogik deutlich besser." haettest.
Die Programmierung mit "Events", "Pipes", etc. ist in der Tat ein schwieriges Feld. Diese Schlagworte treten aber eher im Zusammenhang mit GUI-Programmierung auf, und waren (wie oben erwaehnt) nicht mein Thema. Einen Diskurs ueber Interrups, Polling und DMA haette ich an dieser Stelle eher erwartet.

Ein weites Feld sind auch die Programmiersprachen. Bei diesem Thema moechte ich auch keinen Grabenkrieg ausloesen. :) Was mir in diesem Zusammenhang nur wichtig ist, ist zum einen die primaer fehlende "Objektorientierbarkeit" von KOP/FUP/AWL/Graph, zum anderen das fuer diese Techniken keine einheitliche Entwicklungsumgebung existiert. Obwohl ich freimuetig zugebe, dass es mit TIA-Portal in die richtige Richtung zeigt.

Gruss
Dieter
 
Wenn ich eine SPS programmiere, dann will ich den Code, den ich implementiere, auch in der SPS laufen sehen. (ok, ist selbst bei Siemens nicht komplett so). Zumindest muß alles nachvollziehbar sein. Wenn man in große Programmiersysteme, wie MS-Visual u.ä. reinschaut, dann weiß man nicht mehr, was da wirklich zum Schluß im Prozess alles passiert, was also genau für ein Code generiert wird. Genauso geht es einem dann beim Debuggen, es gibt Fehler, die man kaum nachvollziehen kann. Ich zumindest will das in einer Steuerung nicht haben, weil bei Fehlfunktionen viel zerstört werden kann und ich für mein Programm die Verantwortung trage. Daher ziehe ich in jedem Falle die normale, einfache sequenzielle Programmabarbeitung der multi-irgendwas vor.
 
Hallo Michael.

Die Sicherheit von System dadurch zu klassifizieren, dass es wahrscheinlich weniger kriminelle Energie mit dem notwendigen Knowhow gibt als bei anderen Systemen, halte ich fuer sehr Gefaehrlich!

Es macht einen Unterschied, ob sich eine 10tonnen -Anlage sich unkontrolliert bewegt oder ob meine Emailkontakte sich im freien Umlauf befinden. Die unkontrollierte Verbreitung von Steuerung-Knowhow ist ebenfalls ein Schaden der sich auf die schon existierende Anlage auswirkt. Meistens durch die Weiterverwendung von Dritten, bedingt durch den Auftraggeber, indem er einen Auftrag neu vergibt oder durch Spionage. - Gerne haette ich dazu genaue Zahlen, die ich dann hier dargestellt haette.

Gruss
Dieter
 
Zuviel Werbung?
-> Hier kostenlos registrieren
ist das sps-forum neuerdings als marktforschungs-spielplatz anerkannt?

Ich stimme Ralle völlig zu, was die Debugging-Fähigkeiten angeht.

Man kann mit lüftungsanlagen Gebäude zerstören und mit Kesselanlagen selbige abbrennen, hier sind Aspekte an Sicherheit gefordert, speziell im Maschinenbau sollte das Berücksichtigt werden, die eine echte PC-gestützte Cross-Compiler-Umgebung nicht bieten kann. Wenn ich also hergehe und auf Basis eines Betriebssystems welches per Definition ja nicht dafür konzipiert ist solche Aufgaben auszuführen anfange dann gehe ich damit als SI bzw. Dienstleister ein Risiko ein. Zudem ist die Marktakzeptanz hierfür viel ausschlaggebender als die mögliche Technik. Automobilhersteller wollen zum Beispiel gar nicht damit konfrontiert werden. Hier wird klar wert auf "bewährtes" gelegt.
 
Hallo Ralle.

Ich glaube deine Schilderung ist des Pudels Kern. - Die Angst davor, nicht mehr Latein sondern Englisch zu sprechen, um dann eventuell nicht verstanden zu werden.
Diese Angst halte ich auch fuer voellig begruendet, zumal sie real mit der Verantwortung ueber eine Anlage existiert.
Die Uebersichtsgewinn steigt mit der Uebung. Keiner kann erwarten neue Umgebungen und Sprachen sofort zu durchdringen.

Ich kann aber mit einem Beispiel beweisen, dass sich der Blick ueber den Tellerrand lohnt. Bei deinem Szenario "Fehler", gibt es die Erungenschaft der "exceptions" bzw. "try/catch" in C++/Java/Python/...
(aus Wikipedia:)

try { funktion1(); funktion2(); ... } catch (const std::invalid_argument &e) { std::cerr << "Falsches Argument:" << e.what() << std::endl; } catch (const std::range_error &e) { std::cerr << "Ungültiger Bereich:" << e.what() << std::endl; } catch (...) { std::cerr << "Sonstige Exception" << std::endl; }

... und lassen Fehler glassklar benennen und wiederfinden.

Gruss
Dieter
 
ich programmiere selbst tag täglich mit hochsprachen genau so wie mit spsen, und glaube mir das ein "catch ex" nicht das selbe ist wie die prüfung des eigentlichen codes, dein catch ex gibt laufzeit-fehler der anwendung zutück, hier reden wir allerdings davon die fehler eines prozesses, welche üblicherweise in einer logischen verkettung von aktorik zu sensorik steht im ursprungscode zu finden. das die sps die programmierte aufgabe wunschgemäß ausführt darf unter einhaltung der spezifikationen selbiger ja vorrausgesetzt werden. bei einem selbst geschriebenen programm in einer hochsprache sieht die welt anders aus, da man deutlich mehr damit beschäftigt ist die anwendung auf funktion zu überwachen, wie dein beispiel mit dem "catch ex" beweist
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Rupp.

Ein Betriebsystem ist der Boden einer jeden EDV-Anlage. Auch einer SPS, selbst wenn man es nicht sieht und auch sonst nicht damit in Kontakt kommt.
Zum Thema Verfuegbarkeit, welches meistens gleich gestellt wird zu den Begriffen: Altbewaehrtes oder Robustheit, moechte ich diesen diffusen Kritikpunkt gerne konkretisieren.
Jedes EDV-System ist zu einer Verfuegbarkeit von 99,9% zu haben! Das kann also den Unterschied zwischen den System nicht ausmachen.
Bei der Thematik gibt es aber die nicht zu unterschaetzenden Punkte: "Sicherheitskritischer Zustand" und "Wiederanlauf im Fehlerfall". Das sind in der Tat Dinge, die als Konzepte in der SPS bestehen. - Wobei man hier auch sehr viel "Kaputt-programmieren" kann.
Ich denke aber, das sich diese Erungenschaft in andere Systeme retten laesst. Stichworte: Echtzeitsysteme und Interrupts.

Gruss
Dieter
 
Einen sauberen Code zu schreiben ist hoechste Programmiererpflicht! Wer Mumpitz programmiert, dem kann auch das tollste System, egal in welcher Sprache, nicht belehren. Und das ein Programm die gewuenschte "Verknuepfung" von Sensoren und Aktoren ausfuehrt, sollte auch staendig gegeben sein. - Getreu dem Motto: "Computer machen keine Fehler."

Was spricht denn dagegen mein Programm auf die Funktionen hin zu ueberwachen? Ist dies doch mein primaeres Ziel, dass die Anlage nach meinen Funktionen agieren soll.

Richtig ist deine Klarstellung, das Exceptions nur waerend der Laufzeit geworfen werden. Welche das sind, kann aber immer noch der Programmierer definieren. Fehler sind auch meines Erachtens nur waerend der Laufzeit zu erkennen. Testen, testen und nochmal testen, sollte eine Selbstverstaendlichkeit sein, am besten an der realen (verbauten) Steuerung.
Das schoenste Programm nuetzt wenig, wenn es nur auf dem Schreibtisch liegt.
 
Ebenso verstehe ich den Reiz mittels simpler Verknuepfungslogik grosse Gedankenkonstrukte zu implementieren. Aber von Eventbearbeitung war bei mir nicht die Rede. - Im Gegenteil: Die klassische zyklische Bearbeitung laesst sich auch mittels der Objektorientierten Architektur realisieren. Ein Ablauf waere dann ein Thread von Vielen. Den Vorteil, einen einzelnen Prozess der nach dem zyklischen Dogma bearbeitet wird, kann ich bei dem heutigen Stand der Technik leider nicht erkennen.

Ich wuerde mir wuenschen, wenn du ein Beispiel fuer die Behauptung:
"Ab einer bestimmten Anzahl von Events, die auf einen Prozess / Vorgang einwirken, wird das ganze System extrem unübersichtlich. Hier ist eine klassische SPS mit zyklischer Bearbeitung und simpler Verknüpfungslogik deutlich besser." haettest.
Die Programmierung mit "Events", "Pipes", etc. ist in der Tat ein schwieriges Feld. Diese Schlagworte treten aber eher im Zusammenhang mit GUI-Programmierung auf, und waren (wie oben erwaehnt) nicht mein Thema. Einen Diskurs ueber Interrups, Polling und DMA haette ich an dieser Stelle eher erwartet.

Ein weites Feld sind auch die Programmiersprachen. Bei diesem Thema moechte ich auch keinen Grabenkrieg ausloesen. :) Was mir in diesem Zusammenhang nur wichtig ist, ist zum einen die primaer fehlende "Objektorientierbarkeit" von KOP/FUP/AWL/Graph, zum anderen das fuer diese Techniken keine einheitliche Entwicklungsumgebung existiert. Obwohl ich freimuetig zugebe, dass es mit TIA-Portal in die richtige Richtung zeigt.

Sorry, aber ich habe den Eindruck du wirfst hier mit Begriffen und BuzzWords um dich ohne die richtigen Funktionalitäten überhaupt zu kennen.

Gerade mit der einfachen zyklischen Bearbeitung spart man sich das ganze Theater mit Events, Pipes, Interrupts. Und diese Schlagworte sind eben nicht nur Bestandteil der GUI-Programmierung, sondern eben auch der Programmierung von Anlagen!

Wie handelst du lt. deinen Ideen z.B. das Erreichen eines Endlagenschalters oder das Umschalten einer Betriebsart?
Üblicherweise sind dies doch Events, die durch Interrupts ausgelöst werden, oder?
Wenn nicht, dann musst du den Zustand von IOs durch Polling ermitteln und dann aus den Zustandsänderungen Events erzeugen.
Wie geht es dann mit den Events weiter?
Zentraler Eventhandler, Messagequeue? Wie werden deine Objekte mit den notwendigen Zustandsinformationen versorgt?
Wie stellst du Verriegelungen sicher? Semaphoren? Dann aber schön auf Deadlocks achten!

Also ich bleibe dabei:
Die Funktion einer klassischen SPS ist für die Automatisierungstechnik besser geeignet.

Achja Stichwort: Objektorientierung:
Dies hat rein gar nichts mit der Arbeitsweise einer SPS zu tun.
Du kannst wunderbar KOP/FUP mit Obejektorientierung erweitern. Beckhoff und Codesys zeigen es.
Wo jetzt im SPS-Programm steht:

Code:
U E100.0
U M10.0
= A40.1

steht halt nachher:

U Spanner.Geschlossen
U Station1.Bearbeitungsfreigabe
= Vorschub.Ausfahren

Gruß
Dieter
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Unterschied zwischen PC/Android + Hochsprachen und SPS + Sprachenwelt

Was man nie vergessen darf bei allen diesen lustigen Vergleichen:

Wildes Szenario: Atomreaktor-Steuerung

SPS (wenn in Hardware):
  • lange Verfügbakeit der 100% kompatiblen Hardware (teilweise >10 Jahre) - ein Hardware-Austausch macht dort weit weniger Kopfschmerzen
  • klar definierte Bereichsgrenzen in Geschwindigkeit und Temperatur - Wie schnell kann sie - und geht das auch bei +65 Grad?
  • (soweit ich weiss) Harte Echtzeit - Wenn der Code die Zykluszeit überschreitet geht die SPS in Stop
die obigen Punkte sind nur sehr schwer für eine Android-Umgebung zu erreichen - einer der Hauptgründe warum SPSen immer noch so existieren

(zu Soft-SPS: die Beckhoff-Leute haben ihre Industrie-PCs mit Verfügbarkeit usw. und Echtzeit in ihrem Softwarekern)

Programmiersprachen

Die fehlenenden Möglichkeiten in der SPS-Programmierumgebung führen (im Normalfall) zu einfacheren Programmen - die starken Einschränkungen erlauben
nur eine sehr dezidiert Behandlung der Anforderungen. Damit ist ein SPS-Programm in vielen Fällen per-se laufzeitstabiler als jedes Hochsprachenprogramm auf Basis von C,C++,Java oder auch C#

(Beckhoff kann auch C++ in TwinCat 3 - aber man kommt damit nicht aus dem Kern raus und kann nicht wild Win32, Datenbanken und sonstiges anzapfen)

Ich selbst bin kein SPS-Programmierer - viele Jahre C++ im Steuerungsbereich, Embdedded-Entwicklungs usw. - auch Java und C# - also Fehler zu SPS Aussagen bitte korrigieren
 
Ich kann aber mit einem Beispiel beweisen, dass sich der Blick ueber den Tellerrand lohnt. Bei deinem Szenario "Fehler", gibt es die Erungenschaft der "exceptions" bzw. "try/catch" in C++/Java/Python/...
(aus Wikipedia:)

try { funktion1(); funktion2(); ... } catch (const std::invalid_argument &e) { std::cerr << "Falsches Argument:" << e.what() << std::endl; } catch (const std::range_error &e) { std::cerr << "Ungültiger Bereich:" << e.what() << std::endl; } catch (...) { std::cerr << "Sonstige Exception" << std::endl; }

... und lassen Fehler glassklar benennen und wiederfinden.

Wenn ich das alles so lese, dann kann ich mir nicht vorstellen, das du jemals eine größere SPS-gesteuerte Anlage mit 500 - 1000 EAs programmiert hast.

Bei der SPS-Programmierung ist ONLINE-Beobachtbarkeit voin Schrittketten, Vernüpfungen usw. oberste Plicht.

Zeige mir bitte ein Projekt in deinem EVENT-Stile z.B. einen Rundschalttisch mit zwanzig Station und fünfzehn elektischen Achse, Messegeräten usw.

Gutes Gelingen.

Frank
 
Hallo Ralle.

Ich glaube deine Schilderung ist des Pudels Kern. - Die Angst davor, nicht mehr Latein sondern Englisch zu sprechen, um dann eventuell nicht verstanden zu werden.
Diese Angst halte ich auch fuer voellig begruendet, zumal sie real mit der Verantwortung ueber eine Anlage existiert.
Die Uebersichtsgewinn steigt mit der Uebung. Keiner kann erwarten neue Umgebungen und Sprachen sofort zu durchdringen.

Ich kann aber mit einem Beispiel beweisen, dass sich der Blick ueber den Tellerrand lohnt. Bei deinem Szenario "Fehler", gibt es die Erungenschaft der "exceptions" bzw. "try/catch" in C++/Java/Python/...
(aus Wikipedia:)

try { funktion1(); funktion2(); ... } catch (const std::invalid_argument &e) { std::cerr << "Falsches Argument:" << e.what() << std::endl; } catch (const std::range_error &e) { std::cerr << "Ungültiger Bereich:" << e.what() << std::endl; } catch (...) { std::cerr << "Sonstige Exception" << std::endl; }

... und lassen Fehler glassklar benennen und wiederfinden.

Gruss
Dieter

Ich hab nun auch viele Jahre lang SPS und u.a. Delphi unter Windows programmiert. Mit Delphi und libnodave hab ich eine Maschinendatenerfassung programmiert. Kleine Änderungen am Delphicode konnten große Auswirkungen haben, die ich vorher nicht einmal erahnen konnte, bis hin zu Komplettabstürzen des PC, man mußte Speicher reservieren, wieder freigeben, umkopieren usw. Sicher hab ich da nicht sauber programmiert denke ich, aber es ist wie immer, was geht wird auch gemacht und was nicht getestet ist funktioniert auch nicht. Daher sind gewisse Beschränkungen nicht immer nur ein Mangel und um meine Maschinen zu steuern fehlte mit bisher nichts.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
nicht umsonst halten die IPC Hersteller ihre Betriebssyteme ganz flach und weisen
extra darauf hin am besten so wenig wie möglich darauf zu installieren.
Ich stelle mir mal gerade vor wenn so ein Virus mal das Android BS befällt, dann heißt
es nicht mehr in der Endlage Stop, sondern freie Fahrt.
 
So wie ich das bisher verstanden habe nützt das eh nichts was wir hier vorbringen er möchte seine Feldstudie oder was auch immer es sonst sein soll durchführen ist okay lassen wir ihn.
Meiner Meinung nach ist es zwar ne Gute Idee, aber wie schon vorher erwähnt die Industrie lässt sich selten auf neues ein lieber etwas älter aber für jeden halbwegs intressierten Instandhalter zu bewältigen.
 
Meiner Meinung nach ist es zwar ne Gute Idee, aber wie schon vorher erwähnt die Industrie lässt sich selten auf neues ein lieber etwas älter aber für jeden halbwegs intressierten Instandhalter zu bewältigen.

Es gibt Ideen, die von vornheirein schon Schnulli sind. Das wäre so, als würde jemand ein Studie erstellen Achteckige Räder ans Fahrrad zu bauen.

Mir reicht schon diese "Idee" alles und jedes mit FLASH, DotNet und JAVE vollzumüllen. Wenn ich in meine Postfach will, da muß ich erst mal die neueste Flash installieren - krank sowass.


Frank
 
Zurück
Oben