Validierung und Verifizierung EN 13849-2

Andreas Koenig

Level-1
Beiträge
202
Reaktionspunkte
33
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo, mal eine Frage meinerseits. Was macht Ihr bezüglich der Validierung und Verifizierung gemäß EN 13849-2 ? Das scheint ja ein Spagat zu sein zwischen im geforderten Umfang in der Praxis kaum realisierbaren Maximalforderungen, sieht man mal von der Großserien- und Massenfertigung ab, bei der sich der erhebliche Aufwand auf zahlreiche Endprodukte verteilen dem praktisch machbar (Blöderweise bin ich aber im Sondermaschinenbau tätig. Dass irgend jemand auf die Idee kommen könnte, Maschinen in der Stückzahl 1 herzustellen, will den Normengebern anscheinen aber nicht in den Kopf bzw. es sitzen nur Masssenhersteller in den Greminen. Gruss Andreas
 
Zuletzt bearbeitet:
Hallo Andreas,

eine gute Frage für den Sonntagabend!

Ich habe diese Norm bisher nur genutzt, wenn ich Fehlerausschlüsse
etc. recherchieren wollte.

Daher bin ich Dir jetzt und heute leider keine Hilfe.

Wollte mich aber wenigstens melden.

Kann man die ganzen Normen auch überbewerten???
Wer außer uns guckt da überhaupt rein???

Gruß
Tommi
 
Zuletzt bearbeitet:
Hallo Andreas,
wie kann man diese Normen anwenden.
Wir haben intensiv darüber nachgedacht und Ihr könnt mir glauben was in den Normen steht ist in den allermeisten Fällen logisch und man erfüllt vieles sowieso. Ich bin bei mehreren Fragelisten gelandet die mir die Forderungen auflisten und ich muss mir bei der Konstruktion Antworten einfallen lassen.
Als erste Empfehlung immer wenn möglich zertifizierte Bauteile einsetzen, hier hat sich der Hersteller schon Gedanken gemacht, sprich FMEA die Grundlegenden und Bewährten Sicherheitsprinzipien und weitere Anforderungen sind schon erfüllt. Was muss man jetzt noch machen die Datenblätter und Regeln der Hersteller beachten. Wenn man jetzt die Normen 13849-1 und -2 liest denkt man ist nicht machbar. Aber wenn man die Verifizierung schon bei der Konstruktion mitlaufen lässt ist es auf einmal nicht mehr so viel wie es aussieht. Beispiele Umgebungsbedingungen, Temperatur, IP Schutzart usw. muss man eh prüfen. Jetzt dokumentiere ich das alles noch anhand einer, ja ich benutzte das Wort Checkliste und den Datenblättern dies muss man aber so ablegen das der Validerer auch in kurzer Zeit Überprüfen kann ob es stimmt. Bei der Auswahl eines Bauteils macht man schon einen Großteil der Verifizierung eine strukturiertes Dokumentieren ist jetzt schon die halbe Miete.
Und zur Gegenfrage wie konstruierst Du eine Sicherheitsfunktion ohne Verifizierung und Validierung.
 
Hallo,

ich würde mich freuen, wenn wir mal in nächster Zeit eine gemeinsame
Definition von Validierung und Verifizierung erstellen.

Ist das eigentlich dasselbe in der Sicherheitstechnik wie in der
Qualitätssicherung?

Gruß und guten Wochenstart.

Tommi
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Disskusionsgrundlage

13849-1
4.7 Verifikation, dass der erreichte PL den PLr erfüllt
Für jede einzelne Sicherheitsfunktion muss der PL des zugehörigen SRP/CS dem nach 4.3 bestimmten erforderlichen Performance Level (PLr) entsprechen (siehe Bild 3). Wenn das nicht der Fall ist, wird eine Wiederholung des Prozesses, wie in Bild 3 beschrieben, notwendig.
Die PL verschiedener SRP/CS, die Teil einer Sicherheitsfunktion sind, müssen größer oder gleich dem erforderlichen Performance Level (PLr) dieser Funktion sein.

13849-2
Der Zweck des Validierungsverfahrens ist, die Spezifizierung und die Konformität der Gestaltung der sicherheitsbezogenen Teile der Steuerung (SRP/CS) innerhalb der Gesamtspezifizierungen für die Sicherheitsanforderungen an der Maschine zu bestätigen.
 
Hallo zusammen,

Safety's Normenzitierung stimmt mit dem, was ich heute nachgelesen habe, überein.

Bei der Verifizierung wird gecheckt, dass der Lichtvorhang, den man gerne
einsetzen würde, auch für die ermittelte Gefährdung der Maschine ausreichend ist (PLr gegen PL, incl. MTTF, DC, CCF, Abstand).

Bei der Validierung muss festgestellt werden, dass der Lichtvorhang wirklich alle Gefährdungen abschaltet, die den Bediener treffen können
(PL/PLr ist dabei nicht mehr relevant, es geht rein um Logik) und dass er sich im täglichen Betrieb der Anlage als die richtige Wahl herausstellt und nicht z.B. neue Gefährdungen hervorruft (z.B. herausschleudernde Werkstücke).

Unsere QM-Leute (nicht unser Forums-QM :ROFLMAO:) sehen das fast genauso, aber nur fast. Bei denen geht es nicht um Lichtvorhänge, sondern um Prozesse.

Gruß
Tommi

PS: QM=Qualitätsmanagement
 
Zuletzt bearbeitet:
Ist dann angedacht, die Validierung in Gedanken und Schaltplan durchzuführen oder an der Maschine (Querschluss erzeugen, einkanaligen Fehler erzeugen usw und schauen was die Maschine macht)?
Oder sinnvollerweise beides davon?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo, wenn man das Ganze entsprechend der Normen macht, ist es sehr sehr umfangreich.

Das fängt an, dass man alles sehr genau spezifizieren muss, von den Umgebungsbedingungen herunter bis welche Schaltspannung für welchen Sicherheitskreis zu verwenden, welche Programmodule in einer programmierbaren Sicherheissteuerung verwendet werden, wie die E/A der Sicherheitssteuerung genau zu belegen sind, wie Testungen über die SPS genau auszuführen sind, welche Nachlaufzeit für den Lichtvorhang zulässig ist etc. Diesen Aufwand schätze ich auf mindestens 3/4 des Gesamtaufwandes.

Die Zweite Runde würde dann in einer Prüfplanung bestehen, in der festgelegt wird, wie geprüft wird dass die o.G. Anforderungen und Spezifikationen erfüllt sind. Das geht ja nicht nur um die ISO 13849 z.B auch z.B.
- Prüfung der Verdrahtung
- VDE- Prüfung
- Nachlaufmessung
- Prüfplanungen für die Prüfung der Sicherheitsssteuerung auf logischer, funktioneller Ebene und auf E/A -Ebene (Beispiel: wir schalten als 3. Redundanzpfad die Schaltspannung aller Ventilinseln ab, die gefährliche Bewegungen ansteuern, wenn man die Wartungstür öffnet. Dies ist der sichere Zustand = Stillstand. Dh. auch wenn das Sicherheitsschaltgerät komplett versagt und den Sicherheitsventilblock nicht abschaltet, z.B. eine Dauer-1 programmiert), würde die SPS noch die Bewegungen stoppen --> Sichtprüfung ist zur Verifizierung unzureichend, es muss geschaut werden, dass auch die 2 Spulen am Sicherheitsventilblock tatsächlich abgeschalten werden)
- Prüfen der Sicherheitsschaltgerätprogrammierung und SPS-Test-Programmierung (das ist schon wieder ein größerer Komplex)
- Prüfen eventueller Sicherheitsschnittstellen (von der anderen Seite der Schnittstelle korrekt implementiert? )
- spezifizierte Bauteile auch tatsächlich verbaut etc etc. )

