# Umfrage: Formale Verifikation / Modellprüfung



## Skrjiban (15 April 2014)

Hallo Leute,

ich bin kürzlich mal zufällig auf das Thema _Formale Verifikation von Programmen_  gestoßen und mir kommt das Konzept - grade im Bereich  Automatisierungstechnik - extrem hilfreich vor und es ist mir ein  Rätsel, warum ich davon jetzt zum ersten mal höre. Nachdem ich aber  selbst in meiner Berufslaufbahn bisher vergleichsweise selten zum  tatsächlichen SPS-Programmieren gekommen bin, wollte ich hier ein wenig  "Marktforschung" betreiben bei den Leuten, die drin sind in der Materie.

Zunächst für alle die's nicht wissen: *Was ist Model Checking?*
Ein großes Problem beim Programmieren ist ja die Fehlersuche. Normalerweise mache ich dabei im Prinzip folgendes:
Normaler Testablauf:


Ich überlege mir, welche Betriebsfälle eintreten können. Insbesondere welche einen Fehler hervorrufen könnten.
Ich teste die Fälle und prüfe, ob das eintretende Verhalten das gewünschte ist.
Wenn ja -> gut, wenn nein -> Fehler beheben.
Das ganze kann ich strukturiert machen (z.B. Unit Testing) oder  manuell, indem ich, auf gut Deutsch gesagt, solang rumprobiere bis alles  geht.

Problematisch ist der erste Schritt, denn durch Überlegung kommt man  kaum auf alle abstrusen Fehler, die sich so in ein Programm  einschleichen. Jeder der mal irgendwas programmiert hat kennt das  Problem.

Bei der Modellprüfung funktioniert der Ablauf deshalb so:

Ich lege eine Reihe von Bedingungen fest, die IMMER vom  Programm eingehalten werden. z.B. "Niemals NOT-Aus und Motor an",  "Niemals A0.1 für länger als 10 Sekunden", "Wenn sqrt(EW5 * EW6 > 10)  dann irgendwann A0.5 = 1 binnen 8s". Alle Bedingungen zusammen ergeben  das sog. Modell.
Der Model Checker prüft JEDEN MÖGLICHEN BETRIEBSFALL des Programms auf die Wahrheit des Modells.
Wenn kein Fall existiert, in dem das Modell nicht  eingehalten wird -> gut, ansonsten -> fehlerhaftes Gegenbeispiel  anzeigen -> Fehler beheben.

In der Hardwareentwicklung ist diese Methodik der Formalen Verifikation  recht verbreitet, z.B. um die korrekte Funktionsweise von Prozessoren zu  beweisen. In der Softwareentwicklung habe zumindest ich noch nie etwas  davon mitbekommen. Und bei SPS erst recht nicht.

Eine Recherche ergab dann auch nicht arg viel. Ein Programm namens ArcadePLC hab ich gefunden:
http://arcade.embedded.rwth-aachen.de/doku.php?id=arcade.plc
Ist mir aber beim Datei laden abgestürzt, drum kann ich nichts dazu  sagen. Bis auf eine kostenpflichtige Publikation des Entwicklers habe  ich auch bei google keinerlei Dokumentation oder Diskussion dazu  gefunden.

Das Tool UPPAAL scheint relativ verbreitet zu sein, ist aber nicht speziell für SPSen gedacht : http://www.uppaal.com/index.php?sida=186&rubrik=93

Ich habe nichts gefunden, wo ich einfach mein Programm/Projekt laden konnte, Bedingungen eingebe und dann ein Ergebnis erhalte.

Jetzt zu meinem eigentlichen Anliegen:

Wem war das Prinzip schon vorher geläufig? Setzt ihr es ein?
Wenn ja: Welche Tools verwendet ihr dafür?
Wenn nein: Warum nicht?
Wer das Prinzip vorher nicht kannte: Was meint ihr dazu? Würdet ihr es einsetzen, wenn es eine gute Software dafür gäbe?
usw.

Schonmal danke für die Antworten!


----------



## bike (15 April 2014)

Das Thema hat inzwischen einen echt langen Bart.
Das Problem liegt daran, ein Modell zu erstellen.
Bei einer Serie ab x + 1000 Stück pro Jahr ist solch eine Modulbildung vielleicht sinnvoll.
Doch wer baut so viele Produkte in Serie?
Zu den Tools die Frage:
Wo gibt es für unsere Umgebung irgend welche Tools?

Junge von der Uni, so abstrakt zu fragen zeigt, dass du dich mit der Automatisierung, das unser Geschäft hier ist, nicht im geringsten beschäftigt hast.



bike


----------



## winnman (15 April 2014)

Punkt 1. wird wohl fast jeder Programmierer im SPS Umfeld machen.
2. wird bei der IBS realisiert und daraus ergibt sich Punkt 3.

Was willst du uns sagen?


----------



## Skrjiban (15 April 2014)

Hm, hab ich mich so unklar ausgedrückt?



> Das Problem liegt daran, ein Modell zu erstellen.
> Bei einer Serie ab x + 1000 Stück pro Jahr ist solch eine Modulbildung vielleicht sinnvoll.
> Doch wer baut so viele Produkte in Serie?



Reden wir aneinander vorbei? Mir kommt es so vor, als ob du von einem 3D-Modell sprichst. Darum gehts mir nicht. Mir geht es um eine Spezifikation für ein SPS-Programm. Anschließend will ich prüfen, ob das Programm diese Spezifikation auch einhält. Und das automatisch, mit einem Software-Tool (= http://de.wikipedia.org/wiki/Model_Checking )



> Punkt 1. wird wohl fast jeder Programmierer im SPS Umfeld machen.
> 2. wird bei der IBS realisiert und daraus ergibt sich Punkt 3.



Da komm ich jetzt nicht ganz mit. Auf welche Punkte beziehst du dich?


----------



## Bapho (16 April 2014)

Also m.E. ist das was für akademische Denkspiele.

Ich muß mir ja im Vorfeld meinen Programmablauf, Funktionen und die Sicherheit überlegen und irgendwie definieren. Dieses Konzept wird dann umgesetzt, in dem ich diese Vorgaben mit einer Programmiersprache in eine Logik übersetze. Wenn sowas ordentlich gemacht wird, sollten schonmal kaum gravierende Bugs auftreten und wenn ich das ganze ordentlich strukturiere lassen sich Fehler auch schnell finden und ach Änderungen leichter einpflegen, zBsp. doppelter Code ist einmal zuviel.
Ist auch immer abhängig von der Komplexität der Aufgabe, aber die meiste Arbeit liegt eigentlich vor dem Programmieren und da werden oft die meisten Fehler gemacht.


----------



## bike (16 April 2014)

Skrjiban schrieb:


> Hm, hab ich mich so unklar ausgedrückt?
> 
> 
> 
> ...



Bestimmt nicht.
Für die Definition der Logik braucht doch zuerst ein Modell, was die Maschine bzw Anlage tun soll.
Mit dieser Definition könnte man die Anforderung an das PLC Programm definieren.
Aber dein Unverständnis zeigt, dass du zuerst dich um die Grundlagen kümmern und verstehen sollst.


bike


----------



## ducati (16 April 2014)

Hihi, da treffen sie wieder aufeinander 

Für die (SPS-) Automatisierung ist das wirklich alles Quatsch, da einfach zu aufwendig... (erstens von der Zeit und zweitens von den Kosten)

In der Automobilindustrie (Fahrzeugentwicklung, nicht Fertigung) wird sowas aber schon eingesetzt. Ich hab da mal nen Vortrag gehört, der hat die Algorithmen von nem Schachcomputer verwendet und quasi den Softwaretest gegen das Fahrzeugsteuergerät antreten lassen...

Aber das ist alles schon etwas her, daher habe ich jetzt aus dem Hut auch keine weiterführenden Links.

Aber wie Bike schon sagt, bei Produktzahlen im 6 oder 7 stelligen Bereich mit entsprechenden Kosten für Rückrufaktionen und Imageschäden lohnt sich der Aufwand. In der SPS-Automatisierung mit Verwendung des identischen Programms zwischen vielleicht 1 und 100 mal macht solch ein Aufwand wenig Sinn... Zumal das ganze nicht trivilal für den Durchschnittsingenieur umsetzbar ist.

Was man heute schon häufig macht, ist eine mehr oder weniger aufwändige Simulation der Maschine/Anlage im Büro aufzubauen, um die Software mit angebundener simulierter Hardware zu testen. Das ist aber schon nicht ganz simpel. Natürlich könnte man sich jetzt vorstellen, die Simulationssoftware noch um einen automatischen "Softwarefehlersuchalgorithmus" zu erweitern. Aber solange das nicht *wirklich* intuitiv zu bedienen ist, sehe ich da für die Praxis schwarz.

Erschwerend kommt hinzu, dass die SPS-Software ja nicht alleine dasteht, es gibt noch die Visualisierung, welche mittlerweile eine sehr großen Umfang besitzt. Also müsste für einen automatisierten Softwaretest auch automatisch Eingaben in der Visu vorgenommen werden... und das ist schon schwieriger ohne die Visu selbst zu manipulieren...

Zurück zur Praxis: Softwarefehler sind schön und gut, aber Sorgen sind auf der Baustelle ganz andere vorhanden. In der Regel Projektorganisatorischer Art. Oft erfährt man erst auf der Baustelle, welcher Sensor mit welchem Messbereich an welcher Stelle wirklich verbaut ist... Da nützt die beste Simulation im Vorfeld nichts, wenn die Realität ganz anders aussieht.

Aber trotzdem macht ne Simulation Sinn, ist aber aufwändig (geschätzte zusätzliche 50-100% der SPS-Softwarezeit)

Gruß und habt Euch alle lieb 

PS: eine Industriesteuerung, wie wir sie hier regelmäßig errichten hat nicht 10 Eingänge und 10 Ausgänge sondern mal locker >1000 Eingänge und >500 Ausgänge. Und das sind u.U. nur Teilanlagen von einer großen Produktionsanlage... Das ist das Problem mit dem Aufwand...

PPS: und nein, das sind keine Kernkraftwerke, wo man den Aufwand vielleicht noch rechtfertigen könnte 

PPPS: wenn etwas in der Praxis nicht gemacht wird, liegt das meist nicht daran, dass alle anderen so doof und man selbst so schlau ist  sondern es gibt gute Gründe dafür... abundzu findet man aber trotzdem ne Marktlücke. Oder man hat gut Verkäufer, die auch den letzten Scheiss an den Mann bringen.


----------



## MrSpexx (16 April 2014)

Meiner Meinung macht die Prüfung nur Sinn wenn auch standardisierte Softwarekomponenten verwendet werden. Wird ein Programm von Hand neu gestrickt ist der Aufwand zu groß. Das Problem besteht wohl da drin das der Programmierer und Prüfer der selbe sein wird. Wenn dir bei der Programmierung bestimmte Konstalationen nicht auffallen, wirst du auch bei der Prüfung nicht da dran denken.

Ein guter SWtest ist sehr wichtig. Beim normalen Automatikablauf sind Fehler auch schnell gefunden. Das Problem ist eher, wie reagiere ich bei Fehler xy. Ich teste bei der Inbetriebnahme jede Fehlermeldung und hake sie ab. Damit läßt sich oft noch der ein oder andere Fehler finden.

Aber das Zauberwort heißt: Standardisierung. Ein Motorbaustein der z.B. über einen UDT Fehler ausspuckt und gekapselt ist muss normalerweise nicht mehr getestet werden. So kann viel Zeit gespart werden.

Zu deinem Punkt fällt mir noch folgendes ein:
http://www.freepatentsonline.com/DE102010005308.html


----------



## ducati (16 April 2014)

MrSpexx schrieb:


> Meiner Meinung macht die Prüfung nur Sinn wenn auch standardisierte Softwarekomponenten verwendet werden. Wird ein Programm von Hand neu gestrickt ist der Aufwand zu groß.
> ...
> Aber das Zauberwort heißt: Standardisierung. Ein Motorbaustein der z.B. über einen UDT Fehler ausspuckt und gekapselt ist muss normalerweise nicht mehr getestet werden. So kann viel Zeit gespart werden.



Jo, da dieser Motorbaustein dann ja vielleicht auch 10000 mal verwendet wird, könnte solch ein Test dafür u.U. sinnvoll sein (bzw. nach jeder "kleinen" Änderung mal den Test pauschal drüber laufen lassen). Oder Siemens könnte solch einen Automatischen Softwaretest für seine PCS7-APL-Bibliothek verwenden... Also allgemein für Programmierer von Bibliotheken.

Aber für ein komplettes SPS-Programm macht das alles keinen Sinn.

Gruß.


----------



## Skrjiban (16 April 2014)

Erstmal Danke für die ausführlichen Antworten. Zumindest weiß ich jetzt schonmal, dass die Methodik definitiv nicht in der Praxis gemacht wird, zumindest nicht bei SPS-Programmen.



> wenn etwas in der Praxis nicht gemacht wird, liegt das meist nicht  daran, dass alle anderen so doof und man selbst so schlau ist :wink:


Hat ja auch niemand behauptet 



> Ich muß mir ja im Vorfeld meinen Programmablauf, Funktionen und die  Sicherheit überlegen und irgendwie definieren. Dieses Konzept wird dann  umgesetzt, in dem ich diese Vorgaben mit einer Programmiersprache in  eine Logik übersetze. Wenn sowas ordentlich gemacht wird, sollten  schonmal kaum gravierende Bugs auftreten und wenn ich das ganze  ordentlich strukturiere lassen sich Fehler auch schnell finden und ach  Änderungen leichter einpflegen, zBsp. doppelter Code ist einmal zuviel.
> Ist auch immer abhängig von der Komplexität der Aufgabe, aber die meiste  Arbeit liegt eigentlich vor dem Programmieren und da werden oft die  meisten Fehler gemacht.



Da stimme ich dir natürlich zu. Ich entwickle hauptberuflich PC-Software und auch da ist es meist so, dass eine gute Planung schwieriger als die tatsächliche Implementierung ist. Eine andere Wahrheit ist aber auch, dass sich a) nie alles vorher planen lässt, weil immer wieder Änderungen vorkommen und b) in der Praxis dann doch im Schnitt ein nicht unwesentlicher Teil der Zeit und des Geldes (ich glaube 40% des Budgets oder sowas, habs grad nicht mehr im Kopf) für Fehlersuche und Behebung draufgeht. Ich weiß natürlich nicht wie das in der professionellen Automatisierungsindustrie aussieht (deswegen frage ich euch ja) - ich würde mal auf "ähnlich" tippen.

Ansonsten war der Konsens hier ja, dass so eine Modellbildung zu aufwändig wäre, als dass es sich lohnen würde. Es geht aber ja auch gar nicht darum, das Verhalten vom ganzen Programm im Detail zu spezifizieren. Das ist natürlich utopisch. Und ich will die Modellbildung auch gar nicht in die Planungsphase einbinden. Es geht nur darum, das Testen am Ende schneller und sicherer zu machen, indem ich die _essenziellen_ Verhaltensweisen der Steuerung prüfe.

Minibeispiel: Letztens hab ich eine Torsteuerung mit Logo programmiert. Das Tor sollte abends zugehen und morgens wieder auf (mit Zeitumstellung) das Tor konnte man von außen per Zugangskarte oder per Funk öffnen, von innen über Bewegungsmelder. Dann ne Lichtschranke zur Sicherheit, die verhindert dass jemand eingeklemmt wird. Ganz simpel. Nach ein bisschen rumprobieren lief das Ganze dann auch und die Tests waren gut. Ich bin nach Hause gefahren und hab am nächsten Tag erfahren dass das Tor natürlich nicht abends geschlossen hat wie es sollte, weil sich irgendwo ein mieser kleiner Fehler eingeschlichen hat, der so selten war, dass er beim Testen nie aufgetreten ist.
Da hätte ich jetzt gerne eine Software gehabt, wo ich das Logo-Programm lade, dann eine Bedingung á la "Uhrzeit > 20:00h || Uhrzeit < 06:00h => Tor zu" eingebe (was nun wirklich nicht viel Arbeit ist) und hätte alle Fälle aufgelistet bekommen, in denen dies nicht der Fall ist. Neben einigen legitimen Fällen ware auch der unerwartete dabei gewesen und ich hätte auf die Frage "Geht das Tor jetzt heute abend auch zu?" mit Gewissheit "Ja!" antworten können.

Bei einer größeren Steuerung stelle ich mir das so vor (korrigiert mich bitte wenn ich falsch liege): Ich muss ich ja auch hier nur das Wichtigste prüfen. Ich kann mir zum Beispiel alle Fälle anzeigen lassen, in denen ein Förderband stillsteht. Oder wenn ich eine Joghurtabfüllmaschine programmiere dann teste ich halt zwischendurch kurz "Wenn Ventil offen dann binnen 30 s Ventil wieder zu". Die Syntax für die Eingabe der Bedingungen muss natürlich intuitiv und simpel sein, ansonsten hat da niemand Lust drauf, ist schon klar.



> Erschwerend kommt hinzu, dass die SPS-Software ja nicht alleine dasteht,  es gibt noch die Visualisierung, welche mittlerweile eine sehr großen  Umfang besitzt. Also müsste für einen automatisierten Softwaretest auch  automatisch Eingaben in der Visu vorgenommen werden... und das ist schon  schwieriger ohne die Visu selbst zu manipulieren...


Das ist natürlich auch richtig, ein automatischer Test des UI ist wohl prinzipiell quasi unmöglich. Allerdings sind die Fehler in der Visualisierung ja weniger tragisch als im Steuerungsablauf. Außerdem: Ein- und Ausgaben in der Visualisierung werden doch als rohe Daten mit der Steuerung kommuniziert und könnten hier, genau wie Ein- und Ausgänge, getestet werden. Wenn man denn unbedingt will.


----------



## MrSpexx (16 April 2014)

Das Beispiel mit dem Ventil ist gut. Nur ich würde das nicht als SW-Test bezeichnen sondern als Fehlerabfrage. Wenn Ventil länger als 30 Sekunden offen ist: dann gib einen Fehler aus. Wenn Temperatur zu hoch: gib einen Fehler aus. 
Ich glaube dafür gibt es hier weitgehend Übereinstimmung. Der Unterschied zu PC-Programmen zu Automatisierungsaufgaben ist ja. Wenn etwas nicht tut sieht man es sofort weil der Ablauf/Bewegung nicht stimmt.
Ein großer Brocken ist auch die Verbindung zur Visu und der Handbetrieb. Das ließe sich - soweit ich das verstanden habe - mit SW Test´s schwer umsetzen.


----------



## ducati (17 April 2014)

Skrjiban schrieb:


> Ich entwickle hauptberuflich PC-Software und auch da ist es meist so, dass eine gute Planung schwieriger als die tatsächliche Implementierung ist. Eine andere Wahrheit ist aber auch, dass sich a) nie alles vorher planen lässt, weil immer wieder Änderungen vorkommen .



Naja, wenn vorher nicht klar ist, was die Steuerung im Detail machen soll, dann kannst Du die nicht klaren Fälle auch nicht testen. Da beisst Sich die Katze in den Schwanz.



Skrjiban schrieb:


> Ansonsten war der Konsens hier ja, dass so eine Modellbildung zu aufwändig wäre, als dass es sich lohnen würde. Es geht aber ja auch gar nicht darum, das Verhalten vom ganzen Programm im Detail zu spezifizieren. Das ist natürlich utopisch. Und ich will die Modellbildung auch gar nicht in die Planungsphase einbinden. Es geht nur darum, das Testen am Ende schneller und sicherer zu machen, indem ich die _essenziellen_ Verhaltensweisen der Steuerung prüfe.



Eine Industriesteuerung macht ohne Anlage oder Anlagenmodell nicht wirklich viel sinnvolles. Der ganze Programmablauf wartet ständig auf irgendwelche Signale vom Feld bzw. ist drauf angewiesen. Ohne Simulationsmodell kannst Du da nicht wirklich was sinnvolles testen.
Was sind "essentielle Verhaltenweisen"? Wenn ich nur 2-3 sicherheitsrelevante Dinge testen will, kann/muss ich das auch von Hand machen, dafür brauch ich Deine Test-Software nicht. Für alles, was die Maschienenrichtlinie betrifft gibt es eh genaue Vorschriften, wie ich was programmieren und testen MUSS.



Skrjiban schrieb:


> Das ist natürlich auch richtig, ein automatischer Test des UI ist wohl prinzipiell quasi unmöglich. Allerdings sind die Fehler in der Visualisierung ja weniger tragisch als im Steuerungsablauf. Außerdem: Ein- und Ausgaben in der Visualisierung werden doch als rohe Daten mit der Steuerung kommuniziert und könnten hier, genau wie Ein- und Ausgänge, getestet werden. Wenn man denn unbedingt will.



das siehst Du falsch... Die Visu hat mittlerweile oft einen genauso großen Umfang wie das Steuerungsprogramm und Fehler dort sind genauso tödlich für die Maschine/Anlage. Das mit den Ein/Ausgaben funktioniert so auch nicht, da in der Visu auch noch Software/Scripte ablaufen etc...

Was ist denn die Intension Deiner Fragen hier? M.M. kannst Du Deine Erfahrungen mit der PC-Welt und der Logo so gut wie garnicht auf eine Industrieautomatisierung übertragen. Das siehst Du viel zu blauäugig. Das Extrapolieren funktioniert so überhaupt nicht. Aber wenigsten fragst Du ja hier.

Gruß.


----------



## peter(R) (19 April 2014)

Skrjiban schrieb:


> in der Praxis dann doch im Schnitt ein nicht unwesentlicher Teil der Zeit und des Geldes (ich glaube 40% des Budgets oder sowas, habs grad nicht mehr im Kopf) für Fehlersuche und Behebung draufgeht. Ich weiß natürlich nicht wie das in der professionellen Automatisierungsindustrie aussieht



Wenn ich soviel für die Fehlersuche ausgeben muss habe ich im Vorfeld was falsch gemacht behaupte ich mal - für die Automatisierungstechnik.

peter(R)


----------



## Skrjiban (22 April 2014)

> Was ist denn die Intension Deiner Fragen hier?


Ich möchte wissen, ob es sich lohnt, so etwas zu entwickeln. Ich halte es immer noch für eine Marktlücke, ist außerdem ein schönes mathematisches Thema wozu ich etliche gute Ansätze parat hätte. Nur bin ich eben nicht tief genug in der Anwender-Materie drin um zu wissen, womit die Leute tatsächlich Probleme haben und womit nicht. Sowas wird man ja fragen dürfen.

Wenn also in der SPS-Software kaum Fehler gemacht werden (was mir immer noch schleierhaft vorkommt, seid ihr Übermenschen? ), was macht den Braten denn dann fett?



> Eine Industriesteuerung macht ohne Anlage oder Anlagenmodell nicht  wirklich viel sinnvolles. Der ganze Programmablauf wartet ständig auf  irgendwelche Signale vom Feld bzw. ist drauf angewiesen. Ohne  Simulationsmodell kannst Du da nicht wirklich was sinnvolles testen.


Na das ist ja gerade der Punkt. Bei der Modellprüfung simuliere ich im Endeffekt doch ebenfalls Eingaben vom Feld. Nur wenn ich mir eine Simulation (egal ob in Software oder Hardware) baue, probiere ich _einzelne_ Fälle aus, während ich bei der formalen Verifikation _alle_ auf einmal teste, damit ich nichts vergessen oder übersehen kann. Da brauche ich kein Simulationsmodell, denn alle möglichen Fälle schließen automatisch alle möglichen Simulationsmodelle mit ein.



> Der  Unterschied zu PC-Programmen zu Automatisierungsaufgaben ist ja. Wenn  etwas nicht tut sieht man es sofort weil der Ablauf/Bewegung nicht  stimmt.


Ich glaube ehrlich gesagt nicht dass man das so festhalten kann. Wenn bei meinem PC-Programm etwas nicht passt, dann bleibt nichts stehen, sondern stürzt es eben mit Fehlermeldung ab oder zeigt Blödsinn an. Das fällt genauso auf. Und interne Variablen können doch bei einer Steuerung wie bei einer PC-Software falsche Werte haben, solange sie kurzfristig keine Auswirkungen zeigen.



> Das Beispiel mit dem Ventil ist gut. Nur ich würde das nicht als SW-Test  bezeichnen sondern als Fehlerabfrage. Wenn Ventil länger als 30  Sekunden offen ist: dann gib einen Fehler aus. Wenn Temperatur zu hoch:  gib einen Fehler aus.


Das leuchtet ein. Was ich mich aber halt frage:

Woher weiß ich, dass es für alle relevanten Fehlerfälle auch einen Fehlercode gibt? 
Wie kommst du auf die Logik, der den Fehlercode ausgibt? Zugegeben, sowas wie "Temperatur zu hoch" ist natürlich ziemlich simpel. Aber es kommen doch bestimmt auch mal Fehlercodes vor, deren Erkennung nicht so trivial ist. Wie prüfst du dann, ob die Erkennung des Fehlers auch fehlerfrei ist und in allen Fällen richtig funktioniert? 
Ähnlich wie Punkt 1: Wie schließt du aus, dass so ein nicht-trivialer Fehler erkannt wird, obwohl gar kein Fehler aufgetreten ist? Sowas hab ich zum Beispiel schon öfters gesehen, teilw. auch mit bösen Auswirkungen. 
Wenn mein Programm einen Fehlercode ausgibt und dann stoppt, dann verhindere ich damit natürlich schonmal dass etwas Schlimmeres passiert. Was wohl gut genug ist. Aber ich zeige doch damit im Endeffekt nur die Symptomatik an, nicht die Fehlerursache. Schon klar, häufig wirds einfach irgend ein kaputter Sensor o.ä. sein. Aber sowas wie "Ventil zu lange offen" kann doch tausend verschiedene Ursachen haben, die beim Eintreten des Fehlers dann auch wieder irgendeiner rausfinden muss. 

In der Hoffnung hier nicht gefressen zu werden ,
Skrjiban


----------



## bike (22 April 2014)

Junge denkst du wirklich du hast das Wissen solch ein Projekt anzugehen?
Du hast keine Ahnung von Automatisierung und willst so etwas angehen?
Wenn du in der Lage bist, die Suchfunktion fehlerfrei zu nutzen, würden dir andere Beiträge zu diesem Thema in die Hände fallen.
BiG$ bezahlt Entwickler, die zumindest wissen was PLC Programmierung ist,  um sich dem Thema zu nähern und es klappt noch? nicht.

Allein deine Fragestellung zeigt, dass du es nicht kannst. 


bike

btw ich esse nur was mir schmeckt.


----------



## Skrjiban (22 April 2014)

> btw ich esse nur was mir schmeckt.


uh, der hat gesessen 



> BiG$ bezahlt Entwickler, ... ,  um sich dem Thema zu nähern und es klappt noch? nicht.


D.h. man braucht's doch?


----------



## MrSpexx (22 April 2014)

He nicht streiten! Ich finde die Idee gut. Ich habe noch was für dich wenn der erste Link zu trocken war.

http://www.durr.com/fileadmin/user_upload/durr_career/downloads/report_duerr_top_arbeitgeber.pdf
Bitte Seite 79 - 80 lesen. Das ist ein Tool mit dem vorab getest und somit die IB verkürzt werden kann und danach wohl weniger Fehler enthält. Das wollen wir doch alle!
Ich kenns aber nur von den Artikeln.

Mal abgesehen davon wird es nicht so einfach sein nur Eingang X und y zu setzen und rückzusetzen, weil du intern viele Zustände haben kannt in denen du auf den Eingang X oder auf Eingang Y oder auf beide wartest. Alle Ausgänge mal in allen Kombinationen zu setzen wird dir da nicht viel weiterhelfen, bzw. du wirst wohl auch so viele Fehler bekommen, dass du deine Zustände gar nicht in der gewünschten Reihenfolge durchlaufen kannst. 

Oft kommt es auch gar nicht darauf an wie die Eingänge statisch sitzen, sondern auch in welcher Zeit. Das würde dann endgültig deinen Rahmen sprengen. Für solche Fällen kannst du mit dem SPS Analyser Signale der Steuerung aufzeichnen und dir später in Ruhe anschauen und analysieren.


----------



## MrSpexx (22 April 2014)

Skrjiban schrieb:


> Ich glaube ehrlich gesagt nicht dass man das so festhalten kann. Wenn bei meinem PC-Programm etwas nicht passt, dann bleibt nichts stehen, sondern stürzt es eben mit Fehlermeldung ab oder zeigt Blödsinn an. Das fällt genauso auf. Und interne Variablen können doch bei einer Steuerung wie bei einer PC-Software falsche Werte haben, solange sie kurzfristig keine Auswirkungen zeigen.



Ich glaube mit so einer Fehlerprüfung wird das ganze Programm viiieeel zu kompliziert. Mir ist auch nicht ganz klar was du im Kopf hast. Eine einfache Handlingsaufgabe mit ner Schrittkette? Oder was größerers?  Willst du mit deiner Prüfung den Fehler nur anzeigen oder auch irgendwie darauf reagieren? Und was willst du den überhaupt für Fehler feststellen? Programmierfehler? Ausfall von HW?



Skrjiban schrieb:


> Das leuchtet ein. Was ich mich aber halt frage:Woher weiß ich, dass es für alle relevanten Fehlerfälle auch einen Fehlercode gibt?


_Das darfst du als Programmierer entscheiden. Keiner kennt die Anlage so gut wie du!_



Skrjiban schrieb:


> Wie kommst du auf die Logik, der den Fehlercode ausgibt? Zugegeben, sowas wie "Temperatur zu hoch" ist natürlich ziemlich simpel. Aber es kommen doch bestimmt auch mal Fehlercodes vor, deren Erkennung nicht so trivial ist. Wie prüfst du dann, ob die Erkennung des Fehlers auch fehlerfrei ist und in allen Fällen richtig funktioniert?



_Ich würde das in einen extra Baustein reinmachen. Einer der nur abfragt und nicht steuert. Hier kannst du dann abfragen "Bin ich in Hand, dann gib keinen Fehler aus. bin ich inAutomatik dann gebe einen Fehler "Ventil offen" nach 30 Sekunden aus. Aber du sieht, dass ist Arbeit. Denn deinen Prüfcode solltest du ja auch prüfen._



Skrjiban schrieb:


> Ähnlich wie Punkt 1: Wie schließt du aus, dass so ein nicht-trivialer Fehler erkannt wird, obwohl gar kein Fehler aufgetreten ist? Sowas hab ich zum Beispiel schon öfters gesehen, teilw. auch mit bösen Auswirkungen.



_Du kannst verschiedene Fehlerklassen erstellen und bei wichtigen Fehlern z.B. den Automatikbetrieb stoppen._



Skrjiban schrieb:


> Wenn mein Programm einen Fehlercode ausgibt und dann stoppt, dann verhindere ich damit natürlich schonmal dass etwas Schlimmeres passiert. Was wohl gut genug ist. Aber ich zeige doch damit im Endeffekt nur die Symptomatik an, nicht die Fehlerursache. Schon klar, häufig wirds einfach irgend ein kaputter Sensor o.ä. sein. Aber sowas wie "Ventil zu lange offen" kann doch tausend verschiedene Ursachen haben, die beim Eintreten des Fehlers dann auch wieder irgendeiner rausfinden muss.



_Genau und das ist die viele Arbeit, die die anderen meinen!_



So und jetzt hoffe ich die Zitatfunktion richtig bedient zu haben.


----------



## Skrjiban (22 April 2014)

Danke für den Link! (und den vorherigen auch, ist irgendwie untergegangen).

Morgen mehr dazu.


----------



## ducati (23 April 2014)

@MrSpexx
m.M. will der TE nicht Fehler in der Anlage erkennen sondern vorab das SPS-Programm auf Programmierfehler hin überprüfen.



Skrjiban schrieb:


> Ich möchte wissen, ob es sich lohnt, so etwas zu entwickeln.



NEIN.



Skrjiban schrieb:


> was macht den Braten denn dann fett?



Hängt natürlich von vielem ab. Bei mir in der Prozessautomatisierung/Anlagenbau ist das Problem, dass ich vorher nicht 100%ig weiss wie die Anlage aussieht und was die Steuerung machen soll. Die Infos der "Verfahrenstechniker" sind immer sehr bescheiden bzw. fehlerhaft.
PS: und dass der Kunde tausend Extrawünsche hat, welche das Programm unnötig aufblähen.



Skrjiban schrieb:


> Na das ist ja gerade der Punkt. Bei der Modellprüfung simuliere ich im Endeffekt doch ebenfalls Eingaben vom Feld. Nur wenn ich mir eine Simulation (egal ob in Software oder Hardware) baue, probiere ich _einzelne_ Fälle aus, während ich bei der formalen Verifikation _alle_ auf einmal teste, damit ich nichts vergessen oder übersehen kann. Da brauche ich kein Simulationsmodell, denn alle möglichen Fälle schließen automatisch alle möglichen Simulationsmodelle mit ein.



Wieviele mögliche Fälle hast Du, bei einer Anlage mit 1000 Eingängen und 500 Ausgängen? Das solltest Du ja eigentlich ausrechnen können. Und da ja im Programm auch viele Timer verbaut sind kannst Du höchstens sagen wir mal pro 5 Sekunden einen Fall testen. Wie lang soll sowas dann dauern? Und wer definiert die "richtige Verhalten" für all diese Fälle?

Aber wie schon gesagt, zum Test von vielfach verwendeten Bibliotheken wäre sowas vielleicht denkbar. Aber dann hast Du als Kunden eben nur die vielleicht 100 Bibliotheksentwickler.

Gruß.


----------



## ducati (23 April 2014)

MrSpexx schrieb:


> http://www.durr.com/fileadmin/user_upload/durr_career/downloads/report_duerr_top_arbeitgeber.pdf
> Bitte Seite 79 - 80 lesen. Das ist ein Tool mit dem vorab getest und somit die IB verkürzt werden kann und danach wohl weniger Fehler enthält. Das wollen wir doch alle!
> Ich kenns aber nur von den Artikeln.



Da geht's um Simulation, das ist ganz was anderes, was der TE meint...

Das was Dürr macht gibt es schon lange und wird häufig vom Kunden gefordert. 

Man baut sich im Büro mit einer geeigneten Software (Simit oder Winmod) + Testumgebung mehr oder weniger gut seine Anlage nach... und kann dann sein SPS-Programm im Büro incl. der Schrittketten und sonstwas ausgiebig testen.

Von Siemens (Simit) nimmt man sich nen zusätzlichen Simulations-PC. Dort drinn ist ne spezielle PB-Karte, welche PB-Teilnehmer simulieren kann. Das Ding wird dann über PB mit der originalen SPS mit originalem Programm verbunden. Auf dem Simulation-PC läuft weiterhin die Simulation der verfahrenstechnischen Zusammenhänge, also z.B. wenn man nen Motor ansteuert werden durch das Simulationsprogramm die Eingänge für Drehüberwachung, Motorstrom sonstwas automatisch ausgegeben. Wenn manns dann noch weitertreibt, können auch noch Volumenströme oder was auch immer mit dem Motor zusammenhängt realitätsnah nachgebildet werden.
Hab ich ja eigentlich in meinem ersten Beitrag schon alles geschrieben.

https://eb.automation.siemens.com/mall/de/WW/Catalog/Products/10205995

http://support.automation.siemens.com/WW/view/de/68108412/130000



Gruß.


----------



## bike (23 April 2014)

ducati schrieb:


> Da geht's um Simulation, das ist ganz was anderes, was der TE meint...



Der Grenze zwischen der Validieren und Simulation sind in unser Arbeitswelt nicht bzw nur sehr schwer ziehen. 

Der TE versucht Techniken für die Softwareentwicklung auf die Automatisierung zu verwenden.
Da kommt der Vergleich mit Äpfeln und Melonen wieder zum Tragen.

Da bei Programmen auf Rechner Fehler schwerer zu finden bzw deren Auswirkung manchmal nicht offensichtlich zu erkennen sind.
Aber bei PLC Programmen ist es etwas anderes.
Wenn ein Fehler da ist, dann macht der sich meist schnell bemerkbar.
Theorie ist wichtig, doch noch gibt es keine Modelle nach denen man Validieren könnte.
Auch sind die Anforderungen so verschieden, dass allein das Erstellen solcher Modelle einfach zu fehleranfällig und zu teuer ist.

Warum schreibt der TE nicht, er will eine Geschäftsidee um zu verdienen, bei der aber Andere für ihn arbeiten.
Denn wenn der einmal ein Pflichtenheft sich angeschaut hätte, wären die Fragen klüger ausgefallen.


bike


----------



## ducati (23 April 2014)

bike schrieb:


> Der Grenze zwischen der Validieren und Simulation sind in unser Arbeitswelt nicht bzw nur sehr schwer ziehen.



Jo, das liegt aber daran, dass der Begriff "Simulation" sehr inflationär für alle möglichen Dinge missbraucht wird 

für mich bedeutet Simulation erstmal nur, etwas im Moment nicht vorhandenes "nachzubilden". Also z.B. die SPS durch PLCSIM oder die PB-Geräte und Anlage mit Simit.

Der eigentliche Softwaretest (Validierung) ist für mich nicht Simulation, wird aber von einigen Leuten trotzdem so bezeichnet.

Gruß.


----------



## Skrjiban (23 April 2014)

> @MrSpexx
> m.M. will der TE nicht Fehler in der Anlage erkennen sondern vorab das SPS-Programm auf Programmierfehler hin überprüfen.


Richtig, so wie ichs mir vorstelle braucht man auch keine echte SPS dazu (aber ich muss natürlich vorher irgendwie angeben auf welcher es laufen soll).



> Wieviele mögliche Fälle hast Du, bei einer Anlage mit 1000 Eingängen und  500 Ausgängen? Das solltest Du ja eigentlich ausrechnen können. Und da  ja im Programm auch viele Timer verbaut sind kannst Du höchstens sagen  wir mal pro 5 Sekunden einen Fall testen. Wie lang soll sowas dann  dauern?





> Mal abgesehen davon wird es nicht so einfach sein nur Eingang X und y zu  setzen und rückzusetzen, weil du intern viele Zustände haben kannt in  denen du auf den Eingang X oder auf Eingang Y oder auf beide wartest.  Alle Ausgänge mal in allen Kombinationen zu setzen wird dir da nicht  viel weiterhelfen, bzw. du wirst wohl auch so viele Fehler bekommen,  dass du deine Zustände gar nicht in der gewünschten Reihenfolge  durchlaufen kannst.
> Oft kommt es auch gar nicht darauf an wie die Eingänge statisch sitzen, sondern auch in welcher Zeit.


Das Phänomen das ihr beschreibt heißt Zustandsraumexplosion. Die Anzahl der Ein- und Ausgänge ist nicht so tragisch, wenn ich die genannten 500 Ausgänge habe und jeder so im Schnitt von ~4 - 5 Eingängen abhängt, dann hab ich 16 bis 32 mögliche Kombinationen, also insgesamt 8000 - 16000 Fälle. Das ist Pipifax. Problematisch wirds aber wirklich, wenn man Variablen über mehrere Zyklen behält oder wenn man z.B. Zählereingänge hat. Wenn mein Programm einen Zählereingäng über 5 Zyklen überwacht, hab ich 2^16^5 = 1,089258 * 10^24 Fälle. Das ist hundert mal so viel wie es Sterne im Universum gibt. Und wenn ich Timer verwende sind die zeitkontiniuerlich und asynchron, also gibts prinzipiell unendlich viele Fälle.

... weswegen ich das Ganze ja auch als interessantes mathematisches Problem bezeichnet hab. Denn jedem leuchtet intuitiv ein, dass viele Fälle das gleiche Verhalten erzeugen, und man kann in Vorraus analysieren, welche das sein werden. Und so kann man dann alle Fälle simulieren, ohne alle Fälle simulieren zu müssen.



> Und wer definiert die "richtige Verhalten" für all diese Fälle?


Wie ich vorher schon gesagt hab, gebe ich a) wichtige Fälle an, welche nicht eintreten sollen sowie b) wichtige Fälle, die eintreten sollen. Letzteres mache ich normalerweise durch Ausprobieren und zugucken, typischerweise bei der Inbetriebnahme, wie ihr mir gesagt habt. Und Fall a ist wohl ähnlich dem, was typischerweise als Fehlercode gemeldet wird. Aber bei einem Fehlercode muss ich versuchen, diesen durch Tests explizit zu erzeugen und finde damit nicht alle möglichen Ursachen und weiß beim Eintreten auch nicht genau, was die Ursache war. Bei einer Modellprüfung krieg ich das alles frei Haus geliefert. Zudem kommt hinzu, dass ich zwingend die Peripherie simulieren oder nachbauen muss (wie in dem Dürr-Artikel beschrieben), wenn ich die Fehlercodes noch vor der Inbetriebnahme vernünftig testen möchten, während ich mir das bei der Modellprüfung wohl häufig sparen kann, wenn das Simulationsmodell für die Peripherie nicht so arg kompliziert ist. Und wenn ich die Volumenströme durch Ventile simulieren will, kommen wir zum nächsten Punkt...



> Da geht's um Simulation, das ist ganz was anderes, was der TE meint...
> Das was Dürr macht gibt es schon lange und wird häufig vom Kunden gefordert.


Richtig erkannt, das meine ich nicht. Ist aber insofern interessant, dass es sich mit dem was ich meine teilweise ersetzen oder alternativ auch gut kombinieren lässt. Denn wenn ich das Verhalten der SPS simuliere, kann ich die dadurch erzeugten Ein- und Ausgangswerten ja auch solche Simulationsmodelle für die Peripherie weitergeben und deren Verhalten mitsimulieren. Ist dann aber schon ein weiterführendes Thema.



> Der TE versucht Techniken für die Softwareentwicklung auf die Automatisierung zu verwenden.
> Da kommt der Vergleich mit Äpfeln und Melonen wieder zum Tragen.


ducati spricht davon, nicht vorhandene Teile für den Test durch Simulationen zu ersetzen (da haben wir Mocks und Fakes), MrSpexx von Standardisierung der Softwarebausteine und besseren Softwarestrukturen (da haben wir die ganze OOP, Standard-Klassenbibliotheken mit so Prinzipien wie Kapselung, etliche design patterns uvm.) und das Hauptproblem ist laut ducati, dass der Auftraggeber nicht genau spezifiziert und zu spät im Entwicklungsprozess Sonderwünsche hat (1:1 übernehmbar). Hört sich für mich bislang recht vertraut an.



> Hängt natürlich von vielem ab. Bei mir in der  Prozessautomatisierung/Anlagenbau ist das Problem, dass ich vorher nicht  100%ig weiss wie die Anlage aussieht und was die Steuerung machen soll.  Die Infos der "Verfahrenstechniker" sind immer sehr bescheiden bzw.  fehlerhaft.
> PS: und dass der Kunde tausend Extrawünsche hat, welche das Programm unnötig aufblähen.


Dann muss ich jetzt weiter fragen: Was ist daran problematisch, und was tust du dagegen?


----------



## MrSpexx (23 April 2014)

Ich denke du bist auf dem Holzweg. Versuch mal das Problem von der anderen Seite her anzugehen. Standardbausteine für immer wieder kehrende Aufgaben/ Programmaufbau.

 Aber du bist hartnäckig das gefällt mir.


----------



## ducati (23 April 2014)

auch zwischen Äpfeln und Melonen lassen sich Gemeinsamkeiten finden. Trotzdem bleiben die Unterschiede erhalten 

Zum Rest denke ich ist alles gesagt.

