en
de

SPS vs. Eigenbau (2)

21 Juli 2014
| |
Lesezeit: 3 Minutes

Im ersten Teil dieses Beitrags habe ich über meine Erfahrungen beim Einstieg in die SPS-Welt geschrieben. In diesem zweiten Teil betrachte ich nun die Vor- und Nachteile einer SPS-Lösung für das konkrete Projekt.

Domänen- und Geräte-Modell

Der Domänenexperte im Projekt kann sich vorstellen mit den Möglichkeiten dieses Werkzeugs arbeiten zu können. Ich erstelle eine erste, sehr rudimentäre Version des Domänenmodells für den Composer, um ein besseres Gefühl für das Werkzeug zu entwickeln. Anschließend versucht der Domänenexperte auf dieser Basis ein Gerät zu bauen. Dabei fallen uns direkt einige Pferdefüße auf, obwohl wir wohl erst an der Oberfläche kratzen. Die benötigten CANopen-Module ergeben sich nun direkt aus dem Geräte-Modell, die Busscan-Funktion bleibt ungenutzt. Nach einer Änderung am Modell muss ich alle CANopen-Module aus meinem Projekt entfernen. Nach der Generierung muss ich bei den generierten CANopen-Modulen die NodeIDs wieder korrekt einstellen. Ersteres ist wohl ein Fehler, welchen ich auf die Unreife dieses recht neuen Werkzeugs zurückführen möchte. Zweiteres ist ein Feature, welches ich ernsthaft vermisse.

In das Modell habe ich bisher nur die logische Struktur der Geräte abgebildet. Es gibt Beispiele die auch funktionale Verknüpfungen in das Modell integrieren, etwa für eine einfache Hausautomatisierung: Einer Lampe können die Schalter zugeordnet werden, auf die sie reagieren soll. Die Funktionen des Domänenexperten zur Gerätesteuerung sind jedoch deutlich komplexer. Ein weiteres Beispiel bildet komplette prozedurale Abläufe (Aktionen und Bedingungen) im Domänenmodell nach. Dieser Lösungsweg erscheint mir sehr künstlich, da ich alles, was mir eine prozedurale Programmiersprache wie etwa ST bietet, nachbaue. Als naheliegender erachte ich meine produktspezifische Funktionalität über eigene POEs in das generierte Projekt einzufügen. Leider ist der Zugriff auf die generierten Funktionsblöcke meiner CANopen-Module ebenfalls nicht besonders elegant. Insbesondere von der logischen Struktur des Gerätemodells profitiere ich nicht. Diese Kröten müssen wir wohl schlucken.

Integrierte Visualisierung

Eine weitere große Hoffnung liegt auf der integrierten Visualisierung, die CODESYS mitbringt. Es gelingt mir recht schnell aus den vorgefertigten Anzeigeelementen eine grafische Repräsentation meines Gerätes zu erstellen. Ich kann Schalter und Lämpchen frei platzieren und direkt mit Variablen meines Steuerprogramms verknüpfen. Somit erhält der Domänenexperte einen schnellen Überblick über den Systemzustand und kann diesen bei Bedarf beeinflussen. Das Design dieser Visualisierung ist allerdings Geschmacksache und folgt nicht den sonstigen Designvorgaben im Unternehmen. Für die interne Verwendung ist das kein Problem, aber der Endkunde sollte für alle Geräte einheitliche Oberflächen bekommen. Mit entsprechendem Aufwand lässt sich die Visualisierung hinsichtlich der Designvorgaben anpassen, aber die Projektverantwortlichen präferieren die bisherigen QT-Oberflächen.

Wir überlegen daher eine eigene Client-Applikation über das bereits mehrfach eingesetzte eigene Protokoll mit der SPS-Steuerung zu integrieren. CODESYS stellt ein sogenanntes Runtime-SDK zur Verfügung, mit dem wir die Laufzeitumgebung entsprechend erweitern könnten. Alternativ halte ich es durchaus für möglich das eigene Protokoll und die Anbindung komplett in IEC-Sprachen zu implementieren. Diese Aufgabe erledigt aber wohl selbst ein erfahrener IEC-Entwickler nicht über Nacht. Diesen erfahrenen Entwickler als Dienstleister einzukaufen ist jedoch keine einfache Aufgabe, da es diese scheinbar nicht so häufig gibt wie C-Entwickler.

Schöner sticht schneller

Für die abschließende Entscheidung für oder gegen eine SPS-Lösung ist freilich ganz nüchtern das Preis-Leistungsverhältnis ein wichtiger Faktor. Wir haben daher mit allen Unsicherheiten eine grobe Aufwandsschätzung für zwei Varianten aufgestellt. Wir rechnen für die Gesamtentwicklung lediglich mit etwa 20 Prozent weniger Aufwand für die SPS-Lösung. Dies ist vor allem dem Umstand geschuldet,  dass der Endkunde gar nicht mitbekommen soll, dass im Gerät eine SPS werkelt. Diese 20 Prozent liegen dazu wohl innerhalb der Schätzungenauigkeit dieser frühen Projektphase.

Letztendlich ist für uns alle unwahrscheinlich, dass dieser Vorteil die Risiken dieser Entscheidung aufwiegt. Bisher gibt es im Unternehmen keinerlei SPS-Know-how, dieses müsste parallel zum bestehenden C-Know-how aufgebaut und gepflegt werden. Diese Aussichten stellen für den Software-Gruppenleiter einen echten Nachteil dar. Auch der Domänenexperte müsste sich in ein weiteres Werkzeug einarbeiten. Er hegt wohl zu Recht die Befürchtung mittelfristig mit Support-Anfragen seiner Kollegen zu diesem Werkzeug belastet zu werden. Die erhoffte Entlastung bei der Entwicklung neuer Gerätevarianten schwindet mit dieser Aussicht. Der Projektleiter fürchtet die Risiken einer Entscheidung für eine unbekannte Technologie in einem strategischen Plattformprojekt.

Nach vielen kontroversen Diskussionen sind wir zur gemeinsamen Entscheidung gelangt, dass diese Technologie durchaus ihre Relevanz hat. Für eine künftige Entwicklungsaufgabe, auf die das Werkzeug exakt passt, lohnt eine erneute Überlegung. Bezogen auf das aktuelle Projekt haben wir uns strategisch für Technologien entschieden, die im Unternehmen bereits verankert sind.

Kommentare (0)

×

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.

Erhalten Sie regelmäßige Updates zu neuen Blogartikeln

Jetzt anmelden

Oder möchten Sie eine Projektanfrage mit uns besprechen? Kontakt aufnehmen »