# UML zur Beschreibung von SPS Software



## norustnotrust (29 Oktober 2012)

Hallo!

Nutzt ihr eigentlich Diagramme aus dem UML Standard für Doku/Pflichtenheft? Wenn ja welche?. Außerdem würde mich interessieren ob es spezielle Literatur gibt die sich mit dem Thema UML für SPS beschäftigt?

Regards
No Rust - No Trust!


----------



## RobiHerb (29 Oktober 2012)

*Oo != st*

Sps Programme sind recht weit von OO Programmiertechnik entfernt. UML ist somit in weiten Teilen nicht anwendbar.

Klassen und Instanzen werden noch am nächsten unter ST als Funktionsbausteine angenähert.

Das einzige Programm, was ich so anwendbar gefunden habe ist der PapDesigner.

http://www.heise.de/download/papdesigner.html


----------



## norustnotrust (29 Oktober 2012)

Danke für dein Antwort. UML beinhaltet ja auch Diagrammarten die mit OO mal grundsätzlich ja nix am Hut habe: Sequenzdiagramm, Zustandsaktivitäten-Diagramm, Use-Case-Diagramm...


----------



## Thomas_v2.1 (29 Oktober 2012)

Ich habe mich jüst die Tage damit wieder beschäftigt. Nachdem ich mein auf Papier aufgezeichnetes Schema zweimal umgeworfen habe dachte ich mir jetzt probiers mal wieder digital.
Wie RobiHerb schon schrieb sind die UML-Tools nur sehr bedingt zu gebrauchen, da es sowas wie Methoden in der SPS (noch) nicht gibt. In der SPS-Programmierung nutzt man dafür häufig die In und Out-Bereiche eines FBs, und dieses Paradigma lässt sich mit UML nicht so recht abbilden.

Ich habe es erst mit den UML-Tool von Visio probiert, und dann auch mal dieses ansonsten sehr geniale Tool ausprobiert:
http://www.yworks.com/de/products_yed_about.html

Für Ablaufdiagramme ist das zwar OK, aber ich wollte ganz gerne einen groben Zusammenhang diverser Programmfunktionen zeichnen.

Jetzt habe ich es in einem vereinfachten CFC-Stil in Visio gezeichnet (kleines Bild im Anhang). Also ganz ohne Hilfsmittel einfach Kästchen gemalt und beschriftet, und diese dann untereinander mit Pfeilen verbunden. Aber im Gegensatz zu dem was die UML-Tools leisten können ist das eben nur eine dumme Zeichnung ohne dahinterliegende Logik.

Eine bessere Lösung ist mir auch noch nicht eingefallen. Mit Visio ist sowas auch recht zeitaufwändig, da man überall Verbindungspunkte setzen muss damit es halbwegs brauchbar und erweiterbar ist (und Visio eine etwas sonderbare Vorstellung vom platzieren der Linien hat). Sowas geht mit yEd viel leichter von der Hand, aber das Schema von yEd passt leider nicht auf SPS-Programme.


----------



## WalterNehr (26 November 2012)

Hallo,

als Einstieg empfehle ich z. B. folgenden Link:
http://www.uni-kassel.de/upress/online/frei/978-3-89958-600-8.volltext.frei.pdf

Dort geht es um Objektorientiertheit im Engineering von Anlagen und um den Einsatz von UML-Diagrammen bei der Steuerungsprogrammierung.

Meiner Meinung nach muss zu Beginn der Wunsch nach einer objektorientierten Modellierung bestehen.
Das sind Grundprinzipen wie z. B. 

Ein System besteht aus Objekten, die selbstständig handeln aufgrund innerer Zustände und aufgrund von Signalen aus der Umwelt.
Objekte können Teile ihrer Aufgabe an andere Objekte delegieren.
Objekte können mit anderen Objekten zusammenarbeiten.
Das ist nichts wirklich Neues. Ein gutes modulares Design sollte ohnehin so aussehen, denn letzlich sind Objekte Modelle der realen Welt.

Unter dieser Voraussetzung bietet UML dann eine vereinheitlichte graphische Sprache zur objektorientierten Modellierung und kann den Informationsaustausch z. B. zwischen Projektphasen (Anforderungsanalyse, Design, Implementierung, Test, Inbetriebnahme) oder zwischen Fachabteilungen (Mechanik, Elektrik, Steuerungssoftware) vereinfachen - im Idealfall sogar automatisieren. Proprietäre Beschreibungsmethoden wären potentiell problematischer, um nicht zu sagen ungeeignet.

