Baumusterprüfung / Softwareprüfung

[bebaste]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo guten morgen an alle,

Ich bin auf der Suche nach Jemandem der mir bei folgendem Problem behilflich sein kann.

Mein Kunde ( Maschinenbauer ) hat eine Anlage gebaut „wie immer“.
Bei der Fertigung stellt sich heraus das der Endkunde eine Baumusterprüfung für diese Anlage fordert.
Dann trat der TÜV auf den Plan.
Jetzt muss ich dazu sagen das ich nicht Studiert habe, sondern mit den Aufgaben das Programmieren von SPS Steuerungen „erlernt“ habe.
Die Baumusterprüfung ist soweit gelaufen. Laut TÜV ist die Anlage auch so i.O.
Prüfprotokoll liegt vor jedoch fehlt :

1. Es fehlt der Nachweis, dass die vorhandene Steuerung die Anforderungen nach Kategorie 3
von EN 954-1 erfüllt.

Jetzt fordert der TÜV laut Prüfvorgaben relativ Umfangreiche Dokumente von mir.

Jetzt zu meinem Problem.
Ich habe mir einem TÜV Mitarbeiter begonnen die Software „Implementierungsphase“ nachzustellen.
Aber ich verstehe die Vorgehensweise einfach nicht. Er ist aber auch nicht in der Lage mir die div. Schritte so zu erklären das ich diese bearbeiten kann. Was ist z.B. Sicherheitstechnik in der Software oder wie kann ich die Programmierrichtlinie erklären.

Gibt es wohl jemanden der das kann und sich evtl. bereit erklärt mir dabei zu helfen.

Mit freundlichem Gruß
Stephan

 

[knabi]

Was für eine SPS setzt Du denn ein? Wenn das keine Sicherheitssteuerung ist (Simatic F, Pilz PSS), muß die Maschinensicherheit durch separate Hardware, z.B. Pilz PNOZ oder Siemens SIGUARD, erreicht werden. Allerdings sollte der Kunde ja in dieser Hinsicht Vorgaben gemacht haben.

Gruß

Holger

 

[bebaste]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wir benutzen S7/200.
Die Anlage ist Redundant aufgebaut .
1.SPS übernimmt Regelaufgaben
2.SPS überwacht SPS 1 und gibt z.B. Netzschütz frei.
Natürlich gibt es auch die/das nötige Not Aus Relais.
Also wie gesagt, die Anlage funktioniert und ist auch durch den TÜV als Regelkonform bestätigt.
Was fehlt ist der Dokumentarische Nachweis der Sicherheitskat. der SPS Programme.

Mit freundlichem Gruß
Stephan

 

[PeterEF]

Hallo,

Ich habe mir einem TÜV Mitarbeiter begonnen die Software „Implementierungsphase“ nachzustellen.

Das klingt irgendwie nach V-Modell oder ähnlichen Vorgaben für die Softwareentwicklung. Theoretisch anspruchsvoll und gut - in der Praxis kenn ich kein erfolgreich und im Zeitrahmen damit durchgeführtes Projekt.

Falls sowas gemeint ist - Google liefert massenhaft Hinweise dazu.

 

[bebaste]

Hallo,
ich bin mir nicht ganz sicher ob ich den begriff V-Modell richtig interpretiere.
Aber ich will mein Problem Nocheinmahl anders beschreiben.

Der TÜV hat diese Prüfgrundlage:
EN 1493:1998
EN 61508:2001
EN954-1:1997 Kat.III

Und normalerweise wird eine Anlage ja erst gebaut wenn div. Prüfmechanismen durchgeführt wurden.
wie z. B Validierungsplan , Blockschaltbilder , Pflichtenheft , Implementierung SPS Programm usw.

Das ist bei uns aber leider nicht so gewesen. Das bedeutet die Anlage ist gebaut worden und in der Bauphase sind div. Modifikationen durchgeführt worden. Was eigentlich kein Problem darstellt.
Und zum Schluss der Prüfung kam ein Software Mann des TÜV.
Mit diesem habe ich besprochen wie man die SOFTWARE der SPS beschreiben kann.
Er wollte sich auf diese Dokumente beschränken weil , wie gesagt, die Reihenfolge ja eigentlich falsch ist.

