Metriken in der SPS Programmierung

norustnotrust

Level-1
Beiträge
484
Reaktionspunkte
163
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo

Hat von Euch jemand Erfahrung mit der Verwendung von Metriken (für die Qualitätssicherung) in der SPS Entwicklung? Im Internet werde ich nicht recht schlau daraus. Es gibt zwar ein Tool für die SCL Programmierung (EASYCode9) welches 3 Kennzahlen auswertet aber das Ganze scheint mir nicht besonders vailde zu sein. Ich habe die Komplexität nachgerechnet und ich bin mir nicht sicher ob die Zahlen passen. Zumal mir bei der zyklomatischen Komplexität sowieso unklar ist wie diese für ein SPS Programm berechnet werden kann. Ein ODER oder ein UND hat ja im Grunde so viele Wege wie Zustände ??

THX
 
nein, ich fang jetzt keine Diskussion zum Unterschied zwischen Theorie und Praxis an :)

äquivalent zu "Lines of Code" könnte man ja sowas wie Anzahl der logischen Verknüpfungen nehmen.

Problem sind halt die vielen Möglichkeiten ein SPS-Programm zu schreiben (KOP/FUP/AWL/SCL/CFC/SFC/Graph/HighGraph...nur allein bei Siemens) und ausserdem noch für jeden Hersteller unterschiedlich, da wirds schwierig allgemeingültige und auch noch vergleichbare Kriterien aufzustellen.

Hab dazu auch noch nix gesehn. (zum Glück)


Gruß.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Hi Ducati

Danke für deine Antwort. Nur nebenbei bemerkt, ich stelle mich der Diskussion zum Thema "Theorie und Praxis" gerne da ich selber aus der Praxis komme, in der Praxis bin und nichts mit der Lehre am Hut habe. Dennoch (oder vielleicht gerade deswegen) finde ich das Thema interessant.

Ich denke "Lines of Code" is kein wirkliches Maß denn Lines of Code wird sich gleich verhalten wie die E/As oder Meßstellen. Ich komme auch nicht aus dem Maschinenbau komme sondern eher aus dem Bereich der verfahrenstechnischen Einzelanlagen und ich glaube nicht daß sich daraus sinnvolle Kennzahlen herleiten lassen. Verschiedene Bereiche wie z.B. Kühlwasser haben sicher grundsätzlich ein ganz anderes Verhältnis zwischen logischen Verknüpfungen und EA/s (Loops) als z.B. eine Materialdosierung.

Sicher müßte es auch für SFC, Graph, Higraph andere Kennzahlen geben da diese Programmierarten ja bereits eine gewisse Abstraktion des klassischen SPS-Programmes darstellen. Für KOP/FUP/SWL/CFC glaube ich sollte es eher immer das selbe sein: Ein paar HW Eingänge und ein paar Visu-Befehle bewirken ein paar Ausgänge. Und diese Logik hat eine bestimmte Komplexität die sich doch sicher metern lassen müßte oder?

Für die Hochsprachen gibts ja solche Metriken wie Sand am Meer (Halstead, McCabe und wie sie alle heißen...) und ich frage mich warum es solche in der SPS Programmierung nicht zu geben scheint??
 
Was genau willst Du denn machen, bzw. wofür brauchst Du die Kennzahlen?

sollte es eher immer das selbe sein: Ein paar HW Eingänge und ein paar Visu-Befehle bewirken ein paar Ausgänge. Und diese Logik hat eine bestimmte Komplexität die sich doch sicher metern lassen müßte oder?

Nee, eine ähnliche Aufgabe (z.B. Ansteuerung einer Pumpe) kannst Du von ziemlich Simpel bis beliebig kompliziert aufbauen. Je nachdem, was der Kunde so wünscht bzw. wie groß die Funktionalität sein soll. Ein Pumpenbaustein aus der PCS7 Bibliothek bzw. PTE-Bibliothek hat schätzungsweise 500 Zeilen Quellcode (SCL) im SPS-Baustein und bestimmt 1000 Zeilen Quellcode (C) in WinCC. (grobe Schätzung). Wenn man jetzt die ganzen Funktionen nicht braucht, dann reicht auch ein Button (EIN/AUS) in der Visu (5 Zeilen Code) und diesen in der SPS auf nen Ausgang (auch 5 Zeilen Code).