Das Ziel, das Anlagen-Engineerung qualitativ zu verbessern, ist noch fern. OO und UML können ein Weg dorthin sein.

Auf jeden Fall ist es ein spannendes und interessantes Thema. In diesem Sinne, wünsche ich allen noch viel Spaß bei der Arbeit.


----------



## norustnotrust (26 November 2012)

Hallo

@WalterNehr: Ich werde mir das PDF gleich mal anschauen
@Thomas: Ich schau mir mal das yED an

Ich habe in der Zwischenzeit ein paar Zustands-Aktivitätsdiagramme sowie probeweise ein Use-Case Diagramm mit UMLet (http://www.umlet.com) gemacht. Die Bedienung ist ... interessant... aber das Format ist gut verständliches XML was die Möglichkeit eröffnen würde relativ leicht eine Art "Compiler"/"Decompiler" oder Ähnliches zu machen. Auch Templates ließen sich so leicht erzeugen. Ob sich das ganze dazu eignen würde CFC Schemas zu zeichnen werd ich mir mal anscheuen. Der Ansatz gefällt mir.

Im Grunde würde ja ein CFC ähnlicher Plan (für Verriegelungen und andere statische Zusammenhänge), ein Zustandsaktiviätsdiagramm (für Abläufe) und ein Sequenzdiagramm für Kommunikationen ausreichen um eine komplette SPS Software zu Beschreiben oder?

Vielleicht noch ein Use-Case Diagramm um die Kundensicht zu dokumentieren...

Regards


----------



## Blockmove (26 November 2012)

WalterNehr schrieb:


> als Einstieg empfehle ich z. B. folgenden Link:
> http://www.uni-kassel.de/upress/online/frei/978-3-89958-600-8.volltext.frei.pdf



Ich hab einige Teile davon überflogen.
Einiges davon (Zustandsgraphen) hat Siemens ja versucht mit Higraph umzusetzen.
Hat sich wohl aber in der Praxis nicht bewährt.

UML - meines Erachtens - auch nur bedingt geeignet für SPS. Hier sind klassiche Ablaufdiagramme doch noch häufiger anzutreffen. Komplexe Abläufe hängen oft von vielen Umständen ab, und hier wird UML sehr schnell sehr unübersichtlich.

Man kann auch Objektorientierung in der SPS auch ohne UML verwenden 

Gruß
Dieter


----------



## norustnotrust (27 November 2012)

Blockmove schrieb:


> [...]Komplexe Abläufe hängen oft von vielen Umständen ab, und hier wird UML sehr schnell sehr unübersichtlich.[...]


Ist das ein Bauchgefühl, ein Erfahrungswert?



Blockmove schrieb:


> [...]Man kann auch Objektorientierung in der SPS auch ohne UML verwenden


 Da hast du natürlich Recht aber hat wer das Gegenteil behauptet?

Regards


----------



## Blockmove (27 November 2012)

norustnotrust schrieb:


> Ist das ein Bauchgefühl, ein Erfahrungswert



Hab auch mal damit "rumgespielt"
Die internen Schnittstellen lassen sich gut darstellen.
Aber die eigentliche Logik habe ich nicht vernünftig geschafft darzustellen.
Hier sind die "alten" Diagramme irgendwie besser.
Es hängt auch immer von der Art der Anlage ab, welche Darstellung besser ist.
Aber das ist jaauch keine neue Erkenntnis.

Gruß
Dieter


----------



## borromeus (27 November 2012)

Wir müssen einem Kunden immer als Doku eine "Softwarebeschreibung" abgeben, die er versteht:
heisst: wir machen aus dem Programm einen Stromlaufplan- und das leider handmade.
Letztlich ist es die (vermutlich) einzige Möglichkeit verfahrensneutral Prozesse zu beschreiben, die ein Elektriker versteht.
Komplizierte Funktionen, die sich als Stromläufer nicht darstellen lassen werden verbal beschrieben (zB Sortierung).

Im Vergleich zu dem was ich sonst wo gesehen habe stellt diese Art das präziseste dar, lasse mich aber gerne belehren wie es anders ginge.


----------



## Little-JO (27 November 2012)

Hallo. 

Da du nach spezieller Literatur zu dem Thema fragst. Ich habe mir vor einigen Monaten mal ein sehr interessantes Buch zu dieser Thematik gekauft. Es nennt sich "SCL und OOP mit dem TIA Portal V11". ISBN: 978-3800734368

Leider konnte ich mich aus Zeitgründen noch nicht näher damit beschäftigen. Aber der Autor versucht mithilfe von SCL und auch UML als Darstellungsweise die Objektorientierung konsequent in der SPS-Programmierung umzusetzen. 

Leider ist das Buch kein Schnäppchen ... :-(


----------



## norustnotrust (27 November 2012)

Ich wer nie verstehen warum man heute nicht gleich alle Bücher auch als ebook herausbringt...


----------



## Little-JO (27 November 2012)

Ja, E-Books ist wieder ein Thema für sich. Zum einen ist es natürlich praktisch, das Know-How in digitaler Form bei sich zu haben, aber bei E-Books ist die Formatierung leider nicht so gut bzw. übersichtlich wie bei Print. Ein weiterer Nachteil ist halt, dass ein E-Book am Preis meistens auch nichts (merklich) ändert.

Man bezahlt eben doch (hauptsächlich) für die Informationen


----------



## norustnotrust (27 November 2012)

Naja, ich sitz viel im Flugzeug und ich mag nicht immer 2-3 Bücher im Gepäck haben. Der Preis ist mir da egal, mir gehts ums Gewicht.


----------



## Little-JO (27 November 2012)

Ja das geht mir ähnlich! Es hat alles seine Vor- und Nachteile.


----------



## norustnotrust (27 November 2012)

Vielleicht kannst du mir (uns) eine kurze Rezension des Werkes zuteil werden lassen damit ich abschätzen kann ob sich due Schlepperei lohnt.


----------



## mnuesser (4 Dezember 2012)

da wäre ich wohl auch interessiert


----------



## Ralle (4 Dezember 2012)

Im Internet gibt es eine recht verschworene Bücherfreundegemeinde, die scannen in mühsamer Kleinarbeit komplette Werke ein, bearbeiten die nach und tauschen die dann untereinander. Zur Legalität des Ganzen kann ich grad nichts sagen, wird wohl ähnlich wie mit dem Musiktausch sein.


----------



## Majestic_1987 (4 Dezember 2012)

Also wer behauptet, dass es keine Objektorientierung in der SPS-Programmierung gibt, der hat entweder die letzten Jahre verschlafen oder ist ignorant. In der IEC sind objektorientierte Erweiterungen definiert, sowohl Klassen (hier dann eben in Form des FB), Methoden, Interfaces, Vererbung, etc.

Fakt ist aber, dass diese Erweiterungen in CoDeSys 3.x drin sind, somit auch in IndraWorks und TwinCAT 3, nicht aber in der S7 (und wohl auch in absehbarer Zeit nicht kommen werden). Damit ist der (noch) größte Anteil automatisierungstechnischer Anlagen faktisch lediglich nicht objektorientiert programmierbar. Gehen tut das aber sehr wohl, so man denn will.

Jetzt kommt meine These, untermauert durch die Aussagen vieler SPS-Programmierer, die ich kenne: Kenne mer nit, bruche mer nit, mache mer nit. Die meisten von denen kommen (ich übrigens auch) aus der Elektrotechnik und haben mit Softwareengineering nix am Hut, somit sind vielen (bei weitem nicht allen) die Methoden der Objektorientierten Softwareentwicklung nicht geläufig, also werden die auch nicht eingesetzt.

Dennoch sehe ich darin die Zukunft, weil sich schlicht riesige Vorteile ergeben. Aber auch das muss letztlich jemand bezahlen.

Das gleiche gilt übrigens (generell) für Dokumentation: Keiner macht sie gerne, keiner kalkuliert die Zeit dafür ein und spätestens bei der IBN wird die Aktualisierung etwaiger Doku wieder geschludert. Auch hier gibt es viel Optimierungspotential.

Ich weiß, ich schreibe das alles etwas provokativ...aber ich würde mir etwas mehr Wagemut und Pioniergeist bei vielen Kollegen wirklich wünschen.


----------



## Ralle (4 Dezember 2012)

Majestic_1987 schrieb:


> Also wer behauptet, dass es keine Objektorientierung in der SPS-Programmierung gibt, der hat entweder die letzten Jahre verschlafen oder ist ignorant. In der IEC sind objektorientierte Erweiterungen definiert, sowohl Klassen (hier dann eben in Form des FB), Methoden, Interfaces, Vererbung, etc.
> 
> Fakt ist aber, dass diese Erweiterungen in CoDeSys 3.x drin sind, somit auch in IndraWorks und TwinCAT 3, nicht aber in der S7 (und wohl auch in absehbarer Zeit nicht kommen werden). Damit ist der (noch) größte Anteil automatisierungstechnischer Anlagen faktisch lediglich nicht objektorientiert programmierbar. Gehen tut das aber sehr wohl, so man denn will.
> 
> ...



Ich hätten dann aber mal wirklich eine Aussage zu den "riesigen Vorteilen", dann könnte ich ja mal darüber nachdenken. 
Was geht wirklich besser, was man nicht jetzt schon mit FB's erledigen kann?


----------



## Blockmove (4 Dezember 2012)

Ralle schrieb:


> Ich hätten dann aber mal wirklich eine Aussage zu den "riesigen Vorteilen", dann könnte ich ja mal darüber nachdenken.
> Was geht wirklich besser, was man nicht jetzt schon mit FB's erledigen kann?



Bei S7 oder TIA nix. Mit der Kombination aus FBs, Instanz- und Global-DB kannst quasi objektorientiert arbeiten. Es tun auch viele SPSler schon seit Jahren ohne dass sie sich bewusst sind, dass das OP sein könnte.
Diese Diskussion um OOP in der Automatisierung haben wir schon vor 15Jahren geführt beim Umstieg von S5->S7. 
Für uns "altmodische, ewig Gestrige" ist es halt ein Zylinder mit einem 5/2-Wege-Ventil und 2 Ini's.
Für einen OOPler ist es Objekt vom Typ Zylinder mit den Methoden Einfahren und Ausfahren und den Eigenschaften eingefahren, in Bewegung, ausgefahren.

Gruß
Dieter


----------



## IBFS (4 Dezember 2012)

Majestic_1987 schrieb:


> Das gleiche gilt übrigens (generell) für Dokumentation: Keiner macht sie gerne, keiner kalkuliert die Zeit dafür ein und spätestens bei der IBN wird die Aktualisierung etwaiger Doku wieder geschludert. Auch hier gibt es viel Optimierungspotential.



Das gleiche gilt übrigens (generell) für Dokumentation:  

- keiner sieht den Extraaufwand und daher will keiner die zusätzliche Mannwoche bezahlen.

- egal wie gut diese ist, keiner ließt sie vorher, während oder nach der Übergabe.

Neulich habe ich auf die Frage nach einer speziellen Funktion in der Anwortmail einfach die passende Seitennummer zurückgemailt  ;-)

Ansonsten Herr "Majestic_1987" Allgemeinplätze wohin man schaut  ;-)