Beispiel aus meinem Dokument:
Überwachung und Auswertung der Drehimpulse:

Durch die Drehbewegung der Spindel werden an den Initiatoren Geberscheiben vorbeigeführt, die über 8 Wischer verfügen.
Bei jeder Spindelumdrehung ergeben sich 8 Impulse die in AUF/AB-Gleichlaufzählern gezählt werden und dann weiter verarbeitet werden.
MAIN / NW 13-16 Zählen der positiven Initiatorflanken „I1 - I4“ mit Anforderung in „Z10 – Z13“

Usw. das ganze Programm hindurch.

Und nun sind mehrere Monate vergangen in denen Fragen bezüglich der Funktionsbeschreibung kamen und diese auch beantwortet wurden.
Dann hat der TÜV die weitere Bearbeitung eingestellt. Mit der Begründung „Dokumentation Lückenhaft“!
Jetzt bin ich natürlich nicht sicher ob das was ich da die ganze Zeit gemacht habe, Ansatzweise überhaupt, richtig sein könnte.
Und ob man damit weiterarbeiten kann.
Dazu fehlt mir einfach das Wissen in der Thematik:
„Anforderungen an die Sicherheitsfunktion“ / „Schaltungsstruktur“ / „Softwaregestaltung“

Und da bin ich halt auf der Suche nach Jemandem der sich mit so etwas auskennt und der mir vielleicht ein wenig auf den Richtigen Weg helfen kann.

Mit freundlichem Gruß
Stephan

 

[Kai]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hat Du mal den BIA-Report 6/97 durchgearbeitet?

BIA-Report 6/97: Kategorien für sicherheitsbezogene Steuerungen nach EN 954-1

Gruß Kai

 

[Kai]

Hallo,

Beispiel aus meinem Dokument:
Überwachung und Auswertung der Drehimpulse:

Durch die Drehbewegung der Spindel werden an den Initiatoren Geberscheiben vorbeigeführt, die über 8 Wischer verfügen.
Bei jeder Spindelumdrehung ergeben sich 8 Impulse die in AUF/AB-Gleichlaufzählern gezählt werden und dann weiter verarbeitet werden.
MAIN / NW 13-16 Zählen der positiven Initiatorflanken „I1 - I4“ mit Anforderung in „Z10 – Z13“

Usw. das ganze Programm hindurch.

Das reicht so nicht aus. Du musst dokumentieren, ob es durch den Ausfall von Bauteilen zum Verlust von Sicherheitsfunktionen kommen kann.

Was passiert z.B. beim Ausfall eines Initiator, wenn also keine Impulse mehr gezählt werden? Wird dieser Fehler erkannt? Gibt es einen zweiten Initiator, der parallel zum ersten Initiator arbeitet und die Funktion des ersten übernimmt? Kommt es zu einem Ausfall von Sicherheitsfunktionen? Kann ein gefährlicher Zustand entstehen?

Gruß Kai

 

[Kai]

Beispielhaftes Vorgehen anhand eines Feuerungsautomaten:

IEC61508-Teil 3 - Sicherheitsgerichtete Softwareentwicklung

Allgemeine Vorgehensweise (TÜV-Süd):

Entwicklung und Prüfung sicherheitsrelevanter Software nach IEC 61508-3

Gruß Kai

 

[bebaste]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das reicht so nicht aus. Du musst dokumentieren, ob es durch den Ausfall von Bauteilen zum Verlust von Sicherheitsfunktionen kommen kann.

Was passiert z.B. beim Ausfall eines Initiator, wenn also keine Impulse mehr gezählt werden? Wird dieser Fehler erkannt? Gibt es einen zweiten Initiator, der parallel zum ersten Initiator arbeitet und die Funktion des ersten übernimmt? Kommt es zu einem Ausfall von Sicherheitsfunktionen? Kann ein gefährlicher Zustand entstehen?

Gruß Kai

Hallo,
das Beispiel ist vielleicht ein bisschen wenig.
Die Anlage besteht aus 2 SPS Steuerungen die jeweils über einen Initiator verfügen, der die Drehbewegung erfasst.
Muss man in jedem Beschriebenen Software Block alle Eventualitäten aufzeigen, obwohl sich diese dann in eigenen Blöcken an anderer Stelle wiederholen würden.
Und wenn sich diese Blöcke auf SPS 2 beziehen muss dann hier ein Verweis auf die gleiche Verarbeitung in SPS 1 erfolgen ?