Naja und mit Qualität hat das ganze auch nix zu tun, weil ob ne Software gut oder schlecht ist ist ne ziemlich subjektive und und vom persönlichen Empfinden abhängige Sache.

Aber prinzipiell, je mehr Zeilen Code desto höher auch die Fehlerwarscheinlichkeit. Von daher macht LOC schon Sinn, da man die wenigstens zählen kann.

...


Gruß.
 
Hi Ducati

Was genau willst Du denn machen, bzw. wofür brauchst Du die Kennzahlen?
Nunja, was man mit den Kennzahlen machen könnte hängt sicher damit zusammen welche Aussage sie hätten. ;) Mein grundsätzliches Problem ist ja daß es keine zu geben scheint.

Mir würden aber zumindest folgende Anwendungsfälle vorschweben:

- Wenn ich mir im Zuge von Programmreviews Programme ansehe fallen mir immer wieder Stellen auf die einfach viel aufwendiger gemacht sind als sie eigentlich sein müßten. Das fängt an daß sich Bedingungen vereinfachen ließen und endet dort daß Bedingungen an verschiedenen Stellen mehrfach eingebaut wurden (Jemand war sich offenbar nicht mehr sicher ob dieses und jenes schon berücksichtigt hat - Group LOCK&READY und dann noch mal fürs Feldgerät LOCK&READY und was weiß ich noch wo überall). Bei der Simulation fällt das natürlich nicht auf, solange es funktioniert und beim Review selbst fallen nur Sachen auf die ins Auge springen. Wenn aber bei der IBN noch was geändert werden muß fangen die Probleme an. Dafür würde ich mir ein Auswertungstool für das Projekt wünschen das verdächtige Stellen aufzeigt damit diese im Zuge vom Review gezielt durchsucht werden kann

- Speziell Libaries werden ja immer wieder überarbeitet, verbessert und mitunter auch vereinfacht. Wenn man ein paar Kennzahlen hätte könnte man feststellen ob die letzten Änderungen wirklich einer Verbesserung im Sinne einer Vereinfachung gedient haben

- Gerade in Libaries gibt es immer wieder Auswüchse in Sachen "universelle Bausteine" die dann irgendwan so universell sind daß sie niemand mehr wirklich versteht (außer der, der sie gerade programmiert hat) Mit ein paar Komplexitätskennzahlen könnte man klare Regeln definieren wie viel Komplexität in einem Baustein stecken darf/sollte

(to be continued)


Nee, eine ähnliche Aufgabe (z.B. Ansteuerung einer Pumpe) kannst Du von ziemlich Simpel bis beliebig kompliziert aufbauen. Je nachdem, was der Kunde so wünscht bzw. wie groß die Funktionalität sein soll. Ein Pumpenbaustein aus der PCS7 Bibliothek bzw. PTE-Bibliothek hat schätzungsweise 500 Zeilen Quellcode (SCL) im SPS-Baustein und bestimmt 1000 Zeilen Quellcode (C) in WinCC. (grobe Schätzung). Wenn man jetzt die ganzen Funktionen nicht braucht, dann reicht auch ein Button (EIN/AUS) in der Visu (5 Zeilen Code) und diesen in der SPS auf nen Ausgang (auch 5 Zeilen Code)..

Wenn ein Baustein 30 Eingänge hat und 6 Ausgänge mögen 500 Zeilen Quellcode gerechtfertigt sein, wenn ein Ausgang 1 Ausgang hat eher nicht.

