# Metriken in der SPS Programmierung



## norustnotrust (6 August 2012)

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


----------



## ducati (7 August 2012)

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ß.


----------



## norustnotrust (7 August 2012)

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


----------



## ducati (7 August 2012)

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



norustnotrust schrieb:


> 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ß.


----------



## norustnotrust (7 August 2012)

Hi Ducati



ducati schrieb:


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




ducati schrieb:


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



ducati schrieb:


> 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 



ducati schrieb:


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


----------



## ducati (7 August 2012)

norustnotrust schrieb:


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


----------



## norustnotrust (7 August 2012)

ducati schrieb:


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



ducati schrieb:


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



ducati schrieb:


> 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 



ducati schrieb:


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




ducati schrieb:


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



ducati schrieb:


> 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ß.
> ...



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


----------



## ducati (7 August 2012)

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ß.


----------



## ducati (7 August 2012)

norustnotrust schrieb:


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


----------



## norustnotrust (7 August 2012)

D hast nicht zufällig noch ne Info zu der Konferenz damit ich leichter was finde?


----------



## norustnotrust (7 August 2012)

ducati schrieb:


> macht doch seit zeiten der Logikgatter keiner mehr...



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


----------



## ducati (7 August 2012)

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" 

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

Gruß.


----------



## Blockmove (7 August 2012)

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


----------



## ducati (7 August 2012)

norustnotrust schrieb:


> 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ß.


----------



## ducati (7 August 2012)

Blockmove schrieb:


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


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.


----------



## Blockmove (7 August 2012)

ducati schrieb:


> 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


----------



## norustnotrust (7 August 2012)

@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: 



Blockmove schrieb:


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





Blockmove schrieb:


> 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


----------



## norustnotrust (7 August 2012)

Außerdem: Der Thread zum Thema Unit-Test kommt noch


----------



## ducati (7 August 2012)

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ß.


----------



## ducati (7 August 2012)

norustnotrust schrieb:


> 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ß.


----------



## norustnotrust (7 August 2012)

He, was soll das heißen?



norustnotrust schrieb:


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



Ich will kein Forschungsprojekt ich will eigentlich Software-Metriken einsetzen um die Qualität der Programme zu verbessern...


----------



## ducati (7 August 2012)

Hmm, ich glaub nicht, dass solch ein Programm, wenn es denn eins geben würde, etwas bringt. Dafür sind die Zusammenhänge in der SPS (und erst recht wenn die Visu dazu kommt) einfach zu komplex,
und wie gesagt die Kriterien zu subjektiv. 

Ein Codegenerator, welcher den Code aus Templates je nach Anlagenkonfiguration generiert, bringt schon eher was. Das sind aber die Ansätze von PCS7.

bevor die Software geschrieben wird, ordentliche Kriterien aufstellen. Siehe mein Beitrag #6 dann wird alles gut.

Gruß.


----------



## norustnotrust (7 August 2012)

Ich verstehe und teile eure Zweifel bezüglich Kosten/Nutzen Auf jeden Fall bin ich überrascht daß es dazu so wenig zu finden ist... Es wundert mich halt trotzdem daß sich nicht ein paar kluge Köpfe in den Unis dieser Frage mal gewidmet haben. Auch wenn sie zum Schluß kämen daß das ganze ein nutzloses Unterfangen ist, dann ist das ja auch eine Aussage oder? Zu sagen "es bringt sicher nix" ist halt auch ein Totschlagargument. Offensichtlich wissen wir nicht ob oder was es bringt.

OT.: Ich bin ja eh bei euch Ducati&Blockmove Spezifikation, Code- Generation, Programmierstandards und Richtlinien sowie Simulation sind essentielle Themen. Natürlich arbeiten wir damit und auch da bin ich interessiert und ständig dran das weiterzuentwickeln. Das eine schließt das andere aber nicht aus sondern könnte sich imho wunderbar ergänzen. Nur war/ist für mich eben Thema dieses Threads "Metriken" und nicht "was sollte man schwerpunktmäßig alles diesem Thema vorziehen".


----------



## Blockmove (7 August 2012)

norustnotrust schrieb:


> @Blockmove:
> Widerspruch



