Hi,
nachdem es in diesem Thread ja des öfteren (implizit) um die Frage ging: "Was hat OOP in der Automatisierungstechnik verloren?" möchte ich da einfach mal ein Statement abgeben:
Es ist sicher richtig, dass die 3S-Informatiker von von vornherein OOP sehr aufgeschlossen gegenüber stehen, schließlich wären Tools wie
CoDeSys (oder bestimmt auch Step 7) ohne OOP gar nicht zu realisieren.
Das hat natürlich erst einmal gar nichts mit Euch Anwendungsentwicklern zu tun. Ihr seid die Profis, kennt die Maschinen und Aufgaben und braucht dafür Tools, die Euch dabei behilflich sind. Wie man aus den vielen Einträgen sehen kann, sind die Anforderungen aber durchaus unterschiedlich! Und das deckt sich auch mit dem, was wir in Gesprächen auf Messen und Veranstaltungen mit anderen Applikationsentwicklern gehört haben:
* die Einen sagen: "OOP braucht kein Automatisierer"
* und die Anderen: "Endlich kann man eine SPS vernünftig programmieren"
(Das ist jetzt natürlich ganz stark vereinfacht... Es gibt zwischen diesen zwei Gruppen natürlich einiges dazwischen). In jedem Fall gibt es von (zugegeben bei weitem nicht allen) Applikationsentwicklern eine ganz massive Forderung nach OOP.
Als Tool-Hersteller hören wir solchen Input seit vielen Jahren. Gleichzeitig sehen wir, dass OOP heute nicht nur auf (Fach-)Hochschulen gelehrt wird, sondern zunehmend auch an Techniker-Schulen. D.h. es kommt eine Generation von SPS-Programmierern, die mit diesem Art der Programmierung genauso sicher umgehen, wie andere mit AWL oder Kontaktplan. Ganz ohne Wertung!
Deswegen war es immer unser Ziel, dass CoDeSys so gut wie möglich beide Seiten abdecken kann, sprich den klassischen erfahrenen SPS-Programmierer, als auch den "jungen", der voll auf die neue Möglichkeiten "abfährt". Das unsere Informatiker dabei den neueren Methoden mehr zugetan sind, möchte ich nicht leugnen. Dennoch ziehen wir immer wieder Funktionen, Bedieneigenheiten etc. nach, die uns von den klassischen Programmierern angetragen werden.
Kurz gesagt: Soll doch jeder die Programmiermethode einsetzen, die ihm am meisten zusagt!
Ohnehin werden derzeit viele Bibliotheken mit OOP erzeugt, die dann dem Anwender eine funktionale Aufrufschnittstelle bereitstellen. So sehen wir auch die vernünftigste Verwendung von OOP: Systemprogrammierer werden mit Hilfe von OOP Bibliotheken erzeugen, auf die dann Applikateure oder Inbetriebnehmer funktional zugreifen. Letztere interessiert es dann nicht, wie diese Bibliotheken erzeugt wurden - Hauptsache die tun so, wie sie sollen!
Ob sich OOP in der Automatisierungstechnik durchsetzen wird? Das kann uns eigentlich egal sein, solange die Leute gern CoDeSys einsetzen
(obwohl wir eigentlich überzeugt davon sind). Natürlich kann ich auch den Einwand verstehen, dass die echten IEC 61131-3 Tools im Vergleich zu BigS (man spricht von 70% Marktanteil in Deutschland ) klein dastehen. Andererseits sind die verbleibenden 30% im weltweit größten Automatisierungsmarkt auch kein Pappenstil, und wenn da OOP in einigen Jahren z.B. in einem Drittel der Applikationen einzieht (ist jetzt nur eine Hypothese), dann sprechen wir auch von vielen Tausenden von Maschinen... Und das nur in Deutschland.
Wir sehen uns nicht als Missionare für OOP, sondern als Tool-Hersteller, der dem Markt das geben möchte, was zur erfolgreichen Umsetzung von Automatisierungsapplikation gefordert wird. Und da gehört OOP heute einfach dazu!
.