Frank


----------



## IBFS (4 Dezember 2012)

Blockmove schrieb:


> Für uns "altmodische, ewig Gestrige" ist es halt ein Zylinder mit einem 5/2-Wege-Ventil und 2 Ini's.
> Für einen OOPler ist es Objekt vom Typ Zylinder mit den Methoden Einfahren und Ausfahren und den Eigenschaften eingefahren, in Bewegung, ausgefahren.



Es reden die am abstraktesten, die in der Realität am entferntesten von der Materie sind. 
Das ist nachvollziehbar, aber sollte nicht dazu führen das die, die am weitesten weg sind am lautesten rufen sollten.

Frank


----------



## Blockmove (4 Dezember 2012)

IBFS schrieb:


> Es reden die am abstraktesten, die in der Realität am entferntesten von der Materie sind.
> Das ist nachvollziehbar, aber sollte nicht dazu führen das die, die am weitesten weg sind am lautesten rufen sollten.



Schöner Spruch 

Als ich mit der SPS-Programmierung anfing, gab es Weg-Zeit-Diagramme. Richtig schön mit Aktoren, Sensoren und Wirklinien.
Dann kamen die Flowcharts
Später dann Nassi-Shneidermann-Diagramme
Dann hieß die Weiterschaltbedingung auf einmal Transition und die Befehlsausgabe war die Aktion und aus "=" wurde "N".
Irgenwann wurden die Zustandsgraphen hervorgeholt und alles waren Automaten.
Und in diese Automaten werden jetzt halt Objekte eingebaut.

