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

Seite 2 von 2 ErsteErste 12
Ergebnis 11 bis 14 von 14

Thema: Baumusterprüfung / Softwareprüfung

  1. #11
    Registriert seit
    03.11.2003
    Beiträge
    84
    Danke
    12
    Erhielt 0 Danke für 0 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Hallo Peter,

    Vielleicht kannst Du mir erklären , was ist denn mit einem Modul gemeint ?

    Ist es das Programm Netzwerk
    Ist es die Funktion, die sich im Programm wiederholt?
    Oder wie kann ich das verstehen ?

    Du würdest mir sehr helfen wenn ich wenigstens diesen Begriff endlich verstehen könnte.

    Mit freundlichem Gruß
    Stephan

  2. #12
    Registriert seit
    30.01.2004
    Ort
    Erfurt
    Beiträge
    961
    Danke
    42
    Erhielt 109 Danke für 87 Beiträge

    Standard

    Guten Abend,

    ich versuch mal kurz meine lückenbehafteten Kenntnisse zusammenzufassen. Stell Dir ein 'V' vor: Strich von links oben nach mitte unten und dann wieder hoch nach rechts oben.

    Links oben in der Ecke beginnt der Prozess der Softwareentwicklung mit der Beschreibung der Anforderungen. Danach geht es auf dem V weiter nach unten: das Programm wird entworfen, erst in groebn Zügen und dann von oben nach unten dabei immer feiner werdend: Module beschreiben, Zusammenhänge zwischen den Modulen (M1: Werte lesen, M2: Werte skalieren und prüfen, M3: ......). Irgendwann kommst Du dann auf der Ebene einzelner Funktionen an. Diese werden zuerst mit Ihrer Schnittstelle beschrieben und dann kommt der Teil den 'richtige' Programmierer verächtlich 'Kodieren' nennen - die Umsetzung in ein Programm.

    Wichtig: zwischendurch immer Prüfschritte (Vollständigkeit, Widerspruchsfreiheit,...) einfügen und (z.B. für den TUEV) das Ergebnis dieser Prüfungen dokumentieren. Alles fertige dem Auftraggeber vorlegen und abnicken lassen (nachweisbar!). Im Zweifelsfall wieder einen Schritt zurück auf dem V nach oben und neu beschreiben.

    Das Kodieren nun ist der Punkt mitte unten beim V - jetzt gehts wieder aufwärts. Und zwar von der Ebene der Einzelfunktionen immer weiter bis zum fertigen Produkt: z.B. funktioniert das Einlesen der Analogwerte, was macht die Funktion bei Drahtbruch, Kurzschluß, Überspannung etc.

    Nach dem Test der Einzelfunktionen die größeren Module testen und das Programm/die Maschine/Anlage Stück für Stück anfahren. Wichtig hierbei: Validierung, also immer wieder auf die linke Seite des V gucken, wo ja nun stehen sollte, was die Funktion/das Modul/die Maschine tun muß: stimmt das Soll-Verhalten mit dem Ist-Verhalten überein? Was passiert in Extremsituationen (Stromausfall, NotAus, Sensordefekt, Überlast,.......)
    Und alle Schritte dokumentieren.....

    Das V-Modell stammt ursprünglich wohl aus der militärischen Ecke und ist inzwischen in der Form V-Modell97 bzw. jetzt anscheinend V-Modell XT für alle Softwareprojekte der öffentlichen Hand zwingend vorgeschrieben. Ich hör immer wieder, das auch so grandiose Projekte wie die Autobahnmaut und die Hartz4-Software danach erstellt worden - sollte das stimmen ist entweder das Werkzeug V-Modell nicht ok oder die Werkzeugbenutzer....

    Wegen der Verwendung bei der öffentlichen Hand gibt es (oder besser gab es ca. 2002 als ich mal damit befaßt war) sehr viele Veröffentlichungen darüber im Netz von diversen öffentlichen Stellen

    In meiner Erinnerung schreibt keine Norm die Verwendung des V-Modells z.B. in Deinem Fall vor, aber wenn Du danach vorgehst, solltest Du auf der sicheren Seite sein.

    Stichwort Modul: man zerlegt die Aufgabe in einzeln beschreibbare und ganz wichtig eindeutig prüfbare Module. Bei Dir könnte ich mir vorstellen: SPS1 und SPS2 und dann weiter: Modul Werte einlesen und prüfen, Modul Überwachung, Modul Regler, Modul HMI,........

    Jedes Modul besteht dann aus einzelnen Funktionen, Netzwerke im Sinne SPS-Programmierung sind dann Teil der Funktionen.

    Schönen Abend noch!
    __
    Mit freundlichem Gruß Peter

    ...Wir sind Alle Zeitreisende. Die überwiegende Mehrzahl schafft allerdings täglich nur einen Tag.... (Jasper Fforde: "In einem andern Buch")

  3. #13
    Registriert seit
    25.02.2006
    Ort
    CH-Bern
    Beiträge
    25
    Danke
    0
    Erhielt 0 Danke für 0 Beiträge

    Standard

    Hallo Bebaste,
    Ein bisschen Off- Topic, aber du schreibst, dass du zwei unabhängige Steuerungen S7-200 verwendest, die sich gegenseitig überwachen.
    Ich hab mal einer TÜV- Abnahme beigewohnt (TÜV Brandenburg), bei der der Prüfer zwei über CAN-Bus kommunizierende Steuerungen als potenziell unsicher kritisiert hat. Wir mussten damals zusätzlich einen Handshake über diskrete IOs realisieren.
    Ich gehe davon aus, dass die zwei SPS über MPI/PPI kommunizieren. Hast du alle Vorkehrungen getroffen, dass bei einem Ausfall der Kommunikation die Anlage auf jeden Fall in einen sicheren Zustand wechselt? Habt Ihr auch vorgängige Risikoanalysen für Ausfälle von sicherheitsrelevanten Elementen gemacht?

  4. #14
    Registriert seit
    22.11.2005
    Ort
    kl.Odenwald
    Beiträge
    716
    Danke
    111
    Erhielt 85 Danke für 71 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Ich kram den Artikel mal wieder raus, da wir hier auch (versuchen) das V-Modell anzuwenden.


    Den Modulbegriff verwende ich eigentlich nur noch gleichwertig mit tatsächlich gekapselten FC's oder FB's. Ich definiere was rein geht und was rauskommt.
    Entsprechend gibt's dazu den Modultest.
    (Es sind natürlich auch andere Definitionen möglich, je nachdem was nahe liegt)
    Der Modultest kann sowohl als Entwicklertest, als auch zur Qualifizierung durchgeführt werden. Ist er im ersten Schritt gut dokumentiert, kann der zweite Schritt einfacher ausfallen und umgekehrt.


    Einige Zeit haben wir versucht, den Zusammenbau der Module mit dem Begriff "Integrationstest" zu verbinden, was sich bis jetzt nichts so Sinnvoll herausgestellt hat.

    Das weiteren gibt's denn Blackbox-Test, der nachvollziehbar die Betriebs- und Fehlerfälle erschlagen soll.
    Als einfache Doku kann es reichen, das (unterschriebene) Pflichtenheft zu kopieren und Stück für Stück abzuarbeiten, oder es werden zusätzlich
    Dokumente angefertigt, die die genaue Teststrategie beschreiben.

    Schliesslich kann man auch noch einen Installationstest durchführen. Zum einen um überhaupt nachzuweisen, dass die CPU alles schluckt was man da so in seinem Projekt zusammengebaut hat. Aber auch, dass das beschriebene Vorgehen zur Systemwiederherstellung (Defekte MMC, Defekte CPU) funktioniert. Stichwort "Recovery"

    Und Risikoanalyse? Ich sehe das etwas durchwachsen, sie macht nur sinn, wenn die entsprechenden Kompetenzen hierzu verfügbar sind.
    "Das Leben ist viel zu kurz, um schlecht zu essen !"
    (Johann Lafer zur SWR3 Grillparty)
    Zitieren Zitieren V-Modell  

Ähnliche Themen

  1. Softwareprüfung nach GAMP5
    Von MariusW im Forum Programmierstrategien
    Antworten: 20
    Letzter Beitrag: 23.08.2010, 23:37
  2. Anlagendokumentation: Baumusterprüfung Atex
    Von AndreK im Forum Schaltschrankbau
    Antworten: 10
    Letzter Beitrag: 18.01.2008, 10:24

Lesezeichen

Berechtigungen

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