en
de

SPS vs. Eigenbau (1)

18 Juli 2014
| |
Lesezeit: 3 Minutes

In der letzten Zeit bekommen wir bei Zühlke häufiger die Frage gestellt: Können wir statt einer Eigenentwicklung für unsere Steuerungsaufgabe nicht eine SPS-Kauflösung einsetzen? Mit eben dieser Frage darf ich mich in meinem aktuellen Projekt ebenfalls beschäftigen. Gemeinsam mit den Entwicklern des Kunden habe ich die Lösungen CODESYS von 3S und OpenPCS von InfoTeam in Betracht gezogen. Die Produktpräsentation von 3S hat einen professionelleren Eindruck bei uns hinterlassen. Ich konzentriere mich daher im Folgenden auf dieses Produkt.

Als externer Berater muss ich das Projektziel zunächst besser verstehen, bevor ich den Nutzen einer Kauflösung beurteilen kann. Da ich zeitgleich auch das Requirements Engineering verantworte, ergibt sich hier ein Synergieeffekt. Das Projektziel ist die Entwicklung einer Plattform für künftige Gerätegenerationen. Die immer wiederkehrenden Elektronikkomponenten werden als Modulbaukasten zur Verfügung gestellt. Eine Master-Steuerung übernimmt die Kontrolle der über CANopen vernetzten Module. Die produktspezifischen Steuerungsabläufe soll künftig der Domänenexperte selbst erstellen können, ohne auf die Unterstützung der Entwicklungsabteilung angewiesen zu sein. Der skizzierte Geräteaufbau klingt für mich sehr nach Prozessautomatisierung. Einer SPS gebe ich da den Heimvorteil.

Einstieg in die SPS-Welt

Auf dem Gebiet der SPS-Entwicklung habe ich bisher keinerlei Erfahrungen, daher muss ich mich Schritt für Schritt in diese neue Welt einfinden. Ein Entwickler von 3S sagte sinngemäß: „Die SPS-Welt ist für einen C-Entwickler erst mal ungewohnt, aber wenn man drin ist passt alles.“ Zumindest den ersten Teil des Satzes kann ich soweit unterschreiben. Die Entwicklungsumgebung bringt eine Software-SPS Laufzeitumgebung für Windows mit, sodass ich direkt loslegen kann. Mein USB-CAN-Adapter von PEAK wird unterstützt. Daran schließe ich meine zwei CANopen-Dummies an. Per Bus-Scan konfiguriere ich mein erstes SPS-Projekt mit wenigen Klicks. Das resultierende SPS-Programm führt  zwar noch keine Steuerungsaufgaben durch, aber die reine CANopen-Funktionalität steht direkt zur Verfügung. Soweit also ein echter Gewinn gegenüber einer Eigenbaulösung.

Als nächstes muss ich lernen, wie ich meine Module in einen Programmablauf einbinde. Grundlegend stellt mir dazu eine SPS-Entwicklungsumgebung die nach ISO/IEC 61131 standardisierten fünf Sprachen zur Verfügung, die zwei
textuellen

  • Strukturierter Text (ST)
  • Anweisungsliste (AWL),

sowie die grafische

  • Funktionsbaustein-Sprache (FBS),
  • Ablaufsprache (AS) und
  • Kontaktplan (KOP).

Meine neuen Funktionseinheiten füge ich als sogenannte Programmorganisationseinheit (POE) in mein Projekt ein. Ich habe die Wahl zwischen einem Programm, einem Funktionsbaustein und einer Funktion. Für weitere Details möchte ich auf den Standard verweisen.

Ein POE mit ST wirkt auf mich wie eine Zeitreise in die 80er Jahre, AWL versetzt mich in die Zeit der Assembler-Programmierung zurück. Die Funktionsbaustein-Sprache hat gewisse Ähnlichkeiten mit MATLAB/Simulink, wo ich die Ein-/Ausgänge von Funktionsblöcken miteinander verdrahte. Es bleibt wohl dem persönlichen Geschmack vorbehalten, ob ich lieber mit ST oder FBS arbeite. Schwierigkeiten bereitet mir die Notwendigkeit meine Funktionen für eine zyklische Ausführung zu formulieren. Die Ablaufsprache bietet hier eine interessante Möglichkeit. Mit AS kann ich Zustandsautomaten beschreiben. Die Notation ist für UML-Kenner zunächst etwas ungewohnt, aber funktional sehr ähnlich. Abläufe, die länger benötigen als einen Prozesszyklus, kann ich so elegant aufteilen.

Herstellerspezifische Erweiterungen zur Objektorientierung

Der nutzbare Funktionsumfang in CODESYS geht herstellerspezifisch über den standardisierten hinaus. So entdecke ich in etwa objektorientierte Erweiterungen. Ich möchte das bildlich auf die Strukturen aus C übertragen, die in C++ zu Klassen werden. Ich kann Funktionsblöcke mit Methoden und Eigenschaften erweitern und Vererbung nutzen. Mir gelingt es mit diesen Mechanismen auch komplexe Lösungen zu strukturieren. Ohne diese Möglichkeiten würde ich mir da deutlich schwerer tun.

Als extrem unhandlich empfinde ich hingegen, dass ich das sogenannte I/O-Mapping jedes einzelnen Moduls manuell durchführen muss. Ich bin mir ziemlich sicher, dass der Domänenexperte diese Arbeit nicht machen möchte. Eine Lösung verspricht eine CODESYS-spezifische Produkterweiterung mit dem Namen Application Composer. Mit dem Composer kann ich zunächst das Domänenmodell meiner möglichen Geräte hinterlegen. Ich schaffe mir also eine Art Domänenspezifische-Sprache, um meine Geräte zu beschreiben. In einem zweiten Schritt kann ich in den engen Grenzen des Domänenmodells mein Gerät zusammenbauen. Der integrierte Generator erzeugt dann die eigentliche Applikation, insbesondere auch das benötigte I/O-Mapping.

In einem zweiten Teil dieses Beitrags gehe ich auf die Möglichkeiten einer SPS-Lösung und die getroffene Entscheidung für dieses Projekt ein.

Kommentare (1)

SPS vs. Eigenbau (2)

21 Juli 2014 um 12:06

[…] ersten Teil dieses Beitrags habe ich über meine Erfahrungen beim Einstieg in die SPS-Welt geschrieben. In […]

×

Updates

Schreiben Sie sich jetzt ein für unsere zwei-wöchentlichen Updates per E-Mail.

This field is required
This field is required
This field is required

Mich interessiert

Select at least one category
You were signed up successfully.