Nein, denn die Grundlagen dazu sind - meines Wissens - älter als der PC.
AFAIK kommen die Ansätze zum einen aus der Weltraumforschung / Militär und zum anderen aus der Medizin- und Pharmatechnik.
Die Steuersoftware für Raketen oder Dialysemaschinen liegt näher an einer SPS als z.B. die Finanzsoftware der dt. Börse. 

Gruß
Dieter


----------



## norustnotrust (7 August 2012)

Trotzdem sind Unit Tests in der SW Entwicklung State if the Art. AFAIK ist das in der Sps Programmierung nicht der Fall... Außerdem hat vermutlich alles in der DV seine Grundlagen in einer Zeit davor (und meist beim Militär) Projektmanagement, Internet, etc...

Ist aber ein bißchen die Diskussion um des Kaisers Bart (außerdem ziemlich OT) oder?


----------



## Blockmove (8 August 2012)

norustnotrust schrieb:


> Trotzdem sind Unit Tests in der SW Entwicklung State if the Art. AFAIK ist das in der Sps Programmierung nicht der Fall...



Weil auch hierfür der Aufwand im Regelfall in keinem Verhältnis zum Nutzen steht.
Zum einen gibt es (bislang) keine geeigneten Werkzeuge dafür, zum anderen dauert das Modellieren aussagekräftiger Tests sicherlich länger als das Programmieren des eigentlichen Codes.

Anwendung finden diese Testmethoden nur im Bereich Sicherheitstechnik und in kritischen Bereichen bestimmter Anlagen (Kraftwerke, Chemie, Pharma ...).
Aber dazu können die Kollegen sicher mehr sagen, die in diesen Branchen tätig sind.

Gruß
Dieter


----------



## bike (10 August 2012)

norustnotrust schrieb:


> Trotzdem sind Unit Tests in der SW Entwicklung State if the Art. AFAIK ist das in der Sps Programmierung nicht der Fall... Außerdem hat vermutlich alles in der DV seine Grundlagen in einer Zeit davor (und meist beim Militär) Projektmanagement, Internet, etc...
> 
> Ist aber ein bißchen die Diskussion um des Kaisers Bart (außerdem ziemlich OT) oder?



Wenn du nur Software hast dann kannst du Modelle bauen die funktionieren oder nicht.
Aber im Maschinen- und Anlagenbau kommt noch die Mechanik und Physik dazu.

Und dann haben die Einzelnen Teile, dass diese obwohl hochgenau gefertigt sich nicht immer gleich verhalten.

Dafür die richtigen Modelle zu bauen? 
Viel Erfolg, doch das haben vor dir schon viele versucht.

Wenn du wirklich aus der Praxis kommst und wirklich Anlagen programmiert hast, dann verstehe ich deine Frage nicht.


bike


----------



## norustnotrust (11 August 2012)

Hallo bike

Danke für deine Antwort aber ich bin mir nicht sicher was du meinst? Was hat das was du über Modellierung sagst mit dem Thema Metriken zu tun?

Außerdem setzten wir Prozesssimulation (Ich denke das meinst du mit Modellierung) und erzielen gute Ergebnisse damit.

Mfg norustnotrust


----------



## Blockmove (11 August 2012)

norustnotrust schrieb:


> Außerdem setzten wir Prozesssimulation (Ich denke das meinst du mit Modellierung) und erzielen gute Ergebnisse damit.



Interessehalber:
In welcher Branche bzw. für welche Anwendung nutzt ihr Prozesssimulation?

Gruß
Dieter


----------



## norustnotrust (11 August 2012)

Hallo Blockmove

Verfahrenstechnische Anlagen: beinhaltet üblicherweise Kühlwasser, Gase, Schüttgutfördertechnik, elektromechanische Beweungen (Wägen, ... ) usw... Relativ bunt gemischt und meist irgendwo zwischen 1000 und 10000 EAs


----------



## bike (12 August 2012)

Interessant.
Wie baut ihr eure Algorithmen auf?
Bei uns sind es nur ca  200 e/a und nur ein paar Achsen, dazu noch etwas heizen. kühlen und schmieren.
Und selbst für unsere Standardmaschinen, die wir im Schlaf kennen, haben wir es noch nicht geschafft eine sinnvolle, zu verlässliche Simulation zu bauen.

Warum in Gottes Namen, wird immer wieder versucht Informatik und Automation gleich zu setzen? 
Wobei ich die Entwicklung der Informatik sehr kritisch in Bezug auf Verfügbarkeit, Sicherheit  und Weiterentwicklung sehe.
Denn seit einigen Jahren werden Fehler zahlenmäßig weniger, aber die Auswirkungen fataler.


bike


----------



## norustnotrust (12 August 2012)

Hallo bike



bike schrieb:


> Warum in Gottes Namen, wird immer wieder versucht Informatik und Automation gleich zu setzen?


Da verstehst du mich falsch. Ich versuche nichts gleichzusetzen aber wenn ein Nachbar (als die ich die Informatik schon sehe) etwas in seinem Garten macht dann interessiert man sich halt und fragt sich ob das auch in seinen eigenen Garten passt. Ich denke Scheuklappen und Vorurteile haben haben uns noch nie wirklich weitergeholfen. 



bike schrieb:


> Wobei ich die Entwicklung der Informatik sehr kritisch in Bezug auf Verfügbarkeit, Sicherheit  und Weiterentwicklung sehe.
> Denn seit einigen Jahren werden Fehler zahlenmäßig weniger, aber die Auswirkungen fataler.


 Ja da kann ich dir nur Recht geben. Aber ich sage ja auch nicht "automatisisieren wir in .NET" aber wenn du dir die Entwicklung in Richtung SCL/ST anschaust wäre es doch fahrlässig zu sagen: Was die in ihrer Hochsprachenwelt machen interessiert mich nicht! Oder?


----------



## Thomas_v2.1 (12 August 2012)

bike schrieb:


> Interessant.
> Wie baut ihr eure Algorithmen auf?
> Bei uns sind es nur ca  200 e/a und nur ein paar Achsen, dazu noch etwas heizen. kühlen und schmieren.
> Und selbst für unsere Standardmaschinen, die wir im Schlaf kennen, haben wir es noch nicht geschafft eine sinnvolle, zu verlässliche Simulation zu bauen.



Das Hauptproblem bei einer Simulation ist aber meist nicht dass es technisch nicht möglich ist diese umzusetzen (generelle Probleme mit der Berechenbarkeit wie z.B. beim Dreikörperproblem mal außen vor), sondern ob sich der Aufwand der in die Simulation gesteckt wird letztenendes rechnet (wegen kürzerer Inbetriebnahmezeiten) oder beispielsweise aufgrund sicherheitsrelevanter Problemematiken unvermeidbar ist.
Ich glaube nicht dass z.B. die Flugsoftware eines Airbus A380 aufgrund der Komplexität am lebenden Objekt getestet wurde.

Für klärtechnische Anlagen gibt es sogar mathematische Modelle welche die biologischen Prozesse inklusive Baktierienwachstum simulieren (ASM1-3, Active sludge model). Da würde mancher auch behaupten sowas könne man nicht simulieren.


----------



## Blockmove (12 August 2012)

Es gibt auch von Siemens "Visionen" zu diesem Thema.
Stichwort: Digitale Fabrik
http://www.siemens.com/innovation/d.../industrie_beitraegen/die_digitale_fabrik.htm

Wenn man sich die Leistungsfähigkeit heutiger 3D-CAD-Programme anschaut, dann kann man schon staunen.
Wenn die einzelnen Bauelemente richtig angelegt sind, dann kann man jeden Zylinder, jede Achse bewegen.
Von dieser Seite ist der Weg zum Funktionsmodel schon vorstellbar.
Und mit Unigraphics Solutions hst Siemens ja auch einen CAD-Spezialisten / Hersteller übernommen.

Gruß
Dieter


----------



## bike (12 August 2012)

Thomas_v2.1 schrieb:


> Ich glaube nicht dass z.B. die Flugsoftware eines Airbus A380 aufgrund der Komplexität am lebenden Objekt getestet wurde.



Da gehe ich mit dir nicht ganz konform.
Von der ESA und wie dort entwickelt wird  weiß ich nicht genug.

Doch da vor kurzem ein Flugzeug bei einer Show abgeschmiert ist, denke ich, dass nicht alle Möglichkeiten in einer Simulation erfasst werden können. 

