Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Seite 1 von 5 123 ... LetzteLetzte
Ergebnis 1 bis 10 von 44

Thema: Metriken in der SPS Programmierung

  1. #1
    Registriert seit
    27.07.2012
    Ort
    AUT
    Beiträge
    480
    Danke
    84
    Erhielt 160 Danke für 90 Beiträge

    Standard


    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
    Zitieren Zitieren Metriken in der SPS Programmierung  

  2. #2
    Registriert seit
    09.08.2006
    Beiträge
    3.628
    Danke
    912
    Erhielt 656 Danke für 542 Beiträge

    Standard

    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ß.
    Geändert von ducati (07.08.2012 um 10:31 Uhr)

  3. #3
    norustnotrust ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    27.07.2012
    Ort
    AUT
    Beiträge
    480
    Danke
    84
    Erhielt 160 Danke für 90 Beiträge

    Standard

    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??

  4. #4
    Registriert seit
    09.08.2006
    Beiträge
    3.628
    Danke
    912
    Erhielt 656 Danke für 542 Beiträge

    Standard

    Was genau willst Du denn machen, bzw. wofür brauchst Du die Kennzahlen?

    Zitat Zitat von norustnotrust Beitrag anzeigen
    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ß.

  5. #5
    norustnotrust ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    27.07.2012
    Ort
    AUT
    Beiträge
    480
    Danke
    84
    Erhielt 160 Danke für 90 Beiträge

    Standard

    Hi Ducati

    Zitat Zitat von ducati Beitrag anzeigen
    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)


    Zitat Zitat von ducati Beitrag anzeigen
    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.

    Zitat Zitat von ducati Beitrag anzeigen
    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

    Zitat Zitat von ducati Beitrag anzeigen
    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...

  6. #6
    Registriert seit
    09.08.2006
    Beiträge
    3.628
    Danke
    912
    Erhielt 656 Danke für 542 Beiträge

    Standard

    Zitat Zitat von norustnotrust Beitrag anzeigen
    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.

  7. #7
    norustnotrust ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    27.07.2012
    Ort
    AUT
    Beiträge
    480
    Danke
    84
    Erhielt 160 Danke für 90 Beiträge

    Standard

    Zitat Zitat von ducati Beitrag anzeigen
    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.

    Zitat Zitat von ducati Beitrag anzeigen
    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?

    Zitat Zitat von ducati Beitrag anzeigen
    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

    Zitat Zitat von ducati Beitrag anzeigen
    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.


    Zitat Zitat von ducati Beitrag anzeigen
    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:

    Zitat Zitat von ducati Beitrag anzeigen
    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...

  8. #8
    Registriert seit
    09.08.2006
    Beiträge
    3.628
    Danke
    912
    Erhielt 656 Danke für 542 Beiträge

    Standard

    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&...w=1791&bih=794

    Gruß.

  9. #9
    Registriert seit
    09.08.2006
    Beiträge
    3.628
    Danke
    912
    Erhielt 656 Danke für 542 Beiträge

    Standard

    Zitat Zitat von norustnotrust Beitrag anzeigen
    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...

  10. #10
    norustnotrust ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    27.07.2012
    Ort
    AUT
    Beiträge
    480
    Danke
    84
    Erhielt 160 Danke für 90 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    D hast nicht zufällig noch ne Info zu der Konferenz damit ich leichter was finde?

Ähnliche Themen

  1. Kennenlernen der SPS Programmierung in Step 7
    Von dave_77 im Forum Programmierstrategien
    Antworten: 10
    Letzter Beitrag: 17.08.2012, 00:37
  2. Kennenlernen der SPS Programmierung
    Von dave_77 im Forum Simatic
    Antworten: 2
    Letzter Beitrag: 16.07.2012, 15:27
  3. Biete aktuelle Stelle als in der SPS-Programmierung
    Von Freya im Forum Suche - Biete
    Antworten: 2
    Letzter Beitrag: 24.08.2011, 10:19
  4. SPS MÖLLER PS4-151 Problem bei der Programmierung
    Von nuckes82 im Forum Sonstige Steuerungen
    Antworten: 1
    Letzter Beitrag: 24.06.2010, 00:00
  5. Softwareengineeringtools in der SPS-Programmierung
    Von arcis im Forum Programmierstrategien
    Antworten: 9
    Letzter Beitrag: 22.08.2007, 11:58

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •