Aspekte des Sicherheitsnachweises

zum Einsatz rechnergestützter Leittechnik in

kerntechnischen Anlagen Freddy Seidel

Fachbereich Sicherheit in der KerntechnikBundesamt für Strahlenschutz

Willy-Brandt-Straße 538206 Salzgitterfseidel@bfs.de

2/18

Inhalt:

Sicherheitsnachweis zu Leittechnikumrüstungen (Entwicklungsstand)

Regelwerk Beherrschung gemeinsam verursachter Ausfälle Sicherheitsnachweis für vorgefertigte Leittechnikkomponenten Berücksichtigung der Betriebserfahrung Aspekte Nachweismethoden: Deterministik versus Probabilistik Strukturierung des Sicherheitsnachweises

Zusammenfassung/Ausblick

Schematische Darstellung der KKW-Leittechniknach Umrüstung im Bereich abgestuftersicherheitstechnischer Bedeutung

3/18

ÜberwachungSicherheits-funktionen

Vorrangsteuerung

Gateway

Anlagenbus

Service-rechner

Service-rechner

System zurProzesssteuerungund -überwachung

Sicherheitsleittechnik Betriebsleittechnik

~~

Automatisierungssystem:(Regeln, Verriegeln)

~

MM

Reaktorleistungs-begrenzung

Reaktorschutz

(digital ...) (digital) (analog)

abgestufte Sicherheitsbedeutunghöchste Sicherheitsbedeutung geringe Sicherheitsbedeutung

Sicherheitsbus

Feldkomponenten (Messen, Ansteuern)

Han

dmaß

nahm

en

(...analog)

4/18

Qualifizierung rechnergestützter Leittechnik(Status) Die Leittechnikkomponenten werden mit Werkzeugen (Spezifikationstools, Code-Generatoren, Simulatoren) auf Plattformen nach plattformspezifischen Auslegungs- und Qualifizierungsanforderungen (Invarianten) entwickelt. Die Vorqualifizierung der Komponenten erfolgt nach unterschiedlichen Standards (nationale/ internationale branchenspezifische Standards) Für den Einsatz vorgefertigter Leittechnikkomponenten in der Kerntechnik kann eine Nachqualifizierung nach kerntechnischen Sicherheitsstandards erforderlich werden. Diese Entscheidung hängt ab von

- der sicherheitstechnischen Bedeutung der Anwendung - den verfügbaren Informationen über das Qualifizierungsverfahren und - der verfügbaren relevanten Betriebserfahrung.

Top-down Approach:Abstufung von Anforderungen anhand von Sicherheits-ebenen und Funktions-/Gerätekategorien

5/18

Sicherheitsgrundsatz top

Schutzziele

Sicherheitsfunktion

Systemfunktion ------------------- Ergänzung für Sicherheitsleittechnik -------------------

Sicherheitsleittechnik-Funktion

Sicherheitsleittechnik-System

Leittechnik-Teilsystem

Komponente down

Sicherheits-ebenen

Funktions- /Geräte-

kategorien

6/18

Regelwerk Die technologische Entwicklung der Leit- und Rechentechnik eilt der Weiterentwicklung entsprechender Normen voraus. In KKW wird für Einrichtungen mit hoher Sicherheitsbedeutung i.d.R. keine Neuentwicklung, sondern eine eingehend qualifizierte und betriebsbewährte Technologie eingesetzt.

Sofern technologische Details berücksichtigt werden, sollten die Fach- normen dem Entwicklungsstand der eingesetzten Technik entsprechen. Übergeordnete Anforderungen an Qualifizierung und Nachweisführung sollten dem aktuellen Stand der Sicherheitsphilosophie entsprechen.

Leitlinien: Sicherheitsleitlinien der IAEA, EU-Konsensusbericht; Leitlinien der Reaktorsicherheitskommission (RSK), Kapitel 7 „Sicherheitsleittechnik“ Fachregeln: DIN-IEC-Normen (Leitsysteme: DIN-IEC 61513; Kategorisierung: DIN-IEC 61226; Software Kat. A: DIN-IEC 60880; Kat. B/C: DIN-IEC 62138); Regeln KTA 350x; Überarbeitung der Chapeauregel KTA 3501 steht 2005 an.

7/18

Beherrschung Gemeinsam Verursachter Ausfälle durch Software-Fehler (GVA/CCF) Der Nachweis zur Beherrschung des GVA für rechnergestützte Leittechniksysteme ist wesentlicher Bestandteil des Sicherheitsnachweises. Der Nachweis beruht auf in die Tiefe gestaffelte Maßnahmen gegen das Totalversagen der Leittechnikfunktion:

Ausfall-beherrschung

(Diversität, Toleranz,...)

Fehlererkennung/-beseitig. (V&V)

Fehlervermeidung (QS, Konstruktion)