z.B. folgende Beschreibung die die weitere Verarbeitung der Drehimpulse beschreibt. Diese Funktion ist in jeder SPS enthalten.

Laufüberwachung:

Wenn ein Startbefehl gegeben wurde und die Ausgänge werden freigegeben, aber es gibt keine Taktimpulse der Initiatoren, wird
ein Fehlerbit gesetzt.
Werden durch die Bewegung Impulse erzeugt werden die Zähler ständig zurückgesetzt und können den vorgegebenen Schwellwert nicht übersteigen. Somit wir immer geprüft ob der Signalfluss mit der Anlagenbewegung übereinstimmt.
Das Fehlerbit führt zum sofortigen abschalten der Ausgänge. Die Anlage wechselt in „Störung“.
Das Fehlerbit wird an die SPS 1 versendet, damit diese die Motorschütze abschalten kann.

Lauf_not / NW 6-9 Rücksetzen bei positiven Initiatorflanken mit Anforderung in „Z1 – Z3“

MAIN /NW 8Bei Anforderung durch Motorschütz Ausgänge „ex_m_1_2 – ex_m_4_2“
wird durch pos. Flanke das Rücksetzbit „f_rück“ aktiviert.

MAIN /NW 8 Bei Anforderung durch Drucktaster Heben/Senken „ex_he_2“ – „ex_se_2“
wird durch pos. Flanke das Rücksetzbit „f_rück“ aktiviert.

Lauf_not / NW 6-9 „f_rück“ aktiviert , wodurch die Zähler „Z1 – Z3“ , zurückgesetzt werden.

Lauf_not / NW 10 Vergleich der Zähler „Z1“-„Z4“ mit Schwellwert „lim_lauf“ wenn >/= dann
setzen der Fehlerbits „lauf_1“ – „lauf_4“

Lauf_not / NW 11 „lauf_1“ Rücksetzen „netz“ Ausgang Netzschütz.

Meldung / NW 6 „Gleich_Fehler“ >=1 takten von „s_Gleich“

Meldung / NW 12 „Gleich_Fehler“ >=1 Setzen des Störungsbit „stoe“

MAIN / NW 6 „Gleich_Fehler“ =0 Übergabe an SPS 1 „ex_gl_3“

Lauf_not / NW 11 Rücksetzen „lauf_1“ – „lauf_4“ mit pos. Flanke SM0.7.

MAIN /NW 21 Bei anstehendem Fehlerbit „stoe“ Rücksetzen des Not Aus Merkers „ na“

MAIN /NW 25 Bei anstehendem Fehlerbit „stoe“ Rücksetzen des Netzschützes„ netz“


Mit freundlichem Gruß
Stephan

 

[PeterEF]

Hallo,

in einem ähnlichen Fall hat bei uns eine Beschreibung der Funktion nicht gelangt. Gefordert war zusätzlich eine Darstellung der Entwicklung (warum gerade so und nicht anders) und besonders wichtig eine ausführliche Dokumentation des Test der Software (sowhl der einzelnen Module als auch des Gesamtprogramms) mit Nachweis:
-entspricht das codierte Programm auch den Anforderungen
-werden alle Randbedingungen eingehalten
-wie verhält sich Modul XY bei Fehlzuständen (Daten außerhalb des normalen Wertebereichs, Ausfall von Sensoren oder der Kommunikation

Das alles wie gesagt für jedes Modul und für das Gesamtpaket. Uns wurde damals gerade eine Orientierung am V-Modell nahegelegt, wie es auch im vom Kai oben verlinkten Beispiel dargestellt ist:

Allgemeine Vorgehensweise (TÜV-Süd):

Entwicklung und Prüfung sicherheitsrelevanter Software nach IEC 61508-3

Peter

 

[bebaste]

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

 

[PeterEF]

Zuviel Werbung?
-> Hier kostenlos registrieren

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!

 

[ConEx]

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?

 

[kiestumpe]

V-Modell

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.