Von der Software die im FIZ in München entwickelt wird weiß ich, dass zuerst entwickelt und simuliert wird.
Doch dann kommt das echte Produkt und da wird noch sehr viel verändert.
Da wird auf dem Transporter noch ein Softwareupdate einspielt.

[Zitat]
In der Theorie ist praktisch alles machbar
[/Zitat]


bike


----------



## bike (12 August 2012)

Blockmove schrieb:


> Es gibt auch von Siemens "Visionen" zu diesem Thema.
> Stichwort: Digitale Fabrik
> http://www.siemens.com/innovation/d.../industrie_beitraegen/die_digitale_fabrik.htm




... und wenn man denkt wie lange Siemens diese Visionen schon hat 


bike


----------



## norustnotrust (12 August 2012)

Thomas_v2.1 schrieb:


> Das Hauptproblem bei einer Simulation ist aber meist nicht dass es technisch nicht möglich ist diese umzusetzen[...] sondern ob sich der Aufwand der in die Simulation gesteckt wird letztenendes rechnet.


Da kann ich dir nur zustimmen. Ich wunder mich über diese 0 oder 1 Statements (liegt vielleicht am Metier ). Man schaut sich den Nutzen im Vergleich zu den Kosten an, denkt ein bißchen an den guten alten Vilfredo und setzt Technologien ein wo sie Sinn machen und zwar in einem vernünftigen Ausmaß. In meiner Branche kann eine Simulation imho eine IBN nur sehr schwer ersetzen aber sie kann Zeit sparen und man kann viele Dinge einfacher testen als Vor-Ort. Mal ganz zu schweigen davon daß mittlerweile auch manche Kunde einen FAT mit Simulation fordern.




bike schrieb:


> In der Theorie ist praktisch alles machbar


Täusche ich mich oder hat "die Theorie" in diesem Forum so die Funktion eines Totschlagarguments?



Blockmove schrieb:


> Wenn man sich die Leistungsfähigkeit heutiger 3D-CAD-Programme anschaut, dann kann man schon staunen.
> Wenn die einzelnen Bauelemente richtig angelegt sind, dann kann man jeden Zylinder, jede Achse bewegen.
> Von dieser Seite ist der Weg zum Funktionsmodel schon vorstellbar.


Ja, ich habe mir sowas angesehen. WinMOD hat ein 3D Tool das man an die Simulation hängen und damit animieren kann. Wenn man noch Hüllkurven aus den CAD generiert könnte man wohl auch eine Kollisionerkennung basteln. Leider habe ich noch nichts gesehen was irgendwas "Physik-Engine"-artiges besitzt (Gibt es sowas schon?). In der Prozessindustrie ist das nicht soo interessant da bei ein paar Wägen der Aufwand wohl nicht dafürsteht aber im Automatenbau kann man sicher die eine oder andere Anwendung finden.

AFAIK ist in der Lagerautomation eine (relativ) vollständige Simulation schon etwas länger State-Of-The-Art. Was sicher auch am hohen Standartisierungsgrad auf der SPS Seite (und damit auch auf der Simulationseite) liegen mag.


----------



## Thomas_v2.1 (12 August 2012)

norustnotrust schrieb:


> Ja, ich habe mir sowas angesehen. WinMOD hat ein 3D Tool das man an die Simulation hängen und damit animieren kann. Wenn man noch Hüllkurven aus den CAD generiert könnte man wohl auch eine Kollisionerkennung basteln. Leider habe ich noch nichts gesehen was irgendwas "Physik-Engine"-artiges besitzt (Gibt es sowas schon?).



Als 3D-Tool mit einer mächtigen Physik-Engine kann man sehr schön die UDK Game Engine benutzen. Ich habe dazu nur die Plcsim Anbindung geschrieben, User ErwinLSE hier aus dem Forum hat dann sowas schönes daraus gezaubert:
http://www.youtube.com/watch?v=KzuPgLJ88UU
Das UDK wird auch zur Simulation und Test von autonomen Rettungsrobotern verwendet, da gibt es etliches an Informationen zu im Internet.


----------



## bike (12 August 2012)

norustnotrust schrieb:


> Täusche ich mich oder hat "die Theorie" in diesem Forum so die Funktion eines Totschlagarguments?
> 
> .



Bestimmt nicht bei mir.
Doch es gibt noch? keine Wissenschaft, die sich um die Automatisierung und deren Theorie kümmert.
Und es ist noch? nicht möglich, die Theorie aus der IT Technik in die Automatisierung zu transferieren.

Das sind verschiedene Welten und wer versucht die gleich zuschalten macht einen entscheidenden Denkfehler.


bike


----------



## norustnotrust (12 August 2012)

very very nice ... ich meine mal abgesehen davon daß das ganze optisch schon eie Menge hermacht.... Dieses Wackeln der oberen Fäßer, kommt des wirklich aus der Engine oder wurde das als optisches Gimmick gecoded? Wie groß ist der Aufwand für sowas?


----------



## norustnotrust (12 August 2012)

bike schrieb:


> [...]Doch es gibt noch? keine Wissenschaft, die sich um die Automatisierung und deren Theorie kümmert.


Erzähl das mal den Instituten für Automatisierungstechnik, vielleicht kennen die wen der sich darum kümmert...



bike schrieb:


> Und es ist noch? nicht möglich, die Theorie aus der IT Technik in die Automatisierung zu transferieren. Das sind verschiedene Welten und wer versucht die gleich zuschalten macht einen entscheidenden Denkfehler


 Was ist eigentlich das Argument hinter diese Behauptung?


----------



## Thomas_v2.1 (12 August 2012)

norustnotrust schrieb:


> very very nice ... ich meine mal abgesehen davon daß das ganze optisch schon eie Menge hermacht.... Dieses Wackeln der oberen Fäßer, kommt des wirklich aus der Engine oder wurde das als optisches Gimmick gecoded? Wie groß ist der Aufwand für sowas?



Das kommt alles aus der Physik Engine, dafür braucht nichts gecodet werden.
Der Aufwand - naja, es hat schon etwas Mühe gekostet erstmal das Grundgerüst zu schaffen, wie die Interaktion zwischen dem UDK und Plcsim abzuwickeln ist. Im UDK muss einiges in einer Java/C++ ähnlichen Programmiersprache geschrieben werden. Man kann aber eine Bibliothek aus Simulationsobjekten erstellen (z.B. ein Rollenförderer in dem Video) der dann nur noch dupliziert werden muss und die Adressen der SPS-Anbindung angepasst werden muss.

Aber für kommerzielle Anwendung ist das UDK nicht kostenlos, und den Preis möchtest du nicht wissen ;-)


----------



## norustnotrust (12 August 2012)

Naja, ich habe gerade nachgesehen. Wenn ich das richtig verstehe kostet eine Dev Lizenz 2.500$. Und anscheinend bleibt es dabei so lange man die damit erstellte SW nicht vertreibt:



> Here are some examples:
> 
> A warehouse company  uses UDK to create an application for employee safety training. They develop it  on one computer and then install the resulting application on two computers for  their internal employees to use. They require a single UDK development seat  license for a total cost of US$2,500 per year, for as long as they use UDK to  develop and/or maintain the application.


----------



## Blockmove (12 August 2012)

norustnotrust schrieb:


> Wenn man noch Hüllkurven aus den CAD generiert könnte man wohl auch eine Kollisionerkennung basteln. Leider habe ich noch nichts gesehen was irgendwas "Physik-Engine"-artiges besitzt (Gibt es sowas schon?).



Ich meine, dass Kollisionserkennung bei UG NX und anderen 3D-CAD schon möglich ist.
Momentan laufen wohl Entwicklungen, die dem was du als "Physik-Engine" beschreibst, nahe kommen.
Sprich der Zylinder bekommt nicht mehr nur seine Abmessungen und sonstige mech. Eigenschaften, sondern auch noch sein pneumatischen und hydraulischen Eigenschaften.
Zusammen mit den passenden "virtuellen" Sensoren und Ventilen, hast du dann das Funktionsmodell und eigentlich auch gleich die notwendige Basis für die Visualisierung.

Ich glaub Autodesk arbeitet mit EPlan auch in dieser Richtung.

Gruß
Dieter


----------

