Software Resilienz im SPS-/Produktionsbereich

Zuviel Werbung?
-> Hier kostenlos registrieren
mmmh.... sehe ich nicht, daß ich mich da widerspreche:
Ob eine Strategie besser ist als die andere, kann man nicht unbedingt sagen.
Wichtig ist aber, überhaupt eine zu haben (obwohl man ja sagen kann, drauflosprogrammieren und unkommentierten Code erzeugen kann auch eine Strategie sein ;-) ), um den Code zu strukturieren und nachvollziehbar zu machen.
 
Aber da fängt es doch schon an, auch wenn der eigene Programmierstil, wirklich
der beste ist, heißt es noch lange nicht das er für das Team der beste ist, wenn es
das Team nicht beherrscht.
Das eigene Team ist eine Sache aber in der Betrachtung fehlt dann auch noch der Kunde. Wenn ein Lieferant den tollsten Programmierstil hat und mit allem Arbeitet was die Software hergibt, kommt es doch zu Problemen wenn der Instandhalter beim Kunden das Programm nicht versteht und dann wild anfängt zu ändern.
Wir haben einige Kunden die sehr detaillierte Vorschriften zu Programmierung machen, wo du eigentlich die Hände überm Kopf zusammenschlägst aber es bleibt dir keine Wahl als den Murks abzuliefern
 
deine Variante setzte aber voraus, dass die fraglichen Eingänge als Array zu verwenden sind
Ja, meine Variante setzt voraus, dass strukturiert vorgegangen wurde.

Ihr seht schon, eine Aufgabe viele Lösungen und alle funktionieren.

PS:
Heute sind es 20 Ventile, morgen 60. Will man dann 60x ein IF THEN programmieren? Also ich nicht und bereite dass von Anfang an strukturiert vor.
( ich will das aber auch nicht 20x machen, mit dem IF THEN ).
 
ich kann das jetzt nicht beurteilen - denk aber immer daran : Pflichtenhefte werde oft mit Blut (auf jeden Fall aber mit Schweiss) geschrieben
Sicherlich machen Pflichtenhefte Sinn (wenn Sie vernünftig geschrieben sind) aber oftmals wird auch da versucht die eierlegende Wollmilchsau zu erzeugen damit ja alle Anlagen gleich für die Bediener sind, egal von welchem Lieferanten sie kommen oder mit welchen Funktionen sie ausgestattet sein müssen.
Oder wenn es heißt es muss alles z.B. in FUP gelöst werden, es dürfen keine Skripte verwendet werden weil sich die eigenen Instandhalter damit nicht auskennen.
 
Was wären dem Beispiele für sauberen Code? Ich finde ich kann auch "schön" programmieren und dennoch tut die Software nicht das was sie soll.

Ich muss hier vielen recht geben. Ein sinnvolles Lastenheft für Software habe ich selbst selten gesehen. Meist sind nur die mechanischen Abläufe beschrieben und elektronische Komponenten vorgegeben! Aber Softwarespazialfunktionen kommen meist erst während der ib dazu. So kann man nur schwer den Aufwand abschätzen wenn diese nicht klar sind. Und dann kommt eines zum anderen und man programmiert dann nicht saubere und deshalb evtl nicht stabil.


Also eine voraussetzung für stabile Software sind klar anforderungen. Finde ich und da spielt der Kunde eine große Rolle
 
Zurück
Oben