Aber egal welche Mode gerade aktuell ist, eigentlich gibt es für mich nur 2 Sorten SPS-Programme:
Gute Programme und Scheiß-Programme :sm11:


Gruß
Dieter


----------



## Werner29 (10 Dezember 2012)

Majestic_1987 schrieb:


> Also wer behauptet, dass es keine Objektorientierung in der SPS-Programmierung gibt, der hat entweder die letzten Jahre verschlafen oder ist ignorant. In der IEC sind objektorientierte Erweiterungen definiert, sowohl Klassen (hier dann eben in Form des FB), Methoden, Interfaces, Vererbung, etc.
> 
> Fakt ist aber, dass diese Erweiterungen in CoDeSys 3.x drin sind, somit auch in IndraWorks und TwinCAT 3, nicht aber in der S7 (und wohl auch in absehbarer Zeit nicht kommen werden).



Vorsicht: die OO ist noch nicht normiert, voraussichtliches Datum der Veröffentlichung ist Februar 2013. Dort wird OO ein zentraler Teil sein.

Bernhard


----------



## Werner29 (10 Dezember 2012)

Ralle schrieb:


> Ich hätten dann aber mal wirklich eine Aussage zu den "riesigen Vorteilen", dann könnte ich ja mal darüber nachdenken.
> Was geht wirklich besser, was man nicht jetzt schon mit FB's erledigen kann?