Naja und mit Qualität hat das ganze auch nix zu tun, weil ob ne Software gut oder schlecht ist ist ne ziemlich subjektive und und vom persönlichen Empfinden abhängige Sache.
Dem kann ich nur teilweise beipflichten. Kennzahlen bedürfen sicherlich einer Interpretation. Komplexe Aufgaben haben oft komplexe Lösungen, aber einfache Aufgaben sollten immer einfache Lösungen haben :ROFLMAO:

Aber prinzipiell, je mehr Zeilen Code desto höher auch die Fehlerwarscheinlichkeit. Von daher macht LOC schon Sinn, da man die wenigstens zählen kann.
Ja, in Relation zu den E/As hast du sicherlich Recht. Die Frage ist ob wie man damit für einzellne Teile eine einigermaßen belastbare Aussage zusammen bringt...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
fallen mir immer wieder Stellen auf die einfach viel aufwendiger gemacht sind als sie eigentlich sein müßten

Das ist Deine subjektive Meinung. Der Programmierer könnte Dir da sicherlich erklären, warum das so ist. (und wenns nur die Erklärung ist, das bei der Inbetriebnahme/Stillstand einfach nicht mehr Zeit war, um "sauberer" zu programmieren)

Du suchst ne Software, welche erkennt, ob ein Programm auch hätte "sauberer" programmiert werden können.

Dazu müsste man die Kriterien erstmal festlegen, was dann schon subjektiv ist. Es gibt gerade bei der SPS-Programmierung oft viele Lösungen die zum Ziel führen. Welche man davon anwendet ist eigentlich egal, da das Problem ist, die Lösung zu finden und wenn sie dann funktioniert ists doch gut. Dann fang ich nicht noch an weitere Lösungen zu suchen nur um zu schaun, ob die evtl. "besser" wären.

Das meiste was Du oben geschrieben hast ist rein subjektiv. Der eine findet irgendwas einfach der andere nicht. Und ausserdem weiss ich immer noch nicht, was Du eigentlich machen willst.

Aber folgendes macht Sinn:

- Man erstellt ein sinnvolles Gesamtkonzept für die Automatisierungsanlage
- Man definiert klare sinnvolle Regeln, an die sich alle Programmierer halten müssen.
- Man definiert vor Programmierbeginn, was das das Programm eigentlich machen soll.
- Man gibt dem Programmierer genügend Zeit.
- ...

Dann kommt auch ordentliche Software raus.
 
Das ist Deine subjektive Meinung. Der Programmierer könnte Dir da sicherlich erklären, warum das so ist. (und wenns nur die Erklärung ist, das bei der Inbetriebnahme/Stillstand einfach nicht mehr Zeit war, um "sauberer" zu programmieren)

Das bin ich nicht deiner Meinung. Es gibt Netzwerke die sich mittels Schaltungssynthese vereinfachen lassen (Ich gebe zu, in seltenen Fällen kann es Sinn machen aufgrund der Leserlichkeit dies nicht zu tun, in 99% der Fälle ist es aber sinnvoll). Darüberhinaus gibt es Dinge die "objektiv" unnötig aufwendig sein. Es erschließt sich mir z.B. kein Grund Flankenauswertungen zu lassen wo keine Flankenauswertungen notwendig wären. Aber das, denke ich, ist eh common sense und eigentlich nicht Kern meiner Frage.

Du suchst ne Software, welche erkennt, ob ein Programm auch hätte "sauberer" programmiert werden können.
Fast. Ich hätte gerne eine Software die erkennt welche Programmteile man betreffend einer Vereinfachung untersuchen sollte. Da es diese offenbar nicht gibt frage ich hier im Forum ob jemand eine Ahnung oder Idee von bzw. sogar Erfahrung mit der Theorie/Mathematik hat um sich ein solches Tool selbst schreiben zu können. In der Hochsprachenentwicklung werden solche Auswertungen ja auch verwendet, warum also nicht in der SPS Entwicklung?

Dazu müsste man die Kriterien erstmal festlegen, was dann schon subjektiv ist.
Ich fürchte mittlerweile fast das reicht nicht. Man müßte die Kriterien erst mal finden bevor man sie subjektiv festlegen kann :confused:

Es gibt gerade bei der SPS-Programmierung oft viele Lösungen die zum Ziel führen. Welche man davon anwendet ist eigentlich egal, da das Problem ist, die Lösung zu finden und wenn sie dann funktioniert ists doch gut.
Das sehe ich nicht so. Ich will daß die gefundene Lösung dem Anspruch genüge tut daß sie robust, fehlerunanfällig, leserlich, erweiterbar, testbar, debugbar uvm ist.


Dann fang ich nicht noch an weitere Lösungen zu suchen nur um zu schaun, ob die evtl. "besser" wären.
Das will ich dir fast nicht glauben ... aber das mußt du wissen.


P.S.: Ich habe im Forum einen Eintrag von dir gefunden:

Hmm, naja bissl leid können einem die Entwickler auch tun. Es werden immer mehr Funktionen in der SPS gefordert (von wem auch immer) und irgendwann wirds unüberschaubar und es schleichen sich Fehler ein. Je komplexer das ganze System desto mehr Fehler sind auch drin. Und die Entwicklungszeit wird auch immer kürzer und die Zeit bis ein neues Produkt auf den Markt kommt auch.
Nicht umsonst gibts ja die F-Technik bei der u.a. der Umfang auf die grundlegenden Dinge reduziert ist, und somit (hoffentlich) zuverlässiger.

Gruß.

PS. vielleicht wird die Zuverlässigkeit, welche früher der SPS-Technik allgemein zugeschrieben wurde, bald nur noch mit F-Technik erreicht...

Ich finde das beschreibt meine Sicht der Dinge ganz gut. Aber ich glaube daß die Komplexität in den heutigen System auch daran liegt daß sich die Lösungen nach den technischen Möglichkeiten strecken anstatt sich an den technischen Notwendigkeiten zu orientieren...
 
einige Sachen wrden unter dem Stichwort "Software Safety Integrity" behandelt...

erinnere mich auch noch an nen Konferenzbeitrag da gings um Ausfallwahrscheinlichkeit von Automatisierungstechnik in AKWs. Da wurde auch Software behandelt, aber so weis ich weiss haben die auch LOC angesprochen...

Naja, vielleicht kommst Du aus der Richtung dem Thema näher.

Aber dabei gehts eher um theoretische statistische Berechnungen und dazu sag ich nur:

http://www.google.de/#hl=de&gs_nf=1&cp=25&gs_id=2&xhr=t&q=So+l%C3%BCgt+man+mit+Statistik&pf=p&output=search&sclient=psy-ab&oq=So+l%C3%BCgt+man+mit+Statistik&gs_l=&pbx=1&bav=on.2,or.r_gc.r_pw.r_qf.&fp=df917a291a6ffb4c&biw=1791&bih=794

Gruß.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Es gibt Netzwerke die sich mittels Schaltungssynthese vereinfachen lassen
macht doch seit zeiten der Logikgatter keiner mehr...
Ich will daß die gefundene Lösung dem Anspruch genüge tut daß sie robust, fehlerunanfällig, leserlich, erweiterbar, testbar, debugbar uvm ist.
wer will das nicht... aber Theorie!=Praxis
Aber ich glaube daß die Komplexität in den heutigen System auch daran liegt daß sich die Lösungen nach den technischen Möglichkeiten strecken anstatt sich an den technischen Notwendigkeiten zu orientieren...

Jo, oder an den Anpreisungen der Aussendienstler. Wenn der Kunde das hört, will er das oft auch...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Muss ich mal in meinen alten Unterlagen schaun...

Aber was wird das ganze denn jetzt? Nen Forschungsprojekt zum Thema "Anwendung der Algorithmen zur Softwarequalitätmessung auf die Programmerstellung in der Automatisierungstechnik" :confused:

Könnte man ja fast ne Promotion draus machen... :)
Aber mir wär das zu theoretisch.

Gruß.
 
