Safety Plan. Safety Plan LINZ. System: Doc.Reference: Issue: 1. Date: Prepared by: Herr Anton. Realeased by:

Transkript

1 Safety Plan System: Dokument: Doc.Reference: LINZ Safety Plan S-LINZ E Safety Plan Schmachtl.docx Issue: 1 Date: Prepared by: Herr Anton Realeased by: Seite 1 von 15

2 Inhaltsverzeichnis 1 Zielsetzung 3 2 Basisanforderungen Projektkenndaten Grundlegende Anforderungen an Funktionalität und sicherheitstechnische Eigenschaften 3 3 Projektorganisation Projektmitarbeiter Funktionale Sicherheitsbeurteilung, Zertifizierung V-Modell zum Entwicklungsprozess 5 4 Qualitätssichernde Maßnahmen Projektstrukturplan Anforderungen an die Dokumentation Verzeichnis der Dokumente und Ablage Formale Struktur erstellter Dokumente Freigabe von Dokumenten V&V-Plan SMX Verifikationen Reviews 11 5 Anhang Änderungshistorie 15 Seite 2 von 15

3 1 Zielsetzung In diesem Dokument wird das Safety Management (Projektplan) zur Umsetzung der Vorgaben aus der Spezifikation festgelegt. Das Dokument spezifiziert verbindliche Vorgaben zur organisatorischen und praktischen Umsetzung. Weiter werden hierin übergeordnete Maßnahmen zum Nachweis der nach Systemspezifikation geforderten sicherheitstechnischen Eigenschaften festgelegt und dokumentiert. 2 Basisanforderungen 2.1 Projektkenndaten Teststand - LINZ 2.2 Grundlegende Anforderungen an Funktionalität und sicherheitstechnische Eigenschaften Die grundlegenden Anforderungen an Funktionalität und sicherheitstechnischer Eigenschaften sind in der projektspezifischen Systemspezifikation festgelegt. Seite 3 von 15

4 3 Projektorganisation 3.1 Projektmitarbeiter Name Aufgabe Qualifikation Unternehmen Ort Kontakt Herr Anton Projektleiter Dipl. Ing. SCHMACHTL Linz Frau Berta Sicherheitstechnik, Validierung Dipl.Ing. SCHMACHTL Linz Herr Bravo Sicherheitstechnik, Validierung Sicherheitstechniker SCHMACHTL Linz Herr Caesar SPS-Programmierung Sicherheitssystem Elektrotechniker SCHMACHTL Linz Frau Dora SPS-Sicherheitssystem, Schaltschränke Elektromeister SCHMACHTL Linz Herr Emil Vertriebsverantwortung Vertriebsschulung Sicherheit SCHMACHTL Linz Herr Friedrich Elektroplannung Elektromeister SCHMACHTL Linz Herr Gustav Softwareentwicklung E-Techniker SCHMACHTL Linz Seite 4 von 15

5 3.2 Funktionale Sicherheitsbeurteilung, Zertifizierung Eigenzertifizierung 3.3 V-Modell zum Entwicklungsprozess Grundlage für den Entwicklungsprozess sind die Vorgaben aus der EN (Teil 2 und 3) einschließlich des V-Modells für die Software-Entwicklung. EN für Validierung V&V Plan verweist auf verschiedene Dokumente welch durch die Gesamtdokumentenübersicht ersicht wieder gefunden werden können. Seite 5 von 15

6 4 Qualitätssichernde Maßnahmen 4.1 Projektstrukturplan Der Projektstrukturplan benennt alle Aktivitäten innerhalb des Projektes mit einer eindeutigen ID-Bezeichnung. Soweit Unklarheit über die Zuordnung neuer Dokumente besteht, ist der Projektleiter zu kontaktieren. Hauptgruppe ID-Element Beschreibung 1xx 105 Systementwurf 110 Risikobeurteilung Spezifikationen 120 Safety Plan 130 V+V Plan 140 Protokolle zu Sitzungen 2xx 210 Schaltpläne 220 Architektur HW-Design 230 Zertifikate von Einzelkomponenten 240 Probabilistik Sicherheitsbauteile 3xx 310 Software Flussdiagramme 320 Programmlisting SW-Design 4xx 410 Hardware FMEA FMEA 5xx 520 Validierungsaufzeichnungen Validierung 530 Validierung Methode Siemens SPS 540 Software Code - Review 550 SISTEMA 6xx Anleitungen 7xx Hilfsdokumente 610 Betriebsanleitung 620 Betriebsanleitungen Komponenten 630 CE Erklärung 640 Typenschild Seite 6 von 15