FB's sind ja tatsächlich ein bisschen OO und waren seinerzeit auch umstritten ("Wieso muss ich da eine Instanz deklarieren?").
Ich bin im Grunde genommen hier der Schuldige, ich habe OO in CODESYS V3 implementiert.
Trotzdem will ich niemanden bekehren. Wer ohne OO auskommt, und keinen Mangel spürt, der soll doch so programmieren, wie es ihm gefällt.
(am besten natürlich mit CODESYS).

Ich drehe mittlerweile die Frage immer um: das Prinzip OO muss nicht mehr begründet werden, das hat sich weltweit durchgesetzt.
Wer sagt, OO bringt keine Vorteile bei der SPS-Programmierung, der muss begründen, warum das so sein sollte. Mir leuchtet das nicht ein.
Das Prinzip OO hängt nicht an der Aufgabe, es spielt keine Rolle, ob man einen Antrieb programmiert oder einen Compiler schreibt.
OO hat immer da Vorteile, wo man grosse, komplexe Programmieraufgaben beherrschen muss. Deswegen ist es auch so schwer, die Vorteile
an einem kleinen Beispiel zu erläutern.
Wir haben ja jetzt auch ein bisschen Erfahrung damit und im Moment ist es so, dass nur wenige Projekte die OO benutzen. In Bibliotheken
wird sie jedoch viel eingesetzt. 

Bernhard Werner


----------



## Ralle (10 Dezember 2012)

@Werner29

Ja, in Bibliotheken, entsprechend gut getestet und dokumentiert, kann ich mir das vorstellen.

Ich hab ja lange Delphi7 programmiert und dann ein wenig mit Visual#.
Da erlebte ich dann die ersten Pleiten weil ich in Objekt XY irgendwelche Daten schrieb, sich aber nciht das korrekte Ergebnis einstellte (ohne irgendwelche Fehlermeldungen). Der Fehler lag bei mir, aber er war kaum offen ersichtlich und das macht mir in einer SPS dann doch so große Bauchschmerzen. Ich hätte schon gerne rel. strenge Regeln und einen Compiler der auch moniert, was zu monieren ist und mich nicht einfach machen läßt, bis die 5 Mio. Anlage in den Schrott kann. Das ist jetzt nur eine allg. Forderung, die nichts mit eurer V3 zu tun hat, dafür hatte ich einfach noch keine Zeit, ich hab schon genug mit V2.3 zu tun.


----------