Wie bike schon sagte, schau Dir mal ein Pflichtenheft und ein umfangreiches Automatisierungsprojekt an (das hat mit Deiner Logo so gut wie nichts gemein). Dann verstehst Du uns auch.

Gruß.


----------



## ducati (23 April 2014)

PS: kennt jemand die Adresse von 00Alex? dann können wir die zwei ja zusammenbringen.


----------



## PN/DP (23 April 2014)

00Alex missioniert die PLC-Welt nun hier

Harald


----------



## Skrjiban (23 April 2014)

Naja gut, wenn jetzt schon mit dem Forentroll verglichen werden musss, dann sind euch wohl die Ideen ausgegangen. Ich bedank mich trotzdem für die bisherigen Antworten, war ja doch was informatives dabei.

Gruß


----------



## Bapho (23 April 2014)

Skrjiban schrieb:


> Naja gut, wenn jetzt schon mit dem Forentroll verglichen werden musss, dann sind euch wohl die Ideen ausgegangen. Ich bedank mich trotzdem für die bisherigen Antworten, war ja doch was informatives dabei.
> 
> Gruß


genau
Meine Meinung steht fest, verwirren Sie mich nicht mit Tatsachen...


----------



## Thomas_v2.1 (23 April 2014)

Die Problematik bei Software in der Automatisierungstechnik ist doch, dass diese mit der realen Welt interagiert. Im Gegensatz zu Businessanwendungen, bei denen definierte Daten (Dateien, Benutzereingaben, etc.) hineinkommen und wieder hinausgehen. D.h. deine Verifikation in der Automatisierungstechnik muss zumindest teilweise die reale Welt abbilden können, und die ist bekannterweise komplex.

Das nächste Problem ist, dass eine Anlage nur in den wenigsten Fällen aus nur einer einzigen Steuerung mit einem Steuerungsprogramm besteht. Hast du beispielsweise Busteilnehmer wie Frequenzumrichter oder Servoantriebe mit eigenen Programmen und hunderten von Parametern, busfähige Messungen, Ventilinseln usw., muss deine Verifikation genau wissen wie sich diese Teilnehmer intern verhalten, welche Regelkreise dort ablaufen und das alles abbilden können.
Ich sag mal aus Erfahrung, dass es einem SPS-Programmierer nur selten auf Anhieb gelingt dass die Kommunikation mit einem neuen Busteilnehmer auf Anhieb nur anhand der Beschreibung im Handbuch gelingt. Bei der Inbetriebnahme sind immer kleine Anpassungen zu machen.

Ich teste meine SPS-Programme meistens mit Plcsim mit einer mehr oder weniger aufwändigen Simulation durch. Wie aufwändig ich die Simulation gestalte, hängt davon ab wie kritisch die Anlage ist die man dann in Betrieb nimmt, und wie groß die Möglichkeiten sind an der Anlage irgendwelche Fehlerzustände durchzutesten.
Aber eine komplette Verifikation bei der man dann sagen kann: "Programm ist fehlerfrei" halte ich zumindest bei nicht trivialen Anlagen für unmöglich.

Und dann bleibt ja noch dein angesprochenes mathematisches bzw. logisches Problem: das Halteproblem ;-)


----------



## bike (23 April 2014)

Skrjiban schrieb:


> Naja gut, wenn jetzt schon mit dem Forentroll verglichen werden musss, dann sind euch wohl die Ideen ausgegangen. Ich bedank mich trotzdem für die bisherigen Antworten, war ja doch was informatives dabei.
> 
> Gruß



Es ist immer leicht auf andere mit dem Finger zu zeigen.
Du hast nicht einen vernünftigen, sinnvollen Satz zu dem Thema Automatisierung abgelassen.
Anstelle die Beiträge lesen und zu verstehen, bist du zu weit von der Realität abgehoben, um ernsthaft das Thema zumindest zu diskutieren.
Wer unterstellt, wenn auf ein Modell verweisen wird, an ein 3D Modell gedacht werde, der zeigt was derjenige wirklich von der Programmierung versteht.

Und Ideen? Wer führt denn das große Wort und will die Automatisierung revolutionieren und hat keine Ahnung?
Wir können zumindest programmieren. 

Nimm dir eine Auszeit und denk nach.

bike


----------



## Blockmove (23 April 2014)

Siemens hat ja vor einiger Zeit Unigraphic übernommen.
Damit haben sie mit NX ein sehr leistungsfähiges 3D-CAD-System.
Es wird wohl gerade an der Kopplung TIA-PLCSIM-UG "gebastelt".
Wenn das 3D-Modell "sauber" ist, dann beherrscht NX schon heute Kollisionserkennung.
Also könnte zumindest das Thema Simulation / Test vielleicht einfacher werden ... So in 10-15 Jahren 

Gruß
Dieter


----------



## Thomas_v2.1 (23 April 2014)

Blockmove schrieb:


> Siemens hat ja vor einiger Zeit Unigraphic übernommen.
> Damit haben sie mit NX ein sehr leistungsfähiges 3D-CAD-System.
> Es wird wohl gerade an der Kopplung TIA-PLCSIM-UG "gebastelt".
> Wenn das 3D-Modell "sauber" ist, dann beherrscht NX schon heute Kollisionserkennung.
> Also könnte zumindest das Thema Simulation / Test vielleicht einfacher werden ... So in 10-15 Jahren



3D kann man auch selber machen, mit der Unreal Engine oder der Blender Gameengine. Hab zusammen mit dem ErwinLSE da mal was entwickelt:
http://www.youtube.com/watch?v=KzuPgLJ88UU


----------



## bike (23 April 2014)

Ein 3D Modell damit Störkonturen gefunden werden ist doch schon heute mit jedem bessern CAD Programm möglich.
Doch mit der Simulation kann man nach meinem Wissen keine Software validieren.
Jetzt warte ich auf die PLC ProgrammierAPP für das Eifon.
Denn dann weiß ich, dass es langsam Zeit wird zu gehen. 


bike


----------



## Thomas_v2.1 (24 April 2014)

bike schrieb:


> Doch mit der Simulation kann man nach meinem Wissen keine Software validieren.



Eine Simulation ist schon aufwendig, aber eine automatische Validierung eines kompletten Anlagenprogrammes ist geschätzt mindestens Faktor 10 aufwändiger. Und wie will man z.B. die Stabilität eines Regelkreises beweisen, wenn man mangels gebauter Anlage überhaupt kein Prozessmodell hat?


----------



## bike (24 April 2014)

Thomas du hast wie meist leider recht.
Ich wollte dem TE erklären, dass er bevor das nächste mal so eine unsinnige Frage stellt, sich informieren sollte.


bike


----------



## Skrjiban (24 April 2014)

@Thomasv2.1: Das überzeugt mich. Darf man also sagen, dass eine Verifikation bzw. Validierung schon erstrebenswert ist, aber nur dann, wenn sie auch wirklich die komplette Anlage miteinbezieht, was aufgrund der hohen Komplexität unmöglich ist?



> 3D kann man auch selber machen, mit der Unreal Engine oder der Blender  Gameengine. Hab zusammen mit dem ErwinLSE da mal was entwickelt:


Das sieht ziemlich cool aus. Mit welcher Schnittstelle exportierst du die Daten aus PLCsim?


----------



## Thomas_v2.1 (24 April 2014)

Skrjiban schrieb:


> Das sieht ziemlich cool aus. Mit welcher Schnittstelle exportierst du die Daten aus PLCsim?