7 4.2 Anforderungen an die Dokumentation Die Anforderungen an die Dokumentation werden gemäß EN und / oder EN realisiert. Die Verwaltung der Dokumente ist auf die Anforderungen des Projektstrukturplanes und deren Strukturelemente abgebildet Verzeichnis der Dokumente und Ablage Die im Projekt erstellten bzw. neu verwendeten Dokumente werden in der Datei Verzeichnis der Dokumente LINZ verwaltet. Hierzu sind folgende Regeln zu beachten: Jedes Dokument erhält eine eindeutige Referenzbezeichnung bestehend aus folgenden Elementen: o Projektkategorie bestehend aus ( S = Technische Spezifikation, D = Technische Dokumentation, F = FMEA) o Projektbezeichnung, LINZ. o Die Nummer des Strukturelements, auf die sich das Dokument bezieht. o Die Dokumentennummer innerhalb des Strukturelements o Die Version o Die Information, ob sich das Dokument in der Entwurfsphase ( E) oder ob es freigegeben ist (F). Beispiel: S-LINZ E Ändert sich ein Dokument, so ist dies in der Datei Verzeichnis der Dokumente.xls in der Tabelle Historie mit Angabe der Änderung und Eintrag von Namen und Datum. Die Dokumente werden im Laufwerk /Datenträger/ gespeichert. Für die Ablage existiert hierzu ein identisches Ordnungsprinzip nach dem Strukturplan, d.h., jedes Strukturelement besitzt einen eigenen Ordner auf dem Teamdrive. Jedes Verzeichnis basierend auf einem Strukturelement besitzt weitere drei Unterordner mit folgenden Bedeutungen: Work: aktuelles Arbeitsverzeichnis Release: freigegebene Versionen Miscellaneous: evtl. weitere Ordner und Dokumente Alle Verzeichnisse können weitere Unterverzeichnisse mit Angabe der aktuellen Version besitzen. Der Zugriff auf die Daten ist durch das Teamlaufwerk limitiert. Der Benutzerkreis ist identisch mit dem Projektteam (Zugriff über Serverlogin). Seite 7 von 15

8 4.2.2 Formale Struktur erstellter Dokumente Verbindliche Dokumente innerhalb des Entwicklungsprojektes LINZ sind wie folgt aufgebaut: Hierzu gehören: Titel des Dokuments Dokumentenreferenz Version Autor Bearbeitung des Änderungsindexes mit Angabe der durchgeführten Änderung und Eintrag von Datum und Namen Es ist sicherzustellen, dass sich auf jeder Seite des Dokuments die aktuelle Seitenzahl und die Angabe der Gesamtseiten befinden Freigabe von Dokumenten Dokumente werden ausschließlich über die im V&V Plan festgelegten Personen freigegeben. Hierzu ist ein entsprechender Eintrag in die Datei /abc/abc/.. erforderlich. Seite 8 von 15

9 4.3 V&V-Plan Die Form des V&V Plans wird wie folgt festgelegt: Nr. Bereich Umfang 1 Dokumentenordner Kurzbeschreibung Inhalt Input Name des Dokuments Durchführung Name des Erstellers Validierung Name der Review- Person Output Ergebnisdokument Aufgrund der einfacheren Handhabung wird der V&V Plan als eigenständiges Dokument geführt. Doc.Ref.: S-LINZ V&V Plan Seite 9 von 15

10 4.4 Verifikationen Entwicklungsphase Maßnahme für Validierung System-Validierung Risikobeurteilung System Tests Hardware-Validierung Hardware FMEA Software- Validierung Hardware Entwicklung Systemdokumentation Produktion Software Review / Modultests SW-Integrationstests Software Design und Tools Unterlagen ( Source- Code, Beschreibung verwendeter Bibliotheken ) HW-Design-Review HW-Grenzwert- und Performancetests Durchführung eines Reviews zur Systemdokumentation Durchführung eines Reviews zur Produktionsplanung Bemerkung Risikobeurteilung enthält den strukturellen Nachweis während der Design- Phase zur Erzeilung des geforderten PL / SIL. Systemintegrationstest zum Nachweis der funktionalen und sicherheitstechnischen Gesamteigenschaften Hardware-FMEA untersucht die Wechselwirkungen und Auswirkungen von verschiedenen Designs innerhalb der Hardware Architektur Nachweis der spezifizierten Eigenschaften der einzelnen Softwaremodule. Definition der Tests innerhalb der SW-Testspezifikation Nachweis der vollständigen und ordnungsgemäßen Implementierung aller spezifizierten SW-Funktionalitäten Nachweis der Verwendung von Methoden undnachweis der Verwendung und Verwendbarkeit von bewährten SW-Modulen Nachweis der vollständigen Umsetzung der SRP/CS und SRECS gemäß der Risikobeurteilung Nachweis der spezifizierten Eigenschaften der Hardware durch Grenzwerttests. Definition innerhalb der HW-Testspezifikation Nachweis der vollständigen Integration der Risikominderung gemäß Risikobeurteilung Prüfung der Erfüllung aller Anforderungen der Rsikobeurteilung für Sicherheitsgeräte mit Anforderung SIL 3 bzw. Pl e Prüfung der Erfüllung aller Anforderungen an die Produktion incl. Produktionstests und -dokumentation für Sicherheitsgeräte mit Anforderung SIL 3 bzw. Pl e Seite 10 von 15