Meine ehrliche Meinung dazu:
Das Ganze lohnt der Mühe nicht.
Du kannst nicht einfach Methoden aus der PC-Programmierung in die SPS-Welt tragen.
Automatisierungs- und Anlagentechnik sind andere Welten.

Gruß
Dieter
 
Aber das hat doch nix mit der Anwendbarkeit von einfacher Schaltungsalgebra zu tun oder?

anwendbar ist die schon. es macht nur niemand. Warum auch, Speicherplatz ist genug da, und meistens ist das unvereinfachte Programm deutlich besser zu verstehen.

Im Idealfall gibts ne verbale Beschreibung der Steuerungsaufgabe (wenn Taster 1 UND NICHT Taster 2 ODER Taster 3 dann Pumpe 2 an). Dann programmier ich das auch so und fang nicht an das zu vereinfachen um ne Verknüpfung zu sparen. Wer sollte das denn in Betrieb nehmen?

Gruß.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Meine ehrliche Meinung dazu:
Das Ganze lohnt der Mühe nicht.
Du kannst nicht einfach Methoden aus der PC-Programmierung in die SPS-Welt tragen.
Automatisierungs- und Anlagentechnik sind andere Welten.

Gruß
Dieter
Seh ich auch so, aber:
Immer ne Frage warum man das machen will, deshalb hab ich die Frage nach "warum" auch schon mehrfach gestellt.
Forschen ist per se ja nicht sinnlos.
Für viele Anlagen müssen auch Risikobewertungen durchgeführt werden und da kommt die Software meines Erachtens zur Zeit wirklich zu kurz.

Liegt aber wirklich alles im subjektiven Auge des Betrachters.
 
Forschen ist per se ja nicht sinnlos.
Für viele Anlagen müssen auch Risikobewertungen durchgeführt werden und da kommt die Software meines Erachtens zur Zeit wirklich zu kurz.

Stimmt, aber wenn es notwendig ist, dann gibt es dafür Validierung nach V-Model und / oder Unittests.
Diese Methoden der Qualitätssicherung haben sich wohl schon seit den Zeiten bewährt als IT noch Datenverarbeitung hieß ;)

Gruß
Dieter
 
@Ducati: Nein, es soll kein Forschungsprojekt werden. Ich hatte gehofft daß jemand die Arbeit bereits gemacht hätte ;). Das "Berufsgenossenschaftliches Institut für Arbeitsschutz - BGIA" hat was dazu gemacht sehe ich gerade...

@Blockmove: o_O

Du kannst nicht einfach Methoden aus der PC-Programmierung in die SPS-Welt tragen.
Automatisierungs- und Anlagentechnik sind andere Welten.
Dieter

Stimmt, aber wenn es notwendig ist, dann gibt es dafür Validierung nach V-Model und / oder Unittests.
Diese Methoden der Qualitätssicherung haben sich wohl schon seit den Zeiten bewährt als IT noch Datenverarbeitung hieß :wink:

Widerspruch :confused:
 
Teilweise überlappen sich die verschiedenen Themen auch etwas. Eigenlich sind ja Softwarekomplexität und Validierung 2 verschiedene Dinge.

Man kann aber davon ausgehen, das bei der Validierung evtl. Fehler übersehen werden. Somit bleibt ein "Restrisiko". Und die Wahrscheinlichkeit dieses Restrisikos hängt halt mit der Komplexität des Programms zusammen...

Gruß.
 
Nein, es soll kein Forschungsprojekt werden.

Hmm, dann sehe ich momentan ähnlich Blockmove den Sinn des Ganzen nicht. Leider willst Du uns ja auch nicht aufklären...

Die ganze Diskussion gehört dann eher in die Rubrik Stammtisch.

nochmal meine konkrete Antwort zur Ausgangsfrage: Nein, ich habe keine "Erfahrung mit der Verwendung von Metriken (für die Qualitätssicherung) in der SPS Entwicklung"

Gruß.
 
Zurück
Oben