Beherrschung von GVA - Beitrag der Diversität 1/3 Anwendungsfall: System aus verteilten Rechnern mit Echtzeitfunktionen Nachweisziel: Ein GVA kann sich nur auf ein Teilsystem (eine Diversitätsgruppe) auswirken. Charakterisierung des Funktionsversagens infolge eines SW-Fehlers (z.B. infolge eines SW-Spezifikationsfehlers):

Funktionsversagen ist systematisch (mit Potential für einen GVA), z.B. bei gleicher Historie des Anlagenbetriebs (gleiche Eingangsdaten für die Leittechnik) und bei gleicher leittechnikinterner Betriebshistorie (z.B. zeitgleicher Systemstart, Synchronbetrieb von Teilsystemen)

Anderenfalls ist das Funktionsversagen stochastisch. Anlagen- und System-Historie werden durch Signaltrajektorien charakterisiert (zeitabhängige Daten des Anlagenbetriebs u. Leittechnik-Betriebsfunktionen).

8/18

Beherrschung von GVA - Beitrag der Diversität 2/3

Maßnahme Diversität: Zwei oder mehrere unterschiedliche Mittel oder Verfahren stehen zur Verfügung, um ein bestimmtes Ziel zu erreichen. Diversität muss auf der Funktionsebene realisiert werden, wenn ein GVA in einem Teilsystem nicht zum Totalausfall der Leittechnikfunktion führen soll

=> Funktionale Diversität: Die Leittechnikteilsysteme arbeiten unterschiedliche Signaltrajektorien asynchron ab.

9/18

Beherrschung von GVA - Beitrag der Diversität 3/3

(SW-) Diversität allein genügt nicht, um das Nachweisziel zu erreichen; es sind weitere gestaffelte Maßnahmen vorzusehen (s. VDI/VDE 3527; weiterentwickelt zu Normenentwurf IEC 62340):

Ableitung der I&C-Anforderungen aus der Basisauslegung der Anlage Anforderungen an die Spezifikation der Leittechnik auf den Ebenen System, Teilsystem und HW-/SW-Komponenten; speziell hinsichtlich Fehlervermeidung; Fehlertoleranz; Integrität Anford. an die physische Entkopplung u. Robustheit von Teilsystemen Anforderungen an die Instandhaltung (System, HW, SW)

(SW-) Diversität versus Komplexität des Gesamtsystems (Kompatibilität der Teilsysteme zueinander; erhöhter Aufwand für analytische Qualifizierung)

10/18

Strategie und Bewertungsschema zum Nachweis derVerlässlichkeit vorgefertigter Leittechnikkomponenten

11/18 Nach Pavey, D.J.: CEMSIS - Cost Effective Modernisation of Systems Important to Safety, Work Package 6,FISA-2003, Luxembourg, November 2003

B-BBB-BBB-BB......B-GBGering

B-BBB-BB......B-GBMittelB

B-GB......B-GBHoch

A-BBA-BB...A-WBGering

A-WB...MittelA

...A-WBHoch

NeinJa,liegtvor

NeinJa,liegtvor

NeinJa,liegtvor

Betriebser- fahrung ?

Komplexität

Sicher-heits-klasse

boxBlack-(BB)

boxGrey-(GB)

BoxWhite-(WB)

Testmethode

12/18

Berücksichtigung der Betriebserfahrung:International kontrovers geführte Diskussion:

GB: Zuverlässigkeitsanforderungen werden quantitativ vorgegeben; Nachweis durch statische Analyse und Tests

F: Bereits vor Einsatz des ersten Systems muss der vollständige Sicherheitsnachweis erbracht werden; vom Vorabeinsatz in Bereichen mit geringerer Sicherheitsbedeutung wird kein Kredit genommen.

==> Zweckbestimmung für Betriebserfahrung; z.B.:

- Aufdeckung neuer Fehlermodi; Analyse hinsichtl. Auslegungsinvarianten - Übertragbarkeit - Sicherheitsnachweis - Zuverlässigkeitsbewertung; PSA

==> Aufstellung von Kriterien zur Anwendung der Betriebserfahrung

==> Aufstellen von Anforderungen an die Sammlung der Betriebserfahrung

13/18

Kriterien zur Berücksichtigung der Betriebserfahrungen für den Sicherheitsnachweis: Relevanz der bisherigen Betriebserfahrung für den neuen Einsatz (vergleichbares Anforderungsprofil, Berücksichtigung der Systemumgebung) Nachvollziehbares, umfassendes Konfigurationsmanagement (HW/SW, Syst.) Nachweis zum Reifegrad der Leittechnikentwicklung (Updatehäufigkeit) Nachvollziehbare, vollständige Aufzeichnung der Betriebserfahrung (Spezifikation der Betriebsdaten und Informationen; s. z.B. COMPSIS-GL) Kriterien für Beschränkung der Anwendung der Betriebserfahrung auf die Ebene von Teilsystemen, SW-Komponenten oder Betriebssystemsoftware Spezifische Kriterien zur Berücksichtigung der Betriebserfahrung von Entwicklungs- und Qualifizierungstools

14/18

Berücksichtigung der Betriebserfahrungen für den Sicherheitsnachweis - Mögliche SW-Ebenen für Nutzung der Betriebserfahrung:

Gesamtes SW-System (Funktions- pläne)

Anwend.spez. SW(System)

Tool-SW(off-line)

(Compiler, V&V, Instandhaltung)

SW-Komponenten(z.B. Vergleicher)

Betriebssystem-SW (Ablaufumgebung: u.a. I/O, Datentransfer)

Vorgefertigte SWAnwendungsspezifischentwickelte SW

Nachweismethode: Deterministik versus Probabilistik

15/18

• Statistik aus Betriebserfahrung/ Betriebsbewährung:

- komplexes System (Daten)- Teilsystem (Daten)- HW-Komponente- SW-Komponente (Theorie)

• Analyse- und Testergebnisse für:- komplexes System (Testabdeckung)- Teilsystem- HW-Komponente- SW-Komponente

(Testabdeckung: KISS-Prinzip)

Argumente(kursiv: proble-matisch)

• Zuverlässigkeitswert:- Ausfall pro Zeiteinheit (betriebl.Fkt.)- Ausfall pro Anforderung (Schutzfkt.)

• Herstellungsqualität(insbes. funktionale Eigenschaften)

Nachweis-ziel(kursiv:pro-blematisch)

• System festverdrahtet / SW-gestützt • HW-Komponente• SW-Komponente

• System• HW-Komponente• SW-Komponente

Anwendung:(kursiv: nicht Stand der Technik)

ProbabilistikDeterministik

Strukturierung des Sicherheitsnachweises nach demBehauptung-Argument-Beweis-Prinzip; Beispiel:Anforderung zur Verhinderung der Fehlerausbreitung

16/18 Nach Courtois, P.J.: Semantic structures and logic properties of computer-based system dependability cases,Nuclear Engineering ans Design 203 (2001) 87-106

ÜbergeordneteNormen/ Leitlinien

System-NormenIEC 61513/ 61508

HW-Normen• Schnittstellenausleg.• Gericht. Datenfluss• Betriebsbewährung

Funktion

System

HW-Komponente

SW-Komponente

Plattformprozess Behauptungen/Beweis Argumente Regelwerk

SW-Normen:IEC 60880/ 61508x?

• Redundanz/Diversit.• Räuml.-en. Trenn.• Deterministisches Systemverhalten

• Transferprotokoll• Datentrennung• Betriebsbewährung?

Funktionstest

Systemtest(Typtest)

HW-Typtest

SW-AnalysisSW-Test

• Funktionale Trenn. von Teilssystemen• Funktion. Diversität

Top

- Do w

n

Teilsyst. sind funktion.nicht verknüpft

Teilsyst. sind funkt.nicht verknüpft

SW reagiert fail-safe

Einzelfehler bleibtlokal begrenzt

Systemausleg. geg.Fehlerausbreitg

17/18

Zusammenfassung (1/2) Vorliegende Bewertungen zu Einzelaspekten des Sicherheitsnachweises:

Auf Komponentenebene kann eine geeignete Nachqualifizierung den Nachweis nach nicht-kerntechnischen Standards ergänzen. Funktionale Diversität stellt in Kombination mit Maßnahmen wie Separation die wesentliche Grundlage für den Nachweis zur Beherrschung von GVA dar. Es sind Kriterien für die Nutzung der Betriebserfahrung für den Sicherheitsnachweis aufzustellen und zu beachten; ggf. bei Beschränkung auf Teilsysteme und Komponenten. Nach dem derzeitigen Entwicklungsstand lässt sich das anforderungs- gerechte Verhalten von Sicherheitssystemen auf probabilistischer Basis nicht nachweisen. Ein derartiger Ansatz könnte aber den Zuverlässig- keitsnachweis für Betriebs- und Hilfsfunktionen unterstützen. Für den Nachweis zu vorgefertigten Komponenten liegt ein Bewertungs- schema vor, das Abhängigkeiten vom Testumfang, der Betriebser- fahrung, der Komplexität und der Sicherheitsklasse berücksichtigt.

18/18

Zusammenfassung (2/2) Bezug zur Informatik:

Wird Softwarediversität zur Beherrschung des systematischen Funktionsversagens eingesetzt, ist nachzuweisen, dass die diversitären Softwarelösungen voneinander unabhängig entwickelt wurden und im Anforderungsfall widerspruchsfrei funktionieren. Der Nachweis der Softwaresicherheit kann anhand der Softwarekomplexität ausgerichtet werden. Hierzu sind geeignete Metriken zu entwickeln. Die Ausführung des Sicherheitsnachweises kann durch eine semiformale Nachweisprozedur unterstützt werden, bei der systematisch und hierarchisch die Qualifizierungsbehauptungen mit entsprechenden Argumenten und Beweisen verknüpft werden. Die praktische Anwendbarkeit ist noch zu demonstrieren. Die künftige Methodenentwicklung zum Nachweis quantitativer Zuverlässigkeitsziele wird weiter zu beobachten sein; z.B. auf Komponentenebene anhand von statistischen Tests.