11 4.5 Reviews Die Entwicklungsergebnisse werden jeweils in Form eines Reviews bewertet. Hierzu sind mindestens die folgenden Inhalte zu berücksichtigen: o Review mit Titel, Name des Bearbeiters, Datum der Erstellung o Teilnehmer des Reviews, Datum und Ort der Durchführung o Ziel des Reviews o Kurzbeschreibung zum Inhalt des durchgeführten Reviews o Ergebnis mit Bewertung in Bezug auf Safety-Plan o Falls erforderlich weitere Schritte o Der Ersteller des Dokuments ist im jeweiligen Dokument in der Titelseite vermerkt (Autor) o Der Reviewer ist im V&V Plan genannt. Seite 11 von 15

12 Validierung gemäß Systemspezifikation Die spezifizierten Eigenschaften des Gesamtsystems müssen durch die gewählten Testmethoden nachgewiesen werden. Dazu zählen: Funktionstest und Grenzwertanalyse: Nachweis der spezifizierten Eigenschaften durch Verwendung geeigneter Testvektoren unter Beachtung der Anforderungen der Grenzwertanalyse. Eingangswerte werden jeweils an die möglichen Parametergrenzen und in die Mitte des Datenbereichs gelegt. Testtabelle : Funktion Methode OK Funktion # SRP/CS Resultat / Erwartung Name der Methode Sollergebnis des Tests Testbeschreibung Beschreibung des Tests Rückwirkung Validierung # Auf andere Methoden des Projekts Ergebnis Messung Seite 12 von 15

13 Integrationstests gegenüber den in Abschnitt 4 geforderten sicherheitstechnischen Maßnahmen Die aus der Sicherheitsanalyse in Abschnitt 4 geforderten sicherheitstechnischen Maßnahmen müssen nachgewiesen werden. Dies wird durch einen praktisch durchgeführten Fault-Injection-Test (FIT) wie folgt realisiert: Für jede erforderliche Sicherheitsfunktion gemäß System FMEA und HW-FMEA wird die Hardware dergestalt modifiziert, dass die beabsichtigte Veränderung der Hardwareplattform ein Ansprechen der zu testenden Softwarefunktionalität bewirkt. Die Reaktion des Systems und die dazugehörige Bewertung werden dokumentiert. Testtabelle: Lfd. - Nr Nachzuweisende Sicherheitsfunktion 1 Kurzbeschreibung der zu testenden Softwareeigenschaft Eingangstestvektor Definition der Eingangswerte. Erwartete Reaktion des Systems Beschreibung der Erwartungshaltung des Systems. Reaktion des Systems Dokumentation der beim Test erzeugten Ausgangswerte Bewertung Erfolgreich durchgeführter Test wird mit OK gekennzeichnet. Behebung/ Wiederholter Test Seite 13 von 15

14 Bereits durchgeführte Tests Testtabelle für HW/SW - Validation Version zur Validierung Funktion Methode OK Funktion # SRP/CS 1 Name der Methode Sollergebnis des Tests Funktionstest Drücken des Not-Aus Tasters unter im Testbetrieb OK Resultat / Erwartung ABB Schütze fallen ab Testbeschreibung Beschreibung des Tests auf andere Methoden des Projekts Im Automatikbetrieb wird unvermittelt der Not-Aus gedrückt; Keine Rückwirkung Es wird geprüft ob die Anlage nach dem Entriegeln des Not- Aus wieder einschaltet; Rückwirkung Validierung # Ergebnis Messung /Test 1 1 Fault Injektion Test Überprüfung des Querschluss des Not-Halts OK Einschalten ist nicht möglich ABB Schütze sind freigeschaltet; Es wird überprüft, ob der Schutz gegen wiedereinschalten gewährleistet ist. Keine Rückwirkung 2 2 Unterbrechung einer Verbindung zwischen den SMX11 und Leistungsschütz 3 2 Fremdpotentiale auf der Verbindung zwischen SMX11 und dem STO Falsches Signal / Signatur wird aufgedeckt Tabelle der verwendeten Werkzeuge Nr Bezeichnung Hersteller 1. Multimeter Fluke Version Bemerkung Seite 14 von 15

15 5 Anhang Änderungshistorie Lfd. Nr. Seite Bearbeiter Herr Anton Änderung Dokumentenerstellung Datum Seite 15 von 15