Es gibt dazu eine offizelle Schnittstelle, nennt sich S7ProSim. Damit kann man auch direkt die Peripheriedaten modifizieren, nicht nur das Prozessabbild.
Beim TIA-Portal Plcsim ist die Schnittstelle allerdings nicht mehr vorhanden.


----------



## bike (24 April 2014)

Skrjiban schrieb:


> @Thomasv2.1: Das überzeugt mich. Darf man also sagen, dass eine Verifikation bzw. Validierung schon erstrebenswert ist, aber nur dann, wenn sie auch wirklich die komplette Anlage miteinbezieht, was aufgrund der hohen Komplexität unmöglich ist?
> 
> 
> Das sieht ziemlich cool aus. Mit welcher Schnittstelle exportierst du die Daten aus PLCsim?



Bist du wirklich überzeugt oder fragst du nur ins blaue hinein?
Du nimmst ein Stichwort und machst an einer Stelle weiter, obwohl dir die Grundlagen nicht geläufig sind.

Es ist nach heutigem Stand der Technik nicht möglich in einem überschaubaren Rahmen realistische Modelle zu erstellen und dann die Software zu validieren.



bike


----------



## Skrjiban (24 April 2014)

> Es ist nach heutigem Stand der Technik nicht möglich in einem  überschaubaren Rahmen realistische Modelle zu erstellen und dann die  Software zu validieren.


Das habe ich verstanden. Ich möchte wissen, ob ihr es als sinnvoll erachten würdet, wenn es denn möglich wäre. Das ist eine ehrliche Frage, keine rhetorische.


----------



## winnman (24 April 2014)

Da das Erstellen eines entsprechenden Modells Aufwändig ist, müsste zuerst mal geklärt werden welchen Nutzen das bringen kann. 

Wenn man das Modellerstellen der Eisenwarenhandlung (mech Konstruktion) umhängen kann dann könnte man das Modell sozusagen als Pflichtenheft betrachten.

Wenn es jetzt noch eine einfache Möglichkeit gäbe das Programm auf das Modell loszulassen dann würde das ev. was bringen.

Da die Realität aber meist so ausschaut, dass die mech und e-Konstruktion parallellaufen und die mech-Änderungen meist sehr spät an die E-Konstruktion gehen (falls überhaupt) wird das schönste Modell wunderbare Testergebnisse liefern, das Programm im Realen Leben aber sicher ganz anders als das vom Modell aussehen. -> Sinnlose Anstrengung im Einzelmaschinenbau, . . . ev. im Serienmaschinenbau denkbar.


----------



## bike (24 April 2014)

Skrjiban schrieb:


> Das habe ich verstanden. Ich möchte wissen, ob ihr es als sinnvoll erachten würdet, wenn es denn möglich wäre. Das ist eine ehrliche Frage, keine rhetorische.



Ist es realistisch zu beamen?

bei der Entwicklung von TIA und Win$ wurden bzw werden Modelle zur Validierung verwendet.
Das Ergebnis? 
Da kann man sagen: war nicht im Modell. Doch wem hilft es?
Unsere Konstruktion erklärt mir immer wieder:
Im Modell hat es doch gepasst.

Daher die Skepsis, ob es sinnvoll sein kann.

Sollen wir uns nicht davon verabschieden, dass alles mathematisch berechenbar ist?
Mathematik ist spannend und interessant, doch nicht alles kann damit erklärt werden.


bike


----------



## Blockmove (24 April 2014)

winnman schrieb:


> Da das Erstellen eines entsprechenden Modells Aufwändig ist, müsste zuerst mal geklärt werden welchen Nutzen das bringen kann.
> 
> Wenn man das Modellerstellen der Eisenwarenhandlung (mech Konstruktion) umhängen kann dann könnte man das Modell sozusagen als Pflichtenheft betrachten.
> 
> Wenn es jetzt noch eine einfache Möglichkeit gäbe das Programm auf das Modell loszulassen dann würde das ev. was bringen.



Wie bereits gesagt, soll es bei Siemens Unigraphics so eine Lösung mal geben.
Du kannst ja bei vernünftiger 3D-Konstruktion heute schon jedes Teil im CAD bewegen.
Im einfachsten Fall gibst du dann dem Zylinder im CAD die SPS-Adressen von Ventil und Ini's.
So hast du dann - vielleicht - eine vernünftige Simulation. Und dies könnte die Inbetriebnahme verkürzen.

Aber das hat nicht mit Software-Validierung zu tun.
Ich glaub*e *Skrjiban hat immer noch nicht begriffen wie eine Anlage funktioniert ...

Gruß
Dieter


----------



## norustnotrust (24 Juni 2014)

Interessanter Ansatz und die, die mich kennen wissen, eigentlich steh ich auf sowas (der Thread könnte quasi fast von mir sein) ABER

Erstens ist ein vollständiges Modell der Anlage kein nice-to-have sondern ein must have. Ansonsten hast du nur den halben Teil des Problems. Stellt aber ja mal grundsätzlich kein Problem dar.

Zweitens gehst du imho von einer zu geringen Komplexität aus. Du schreibst von 4-5E/A. Ich hab mir das mal exemplarisch an einem Motor angesehen:
Bereit: 2E, Lock: 4E, Feedback:1E, MCB:1E, Lokal:2E, Auto:ca.16E, Visu:ca. 4E macht ca. 30E für den Ausgang ON also 2^30 Möglichkeiten sind an die 1,1Mrd möglichen Kombinationen die du für jeden Motor betrachten willst?

Drittens muß man natürlich in der Definiton aus den 1,1Mrd Möglichkeiten die finden die gültig bzw. nicht gültig sind. Wie wahrscheinlich ist es dabei Fehler zu machen?

Viertens bleibt das Problem mit den Zeitgliedern die du fast immer hast. Im obrigen Beispiel muß nämlich natürlich wenn nach Ablauf der Zeit x das Feedback nicht kommt der Ausgang 0 werden. (sofern das für den Motor parametriert ist)

Deine letzte Frage kann ich leider nicht beantworten. Da die Frage ob ich das einsetzen würde am Kosten/Nutzen Verhältnis liegt und ich die Kosten nicht abschätzen kann bleibt sie für mich wertlos.


----------



## ducati (25 Juni 2014)

norustnotrust schrieb:


> Zweitens gehst du imho von einer zu geringen Komplexität aus. Du schreibst von 4-5E/A. Ich hab mir das mal exemplarisch an einem Motor angesehen:
> Bereit: 2E, Lock: 4E, Feedback:1E, MCB:1E, Lokal:2E, Auto:ca.16E, Visu:ca. 4E macht ca. 30E für den Ausgang ON also 2^30 Möglichkeiten sind an die 1,1Mrd möglichen Kombinationen die du für jeden Motor betrachten willst?



Und das sind fast die Mindestanforderungen für einen kleinen Motorbaustein.

Wie sowas auch aussehen kann sieht man an der PCS7-APL-Bibliothek: 

Anhang anzeigen MotSpdL_APL_80SP2_s7jal80a_de-DE.pdf


Gruß


----------



## MrSpexx (25 Juni 2014)

Wie komme ich an diese PCS7-APL Bibliothek?


----------



## ducati (25 Juni 2014)

MrSpexx schrieb:


> Wie komme ich an diese PCS7-APL Bibliothek?



PCS7 kaufen. Ist dann mit dabei.

Gruß.


----------