Da ist die 13849 ein Sonntagsspaziergang gegen... Gruss Andreas
 
Ist dann angedacht, die Validierung in Gedanken und Schaltplan durchzuführen oder an der Maschine (Querschluss erzeugen, einkanaligen Fehler erzeugen usw und schauen was die Maschine macht)?
Oder sinnvollerweise beides davon?

Hallo,

sicherlich beides.:s12:

Ich war bisher der Meinung, daß das Prüfen von Querschlüssen etc.
Bestandteil der Verifizierung im Rahmen der Modultests ist und die Validierung dann die eigentliche Funktionstestung mit Fehlersimulation
z.B. Not-Halt während Muting oder Betriebsartenumschaltung während
Not-Halt etc., ist (siehe V-Modell für Software nach 13849-1 im Anhang).

Und last not least ist Validierung der Test, daß die Sicherheitsfunktionen auch den Betriebsanforderungen (Dreck, Anreiz zur Manipulation, etc.) standhalten, also die Prozeßfähigkeit gegeben ist.

In der 13849-2 steht das aber anders, da soll auch der Querschluss etc.
im Rahmen der Validierung getestet werden.

Oder ist der Hauptunterschied zwischen Verifizierung und Validierung der,
das Beides von unterschiedlichen Personen durchgeführt wird, die Testinhalte aber identisch sind? Also wird doppelt geprüft!? Oder prüft der, der es gebaut hat, garnicht? Oder irgendwas dazwischen?

Wenn man den Aufwand, den Andreas beschreibt, schon treibt, dann soll er auch "gerichtsfest" sein.

Wenn wir eine Anlage abnehmen, dann verifizieren wir nicht. Das bestätigt
uns der Lieferant mit dem CE-Zeichen. Ausnahmen bei begründetem Verdacht.
Wir validieren die Funktionen der Anlage und die Prozeßfähigkeit, wie oben beschrieben.

So, das wär's für jetzt...

Gruß
Tommi
 

Anhänge

  • V-Modell.JPG
    V-Modell.JPG
    46,4 KB · Aufrufe: 162
Zuletzt bearbeitet:
Ich muss das Thema nochmal aufgreifen.

Es gibt von der IFA den Report 2/2016. Arbeitet jemand nach dieser Methode ? Die Software die von der IFA für 2017 angekündigt wurde scheint ja noch nicht fertig zu sein. (SOFTEMA)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Lipperlandstern,
ich habe mir den Bericht auch angesehen hatte aber schon meine eigene Umsetzung der Norm in entsprechenden Dokumenten erstellt. Ich finde die Matrix-Methode nicht besonders gut, warum soll ich nochmal eine Zeichnung von einer Steuerung machen und mit bunten Bilder die Komponenten darstellen. Wichtig ist das man in der Risikobeurteilung schon ordentlich die SF definiert und dann dem Programmierer klar mitteilet was die Software zu leisten hat. Alle Komponenten sind schon im Schaltplan und wenn es richtig läuft ist die Hardware beurteilt. Dann kommt die Software und man muss Programmierregeln erarbeiten, da die SF in der SRASW oft gleich bzw. sehr ähnlich sind. Z.B. schon Vorgaben machen wie Baugruppen zu parametrisieren sind und welche geprüften Funktionsbausteine wie eingesetzt werden müssen. Alle Programmierer entsprechend auf den gleichen Wissenstand bringen und sehen das sich alle an die Regeln halten. Man kann so schon sehr viele Fehler vermeiden.
Ich habe es in letzter Zeit immer mehr mit sehr großen Maschinen zu tun und kann mich mit der Matrix-Methode nicht anfreunden. Anlagen mit 3000 sicheren E/A sind da nach meiner Meinung nicht abdeckbar.
Ein Kollege von mir Herr Stefan Weidle hat unsere Vorgehensweise mal auf der Motek mit einem Vortag vorgestellt, den findest Du auf unserer Homepage.
 
Hallo,
ich denke der Bericht findet in der Praxis sicher Anwendung. Ich meine, dass namhafte Anbieter von Sicherheitstechnik selbst mit Abschaltmatrizen arbeiten. Ich sehe insbesondere die Skalierbarkeit für große Anlagen so wie Safety kritisch.
Generell ist die Methode jedoch mit Vorsicht zu genießen. Den Bereits in der Einleitung steht:
"Zusätzlich zur Anwendung der Matrixmethode müssen im Einzelfallweitere Details spezifiziert und geprüft werden, z. B.
• herstellerspezifische Parametrierungen der verwendeten Peripheriegeräte
(z. B. Umrichter, Sensoren),
• weitere sicherheitsrelevante Funktionen der Maschinensteuerungen,
die nicht von der Matrixmethode des IFA abgedeckt
sind, und
• zusätzliche sonstige, nicht direkt sicherheitsrelevante Funktionen,
wie z. B. spezielle Quittierphilosophien"
Hier kommen neben der Matrix noch einige Sachen hinzu (z. B. Parametrierung der verwendeten Bausteine, Safetyklemmen etc.)

@Safety: Schreibt ihr bei dem Softwareentwurf (seite 15 in der Präsentation) wirklich jede SF so auf? Bei ca. 300 SF ist das auch ein hoher Aufwand(Bitte nicht als kritik verstehen, finde die Darstellung schon sinnvoll)
 
Hallo,
ja das ist unsere Vorgehensweise einmal eine Tabelle für die Hardware und einmal für die SRASW.
Erst wird in der Risikobeurteilung, die oft auch von uns kommt, jede Sicherheitsfunktion definiert und auch aufgeführt, danach geht es an die Anwendung der DIN EN ISO 13849-1 zunächst an die HW Beurteilung, dabei verwenden wir Sistema nur als Taschenrechner. Die ganzen anderen Sachverhalte die in der Sistema mit einem Häkchen bestätigt werden, ermitteln und dokumentieren wir in dieser Form. Aber man kann sehr oft und sehr viel zusammenfassen. Dann geht es an die SRASW auch hier haben wir eine Tabelle entwickelt in der die wichtigsten Anforderungen der Norm aufgeführt sind, aber auch hier kann man sehr viel zusammenfassen, da ja nur der Softwareteil betrachtet wird.
Beispiel:
Not-Halt Hardware viele Not-Halt schalten verschiedene Antriebe die aber alle z.B. über ein Schaltgerät abgeschaltet werden das auf die STO Eingänge geht. Die Software deckt nur das Einlesen und verarbeiten der Not-Halt Signale und das Abschalten des Schaltgerätes ab. Wie man sieht ist die Software ja nur ein Teil und man kann zusammenfassen. Auch arbeiten wir mir Programmausdrucken bzw. Ausschnitten um den Datenfluss und die Funktion nachzuweisen, zu erklären und zu dokumentieren. Wie schon geschrieben macht es auch Sinn sowohl in der SRASW als auch bei der Parametrisierung von Baugruppen und Komponenten vorgaben zu machen die schon einmal validiert wurden. Wie bei der Auswahl von schon vom Hersteller geprüften Bausteinen, die sichtet man, wählt entsprechend der Aufgabe die richten aus, klärt wie die Parametrisierung aussehen muss und validiert diese so vor, nun müssen die nur so verwendet bzw. können sogar kopiert werden. Also klar Programmierregeln, insbesondere bei großen Projekten kann man so schon jede Menge Fehler vermeiden, auch wird die sogenannten Safety-Matrix (hat nix mit der Matrix-Methode zu tun) als eine Art Softwareentwurf benutzt und damit die Integrationstests durchgeführt.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Guten Abend.

Als reiner Softwaredienstleister für den Sondermaschinenbau waren wir gezwungen unsere SRASW umfassend zu dokumentieren. Hintergrund war ganz einfach der, dass wir eine Absicherung brauchten und die Verantwortung klar abgrenzen mussten. Denn - auch wenn es keiner hören will - ich kenne keinen Maschinenhersteller, der dem Programmierer eine Softwarespezifikation mit Auflistung der SF in die Hand drückt. Oft ist es rätselraten anhand von PLr, EPlan, Betriebsartenvorgaben und Endkundenwünschen. Ein zur Anlage passendes Sistemaprojekt ist mir noch nicht untergekommen.

Wir dokumentieren unsere SRASW anhand der Matrixmethode, wobei ich die Darstellung etwas vereinfacht habe (Inhalte sind aber ähnlich). Z.B. werden hier auch Gruppierungen dargestellt und dann jeder SF zugeordnet. Vermutlich sieht das ähnlich wie bei Safety aus... und wir haben auch keine 3000 EAs (max. 100).
Als Ergebnis erhält unser Maschinenbauer ein Dokument, dass er vom E-Konstrukteur/Sicherheitsbeauftragten validieren lassen kann. Der Aufwand bis hier hin hält sich mit entsprechenden Vorlagen und einem Standard in der SRASW in Grenzen... auch bei Unikaten.

Für uns als Dienstleister ist diese Methode also durchaus sinnvoll. Vorallem dann, wenn tatsächlich mal was passieren sollte.
 
Zurück
Oben