Sie sind auf Seite 1von 87

DEUTSCHE NORM

Juni 2005

DIN EN ISO 14620-1

ICS 49.140

Raumfahrtsysteme – Sicherheitsanforderungen – Teil 1: Systemsicherheit (ISO 14620-1:2002); Deutsche und Englische Fassung EN ISO 14620-1:2002

Space systems – Safety requirements – Part 1: System safety (ISO 14620-1:2002); German and English version EN ISO 14620-1:2002

Systèmes spatiaux – Exigences de sécurité – Partie 1: Sécurité système (ISO 14620-1:2002); Version allemande et anglaise EN ISO 14620-1:2002

Gesamtumfang 87 Seiten

Normenausschuss Luft- und Raumfahrt (NL) im DIN

DIN EN ISO 14620-1:2005-06

Nationales Vorwort

Die European Cooperation for Space Standardization (ECSS), eine Einrichtung zur Erstellung eines koh‰renten, einheitlichen Normenwerkes zur Anwendung in allen europ‰ischen Raumfahrtprojekten, hat am 1996-11-13 vom Europ‰ischen Komitee f¸r Normung (CEN) das Mandat (M/237) erhalten, f¸r den CEN-Subsector T02 ÑAerospaceì Europ‰ische Normen (EN) auszuarbeiten.

die

Normungsprogramme dieser Partner abgestimmt und die Abstimmungsregeln gem‰fl Abschnitt 5.2 der

Aufgrund

der

zwischen

ISO/TC 20/SC 14

ÑRaumfahrtì

und

ECSS

vereinbarten

A-Liaison

werden

Wiener-Vereinbarung angewendet.

Die vorliegende Norm EN ISO 14620-1:2002 wurde von CEN/CS T02 auf Basis der ECSS-Q-00 unter Mitwirkung des Arbeitsausschusses 5.1.1 ÑRaumfahrtì der Normenstelle Luftfahrt erarbeitet.

Entsprechend Beschluss 57/9 des Technischen Ausschusses des Beirats der Normenstelle Luftfahrt sind die europ‰ischen Luft- und Raumfahrt-Normungsergebnisse zweisprachig, in Deutsch und Englisch, in das Deutsche Normenwerk zu ¸berf¸hren. Aus diesem Grund wurde in dieser nationalen Norm der Deutschen Fassung die Englische Fassung hinzugef¸gt.

EUROPƒISCHE NORM EUROPEAN STANDARD NORME EUROP…ENNE

EN ISO 14620-1

Dezember 2002

ICS 49.140

Deutsche Fassung

Raumfahrtsysteme ñ Sicherheitsanforderungen ñ Teil 1:

Systemsicherheit (ISO 14620-1:2002)

Space systems ñ Safety requirements ñ Part 1: System safety (ISO 14620-1:2002)

Diese Europ‰ische Norm wurde vom CEN am 24. Juni 2002 angenommen.

SystËmes spatiaux ñ Exigences de sÈcuritÈ ñ Partie 1:

SÈcuritÈ systËme (ISO 14620-1:2002)

Die CEN-Mitglieder sind gehalten, die CEN/CENELEC-Gesch‰ftsordnung zu erf¸llen, in der die Bedingungen festgelegt sind, unter denen dieser Europ‰ischen Norm ohne jede ƒnderung der Status einer nationalen Norm zu geben ist. Auf dem letzten Stand befindliche Listen dieser nationalen Normen mit ihren bibliographischen Angaben sind beim Management-Zentrum oder bei jedem CEN-Mitglied auf Anfrage erh‰ltlich.

Diese Europ‰ische Norm besteht in drei offiziellen Fassungen (Deutsch, Englisch, Franzˆsisch). Eine Fassung in einer anderen Sprache, die von einem CEN-Mitglied in eigener Verantwortung durch ‹bersetzung in seine Landessprache gemacht und dem Management-Zentrum mitgeteilt worden ist, hat den gleichen Status wie die offiziellen Fassungen.

CEN-Mitglieder sind die nationalen Normungsinstitute von Belgien, D‰nemark, Deutschland, Finnland, Frankreich, Griechenland, Irland, Island, Italien, Luxemburg, Malta, Niederlande, Norwegen, ÷sterreich, Portugal, Schweden, Schweiz, Spanien, der Tschechischen Republik und dem Vereinigten Kˆnigreich.

der Tschechischen Republik und dem Vereinigten Kˆnigreich. EUROPƒISCHES KOMITEE F‹R NORMUNG EUROPEAN COMMITTEE FOR

EUROPƒISCHES KOMITEE F‹R NORMUNG EUROPEAN COMMITTEE FOR STANDARDIZATION COMIT… EUROP…EN DE NORMALISATION

Management-Zentrum: rue de Stassart, 36

B-1050 Br¸ssel

EN ISO 14620-1:2002 (D)

Inhalt

Seite

Vorwort

5

Einleitung

5

1

Anwendungsbereich

6

1.1

Allgemein

6

1.2

Anwendungsbereich

6

1.3

Anpassung

7

2

Normative Verweisungen

7

3

Begriffe und Abk¸rzungen

7

3.1

Begriffe

7

3.2

Abk¸rzungen

12

4

Systemsicherheitsprogramm

13

4.1

Anwendungsbereich

13

4.2

Sicherheitsorganisation

13

4.2.1

Allgemeines

13

4.2.2

Sicherheitsvertreter

13

4.2.3

Berichterstattungslinie

13

4.2.4

Integrierte Sicherheit

13

4.2.5

Koordination mit anderen Stellen

13

4.3

Zugangsrecht und Befugnis des Sicherheitsvertreters

14

4.3.1

Zugang

14

4.3.2

‹bertragene Befugnis zur Zur¸ckweisung oder Unterbindung der Arbeit

14

4.3.3

‹bertragene Befugnis zur Unterbrechung von Betriebsvorg‰ngen

14

4.3.4

‹bereinstimmung

14

4.3.5

Berichtsgenehmigung

14

4.3.6

Review

14

4.3.7

Vertretung in Ausch¸ssen

14

4.4

Sicherheitsrisikomanagement

14

4.4.1

Risiko

14

4.4.2

Gef‰hrdungsbewertung

15

4.4.3

Maflnahmen

15

4.5

Projektphasen und Sicherheits-Reviewzyklus

15

4.5.1

Fortschrittsbesprechung

15

4.5.2

Projekt-Reviews

15

4.5.3

Sicherheitsprogramm

18

4.5.4

Sicherheitsdatenpaket

18

4.6

Sicherheitsprogrammplan

18

4.6.1

Durchf¸hrung

18

4.6.2

Sicherheitsaktivit‰ten

18

4.6.3

Definition

18

4.6.4

Beschreibung

18

4.6.5

Sicherheits- und Projektengineering-T‰tigkeiten

19

4.6.6

Lieferanten und Unterlieferanten

19

4.6.7

Einhaltung

19

4.7

Sicherheitszertifizierung

19

4.8

Sicherheitstraining

19

4.8.1

Bestandteil

19

4.8.2

Teilnahme

20

4.8.3

Eingehendes technisches Training

20

4.8.4

Produktspezifisches Training

20

4.8.5

Aufzeichnungen

20

4.8.6

Identifizierung

20

4.9

Berichterstattung und Untersuchung von Unf‰llen/Zwischenf‰llen

20

EN ISO 14620-1:2002 (D)

Seite

4.10

Sicherheitsdokumentation

20

4.10.1

Allgemeines

20

4.10.2

Kundenzugang

20

4.10.3

Lieferant

20

4.10.4

Dokumentation

21

4.10.5

Sicherheitsdatenpaket

21

4.10.6

Sicherheitsbezogene Sonderfreigabe (vor und nach Realisierung)

21

4.10.7

Verifikationskontroll-Dokument

22

4.10.8

Erfahrungsdatei

22

5

Sicherheitstechnik

22

5.1

Sicherheitstechnische Grunds‰tze

22

5.1.1

Allgemeines

22

5.1.2

Elemente

23

5.1.3

Gewonnene Sicherheitserkenntnisse (lessons learnt)

23

5.2

Sicherheitsbezogene Designgrunds‰tze

23

5.2.1

Menschliche ‹berlegung

23

5.2.2

Designauswahl

23

5.2.3

Gef‰hrdungsbeseitigungs- und -kontrollmaflnahmen

23

5.2.4

Umweltvertr‰glichkeit

24

5.2.5

Sicher ohne externe Dienste

24

5.2.6

ÑFail Safeì-Design

24

5.2.7

Gef‰hrdungserkennung ó Signalisierung und Sicherung

24

5.2.8

Zugang

25

5.3

Sicherheitsrisikoreduzierung und -kontrolle

25

5.3.1

Schweregrad

25

5.3.2

Fehltoleranzanforderungen

26

5.3.3

Auslegung f¸r minimales Risiko

27

5.3.4

Probabilistische Sicherheitsziele

28

5.4

Identifizierung und Kontrolle sicherheitskritischer Funktionen

29

5.4.1

Identifizierung

29

5.4.2

Unbeabsichtigtes Auslˆsen

29

5.4.3

Maflnahmen

29

5.4.4

Sichere Abschaltung und Fehlertoleranzanforderungen

29

5.4.5

Elektronische, elektrische, elektromechanische Bauelemente

29

6

Sicherheitsanalyse ó Anforderungen und Techniken

29

6.1

Allgemeines

29

6.2

Bewertung und Zuweisung von Anforderungen

30

6.2.1

Sicherheitsanforderungen

30

6.2.2

Zus‰tzliche Sicherheitsanforderungen

30

6.2.3

Sicherheitsanforderungen an Funktionen

30

6.2.4

Sicherheitsanforderungen an Subsysteme

30

6.2.5

Berechtigung

30

6.2.6

Funktions- und Subsystemspezifikation

31

6.3

Sicherheitsanalyse

31

6.3.1

Allgemeines

31

6.3.2

Missionsanalyse

31

6.3.3

Durchf¸hrbarkeit

31

6.3.4

Vordefinition

31

6.3.5

Detaildefinition, Produktion und Qualifikation

31

6.3.6

Betrieb

31

6.3.7

Entsorgung

31

6.4

Spezielle Sicherheitsanalyse

32

6.4.1

Allgemeines

32

6.4.2

Gef‰hrdungsanalyse

32

6.4.3

Sicherheitsrisikobewertung

33

6.4.4

Sicherheitsanalyse f¸r Hardware-Softwaresysteme

33

EN ISO 14620-1:2002 (D)

Seite

6.5

Unterst¸tzende Bewertung und Analyse

34

6.5.1

Allgemeines

34

6.5.2

Warnzeitanalyse

34

6.5.3

Vorsicht- und Warnanalyse

34

6.5.4

Analyse der gemeinsamen Ausfall-/Fehlerarten und -ursachen

35

6.5.5

Fehlzustandsbaumanalyse (FTA)

35

6.5.6

Analyse der menschlichen Zuverl‰ssigkeit

35

6.5.7

Fehlerart-, -auswirkungs- und -kritikalit‰tsanalyse (FMECA)

36

6.5.8

Sneak-Analyse

36

6.5.9

Zonenanalyse

36

6.5.10

Energieverlaufsanalyse

37

7

Sicherheitsverifikation

37

7.1

Allgemeines

37

7.2

Gef‰hrdungsverfolgung

37

7.2.1

Gef‰hrdungsberichtssystem

37

7.2.2

Status

37

7.2.3

Sicherheitsfortschrittsbesprechung

37

7.2.4

‹berpr¸fung und Verf¸gung

37

7.2.5

Dokumentation

38

7.2.6

Pr¸fpunkt

38

7.3

Sicherheitsverifikationsmethoden

38

7.3.1

Verifikationstechnik und Planung

38

7.3.2

Berichte und Methoden

38

7.3.3

Verifikationanforderungen

38

7.3.4

Analyse

38

7.3.5

Inspektion

38

7.3.6

Tests

39

7.3.7

Verifikation und Genehmigung

39

7.4

Qualifikation sicherheitskritischer Funktionen

39

7.4.1

G¸ltigkeit

39

7.4.2

Qualifikation

39

7.4.3

Fehlertests

39

7.4.4

Verifikation des Design oder Betriebsmerkmale

39

7.4.5

Sicherheitsverifikationstest

40

7.5

Beglaubigung des Gef‰hrdungsausschlusses

40

7.5.1

Sicherheitssicherungsstelle

40

7.5.2

Sicherheitszertifizierungsstelle

40

7.6

Restrisikoreduzierung

40

8

Betriebssicherheit

40

8.1

Anforderungsgrundlage

40

8.2

Flugbetriebs- und Missionskontrolle

41

8.2.1

Tr‰gersystem

41

8.2.2

Verschmutzung

41

8.2.3

Flugregeln

41

8.2.4

Kontrolle gef‰hrdender Befehlsgebungen

41

8.2.5

ƒnderungskontrolle des Missionsbetriebs

42

8.2.6

Sicherheits¸berwachung und Kontrolle von Anomalien

42

8.3

Bodenbetrieb

42

8.3.1

Anwendbarkeit

42

8.3.2

Einleitung

42

8.3.3

Reviews und Pr¸fungen

42

8.3.4

Gef‰hrdender Betrieb

43

8.3.5

Start- und Landeplatzanforderungen

43

8.3.6

Anforderungen an Bodendienstger‰te (Servicing-Ger‰te, Checkout- und Testger‰te, Handhabungs- und Transportger‰te, Nabelverbindungen, Hilfsger‰te)

43

Literaturhinweise

44

EN ISO 14620-1:2002 (D)

Vorwort

Dieses Dokument (EN ISO 14620-1:2002) wurde vom Technischen Komitee CEN/SS T02 „Luft- und Raumfahrt“, in Zusammenarbeit mit dem Technischen Komitee ISO/TC 20 „Luft- und Raumfahrzeuge“, erarbeitet, dessen Sekretariat vom CMC gehalten wird.

Diese Europäische Norm muss den Status einer nationalen Norm erhalten, entweder durch Veröffentlichung eines identischen Textes oder durch Anerkennung bis Juni 2003, und etwaige entgegenstehende nationale Normen müssen bis Juni 2003 zurückgezogen werden.

Die Europäische Norm EN ISO 14620-1 wurde von der ECSS-Arbeitsgruppe (European cooperation for Space Standardization) für CEN in Zusammenarbeit mit dem Technischen Komitee ISO/TC 20, Luft- und Raumfahrzeuge, Unterkomitee SC 14, Raumfahrtsysteme, WG 5, Managementprogramm, erarbeitet.

EN ISO 14620 besteht aus den folgenden Teilen mit dem gemeinsamen Titel Sicherheitsanforderungen:

Teil 1: Systemsicherheit

Teil 2: Abschussbasisoperationen

Raumfahrtsysteme —

Entsprechend der CEN/CENELEC-Geschäftsordnung sind die nationalen Normungsinstitute der folgenden Länder gehalten, diese Europäische Norm zu übernehmen: Belgien, Dänemark, Deutschland, Finnland, Frankreich, Griechenland, Irland, Island, Italien, Luxemburg, Malta, Niederlande, Norwegen, Österreich, Portugal, Schweden, Schweiz, Spanien, die Tschechische Republik und das Vereinigte Königreich.

Einleitung

Diese Europäische Norm ist eine der Serien der Raumfahrt, die zusammen mit dem Management, der Tech- nik und Produktsicherheit in Raumfahrtprojekten und Anwendung benutzt wird.

EN ISO 14620-1:2002 (D)

1

Anwendungsbereich

1.1 Allgemein

Diese Europ‰ische Norm legt das Sicherheitsprogramm und die sicherheitstechnischen Anforderungen fest, die in ‹bereinstimmung mit der in ISO 14300-2 festgelegten Sicherheitsleitlinien umzusetzen sind, um Flug- und Bodenpersonal, Tr‰ger, zugehˆrige Nutzlasten, Bodendienstger‰te, die allgemeine ÷ffentlichkeit, ˆffentliches und privates Eigentum sowie die Umwelt vor Gef‰hrdungen im Zusammenhang mit europ‰ischen Raumfahrtsystemen zu sch¸tzen. Abschussbasisoperationen sind in ISO 14620-2 beschrieben.

Die Sicherheitsleitlinien werden durch Umsetzung eines Sicherheitsprogramms, unterst¸tzt durch eine Risiko- bewertung, verwirklicht, das sich wie folgt zusammenfassen l‰sst:

a) Gef‰hrdungsmerkmale (System- und Umweltgef‰hrdungen) und Funktionen mit potentiell gef‰hrdenden Ausfall-/Fehlerauswirkungen werden identifiziert und schrittweise durch iterative Durchf¸hrung systema- tischer, deterministischer Sicherheitsanalysen bewertet;

b) potentielle Gef‰hrdungsfolgen im Zusammenhang mit den Merkmalen und Funktionsausf‰llen/-fehlern des Systems werden einer Gef‰hrdungsreduzierungssequenz unterzogen, wobei:

1)

Gef‰hrdungen aus dem Systemdesign und ñbetrieb beseitigt;

 

2)

Gef‰hrdungen minimiert;

 

3)

Gef‰hrdungskontrollmaflnahmen angewandt und verifiziert werden.

 

c) nach

Die

Durchf¸hrung

des

Gef‰hrdungsbeseitigungs-

und

-reduzierungsprozesses

verbleibenden

Risiken werden schrittweise bewertet und einer Risikobewertung unterzogen, um:

1)

die ‹bereinstimmung mit den Sicherheitszielen aufzuzeigen;

2)

vergleichende Designbewertungen zu unterst¸tzen;

3)

Risikoverursacher festzustellen und einzustufen;

4)

die Zuteilung von Projektmitteln zur Risikoreduzierung zu unterst¸tzen;

5)

den Fortschritt der Risikoreduzierung zu beurteilen;

6)

den Prozess von Sicherheits- und Projektentscheidungsfindungen (z. B. Sonderfreigaben, Restri- sikobilligung) zu unterst¸tzen.

d) Die Angemessenheit der Gef‰hrdungs- und Risikokontrollmaflnahmen wird formal verifiziert, um die Be- glaubigung der Sicherheit und die Risikobilligung zu unterst¸tzen.

e) Die Sicherheitskonformit‰t ist f¸r das Produkt zu beurteilen und die Sicherheit von den zust‰ndigen Stel- len zu erlangen.

1.2 Anwendungsbereich

Diese Europ‰ische Norm gilt f¸r alle Raumfahrtprojekte, bei denen in irgendeiner Projektphase die Mˆglichkeit von Gef‰hrdungen f¸r Personal oder die allgemeine ÷ffentlichkeit, Raumflugsysteme, Bodendienstger‰te, Einrichtungen, ˆffentliches oder privates Eigentum oder die Umwelt besteht.

Die Vorgabe dieser Anforderungen f¸r die Projektt‰tigkeiten der Lieferanten setzt voraus, dass die Projekt- Produktsicherungs- und -Sicherheitsorganisation des Kunden ebenfalls diesen Anforderungen in einer der Sicherheitskritikalit‰t des Projekts angemessenen Weise entspricht.

EN ISO 14620-1:2002 (D)

1.3 Anpassung

Im Hinblick auf den Kontext eines speziellen Programms oder Projekts sollten die in dieser Europ‰ischen Norm festgelegten Anforderungen an die tats‰chlichen Anforderungen f¸r das jeweilige Profil und die Gege- benheiten eines Programms oder Projekts angepasst werden.

ANMERKUNG Anpassung ist der Prozess, durch den einzelne Anforderungen von Spezifikationen, Normen und ver- wandten Dokumenten bewertet und f¸r ein spezifisches Programm oder Projekt durch Auswahl und in einigen Aus- nahmef‰llen durch ƒnderung von bestehenden oder Zuf¸gung von neuen Anforderungen anwendbar gemacht werden.

2 Normative Verweisungen

Diese Europ‰ische Norm enth‰lt durch datierte oder undatierte Verweisungen Festlegungen aus anderen Publikationen. Diese normativen Verweisungen sind an den jeweiligen Stellen im Text zitiert, und die Publikationen sind nachstehend aufgef¸hrt. Bei datierten Verweisungen gehˆren sp‰tere ƒnderungen oder ‹berarbeitungen dieser Publikationen nur zu dieser Europ‰ischen Norm, falls sie durch ƒnderung oder ‹berarbeitung eingearbeitet sind. Bei undatierten Verweisungen gilt die letzte Ausgabe der in Bezug genommenen Publikation (einschliefllich ƒnderungen).

ISO 14300-1, Space systems ó Programme management ó Part 1: Structuring of a programme.

ISO 14300-2, Space systems ó Programme management ó Part 2: Product assurance.

ISO 14620-2, Space systems ó Safety requirements ó Part 2: Launch site operations.

3 Begriffe und Abk¸rzungen

3.1 Begriffe

F¸r die Anwendung dieser Europ‰ischen Norm gelten die folgenden Begriffe.

3.1.1

Unfall unerw¸nschtes Ereignis, das sich aus dem Einsatz von projektspezifischen Einheiten ergibt und Folgendes bewirkt:

a) Tod oder Verletzung von Personen;

b) Verlust oder Besch‰digung von Projekt-Hardware, -Software oder ñEinrichtungen, wodurch die Erf¸llung der Mission beeintr‰chtigt werden kˆnnte;

c) Verlust oder Besch‰digung von ˆffentlichem oder privatem Eigentum; oder

d) sch‰dliche Auswirkungen f¸r die Umwelt

[EN 13701:2001]

ANMERKUNG

Unfall und Panne sind Synonyme.

3.1.2

Ursache das, was eine Wirkung hervorruft; das, was eine Aktion, eine Erscheinung oder einen Zustand zur Folge hat

ANMERKUNG 1

Ursache und Wirkung sind korrelative Begriffe (Oxford Englisch Dictionary).

EN ISO 14620-1:2002 (D)

ANMERKUNG 2 Speziell f¸r diese Europ‰ische Norm, im Zusammenhang mit der Gef‰hrdungsanalyse: Vorgang o- der Zustand, durch den ein Gef‰hrdungsereignis ausgelˆst wird (auslˆsendes Ereignis). Die Ursache kann durch einen Ausfall/Fehler, menschliches Fehlverhalten, Designmangel, induzierte oder nat¸rliche Umgebungsbedingungen, System- konfigurations- oder -betriebsart(en) entstehen.

ANMERKUNG 3

In Anlehnung an EN 13701:2001.

3.1.3

"Vorsicht"-Zustand Zustand, der das Potential hat, sich in einen "Warn"-Zustand zu verschlechtern, und spezifische Maflnahmen

erfordern kˆnnte, einschliefllich der Durchf¸hrung besonderer Verfahren oder Einschr‰nkungen f¸r den Be- trieb des Systems

[EN 13701:2001]

3.1.4

Ausfall (Fehler) mit gemeinsamer Ausfall(Fehler)ursache Ausf‰lle (Fehler) von mehreren Einheiten, die eine einzelne Ursache haben, die allen gemeinsam ist

[NUREG/CR-2300 PRA:1982]

3.1.5

Ausfall (Fehler) mit gemeinsamer Ausfall(Fehler)art Ausf‰lle (Fehler) von mehreren identischen Einheiten, die auf dieselbe Art und Weise versagen

ANMERKUNG 1

mit gemeinsamer Ausfall(Fehler)ursache.

Ausf‰lle(Fehler) mit gemeinsamer Ausfall(Fehler)art sind ein besonderer Fall von Ausf‰llen(Fehlern)

ANMERKUNG 2

In Anlehnung an NUREG/CR-2300 PRA:1982.

3.1.6

Stˆrfallverfahren ein vorausgeplantes Verfahren, das im Falle einer Abweichung von einem festgelegten Verhalten zur Anwen- dung gelangt

[EN 13701:2001]

3.1.7

kritischer Fehlzustand Fehlzustand, der als Gefahr eingestuft wird, Personensch‰den, betr‰chtliche Sachsch‰den oder andere un-

vertretbare Folgen zu verursachen

[IEC 60050:1992]

3.1.8

Not(fall) Zustand, in dem potentiell katastrophale oder kritische Gef‰hrdungsereignisse eingetreten sind und sofortige vorausgeplante Sicherungsmaflnahmen zum Schutz von Personen mˆglich und zwingend sind

ANMERKUNG

In Anlehnung an EN 13701:2001.

EN ISO 14620-1:2002 (D)

3.1.9

sicher bei Ausfall (fail safe) Konstruktionseigenschaft einer Einheit, die verhindert, dass deren Ausf‰lle zu kritischen Fehlzust‰nden f¸hren

[IEC 60050:1992]

3.1.10

Ausfall Beendigung der F‰higkeit einer Einheit, eine geforderte Funktion zu erf¸llen

[IEC 60050:1992]

3.1.11

Fehlzustand, m <Zustand> Zustand einer Einheit, in dem sie unf‰hig ist, eine geforderte Funktion zu erf¸llen, wobei die durch Wartung oder andere geplante Handlungen bzw. durch das Fehlen ‰uflerer Mittel verursachte Unf‰higkeit ausgeschlossen ist

ANMERKUNG 1 Ein Fehlzustand ist oft das Ergebnis eines Ausfalls(Fehlers) der Einheit selbst, er kann aber auch ohne vorherigen Ausfall vorhanden sein.

ANMERKUNG 2

In Anlehnung an IEC 60050:1992.

3.1.12

Fehlzustand, m <Ereignis> unplanm‰fliges Vorkommnis oder Fehler in einer Einheit, das bzw. der zu einem oder mehreren

Ausf‰llen (Fehlern) der Einheit selbst oder anderer zugehˆriger Ausr¸stung f¸hren kann

[IEC 60050:1992]

ANMERKUNG Eine Einheit kann einen Fehlzustand eines Teilelements aufweisen, einen Fehler, der sich nur unter bestimmten Umst‰nden zeigt. Wenn diese Umst‰nde eintreten, f¸hrt der Fehler im Teilelement zum Ausfall der Einheit, was eine Fehlaussage zur Folge hat. Diese Fehlaussage kann sich auf andere Einheiten ausdehnen, die dadurch ihrerseits zum Ausfall f¸hren. Nach dem Eintreten des Ausfalls gilt, dass die Einheit als Ganzes einen Fehlzustand hat oder in einem fehlerhaften Zustand ist (Definition 3.1.11 oben)

[EN 13701:2001]

3.1.13

Gef‰hrdung bestehender oder potentieller Zustand einer Einheit, die zu einer Panne f¸hren kann

ANMERKUNG

stehen und hat das Potential f¸r Pannen.

Dieser Zustand kann mit Design, Herstellung, Betrieb oder Umgebung einer Einheit im Zusammenhang

[ISO 14620-2]

3.1.14

Gef‰hrdungsereignis Ereignis, das zu unerw¸nschten Folgen f¸hrt und durch Auslˆsung einer oder mehreren Gef‰hrdungen auf-

grund eines oder mehrerer Auslˆseereignisse hervorgerufen wird

ANMERKUNG

In Anlehnung an EN 13701:2001.

3.1.15

Zwischenfall ungeplantes Ereignis, das ein Unfall h‰tte sein kˆnnen, es jedoch nicht war

[EN 13701:2001]

EN ISO 14620-1:2002 (D)

3.1.16

Sperre Designmerkmal, das eine physische Unterbrechung zwischen einer Energiequelle und einem Funktions-

auslˆser herstellt

BEISPIEL Relais oder Transistor zwischen einer Batterie und einem pyrotechnischen Auslˆser, Sperrventil zwischen Treibstofftank und Triebwerk.

ANMERKUNG 1

Zwei Sperren gelten als unabh‰ngig, wenn ein Einzelfehler nicht mehr als eine Sperre beseitigen

kann.

ANMERKUNG 2

In Anlehnung an EN 13701:2001.

3.1.17

Fehlverhalten des Betriebspersonals Versagen des Betriebspersonals, eine Handlung anforderungs- oder anleitungsgem‰fl auszuf¸hren oder die unabsichtliche oder fehlerhafte Handlung des Betriebspersonals

3.1.18

Organisation Gruppe von Personen und Einrichtungen mit einem Gef¸ge von Verantwortungen, Befugnissen und Bezie-

hungen

BEISPIELE Gesellschaft, Kˆrperschaft, Firma, Unternehmen, Institution, gemeinn¸tzige Organisation, Einzelunter- nehmer, Verband oder Teile oder Mischformen solcher Einrichtungen.

ANMERKUNG 1

Das Gef¸ge ist ¸blicherweise geordnet.

ANMERKUNG 2

Eine Organisation kann ˆffentlich-rechtlich oder privatrechtlich sein.

ANMERKUNG 3

Diese Definition gilt im Rahmen von Normen zu Qualit‰tsmanagementsystemen. Der Begriff ÑOrga-

nisationì ist im ISO/IEC-Leitfaden 2 anders definiert.

[EN ISO 9000:2000]

3.1.19

Programm koordinierter Satz von nicht notwendigerweise voneinander abh‰ngigen T‰tigkeiten, die ¸ber einen Zeitraum

bestehen und zur Erlangung weitgefasster wissenschaftlicher oder technischer Ziele oder vermehrter Kennt- nis ¸ber ein bestimmtes Thema dienen

BEISPIEL

Das Verteidigungsprogramm; das Apollo-Programm; das Erdbeobachtungsprogramm.

ANMERKUNG 1

Ein Programm kann mehrere Projekte umfassen.

ANMERKUNG 2

Ein Programm kann mehrere Jahre laufen.

ANMERKUNG 3

Ñprogramì ist die amerikanische Standard-Schreibweise f¸r Ñprogrammeì.

ANMERKUNG 4

Ñprogramì ist der britische Standard-Ausdruck f¸r Ñeine Reihe kodierter Anweisungen, um die Arbeit

eines Rechners oder einer Maschine zu kontrollierenì ó Oxford English Dictonary.

3.1.20

Projekt Gesamtheit von koordinierten T‰tigkeiten mit bestimmten Start- und Zielpunkten, die von einer Person oder Organisation durchgef¸hrt werden, um spezifische Ziele im rahmen festgelegter Zeit-, Kosten- und Leistungsparameter zu erreichen

[BS 6079:1996]

EN ISO 14620-1:2002 (D)

3.1.21

Auftraggeber Kunde in einer Vertragssituation

ANMERKUNG

Der Auftraggeber wird manchmal als die Ñbusiness second partyì bezeichnet.

3.1.22

Restrisiko Risiko, das in einem System nach Ausf¸hrung des Gef‰hrdungsreduzierungs- und -¸berwachungsprozesses

bestehen bleibt

[EN 13701:2001]

3.1.23

Risiko quantitatives Mafl f¸r die Grˆfle eines potentiellen Verlusts und die Eintrittswahrscheinlichkeit eines solchen Verlusts

[EN 13701:2001]

3.1.24

sicherer Zustand Zustand, der nicht zu kritischen oder katastrophalen Folgen f¸hrt

3.1.25

sicherheitskritische Funktion Funktion, die bei Verlust oder Minderung oder durch unsachgem‰flen oder unbeabsichtigten Betrieb zu ka- tastrophalen oder kritischen Folgen f¸hren kˆnnte

ANMERKUNG

In Anlehnung an EN 13701:2001.

3.1.26

Sicherung(smaflnahme) Maflnahme, die durchgef¸hrt wird, um Not- und Warnsituationen einzugrenzen oder unter Kontrolle zu bringen oder ein System (oder einen Teil davon) in einen vorausbestimmten sicheren Zustand zu versetzen

ANMERKUNG

In Anlehnung an EN 13701:2001.

3.1.27

Lieferant Organisation oder Person, die ein Produkt bereitstellt

BEISPIEL Hersteller, Vertriebseinrichtung, Einzelh‰ndler, Verk‰ufer eines Produkts oder Erbringer einer Dienst- leistung oder Bereitsteller von Informationen.

ANMERKUNG 1

Ein Lieferant kann der Organisation angehˆren oder ein Auflenstehender sein.

ANMERKUNG 2

In einer Vertragssituation wird ein Lieferant manchmal als ÑAuftragnehmerì bezeichnet.

[EN ISO 9000:2000]

EN ISO 14620-1:2002 (D)

3.1.28

System Zusammenstellung von zusammenh‰ngenden Elementen zum Erreichen eines vorgegebenen Ziels durch

Ausf¸hrung einer festgelegten Funktion

ANMERKUNG

getrennt betrachtet, die die Verbindungen zwischen diesen und dem betrachteten Systems trennt. ‹ber diese Verbindun-

gen wird das System durch die Umgebung beeinflusst, der Einwirkung externer Systeme ausgesetzt oder wirkt selbst auf die Umgebung oder externe Systeme ein.

Das System wird von der Umgebung und anderen externen Systemen durch eine imagin‰re Oberfl‰che

[IEC 60050:1992]

3.1.29

Systemsicherheit Anwendung von Engineering- und Managementgrunds‰tzen, -kriterien und -techniken, um alle sicherheitsbe- zogenen Aspekte innerhalb der Grenzen von Funktionsf‰higkeit, Zeit und Kosten w‰hrend aller Lebens- zyklusphasen des Systems zu optimieren

3.1.30

Warnzustand Zustand, in dem potentiell katastrophale oder kritische Gef‰hrdungsereignisse unmittelbar bevorstehen und

vorausgeplante Sicherungsmaflnahmen innerhalb einer begrenzten Zeit durchgef¸hrt werden m¸ssen

ANMERKUNG

In Anlehnung an EN 13701:2001.

3.1.31

Zonenanalyse systematische Pr¸fung der geographischen Lage der Elemente und der Wechselwirkungen eines Systems, Bewertung der potentiellen Wechselwirkungen zwischen Subsystemen mit und ohne Ausfall/Fehler und Be-

urteilung der Schwere der mˆglichen systeminstallationseignen Gef‰hrdungen

3.2

Abk¸rzungen

Die folgenden Abk¸rzungen werden in dieser Europ‰ischen Norm entsprechend benutzt.

Abk¸rzung

Bedeutung

CCB

Konfigurations-‹berwachungsausschuss

ECSS

European Cooperation for Space Standardization

EEE

elektronisch, elektrisch, elektromechanisch

FMECA

Fehlerart-, -auswirkungs- und -kritikalit‰tsanalyse

FTA

Fehlzustandsbaumanalyse

GEO

geostation‰re Umlaufbahn

GSE

Bodendienstger‰t

IEC

Internationale Elektrotechnische Kommission

LEO

niedrige Erdumlaufbahn

MIL STD

milit‰rische Norm (US Verteidigungsministerium)

MIP

verbindlich vorgeschriebener Pr¸fpunkt

NRB

Nichtkonformit‰ts-Untersuchungsausschuss

NUREG-CR

US-Atomaufsichtskommission ó Contractor Report (Bericht des Auftragnehmers)

TRB

Test-Untersuchungsausschuss

VTL

Verifkations-Nachweisverzeichnis

EN ISO 14620-1:2002 (D)

4

Systemsicherheitsprogramm

4.1 Anwendungsbereich

a) Ziel und Zweck des Sicherheitsprogramms ist die Erstellung eines Sicherheitsmanagementsystems zur Umsetzung der Festlegungen dieser Europ‰ischen Norm im Einklang mit den Programmanforderungen.

b) Das Systemsicherheitsprogramm sollte vom Kunden je nach Projekttyp, Sicherheitskritikalit‰t, Komplexi- t‰t und Entwicklungsphase in ‹bereinstimmung mit den Anforderungen von ISO 14300-1 und ISO 14300-2 angepasst werden.

1)

Der Lieferant muss ein Sicherheitsprogramm f¸r das System erstellen und aufrechterhalten.

2)

Der Lieferant muss die Sicherheitsanforderungen und -vorschriften f¸r Startplatz und Tr‰ger entspre- chend den Projektanforderungen anwenden, um die effiziente und effektive Durchf¸hrung der Sys- temsicherheitszielsetzungen zu ermˆglichen.

3)

Die entsprechenden Anforderungen an das Systemsicherheitsprogramm nach dieser Europ‰ischen Norm sind zur Umsetzung der f¸r Startplatz und Tr‰ger anzuwendenden Anforderungen und Vor- schriften heranzuziehen.

c) Die Einhaltung der hierin festgelegten Sicherheitsanforderungen entbindet den Lieferanten keineswegs von der Einhaltung nationaler oder internationaler Sicherheitsvorschriften.

d) Bei der Anpassung darf die Zielsetzung , Flug- und Bodenpersonal, Tr‰ger, zugehˆrige Nutzlasten, Bo- dendienstger‰ten, die allgemeine ÷ffentlichkeit, ˆffentliches und privates Eigentum sowie die Umwelt vor Gef‰hrdungen im Zusammenhang mit Raumfahrtsystemen zu sch¸tzen, nicht gemindert werden.

4.2 Sicherheitsorganisation

4.2.1 Allgemeines

Jeder Lieferant ist f¸r die Sicherheit seines Produktes verantwortlich. Deshalb gelten folgende Anforderungen.

4.2.2 Sicherheitsvertreter

Jeder Lieferant muss entsprechend ISO 14300-2 einen Sicherheitsvertreter benennen, der aufgrund seiner Ausbildung oder Erfahrung qualifiziert ist, Systemsicherungsfunktionen durchzuf¸hren.

4.2.3 Berichterstattungslinie

Die Sicherheitsvertreter m¸ssen Berichterstattungslinien zum Projektleiter und zur obersten Unternehmens- leitung haben, die unabh‰ngig von der hierarchischen Berichterstattungslinie innerhalb des Projekts sind.

4.2.4 Integrierte Sicherheit

Die Sicherheit ist in alle Projektt‰tigkeiten zu integrieren.

4.2.5 Koordination mit anderen Stellen

Die Sicherheitsvertreter m¸ssen bestehende Zug‰nge zu allen betroffenen medizinischen Aussch¸ssen, Strahlungsschutzkommissionen und industriellen Sicherheitsorganen, soweit zweckm‰flig, haben.

EN ISO 14620-1:2002 (D)

4.3 Zugangsrecht und Befugnis des Sicherheitsvertreters

4.3.1 Zugang

Der Sicherheitsvertreter muss das Zugangsrecht zu allen f¸r die Projektsicherheit relevanten Daten haben und frei und ohne Organisationszwang ¸ber alle Aspekte der Projektsicherheit berichten d¸rfen.

4.3.2 ‹bertragene Befugnis zur Zur¸ckweisung oder Unterbindung der Arbeit

Dem Sicherheitsvertreter muss die Befugnis ¸bertragen sein, Projektdokumente zur¸ckzuweisen oder Pro- jektt‰tigkeiten zu unterbinden, die nicht den genehmigten Sicherheitsanforderungen oder ñvorschriften ent- sprechen.

4.3.3 ‹bertragene Befugnis zur Unterbrechung von Betriebsvorg‰ngen

Zur korrekten Risikokontrolle muss dem Sicherheitsvertreter die Befugnis ¸bertragen sein, gef‰hrdende Be- triebsvorg‰nge zu unterbrechen und das betreffende System wieder in einen sicheren Zustand zu versetzen, wenn sich zeigt, dass der Betrieb nicht den Maflnahmen entspricht.

4.3.4 ‹bereinstimmung

Der Lieferant muss die ‹bereinstimmung seiner eigenen und der Projektt‰tigkeiten seiner Unterlieferanten mit den Sicherheitsgrunds‰tzen des Projektes und den Anforderungen sicherstellen.

4.3.5 Berichtsgenehmigung

Der Lieferant darf ohne unterzeichnete Genehmigung des Sicherheitsvertreters keinen Projektbericht heraus- geben lassen, der Aspekte der Sicherheitszertifizierung ber¸hrt.

4.3.6 Review

Ohne vorheriges Sicherheits-Review und die schriftliche Zustimmung des Sicherheitsvertreters d¸rfen gef‰hr- dende Projektbetriebsvorg‰nge oder Systemeins‰tze nicht vorgenommen werden.

4.3.7 Vertretung in Ausch¸ssen

Die Sicherheit muss in den Konfigurations-‹berwachungsaussch¸ssen (CCBís), den Material-Untersuchungs- aussch¸ssen (MRBís), den Test-Untersuchungsaussch¸ssen (TRBís), bei den Qualifikations- und Abnahme- Reviews vertreten sein, wenn Sicherheitsanforderungen und sicherheitskritische Funktionen und/oder sicherheitskritische Einheiten betroffen sind. Die Sicherheit muss weiterhin in allen medizinischen oder ver- gleichbaren Aussch¸ssen vertreten sein, wenn Grenzen der Belastbarkeit/Ausdauer f¸r die Flug- und Boden- mannschaften festgelegt werden.

4.4 Sicherheitsrisikomanagement

4.4.1 Risiko

Das Risiko f¸r Menschenleben, Investitionen, Mission und Umwelt ist im gesamten Projektverlauf durch Aus- ¸bung folgender T‰tigkeiten zu steuern:

a) Zuweisung von Sicherheitsanforderungen;

b) Gef‰hrdungsidentifizierung;

c) Gef‰hrdungsbewertung;

d) Gef‰hrdungsverh¸tung, -reduzierung und -kontrolle;

e) Gef‰hrdungsausschluss einschliefllich Restrisikobilligung.

EN ISO 14620-1:2002 (D)

4.4.2 Gef‰hrdungsbewertung

Bei allen Gef‰hrdungsbewertungen m¸ssen in erster Linie das Gef‰hrdungspotential betrachtet und alle Gef‰hrdungen je nach Schweregrad eingestuft werden. Entsprechende Kontrollmaflnahmen sind vorzu- schlagen. Das urspr¸ngliche Design ist so zu w‰hlen, dass das Gef‰hrdungspotential und der jeweilige Schweregrad der Folgen minimiert werden. Die Wahrscheinlichkeit eines Gef‰hrdungsereignisses ist folglich immer dann in Betracht zu ziehen, wenn Methoden zur Schweregradreduzierung von Gef‰hrdungsfolgen allein als unzureichend angesehen werden, d. h. alle Mindestrisiko-Designbereiche oder die Zuverl‰ssigkeit von Sicherheitsger‰ten.

4.4.3 Maflnahmen

Maflnahmen zur Reduzierung des Gef‰hrdungspotentials, durch die zumindest die Zuverl‰ssigkeit nicht ein- geschr‰nkt wird, sind vorzuziehen. Wahrscheinlichkeits- und somit risikobezogenen Reduzierungsmafl- nahmen, die nicht zu einer erhˆhten Kritikalit‰t f¸hren, ist der Vorzug zu geben.

4.5 Projektphasen und Sicherheits-Reviewzyklus

4.5.1 Fortschrittsbesprechung

Im Rahmen dieser Europ‰ischen Norm festgelegten Projektfortschrittsbesprechungen muss der Lieferant regelm‰flig Sicherheitsfortschrittsbesprechungen mit dem Kunden und seinen Unterlieferanten abhalten. Auf den Besprechungen m¸ssen die jeweiligen Experten des Kunden und Lieferanten vertreten sein und der Stand der Sicherheitsprogrammt‰tigkeiten nach den Festlegungen dieser Norm und des Vertrags ¸berpr¸ft werden.

4.5.2

Projekt-Reviews

4.5.2.1

Allgemeines

a) Der Lieferant muss die Sicherheits-Reviews des Projektsicherheitsstatus durch den Kunden und gege- benenfalls die zust‰ndige Startorganisation, wie in dieser Norm gefordert, unterst¸tzen.

b) Sicherheits-Reviews sind auf allen Ebenen abzuhalten, die zur Sicherstellung der zufriedenstellenden Umsetzung des Sicherheitsprogramms und der sicherheitstechnischen Anforderungen notwendig sind.

c) F¸r jedes Review ist in der Regel ein Sicherheitsdatenpaket zu erstellen.

d) Sicherheits-Reviews sollten in Verbindung mit den folgenden Projektmeilensteinen, soweit zutreffend, und den im jeweiligen Unterabschnitt beschriebenen Zielsetzungen durchgef¸hrt werden.

4.5.2.2 Missiondefinitions-Review

Beim Missiondefinitions-Review muss der Lieferant den folgenden Nachweis f¸hren:

a) Die Sicherheitsanforderungen und Erfahrungen aus fr¸heren Projekten wurden analysiert. Vergleichende Design- und Betriebskonzeptbewertungen wurden unterst¸tzt.

b) Die wichtigsten Sicherheitsanforderungen auf Systemebene wurden identifiziert.

4.5.2.3 Vorl‰ufiges Anforderungs-Review

Beim vorl‰ufigen Anforderungs-Review muss der Lieferant den folgenden Nachweis f¸hren:

a) Die Gef‰hrdungen, Gef‰hrdungszust‰nde und -ereignisse auf Systemebene, zusammen mit den sicher- heitskritischen Aspekten und dem Sicherheitsrisiko der analysierten Konzepte, wurden identifiziert und verglichen.

b) Die Projektsicherheitsanforderungen auf Systemebene wurden verfeinert.

EN ISO 14620-1:2002 (D)

4.5.2.4 Systemanforderungs-Review

Beim Systemanforderungs-Review muss der Lieferant den folgenden Nachweis f¸hren:

a) Die Sicherheitsanforderungen wurden ausreichend detailliert spezifiziert, um die Definition der techni- schen Lˆsungen f¸r das in Phase A gew‰hlte Systemkonzept zu ermˆglichen.

b) Die Ergebnisse der Sicherheitsanalyse sind zur Best‰tigung der ‹bereinstimmung der empfohlenen Lˆ- sung mit den Projektsicherheitsanforderungen verf¸gbar.

4.5.2.5 Vorl‰ufiges Design-Review

Beim vorl‰ufigen Design-Review muss der Lieferant den folgenden Nachweis f¸hren:

a) Die Gef‰hrdungskontrollmaflnahmen und Sicherheitsanforderungen wurden hinreichend definiert, um mit dem Detaildesign beginnen zu kˆnnen.

b) Das vorgestellte Design entspricht den Sicherheitsanforderungen in dem f¸r das Review geforderten Detailumfang.

c) Die Verifikationsmethoden f¸r die Gef‰hrdungskontrollmaflnahmen wurden vorgeschlagen.

d) Die Definition der Sicherheitsanforderungen auf System- und nachgeordneten Ebenen wurde zum Ab- schluss gebracht.

e) Die geforderten T‰tigkeiten wurden in das Projektverifikationsprogramm aufgenommen.

f) Abweichungen von den Sicherheitsanforderungen wurden identifiziert.

4.5.2.6 Kritisches Design-Review

Beim kritischen Design-Review muss der Lieferant den folgenden Nachweis f¸hren:

a) Die Ergebnisse der Sicherheitsanalysen an der in der vorangegangenen Phase erzielten Lˆsung wurden zur Verf¸gung gestellt, um verifizieren zu kˆnnen, dass das Detaildesign mit den Projektsicherheitsanfor- derungen ¸bereinstimmt und als Basis f¸r die Herstellung von Qualifikationsmodellen benutzt werden kann.

b) Alle an technischen Anforderungen vorgenommenen ƒnderungen wurden bewertet, um festzustellen, welche ƒnderungen sich daraus f¸r die Gef‰hrdungskontrollmaflnahmen ergeben.

c) Die Sicherheitsverifikationsmethoden f¸r alle Gef‰hrdungskontrollmaflnahmen wurden vereinbart und die erforderlichen T‰tigkeiten wurden in das Verifikationsprogramm aufgenommen.

4.5.2.7 Qualifikations-Review

Beim Qualifikations-Review muss der Lieferant den folgenden Nachweis f¸hren:

a) Alle Designqualifikatkionst‰tigkeiten in Bezug auf sicherheits- und bruchkritische Einheiten sowie sicher- heitskritische Funktionen wurden der Review-Ebene entsprechend abgeschlossen und die zugehˆrigen Berichte wurden genehmigt.

b) Alle sicherheitskritischen Einheiten und sicherheitskritischen Funktionen wurden qualifiziert.

EN ISO 14620-1:2002 (D)

4.5.2.8 Abnahme-Review

Beim Abnahme-Review muss der Lieferant den folgenden Nachweis f¸hren:

a) Alle sp‰teren ƒnderungen an Design und technischen Anforderungen wurden auf eventuelle Folge‰nde- rungen f¸r Gef‰hrdungskontrollmaflnahmen und deren Verifikationen bewertet.

b) Die Verifikation f¸r alle festgelegten Gef‰hrdungskontrollmaflnahmen wurde abgeschlossen und gebilligt.

c) Jede noch offene Verifikation wurde zu diesem Zeitpunkt im Verifikationskontroll-Dokument (VCD) ver- merkt. Die Verifikationsverfahren f¸r zum Zeitpunkt der Abnahme noch offene Verifikationen wurden qua- lifiziert und gegebenenfalls zur sp‰teren Ausf¸hrung gegenseitig vereinbart.

d) Alle sicherheitsbezogenen Nichtkonformit‰ten, Fehler, Ausf‰lle, Sonderfreigaben sowie Unfall/Zwischen- fallberichte wurden formal gebilligt und abgeschlossen oder in einer Liste offener Punkte mit Angabe eventueller Einschr‰nkungen dokumentiert.

4.5.2.9 Flugbereitschafts-Review

Beim Flugbereitschafts-Review muss der Lieferant den folgenden Nachweis f¸hren:

a) Das Verifikationskontroll-Dokument (VCD) weist keine weiteren offenen Verifikationen auf.

b) Verifikationen, die plangem‰fl zu einem sp‰teren Zeitpunkt durchzuf¸hren sind, d. h. Sp‰tzugangs- Inspektionen usw., wurden auf der Grundlage einer existierenden Startorganisationsvorschrift, welche von entsprechend angeleitetem Personal durchzuf¸hren ist, fˆrmlich abgeschlossen.

c) Alle offenen Arbeiten im Zusammenhang mit sicherheitskritischen Einheiten und sicherheitskritischen Funktionen wurden abgeschlossen oder als Teil der normalen Startvorbereitungs-T‰tigkeiten terminlich vorgesehen.

d) Alle sicherheitsbezogenen Nichtkonformit‰ten, Fehler, Ausf‰lle, Sonderfreigaben und Unfall/Zwischenfall- berichte wurden formal gebilligt und abgeschlossen.

e) Alle sicherheitsrelevanten Fluganomalien an bereits fr¸her im Flug eingesetzten ‰hnlichen Designs oder erneut im Flug eingesetzter Hardware wurden gelˆst und zum Abschluss gebracht.

4.5.2.10 Betriebsbereitschafts-Review

Die Ergebnisse der Tr‰ger/Boden-Kompatibilit‰tstests und der Betriebsqualifikationstests (in deren Verlauf die Betriebsvorschriften verifiziert sein m¸ssen) sind zu bewerten, um festzustellen, ob der kombinierte Betrieb von Tr‰ger und Bodeneinrichtungen nicht zu neuen Gef‰hrdungen f¸hrt oder zus‰tzliche Kontrollmaflnahmen erfordert.

4.5.2.11 Startfreigabebesprechung

Ein Delta-Sicherheitsbericht ist vorzulegen, der den aktuellen Sicherheitsstatus dokumentiert, einschliefllich aller potentiellen Auswirkungen von Countdown-Anomalien, Wetter- und Hardware- oder Personalzust‰nden. In dem Bericht ist anzugeben, ob der Sicherheitsstatus f¸r den Startvorgang annehmbar ist. Der Bericht ist vom Kunden und der zust‰ndigen Startorganisation zu ¸berpr¸fen und formal zu billigen.

4.5.2.12 Orbitaltest-Review

Die G¸ltigkeit einer fr¸heren Gef‰hrdungs- und Risikobilligung ist unter Ber¸cksichtigung aller eingef¸hrten Design- oder Betriebs‰nderungen neu zu best‰tigen. Dazu gehˆren auch eine Bewertung der fortdauernden G¸ltigkeit von fr¸her gebilligten Betriebsreserven und Sonderfreigaben f¸r sicherheitskritische Funktionen. Aktualisierte Sicherheitsanalysen sind, soweit erforderlich, zur Unterst¸tzung der Entscheidung ¸ber die Zu- lassung des weiteren Gebrauchs des Systems zu liefern.

EN ISO 14620-1:2002 (D)

4.5.2.13 Bewertung des Lebensdauerendes

Ein Sicherheitsdatenpaket ist zu liefern, in dem der Sicherheitsstatus des Systems im Hinblick auf seine Tauglichkeit f¸r die geplanten Lebensdauerabschluss- und Entsorgungsvorg‰nge und deren Konformit‰t mit den geltenden Anforderungen, einschliefllich jedweder internationaler Sicherheitsvorschriften, dokumentiert wird.

4.5.3 Sicherheitsprogramm

Das Sicherheitsprogramm ist je nach Projektkritikalit‰t entweder:

a) als Teil der planm‰fligen Projektmeilenstein-Reviews; oder

b) als Teil eines gezielten Sicherheits-Reviews zu ¸berpr¸fen.

4.5.4 Sicherheitsdatenpaket

Der Lieferant muss das Sicherheitsdatenpaket ausarbeiten und bereitstellen. Der Inhalt des Sicherheitsdaten- paketes muss f¸r jedes Projekt oder Programm von der zust‰ndigen Sicherheitszertifizierungsstelle festgelegt werden.

4.6

Sicherheitsprogrammplan

4.6.1 Durchf¸hrung

Der Lieferant muss aufzeigen, wie das Sicherheitsprogramm im Sicherheitsprogrammplan nach ISO 14300-2 umgesetzt wird. Der Plan kann entweder als Teil eines Gesamtproduktsicherungsplans des Projekts oder als separater Sicherheitsprogramm-Teilplan aufgenommen werden.

4.6.2 Sicherheitsaktivit‰ten

Die Sicherheitsplanung muss die Sicherheitst‰tigkeiten f¸r die Projektphasen nach ISO 14300-1 enthalten.

4.6.3 Definition

Der Plan muss Folgendes festlegen:

a) die durchzuf¸hrenden Sicherheitsprogrammaufgaben;

b) Personal/Lieferant, das/der f¸r die Durchf¸hrung der Aufgaben zust‰ndig ist;

c) Zeitplan der Sicherheitsprogrammaufgaben bezogen auf Projektmeilensteine;

d) Schnittstellen der Sicherheitsprogrammt‰tigkeiten mit dem Projektengineering und anderen Produkt- sicherungst‰tigkeiten;

e) (gegebenenfalls durch Hinweis auf interne Verfahren) wie der Lieferant die Aufgaben erf¸llen und ihre zufriedenstellende Erf¸llung verifizieren wird.

4.6.4 Beschreibung

Der Plan muss beinhalten: Beschreibung der Projektsicherheitsorganisation, ihrer Zust‰ndigkeiten und ihrer Arbeitsbeziehungen zu den Produktsicherungsdisziplinen Zuverl‰ssigkeit, Instandhaltbarkeit, Software- produktsicherung, Teile, Materialien und Prozesse und Qualit‰tssicherung, zum Konfigurationsmanagement und zur Systemtechnik sowie zu Design und anderen Projektfunktionen und Unternehmensabteilungen.

EN ISO 14620-1:2002 (D)

4.6.5 Sicherheits- und Projektengineering-T‰tigkeiten

Der Plan muss aufzeigen, wie die Projektsicherheitsorganisation die parallel laufenden Sicherheits- und Projektengineering-T‰tigkeiten zur st‰ndigen Unterst¸tzung des Projektdesign- und -entwicklungsprozesses verwirklichen wird.

4.6.6 Lieferanten und Unterlieferanten

Der Plan muss beschreiben, wie die sicherheitsbezogenen T‰tigkeiten und Anforderungen f¸r die Unter- lieferanten und Lieferanten festgelegt und an ihren Standorten ¸berwacht werden. Es sind nur solche Anfor- derungen verbindlich vorzugeben, die f¸r die T‰tigkeiten und Verantwortlichkeiten der Unterlieferanten und Lieferanten relevant sind.

4.6.7 Einhaltung

Der Plan muss Vorkehrungen zur Sicherstellung der Einhaltung der Sicherheitsanforderungen und -bestimmungen, die f¸r jede zus‰tzliche im Projektverlauf zu benutzende Einrichtung und Dienstleistung gel- ten, vorsehen.

4.7 Sicherheitszertifizierung

a) F¸r alle Projekte muss zertifiziert werden, dass die Flug- und Bodensystemprodukte sicher sind und den Anforderungen dieser Norm sowie allen geltenden projektspezifischen Sicherheitsanforderungen ent- sprechen.

b) Der Zertifizierungsprozess muss abgeschlossen sein, bevor eine Auslieferung an irgendeine Partei, aufler dem K‰ufer, erfolgt.

c) Die Zertifizierung muss einen Hinweis enthalten, dass noch offene Verifikationen gem‰fl dem gef¸hrten Verifikations-Nachweisverzeichnis abgeschlossen werden und die sichere Weiterf¸hrung auf dem Gel‰n- de von Drittparteien nicht beeintr‰chtigen.

d) Bei jedem Projekt ist der Kunde, der detaillierte sicherheitstechnische Anforderungen festlegt oder ver- bindlich vorgibt, die zust‰ndige Sicherheitszertifizierungsstelle oder Teil davon.

e) Die Projektorganisation muss der zust‰ndigen Zertifizierungsstelle alle sicherheitsbezogenen Informa- tionen zur Verf¸gung stellen, die erforderlich sind, um die Sicherheitskonformit‰tserkl‰rung billigen und verstehen zu kˆnnen.

4.8 Sicherheitstraining

4.8.1 Bestandteil

a) Das Sicherheitstraining ist Bestandteil des nach ISO 14300-1 und ISO 14300-2 geforderten Gesamttrai- nings.

b) Jedes sicherheitsbezogene Training von Personen, die ó st‰ndig oder vor¸bergehend ó mit Produkten arbeiten, die Gef‰hrdungsmerkmale haben kˆnnen, hat drei Hauptaspekte zum Inhalt:

1)

allgemeine ‹bersicht zur Bewusstseinsbildung ¸ber Sicherheitsmaflnahmen, die in einem bestimm- ten Ort oder Arbeitsumfeld zu treffen sind;

2)

technisches Grundtraining in den geforderten Sicherheitstechniken und Fertigkeiten, z. B. Pr¸fung, Test, Instandhaltung oder Integration, die zur Erf¸llung der betreffenden Aufgabenstellung erforder- lich sind;

3)

produktspezifisches Training, das sich schwerpunktm‰flig mit den f¸r das Produkt spezifischen Ge- f‰hrdungen befasst.

EN ISO 14620-1:2002 (D)

4.8.2 Teilnahme

Die Teilnahme an den allgemeinen Einweisungen ist f¸r alle Personen verbindlich, die Zugang zu dem Be- reich haben m¸ssen, in dem das Produkt be- oder verarbeitet wird.

4.8.3 Eingehendes technisches Training

Ein eingehendes technisches Training ist dem Projektengineering- und Sicherheitspersonal zu erteilen, das mit gef‰hrdenden Produkten zu tun hat.

4.8.4 Produktspezifisches Training

Ein produktspezifisches Training ist von Sicherheitsexperten allen neuen Projektingenieuren sowie den Flug- und Bodenmannschaften zu erteilen.

4.8.5 Aufzeichnungen

Aufzeichnungen ¸ber die Personen, die ein Training erhalten haben, sind zu f¸hren.

4.8.6 Identifizierung

Wenn ein Sicherheitstraining f¸r die Flugbetriebsmannschaft oder f¸r das Missionskontrollpersonal als erforderlich angesehen wird, ist dies dem Kunden unter Angabe von Art und Umfang des erforderlichen Trainings mitzuteilen. Der Lieferant muss die Verwirklichung des Trainingsprogramms, wie vom Kunden fest- gelegt, unterst¸tzen.

4.9 Berichterstattung und Untersuchung von Unf‰llen/Zwischenf‰llen

a) Der Lieferant muss dem Kunden ¸ber alle Unf‰lle und Zwischenf‰lle berichten, die w‰hrend der Projekt- t‰tigkeiten, die in seinem Verantwortungsbereich oder dem seiner Unterlieferanten liegen, auftreten.

b) Der Sicherheitsvertreter des Lieferanten ist verantwortlich f¸r die Untersuchung aller zu meldenden Zwi- schenf‰lle und f¸r die Unterst¸tzung des Kunden bei der Untersuchung von Unf‰llen, wie dies ange- wiesen wird.

4.10 Sicherheitsdokumentation

4.10.1 Allgemeines

Der Lieferant muss sicherheitsrelevante Daten zur Unterst¸tzung der Reviews und der Sicherheitszertifizie- rung bereithalten.

4.10.2 Kundenzugang

W‰hrend der beim Lieferanten abgehaltenen Audits, Sicherheits-Reviews und Besprechungen m¸ssen die in der Sicherheitserfahrungsdatei enthaltenen Daten dem Kunden auf Wunsch zug‰nglich gemacht werden.

4.10.3 Lieferant

Der Lieferant muss die Projektdokumentation einschliefllich Spezifikationen, Zeichnungen, Analysen, Verfahren und Berichten, Nichtkonformit‰tenberichten, Fehler-/Ausfallberichten, Sonderfreigaben und Dokumentations‰nderungen einem Review unterziehen, um Folgendes zu ¸berpr¸fen oder ihre Auswirkung zu beurteilen auf:

a) Umsetzung der Sicherheitsanforderungen und Gef‰hrdungs- und Risikokontrollmaflnahmen;

b) Einarbeitung der Gef‰hrdungs- und Risikokontrollmaflnahmen in das Design oder Verifikationsprogramm;

EN ISO 14620-1:2002 (D)

c) Abschluss der Verifikationst‰tigkeiten;

d) Design- und Betriebssicherheit des Systems;

e) G¸ltigkeit der durchgef¸hrten und dokumentierten Sicherheitsanalysen.

4.10.4 Dokumentation

a) Es sind Aufzeichnungen ¸ber die ¸berpr¸ften Dokumente zu f¸hren.

b) Die Sicherheitsdokumentation ist gegebenenfalls zu aktualisieren, um dem neuesten Stand zu ent- sprechen.

c) Der Lieferant muss zertifizieren, dass die Sicherheitsdokumentation genau, g¸ltig, umfassend und voll- st‰ndig ist, bevor sie auf dem Startgel‰nde weitergef¸hrt wird.

4.10.5 Sicherheitsdatenpaket

a) Der Lieferant muss f¸r die Reviews ein Sicherheitsdatenpaket vorlegen (siehe 4.5.4). Dies kann ein separates Paket oder Bestandteil des Gesamtdatenpaketes sein, wenn das Sicherheits-Review Teil eines Gesamtprojektreviews ist.

b) Der Inhalt des Datenpaketes ist zu spezifizieren, um f¸r die inhaltliche Bestimmung von Sicherheitsdaten- paketen herangezogen zu werden.

c) Die Design- und Betriebsgrundlage, die Gegenstand des Sicherheitsdatenpaketes ist, muss durch Bezug auf die entsprechende Dokumentation festgelegt werden.

d) Alle bei fr¸heren Sicherheitsreviews geforderten Daten sind in das Sicherheitsdatenpaket aufzunehmen.

e) Der Lieferant muss die Sicherheitsdaten, die sich auf die einzelnen Subsysteme oder Ger‰te des Sys- tems beziehen, in das beim Sicherheitsreview vorzulegende Sicherheitsdatenpaket einbeziehen.

f) Alle Sicherheitsdaten m¸ssen vom Sicherheitsdatenpaket zur¸ckverfolgbar sein und f¸r das Review zur Verf¸gung stehen, sofern zutreffend.

4.10.6 Sicherheitsbezogene Sonderfreigabe (vor und nach Realisierung)

4.10.6.1 Abweichung

Sicherheitsanforderungen, die nicht eingehalten werden kˆnnen, sind zu identifizieren, und es muss eine Sonderfreigabe erwirkt werden.

4.10.6.2 Beschreibung, Analyse und Begr¸ndung

Die Sonderfreigabe muss darlegen, warum die Anforderung nicht eingehalten werden kann, und eine aus- reichende Analyse und Begr¸ndung zur Unterst¸tzung der Abweichung von der Anforderung liefern.

4.10.6.3 Identifizierung und Review

Der Lieferant muss alle Sonderfreigaben (vor und nach Realisierung) identifizieren, die die anzuwendenden Projektsicherheitsanforderungen beeinflussen. Diese Sonderfreigaben sind vom Projektsicherheitsvertreter zu ¸berpr¸fen, um sicherzustellen, dass eventuelle Auswirkungen auf die Sicherheit vollst‰ndig analysiert und jede vom Lieferanten als vertretbar angesehene Abweichung ausreichend begr¸ndet ist.

EN ISO 14620-1:2002 (D)

4.10.6.4 Bewertung der Sonderfreigaben

Die kumulierten Sonderfreigaben (vor und nach Realisierung), die die Sicherheit betreffen, sind zu bewerten, um sicherzustellen, dass die Auswirkungen einzelner Sonderfreigaben die f¸r die Annahme anderer Sonder- freigaben gelieferte Begr¸ndung nicht ung¸ltig machen. Der Lieferant muss eine ‹bersichtsliste f¸hren, in der alle ¸berpr¸ften sicherheitsbezogenen Sonderfreigaben festgehalten sind.

4.10.6.5 Review und Disposition

Sonderfreigaben, die Projektsicherheitsanforderungen oder sicherheitskritische Funktionen und Einheiten betreffen und vom Lieferanten als annehmbar angesehen werden, m¸ssen von der zust‰ndigen Sicherheits- stelle des Kunden ¸berpr¸ft und entschieden werden.

4.10.6.6 Genehmigung der Sicherheitsstelle

Die sicherheitsbezogenen Sonderfreigaben bed¸rfen der Genehmigung durch die zust‰ndigen Sicherheits- zertifizierungsstellen einschliefllich der zust‰ndigen Startorganisation, soweit wie angemessen.

4.10.7 Verifikationskontroll-Dokument

Ein Verifikationskontroll-Dokument (VCD) ist zu f¸hren, aus dem eindeutig die zum Abschluss f¸hrenden Schritte f¸r die Verifikationspunkte nach dem Gef‰hrdungsbericht hervorgehen. Sobald die Verifikations- methoden zur gegenseitigen Zufriedenheit der Projekt- und Zertifizierungsstellen in den Gef‰hrdungsberichten dokumentiert sind, billigt das Verifikations-Nachweisverzeichnis den zugehˆrigen Beglaubigungseintrag.

4.10.8 Erfahrungsdatei

a) Der Lieferant muss die im Projektverlauf gewonnenen Sicherheitserfahrungen sammeln. Der Lieferant muss sicherstellen, dass die gewonnenen Erfahrungen, soweit sie von Belang sind, noch w‰hrend der Projektlaufzeit in das Projekt einflieflen.

b) Die gewonnenen Sicherheitserfahrungen m¸ssen mindestens Folgendes erfassen:

1)

Auswirkungen neu vorgegebener Anforderungen;

2)

Bewertung aller Funktionsstˆrungen, Unf‰lle, Anomalien, Sonderfreigaben;

3)

Effektivit‰t der Sicherheitsstrategien des Projektes;

4)

neue Sicherheitswerkzeuge und -methoden, die entwickelt oder dargelegt wurden;

5)

Vergleich von durchgef¸hrten wirksamen und unwirksamen Verifikationen;

6)

ƒnderungsvorschl‰ge zu Sicherheitsgrunds‰tzen, Sicherheitsstrategie oder sicherheitstechnischen Anforderungen, einschliefllich Begr¸ndung.

5

Sicherheitstechnik

5.1 Sicherheitstechnische Grunds‰tze

5.1.1 Allgemeines

Die Sicherheit ist integraler Bestandteil aller Produktsicherungs- und Engineering-T‰tigkeiten des Projektes und somit keine isolierte T‰tigkeit. Die Qualit‰t aller Arbeiten im Zusammenhang mit der Sicherheitstechnik beruht auf der Sicherstellung, dass Design, Qualifikation, Herstellung und Betrieb des Systems den Produkt- sicherungsanforderungen entsprechen.

EN ISO 14620-1:2002 (D)

5.1.2 Elemente

Die Sicherheitstechnik umfasst das Management der Gef‰hrdungs- und Risikoreduzierungsprozesse, Gef‰hr- dungs- und Risikopotentialbewertung, Design-Sicherung und Gef‰hrdungs- und Risikokontrollt‰tigkeiten.

5.1.3 Gewonnene Sicherheitserkenntnisse (lessons learnt)

Die w‰hrend des Designsprozesses gewonnenen Erkenntnisse sollten weitgehend zur Anwendung kommen.

5.2 Sicherheitsbezogene Designgrunds‰tze

5.2.1 Menschliche ‹berlegung

Die Bewahrung der Sicherheit des Personals muss bei der Entwicklung und dem Betrieb von Raumfahrtsys- temen die hˆchste Priorit‰t haben.

5.2.2 Designauswahl

Hauptziel in der Designphase ist die Sicherstellung einer inh‰renten Sicherheit durch Auswahl angemessener Designmerkmale. Schadensbegrenzung, Eingrenzung und Isolierung potentieller Gef‰hrdungen sind in die Design¸berlegungen einzubeziehen.

5.2.3 Gef‰hrdungsbeseitigungs- und -kontrollmaflnahmen

Bei den identifizierten Gef‰hrdungen, Gef‰hrdungszust‰nden und Funktionen, deren Ausfall/Fehler Gef‰hr- dungsfolgen hat, ist die folgende Reihenfolge der T‰tigkeiten einzuhalten:

a) Gef‰hrdungsbeseitigung

Gef‰hrdungen und Gef‰hrdungszust‰nde m¸ssen entsprechend den Projektauflagen und Missionszielen ¸ber die Auswahl von Design-Technologie, Design-Architektur und Betriebsmerkmalen aus den Design- und Betriebskonzepten beseitigt werden.

b) Gef‰hrdungsminimierung

Kˆnnen Gef‰hrdungen und Gef‰hrdungszust‰nde nicht beseitigt werden, ist die Schwere der damit ver- bundenen Gef‰hrdungsereignisse und ñfolgen entsprechend den Projektauflagen und Missionszielen durch Auswahl der am wenigsten gef‰hrdenden Design-Architektur, Design-Technologien und Betriebs- merkmale zu minimieren.

c) Gef‰hrdungskontrolle ó Sicherheitseinrichtungen

Gef‰hrdungen, die ¸ber die Designauswahl nicht beseitigt werden kˆnnen, m¸ssen reduziert und mit Hilfe automatischer Sicherheitseinrichtungen als Teil des Systems, Subsystems oder Ger‰ts kontrollier- bar gemacht werden.

d) Gef‰hrdungskontrolle ó Warnvorrichtungen

Ist es nicht mˆglich, das Vorhandensein oder Eintreten bekannter Gef‰hrdungen auszuschlieflen oder automatische Sicherheitseinrichtungen einzusetzen, sind Vorrichtungen zur rechtzeitigen Erkennung des Zustandes und Erzeugung eines geeigneten Warnsignals zu verwenden, gekoppelt mit Notfall-Kontrollen, bestehend aus Korrekturmaflnahmen durch das Betriebspersonal, um das betroffene Subsystem zu sichern oder abzuschalten.

e) Gef‰hrdungskontrolle ó Besondere Vorschriften

1)

Ist es nicht mˆglich, das Ausmafl einer Gef‰hrdung ¸ber das Design, Sicherheitseinrichtungen oder Warnvorrichtungen zu reduzieren, sind besondere Vorschriften zu entwickeln, um den Gef‰hrdungs- zust‰nden zur Erhˆhung der Sicherheit f¸r die Besatzung entgegenzuwirken.

EN ISO 14620-1:2002 (D)

2)

Besondere Vorschriften kˆnnen Not- und Stˆrfallvorschriften, Verfahrensvorschriften oder die An- wendung eines kontrollierten Instandhaltungsprogramms beinhalten.

3)

Besondere Vorschriften sind durch Tests zu qualifizieren, und das Personal ist entsprechend einzu- weisen.

4)

Von den verf¸gbaren Gef‰hrdungskontroll- und Risikoreduzierungsmaflnahmen sind die besonderen Vorschriften am wenigsten effektiv. Vorrang ist daher der Gef‰hrdungskontrolle durch Anwendung der alternativen Gef‰hrdungskontrollmaflnahmen in der angegebenen Reihenfolge zu geben.

5)

Die Anforderung f¸r die Gef‰hrdungserkennung, -signalisierung und ñsicherung durch die Besatzung zur Kontrolle zeitkritischer Gef‰hrdungen ist zu minimieren und nur dann umzusetzen, wenn es keine alternative Lˆsung zur Reduzierung oder Kontrolle von Gef‰hrdungszust‰nden gibt.

6)

Um den Einsatz von Echtzeit-Monitoring-, Gef‰hrdungserkennungs- und ñsicherungssystemen f¸r die Gef‰hrdungskontrolle zulassen zu kˆnnen, muss die Verf¸gbarkeit einer ausreichenden Reakti- onszeit f¸r die Besatzung verifiziert werden. Abnehmbare Sicherungsverfahren m¸ssen entwickelt und verifiziert werden, und das Personal ist entsprechend einzuweisen.

7) Physische Barrieren, sichere Trennabst‰nde, Beschr‰nkung des Personals mit Befugnis f¸r Zu- gangskontrollen, Fern¸berwachung, Energieabschaltverfahren und zeitlich begrenzte Belastung sind als Mittel zur Gef‰hrdungseind‰mmung und Risikominderung in Betracht zu ziehen.

5.2.4 Umweltvertr‰glichkeit

a) Das Systemdesign muss unter den f¸r das Projekt definierten ung¸nstigsten nat¸rlichen und induzierten Umgebungsbedingungen die geltenden Sicherheitsanforderungen erf¸llen.

b) Design- und Leistungsreserven sind festzulegen und anzuwenden unter Ber¸cksichtigung der un- g¸nstigsten Kombinationen von induzierten und nat¸rlichen Umgebungsbedingungen und Betriebs- merkmalen.

5.2.5 Sicher ohne externe Dienste

H‰ngt der sichere Betrieb des Systems von externen Diensten (z. B. Energieversorgung) ab, muss das Systemdesign so ausgelegt sein, dass aus dem Verlust solcher Dienste (zumindest f¸r einen bestimmten, f¸r jedes Projekt festzulegenden Zeitraum) keine kritischen oder katastrophalen Folgen entstehen.

5.2.6 ÑFail Safeì-Design

Das System und seine Bestandteile m¸ssen so ausgelegt sein, dass bei Ausf‰llen das System in einen Ñsicheren Zustandì ¸bergeht.

5.2.7 Gef‰hrdungserkennung ó Signalisierung und Sicherung

a) Bei bemannten Raumflugsystemen m¸ssen Sicherheits¸berwachungs-, Anzeige-, Alarm- und Siche- rungseinrichtungen vorhanden sein. Diese Einrichtungen m¸ssen die notwendigen Informationen liefern, die es der Besatzung und dem Systembetriebspersonal ermˆglichen, eventuell erforderliche Maflnahmen zum Schutz von Personen vor den Folgen von Ausf‰llen innerhalb sicherheitskritischer Funktionen und vor dem Ausfall von Gef‰hrdungskontrollmaflnahmen zu ergreifen.

b) Das Systemdesign muss die Mˆglichkeit bieten, Fehler zu erkennen, die zu einer Verschlechterung der Fehlertoleranz f¸r die Gef‰hrdungserkennungs-, -signalisierungs- und -sicherungsfunktion f¸hren. Die Leistung dieser Funktionen muss nach deren Verwirklichung w‰hrend der Flug- und Bodenbetriebs- phasen verifizierbar sein.

c) Die Not-, Vorsicht- und Warnfunktion muss die Not-, Vorsicht- und Warnsituationen erkennen und der Besatzung und dem Systembetriebspersonal melden.

d) Sicherungsfunktionen und -einrichtungen m¸ssen zur Eingrenzung oder Kontrolle von Not-, Vorsicht- und Warnsituationen vorhanden sein.

e) Vorkehrungen zur Verfolgung der Ausf¸hrung der Sicherungsfunktion m¸ssen vorgesehen sein.

EN ISO 14620-1:2002 (D)

f) F¸r Notsituationen muss es gezielte Sicherungsfunktionen geben. Die Kontrolle von Vorsicht- und Warn- situationen ¸ber System-Rekonfiguration oder gezielte Sicherungsfunktionen ist je nach Fall zul‰ssig.

g) Kein einzelner Ausfall darf zum Verlust der Not- und Warnfunktion f¸hren.

h) Wenn durch den Betrieb eines Sicherungssystems neue Gef‰hrdungen eingebracht werden, muss zu- mindest die unbeabsichtigte Aktivierung des Sicherungssystems in ‹bereinstimmung mit den Fehler- toleranzanforderungen unter Kontrolle gebracht werden.

i) Kein einzelner Ausfall darf den Verlust der Not- und Warnfunktionen zusammen mit den ¸berwachten Funktionen zur Folge haben.

j) Not-, Warn- und Vorsichtdaten- und Grenz¸berschreitungsmeldungen und Sicherungsbefehle m¸ssen Vorrang vor anderen Datenverarbeitungs- und Befehlsfunktionen haben.

k) Wenn Systeme oder Elemente in andere Systeme oder Elemente integriert oder mit diesen gekoppelt werden, muss die Not-, Warn-, Vorsicht- und Sicherungsfunktion es den verantwortlichen Kontrollstellen ermˆglichen, die jeweiligen Parameter zu verfolgen und anzuzeigen und die entsprechenden Sicherungs- funktionen zu ¸berwachen.

l) Statusinformationen ¸ber die Not-, Warn- und Vorsichtparameter m¸ssen in den Start- und Missionsleit- zentren Ñechtzeitnahì w‰hrend der relevanten Betriebsphasen zur Verf¸gung stehen und angezeigt werden. Die Besatzung muss die Mˆglichkeit haben, den Status der Not-, Warn- und Vorsichtparameter nichtbemannter Systeme oder Elemente vor dem Ankoppeln an bemannte Systeme in ÑEchtzeitì festzu- stellen und zu verfolgen.

5.2.8 Zugang

Das Projektprodukt muss so ausgelegt sein, dass jeder w‰hrend des Flug- oder Bodenbetriebs erforderliche Zugang zu einzelnen Produkten mit einem Minimum an Risiko f¸r das Personal vollzogen werden kann.

5.3 Sicherheitsrisikoreduzierung und -kontrolle

5.3.1 Schweregrad

a) Der Schweregrad der identifizierten Gef‰hrdungsereignisse ist nach folgenden Kategorien einzustufen (siehe Tabelle 1):

Tabelle 1 ó Schweregrad der Gef‰hrdungen und Folgen (1)

 

Schweregrad

 

Folge

1)

Katastrophale Gef‰hrdungen

i)

Verlust menschlichen Lebens, lebensbedrohende oder zu dauernder Arbeitsunf‰higkeit f¸hrende Verletzung oder Berufskrankheit, Verlust eines Elementes eines angrenzenden bemannten Flugsystems;

ii)

Verlust von Startplatzeinrichtungen;

 

iii)

sch‰dliche Langzeitauswirkungen f¸r die Umwelt.

 

2)

Kritische Gef‰hrdungen

i)

zu vor¸bergehender Arbeitsunf‰higkeit f¸hrende, jedoch nicht lebensbedrohende Verletzung oder vor¸bergehende Berufs- krankheit;

ii)

Verlust oder grˆflere Besch‰digung des Flugsystems, von

Hauptelementen

des

Flugsystems

oder

von

Bodeneinrich-

tungen;

iii)

grˆflere Besch‰digung von ˆffentlichem oder privatem Eigen- tum; oder

iv)

grˆflere sch‰dliche Auswirkungen f¸r die Umwelt.

 

EN ISO 14620-1:2002 (D)

b) Neben den vorgenannten zwei Kategorien d¸rfen weitere Kategorien f¸r die vollst‰ndige Bewertung des angenommenen Sicherheitsrisikos herangezogen werden.

Tabelle 2 ó Schweregrad der Gef‰hrdungen und Folgen (2)

 

Schweregrad

Folge

3)

geringf¸gige Gef‰hrdungen

kleinere Verletzung, kurzzeitige Arbeitsunf‰higkeit, kurzzeitige Berufskrankheit oder kleinerer System- oder Umweltschaden.

4)

vernachl‰ssigbare Gef‰hrdungen

sehr geringf¸gige Verletzung, Arbeitsunf‰higkeit, Berufsunf‰higkeit oder sehr geringf¸giger System- oder Umweltschaden.

c) Die Verf¸gbarkeit von:

1)

Designmerkmalen, die die Eintrittswahrscheinlichkeit eines Gef‰hrdungsereignisses herabsetzen, nicht aber seinen Schweregrad beeinflussen;

2)

Warnvorrichtungen, Zufluchts- oder Rettungsmˆglichkeiten f¸r die Besatzung

d¸rfen nicht als Begr¸ndung f¸r die Herabsetzung des Gef‰hrdungsgrades betrachtet werden.

d) Bei Gemeinschaftsprogrammen ist f¸r die gemeinsamen Betriebsphasen ein koh‰renter Satz von Folgen- schweregradkategorien einzuf¸hren. Diese Kategorien d¸rfen jedoch weder den Grunds‰tzen der Vor- rangigkeit des Schutzes menschlichen Lebens noch den Kategorisierungsregeln gem‰fl den in Tabelle 1 festgelegten Folgenschweregradkategorien zuwiderlaufen.

e) Die Folgenschweregrade klassifizieren die Gef‰hrdungen nach ihrer Auswirkung auf menschliches Leben. Diese Auswirkung kann unmittelbar und personenbezogen sein. Sie kann aber auch in einem grˆfleren Rahmen nicht nur auf eine Einzelperson beschr‰nkt sein. Die Gef‰hrdungsfolgen kˆnnen kurz- oder langzeitig sein. Als besonders wichtig gilt die Betrachtung der umweltsch‰dlichen Auswirkungen unter dem Aspekt langfristiger Gef‰hrdungsfolgen f¸r die Menschheit insgesamt.

f) Bei Raumfl¸gen kann es sich bei der betroffenen Umwelt sowohl um den erdnahen Raum, einschliefllich Mond und Planeten, um geostation‰re/erdnahe (GEO/LEO) Umlaufbahnen als auch um die Erd- atmosph‰re handeln. Empfohlen werden eingehende systemanalytische Studien zur Pr‰ventivbewertung der Technologiefolgen f¸r die Gesamtheit der menschlichen Umwelt.

5.3.2

Fehltoleranzanforderungen

5.3.2.1

Sicherheitsanforderungen

Die Fehlertoleranz ist eine der grundlegenden Sicherheitsanforderungen zur Beherrschung von Gef‰hr- dungen. Das Systemdesign muss folgende Fehlertoleranzanforderungen erf¸llen:

a) Kein Einzelfehler oder kein einzelnes menschliches Fehlverhalten darf kritische oder katastrophale Folgen haben.

b) Keine Kombination aus

1)

zwei Fehlern; oder

2)

zweifachem menschlichem Fehlverhalten; oder

3)

einem Fehler und einem menschlichen Fehlverhalten

darf katastrophale Folgen haben.

EN ISO 14620-1:2002 (D)

c) Alle Gef‰hrdungen, die nicht ¸ber die Fehlertoleranzkonformit‰t kontrolliert werden, sind durch Kon- formit‰t mit dem ÑMindestrisiko-Designì zu kontrollieren.

d) Die technischen Anforderungen an Mindestrisiko-Designbereiche m¸ssen identifiziert und genehmigt werden sowie die Zustimmung der zust‰ndigen Sicherheitszertifizierungsstellen erhalten.

5.3.2.2 Software

a) Die geforderte Fehlertoleranz f¸r die Software, die eine sicherheitskritische Funktion unterst¸tzt, muss mittels unterschiedlicher Methoden und Algorithmen (Diversit‰t) implementiert werden. Alternativ kann eine unabh‰ngige Hardwaresicherung f¸r die Softwarefunktion vorgesehen werden.

b) Die Erkennung von Anomalien und die Bet‰tigung von Sicherheitsfunktionen, wie z. B. Notausschaltern, sollte von Verkn¸pfungssteuerungen f¸r Software und Programm unabh‰ngig sein.

c) Eine akzeptable Softwaresicherheit kann durch ein formales Softwaresicherheitsprogramm, bestehend aus Gef‰hrdungsanalyse, Analyse der Designanforderungen, Pr¸fung sowie Verifikation und Validierung der Software, erreicht werden.

5.3.2.3 Nutzlastschnittstelle

Nutzlasten m¸ssen so ausgelegt sein, dass ein Verlust oder eine Verschlechterung der Nutzlastversorgungen durch den Tr‰ger nicht zu katastrophalen oder kritischen Gef‰hrdungsfolgen f¸hrt, unter Ber¸cksichtigung e- ventueller Fehlertoleranzen, die vom Tr‰ger den Nutzlastversorgungen einger‰umt werden.

5.3.2.4 Redundanztrennung

a) Das Systemdesign muss die Mˆglichkeit eines bordeigenen Redundanzmanagements der sicherheits- kritischen Funktionen vorsehen und den Flug- und Bodenmannschaften Fehlertoleranz- und Redundanz- statusinformationen liefern, einschliefllich sofortiger Meldung an die Besatzung bei Fehlererkennung, Re- dundanzumschaltung oder Verlust der Betriebsredundanz.

b) Das Redundanzmanagement muss die Fehlererkennung, die Fehlerisolierung und das Umschalten re- dundanter Einheiten einschlieflen.

c) Flugbesatzung und Missionsleitstelle m¸ssen die automatische Sicherung und Redundanzumschaltung aufheben kˆnnen.

d) Alternative oder redundante sicherheitskritische Funktionen m¸ssen physisch und funktional getrennt o- der derart gesch¸tzt sein, dass kein Ereignis, das den Verlust eines Pfades verursacht, zum Verlust von alternativen oder redundanten Pfaden f¸hrt.

5.3.2.5 Fehlerausbreitung

Hardware- oder Softwarefehler d¸rfen keine weiteren Fehler mit Gef‰hrdungsauswirkungen verursachen bzw. sich nicht ausbreiten und zu einer Betriebsgef‰hrdung der angrenzenden Hardware f¸hren.

5.3.3

Auslegung f¸r minimales Risiko

5.3.3.1

Allgemeines

Gef‰hrdungen der auf Mindestrisiko ausgelegten Designbereiche (z. B. Mechanismen, Strukturen, Druck- beh‰lter, Druckleitungen und ñverbindungen, pyrotechnische Vorrichtungen, Materialvertr‰glichkeit, Material- entflammbarkeit) sind ¸ber die sicherheitsbezogenen Eigenschaften und Merkmale des Designs, wie Sicher- heitsreserven oder ñfaktoren, unter Kontrolle zu bringen. Fehlertoleranzanforderungen sind f¸r diese Designs nur soweit erforderlich anzuwenden, um sicherzustellen, dass die konkreten Fehler, die das Design beein- flussen kˆnnen, ihre sicherheitsbezogenen Merkmale nicht ung¸ltig machen.

EN ISO 14620-1:2002 (D)

5.3.3.2 Bruchmechanik

Wenn Strukturfehler katastrophale oder kritische Folgen haben kˆnnen, m¸ssen die Strukturen, Druck- beh‰lter, Verbindungselemente und Belastungspfade der Mechanismen nach den Grunds‰tzen der Bruch- mechanik ausgelegt werden.

5.3.3.3 Sicherheitsfaktoren

a) Struktursicherheitsfaktoren sind zu definieren und anzuwenden.

b) Bei der Ermittlung der Sicherheitsreserven ist die voraussichtlich ung¸nstigste Kombination von Umge- bungsbedingungen in Betracht zu ziehen.

5.3.3.4 Materialien

Materialien sind auszuw‰hlen und zu steuern. Die Materialauswahl muss sicherstellen, dass Gef‰hrdungen im Zusammenhang mit Materialeigenschaften (z. B. Toxizit‰t, Entflammbarkeit, Spannungskorrosionsbest‰ndig- keit, Ausgasen, Strahlungswiderstandsf‰higkeit, Best‰ndigkeit gegen zyklische Temperaturbeanspruchung, Kriechwegbildung, thermische Degradation, mikrobiologisches Wachstum) entweder beseitigt oder kontrolliert werden. Ist das nicht mˆglich, muss das Systemdesign die notwendigen Vorkehrungen (z. B. Eingrenzung von Gefahrstoffen) zur Beherrschung von Gef‰hrdungsereignissen im Zusammenhang mit Materialeigen- schaften entsprechend den Anforderungen dieser Europ‰ischen Norm enthalten.

5.3.4 Probabilistische Sicherheitsziele

a) Probabilistische Sicherheitsziele sollten f¸r Gef‰hrdungsfolgen auf Systemebene, die katastrophal sind, festgelegt werden.

b) Bei der Festlegung solcher Ziele sollte ‹bereinstimmung mit den von den Startsicherheitsstellen aufge- stellten Anforderungen sowie den nationalen und internationalen Vorschriften hergestellt werden. Zus‰tz- lich sollten bei der Aufstellung solcher Ziele auch die nachfolgenden Kriterien beachtet werden:

1)

Bez¸glich der Sicherheitsziele f¸r das Boden- und Flugpersonal sollte das individuelle Risiko ver- gleichbar sein mit dem, das bei anderen beruflich exponierten Personen angenommen wird (z. B. kˆnnte das Risiko f¸r Besatzungsmitglieder mit dem f¸r Testpiloten verglichen werden, das Risiko f¸r Bodenpersonal mit dem f¸r Industriearbeiter);

2)

Bez¸glich der Sicherheitsziele f¸r die Zivilbevˆlkerung sollte das Gesamtrisiko f¸r die am Boden be- troffene Bevˆlkerung mit dem verglichen werden, das durch andere gef‰hrdende menschliche T‰tig- keiten verursacht wird (z. B. Risiko im Zusammenhang mit Atomkraftwerken oder Chemieanlagen).

c) Die Bewertung der ‹bereinstimmung mit den Sicherheitszielen sollte auch dazu dienen:

1)

die Hauptrisikoverursacher zu identifizieren und einzustufen;

2)

den Entscheidungsfindungsprozess in den F‰llen zu unterst¸tzen, in denen Nicht¸bereinstimmung mit den qualitativen Anforderungen festgestellt werden.

d) Die Sicherheitsziele sind nicht als alleinige Anforderungen zu verwenden, die einem System auferlegt werden, sondern in Kombination mit den anderen qualitativen Anforderungen dieser Europ‰ischen Norm.

e) Zu beachten ist auflerdem, dass in 6.1 die Zuweisung von ÑZielenì zu den verschiedenen Funktionen und Subsystemen behandelt wird. Die ‹bereinstimmung mit den quantitativen Anforderungen erfolgt ¸ber die Risikoanalyse (siehe 6.4.3).

EN ISO 14620-1:2002 (D)

5.4 Identifizierung und Kontrolle sicherheitskritischer Funktionen

5.4.1 Identifizierung

Systemfunktionen, die bei Verlust oder Minderung oder durch unsachgem‰flen oder unbeabsichtigten Einsatz zu katastrophalen oder kritischen Gef‰hrdungsfolgen f¸hren w¸rden, sind als sicherheitskritische Funktionen zu identifizieren.

BEISPIEL

sichtigt auftreten oder nicht ordnungsgem‰fl ablaufen.

Dazu z‰hlen Serien von Betriebsereignissen, die zu einer Gef‰hrdung f¸hren kˆnnen, wenn sie unbeab-

5.4.2 Unbeabsichtigtes Auslˆsen

Das unbeabsichtigte Auslˆsen einer sicherheitskritischen Funktion ist zu verhindern durch:

a) zwei unabh‰ngige Sperren, wenn dadurch Folgen des kritischen Schweregrades entstehen;

b) drei unabh‰ngige Sperren, wenn dadurch Folgen des katastrophalen Schweregrades entstehen.

5.4.3 Maflnahmen

Das System muss bei bemannten Raumfahrtsystemen folgende Maflnahmen vorsehen und diese sollten auch f¸r den Bodenbetrieb des Systems bei unbemannten Raumfahrtsystemen als Ziel gesetzt werden:

a) Fehlertoleranz- und Redundanzstatusinformationen ¸ber sicherheitskritische Funktionen;

b) Status von mindestens zwei Sperren f¸r Funktionen, die bei unbeabsichtigtem Auslˆsen zu katastropha- len Folgen f¸r Flug- und Bodenmannschaft f¸hren kˆnnten, einschliefllich:

1)

Echtzeit-Meldung einer Fehlererkennung;

2)

Anzeige eines Betriebsredundanzverlustes;

3)

Meldung einer Redundanzumschaltung oder

4)

Sperrenstatus‰nderung.

5.4.4 Sichere Abschaltung und Fehlertoleranzanforderungen

Das Design muss entweder die Mˆglichkeit der sicheren Abschaltung sicherheitskritischer Funktionen vor dem Wartungsbetrieb im Flug vorsehen oder den Fehlertoleranzanforderungen w‰hrend des Wartungs- betriebs entsprechen.

5.4.5 Elektronische, elektrische, elektromechanische Bauelemente

EEE-Bauelemente, die zur Unterst¸tzung von sicherheitskritischen Funktionen in Flugstandard-Hardware ein- gesetzt werden, sind nach den entsprechenden Anforderungen auszuw‰hlen und zu beschaffen. [Siehe auch ISO 14621].

6 Sicherheitsanalyse ó Anforderungen und Techniken

6.1 Allgemeines

a) Sicherheitsanalysen sind systematisch durchzuf¸hren, um sicherzustellen, dass die Sicherheitsrisiko- quellen festgestellt und beseitigt oder minimiert und kontrolliert werden.

EN ISO 14620-1:2002 (D)

b) Sicherheitsrisiken kˆnnen sich ergeben aus Gef‰hrdungsmerkmalen im Zusammenhang mit:

1)

dem Design, einschliefllich der gew‰hlten Technologie, der physischen Anordnung der Elemente, Subsysteme und Ger‰te;

2)

den Betriebsarten;

3)

dem Fehlverhaltenspotential des Personals;

4)

der Betriebsumgebung;

5)

den Gef‰hrdungsauswirkungen, die sich aus Funktionsausf‰llen/-fehlern ergeben kˆnnen.

c) Sicherheitsanalysen sind fr¸hzeitig in der Designphase einzuleiten und m¸ssen gleichzeitig das Projektengineering bei der Auswahl der Design- und Betriebsoptionen mit dem geringsten Gef‰hrdungs- potential, die mit der Projektmission und den Programmatik-Randbedingungen vereinbar sind, unter- st¸tzen.

d) Die Ergebnisse der Sicherheitsanalysen sind auch heranzuziehen zur Unterst¸tzung des Projektmanage- ments bei der Verifikation der Risikoreduzierung, Einstufung der Risikoquellen, Unterst¸tzung bei der Projektmittelzuordnung, ‹berwachung der Risikotrends und Restrisikobilligung.

e) Die Analysen m¸ssen immer unter Bezugnahme auf eine bestimmte Bezugskonfiguration vorgenommen werden.

6.2 Bewertung und Zuweisung von Anforderungen

6.2.1 Sicherheitsanforderungen

Der Lieferant muss die f¸r das Projekt geltenden Sicherheitsanforderungen umsetzen und erf¸llen.

6.2.2 Zus‰tzliche Sicherheitsanforderungen

Der Lieferant muss auch die zus‰tzlichen Sicherheitsanforderungen identifizieren durch die Ber¸cksichtigung der in fr¸heren Projekten gemachten Erfahrungen und die Sicherheitsanalysen, die im Verlauf des Projekts durchgef¸hrt werden.

6.2.3 Sicherheitsanforderungen an Funktionen

Der Lieferant muss unter Ber¸cksichtigung der Ergebnisse der Funktionsfehleranalyse und der Sicherheits- anforderungen auf Systemebene die Sicherheitsanforderungen f¸r die verschiedenen Systemfunktionen fest- legen.

6.2.4 Sicherheitsanforderungen an Subsysteme

Anschlieflend muss der Lieferant unter Ber¸cksichtigung der Ergebnisse der vorl‰ufigen Sicherheitsanalyse und der Systemarchitektur die Sicherheitsanforderungen im Zusammenhang mit den verschiedenen Sub- systemen festlegen.

6.2.5 Berechtigung

Sp‰testens am Ende der Phase ÑDetaildefinitionsphaseì muss der Lieferant eine Begr¸ndung f¸r die vorge- schlagene Zuweisung der Sicherheitsanforderungen vorlegen.

EN ISO 14620-1:2002 (D)

6.2.6 Funktions- und Subsystemspezifikation

Der Lieferant muss sicherstellen, dass die funktions- und subsystembezogenen Sicherheitsanforderungen in die entsprechenden Funktions- und Subsystemspezifikationen aufgenommen werden.

6.3

Sicherheitsanalyse

6.3.1 Allgemeines

Sicherheitsanalysen sind mit fortschreitendem Designprozess iterativ zu verfeinern und zu aktualisieren, um sicherzustellen, dass die Gef‰hrdungen und Gef‰hrdungsereignisse bewertet werden, und dass die ent- sprechenden Detaildesign- und Betriebsanforderungen, Gef‰hrdungskontrollmaflnahmen und Verifikations- t‰tigkeiten festgelegt und umgesetzt werden.

6.3.2 Missionsanalyse

Die Sicherheitsanalyse muss die Identifizierung der wichtigsten Sicherheitsrisikoquellen sowie die Durch- f¸hrung vorl‰ufiger Vergleichsbewertungen zwischen mˆglichen Systemkonzepten unterst¸tzen.

6.3.3 Durchf¸hrbarkeit

Die Sicherheitsanalyse muss die Vergleichsbewertungen unterst¸tzen, um unter Beachtung der Projekt- und Missionsauflagen zu dem Konzept zu gelangen, das die geringsten Sicherheitsrisiken mit sich bringt. Die Analyse muss sich auf die Gef‰hrdungsbeseitigung oder -minimierung konzentrieren, indem sie die Wahl des umzusetzenden Systemtechnologie- und -betriebskonzeptes sowie die Wahl der sichersten Systemarchitektur unterst¸tzt.

6.3.4 Vordefinition

Die Sicherheitsanalyse muss eine weiterf¸hrende und detailliertere Sicherheitsoptimierung des Systemdesigns und -betriebs und die Identifizierung der sicherheitstechnischen Anforderungen und deren Geltungsbereich unterst¸tzen. Die Analyse muss auch Beitr‰ge zur Sicherheitsrisikobewertung leisten durch Unterst¸tzung der Sicherheitsrisikobeurteilung und Feststellung der wesentlichen Risikoverursacher im Design- und Betriebskonzept.

6.3.5 Detaildefinition, Produktion und Qualifikation

Die Sicherheitsanalyse muss die Detaildesign- und Betriebssicherheitsoptimierung, die Beurteilung der Um- setzung der Sicherheitsanforderungen, die Risikoreduzierungsverifikation und die Gef‰hrdungs- und Risiko- billigung unterst¸tzen. Die Analyse der Betriebssicherheit muss auflerdem die Identifizierung der Planungs- und Schulungsanforderungen f¸r Not- und Stˆrfallmaflnahmen sowie die Entwicklung von Vorschriften unterst¸tzen.

6.3.6 Betrieb

Die Sicherheitsanalyse muss Design- und Betriebs‰nderungen auf ihre Auswirkung auf die Sicherheit bewerten und sicherstellen, dass die Sicherheitsreserven gewahrt bleiben und der Betrieb mit kleinst- mˆglichem Risiko vonstatten geht. Die Analyse muss auch die Beurteilung der Betriebsanomalien im Hinblick auf ihre Auswirkung auf die Sicherheit und die kontinuierliche Risikotrendbeurteilung unterst¸tzen.

6.3.7 Entsorgung

Die Sicherheitsanalyse muss alle Entsorgungsvorg‰nge und die damit verbundenen Gef‰hrdungen f¸r die Bevˆlkerung am Boden und f¸r die Umwelt beurteilen. Die Entsorgungslˆsungen mit den geringsten Gef‰hrdungsfolgen m¸ssen festgestellt werden.

EN ISO 14620-1:2002 (D)

6.4 Spezielle Sicherheitsanalyse

6.4.1 Allgemeines

Die f¸r ein gegebenes Projekt auszuw‰hlenden Arten von Analysen sind vom Produktlieferanten auf der Grundlage fr¸herer Erfahrungen vorzuschlagen und im Laufe der Sicherheitsanalyse nach Bedarf zu aktuali- sieren.

ANMERKUNG Die Sicherheitsanalyse besteht aus einer Kombination aller im weiteren Verlauf dieses Abschnitts be- schriebenen Analysen. Unterst¸tzende Analysen sind in 6.5 beschrieben.

6.4.2 Gef‰hrdungsanalyse

a) Die Gef‰hrdungsanalyse ist systematisch von Anbeginn der Konzeptphase bis hin zur Betriebsphase ein- schliefllich Lebensdauerende und Entsorgung durchzuf¸hren.

b) Die Gef‰hrdungsanalyse muss folgende Aspekte identifizieren und beurteilen:

1)

Gef‰hrdungen im Zusammenhang mit Systemdesign, Systembetrieb und Betriebsumgebung;

2)

Gef‰hrdungsauswirkungen infolge der physischen und funktionalen Ausbreitung von Auslˆse- ereignissen;

3)

Gef‰hrdungsereignisse infolge Ausfall/Fehler von Systemfunktionen und Funktionselementen;

4)

zeitkritische Situationen.

c) Folgende potentielle Auslˆseereignisse sind in Betracht zu ziehen:

1)

Hardwarefehler (zuf‰llig oder zeitabh‰ngig);

2)

latente Softwarefehler;

3)

Fehlverhalten des Betriebspersonals;

4)

Designunzul‰nglichkeiten einschliefllich:

i) unangemessener Reserven;

ii) unbeabsichtigter Betriebsarten, verursacht durch Sneak-Kreise;

iii) Materialunzul‰nglichkeiten und -unvertr‰glichkeiten;

iv) Hardware/Software-Wechselwirkungen;

5)

nat¸rliche und induzierte Umweltauswirkungen;

6)

Verfahrensm‰ngel.

d) Dies beinhaltet eine systematische Analyse der ÑSystemì-Betriebsvorg‰nge und -vorschriften, die in der Detaildesign- und Betriebsphase eines Projektes durchgef¸hrt wird, um die sichere Funktionsf‰higkeit des Systems zu beurteilen, die sichersten Betriebsarten zu ermitteln und die Freigabef‰higkeit der Betriebsvorschriften zu bewerten. Die Analyse wird mit fortschreitender Design- und Betriebsdetaillierung wiederholt, wobei das Augenmerk besonders auf die Betriebsarten des Systems und seine Schnittstellen Mensch/Maschine zu richten ist.

EN ISO 14620-1:2002 (D)

6.4.3 Sicherheitsrisikobewertung

a) Die Sicherheitsrisikobewertung ist in fortschreitenden Stufen im Laufe der Implementierung des Sicher- heitsprogramms vorzunehmen.

b) Die Risikobewertung ist zu benutzen, um:

1)

Designvergleichsbewertungen zu unterst¸tzen (Risikovergleich);

2)

Risikoverursacher einzustufen;

3)

Hauptrisikoverursacher festzustellen;

4)

den Sicherheitsentscheidungsprozess zu unterst¸tzen (z. B. f¸r Sonderfreigaben, ungelˆste Rest- risiken);

5)

die Wirksamkeit des Gef‰hrdungskontroll- und Risikoreduzierungsprozesses durch Absch‰tzung der Sicherheitsrisikotrends aufzuzeigen;

6)

die ‹bereinstimmung mit probabilistischen Sicherheitszielen zu beurteilen.

c) Die Ergebnisse der Sicherheitsrisikobewertung sind nicht als einzige Grundlage f¸r die Billigung oder Zur¸ckweisung von Restrisiken zu verwenden.

d) Die zur Risikobewertung benutzten Datenquellen sind zu identifizieren und vom Lieferanten zu be- gr¸nden.

6.4.4

Sicherheitsanalyse f¸r Hardware-Softwaresysteme

6.4.4.1

Sicherheitskritische Funktion

Die Software, die sicherheitskritische Funktionen umsetzt oder ¸berwacht, ist einer Sicherheitsanalyse zu unterziehen. Je nach Anwendungsfall kann diese Software-Sicherheitsanalyse als gesonderte Software- Sicherheitsanalyse oder als Teil anderer Sicherheitsanalysen durchgef¸hrt werden. In jedem Fall m¸ssen Umfang und Ausf¸hrlichkeit der Software-Sicherheitsanalyse, wie anhand der Funktionsfehleranalyse und der vorl‰ufigen Sicherheitsanalysen auf Systemebene festgestellt, sowie ihre Durchf¸hrung mit der FTA, der Gef‰hrdungsanalyse, der FMECA und der Sneak-Analyse abgestimmt werden.

6.4.4.2 Definitionsphase der Anforderungen

W‰hrend der Definitionsphase der Softwareanforderungen muss der Lieferant die System- und Software- anforderungen auf unsichere Betriebsarten (z. B. Sequenzfehler, falsches Ereignis, unbeabsichtigter Befehl, fehlender Befehl, Deadlocking) pr¸fen. Die Analyse ist vorzugsweise mit Hilfe einer FMECA und FTA (auf hoher Ebene) durchzuf¸hren. Geeignete Software-Sicherheitsanforderungen sind in dem Softwareanforde- rungs-Dokument zur Kontrolle der obigen unsicheren Betriebsarten aufzunehmen.

6.4.4.3 Architekturdesign- und Detaildesignphase

In der Software-Architekturdesign- und der Detaildesignphase muss der Lieferant ermitteln, wann und unter welchen Bedingungen das System Gef‰hrdungsereignisse auslˆsen kˆnnte. Eingabe/Ausgabe, Zeit- bestimmung und Auswirkung von Hardwarefehlern auf die Software sollten zu diesem Zeitpunkt in die Analyse einbezogen werden. FTA und Design-Reviewmethoden auf Checklisten-Basis kˆnnen angewandt werden.

EN ISO 14620-1:2002 (D)

6.4.4.4

Softwarecode

Wenn der Softwarecode verf¸gbar ist, muss der Lieferant:

a) auf Richtigkeit und Vollst‰ndigkeit analysieren;

b) verifizieren, ob die Software-Sicherheitsanforderungen korrekt implementiert wurden;

c) verifizieren, ob die Software den entsprechenden Code auch unter den voraussichtlichen ‹berlast- bedingungen der Eingabe handhaben kann.

6.5 Unterst¸tzende Bewertung und Analyse

6.5.1 Allgemeines

Die Anwendung der folgenden unterst¸tzenden Bewertung und der Analysenwerkzeuge liegt im Ermessen der f¸r das Programm oder das Projekt zust‰ndigen Behˆrden.

6.5.2 Warnzeitanalyse

a) In der Konzeptdefinitionsphase und der Design- und Entwicklungsphase ist eine Warnzeitanalyse durch- zuf¸hren, um die in der Gef‰hrdungsanalyse festgestellten zeitkritischen Situationen zu bewerten und die Implementierung von Erkennungs- und Warnvorrichtungen f¸r Gef‰hrdungssituationen oder von Stˆrfall- vorschriften zu unterst¸tzen.

b) Die Analyse muss Folgendes ermitteln:

1)

Zeit, in der das Ereignis zu erkennen und die Reaktionsmaflnahme zu treffen ist;

2)

Erkennungsvermˆgen des vorgeschlagenen Designs im Hinblick auf Empfindlichkeit und Zeit der Er- kennung;

3)

resultierende Zeit, die f¸r die Reaktion zur Verf¸gung steht;

4)

Eignung der vorgeschlagenen Designlˆsung oder Stˆrfallvorschriften, einschliefllich Notevakuierung, Rettung, System-Rekonfiguration, Redundanzumschaltung und Instandhaltung.

c) Als Erkennungszeiten sind folgende zu ermitteln:

1)

ab Eintritt des Auslˆseereignisses bis zum Zeitpunkt des Eintritts einer Gef‰hrdungsfolge (Ausbrei- tungszeit);

2)

ab Eintritt des Auslˆseereignisses bis zum Zeitpunkt der fr¸hesten Erkennung oder Meldung; und

3)

Zeit, die f¸r die durchzuf¸hrende Korrekturmaflnahme verbraucht wird.

6.5.3 Vorsicht- und Warnanalyse

a) Die Vorsicht- und Warnanalyse ist in der Konzeptdefinitionsphase und der Design- und Entwicklungs- phase von bemannten Raumfahrtprogrammen durchzuf¸hren, um Folgendes festzustellen:

1)

Not-, Warn- und Vorsichtparameter;

2)

erforderliche Sicherungsfunktionen und -einrichtungen;

3) Grenzwerterfassungsanforderungen;

4)

G¸ltigkeit der einzelnen Vorsicht- und Warnfunktionen in den verschiedenen Missionsphasen.

b) Die Vorsicht- und Warnanalyse muss die Ergebnisse der Warnzeit- und Gef‰hrdungsanalysen, soweit zweckm‰flig, ber¸cksichtigen.

EN ISO 14620-1:2002 (D)

6.5.4

Analyse der gemeinsamen Ausfall-/Fehlerarten und -ursachen

6.5.4.1

Mehrfache Ausf‰lle/Fehler

Mehrfache Ausf‰lle/Fehler, die sich aus Mechanismen gemeinsamer Ausfall-/Fehlerarten oder -ursachen ergeben, sind im Hinblick auf die Fehlertoleranzbestimmung als Einzelausfall/-fehler zu betrachten.

6.5.4.2 Identifizierung der Anforderungen und des Anwendungsbereiches

Der Lieferant muss Notwendigkeit und Umfang von gezielten Analysen gemeinsamer Ausfall-/Fehlerarten und ñursachen nach ‹berpr¸fung der Ergebnisse der anderen Sicherheitsanalysen [z. B. Fehlzustandsbaum- analyse (FTA), Gef‰hrdungsanalyse] und der Charakteristik des Systems und seiner Umgebung bestimmen.

6.5.4.3 Identifizierung der Ausf‰lle/Fehler

Der Lieferant muss die potentiellen Ausf‰lle/Fehler mit gemeinsamer Ausfall-/Fehlerursache durch Bewertung der Auswirkungen von gemeinsamen Ursachen (z. B. Strahlung, thermische Umgebung, Feuer) feststellen. Diese Analyse ist in Abstimmung mit der Fehlzustandsbaumanalyse (FTA) und der Gef‰hrdungsanalyse durchzuf¸hren. Die Analyse der Ausf‰lle/Fehler mit gemeinsamer Ausfall-/Fehlerursache erfordert eventuell die Einbeziehung der Ergebnisse gezielter Engineeringanalysen (z. B. thermische Analysen, Meteoriten- oder Debris-Aufschlaganalyse).

6.5.4.4 Analyse der Ausf‰lle/Fehler

Die Ausf‰lle/Fehler mit gemeinsamer Ausfall-/Fehlerart sind anhand von (vom Lieferanten zu erstellenden) Checklisten zu analysieren, in denen die mˆglichen gemeinsamen Ausfall-/Fehlerarten f¸r die System- bestandteile w‰hrend der Fertigungs-, Integrations-, Test-, Betriebs- und Instandhaltungsphasen aufgef¸hrt sind. Die Analyse gemeinsamer Ausfall-/Fehlerarten sollte mit der Fehlerart-, -auswirkungs- und ñkritikalit‰ts- analyse (FMECA) abgestimmt werden.

6.5.4.5 Integration der Ergebnisse

Die Ergebnisse der Analyse der gemeinsamen Ausfall-/Fehlerarten und -ursachen sollten auf der jeweiligen Ebene mit den Ergebnissen der Sicherheitsanalysen auf Systemebene (FTA, Gef‰hrdungsanalyse) integriert werden.

6.5.5 Fehlzustandsbaumanalyse (FTA)

Die Fehlzustandsbaumanalyse ist vorzunehmen, um eine systematische Beziehung zwischen der Gef‰hrdung auf Systemebene und den beitragenden Gef‰hrdungsereignissen und dem Ausfall von Subsystemen, Ger‰ten oder Einzelteilen herzustellen. Notwendig ist eine FTA oder gleichwertige Analyse, um die Fehler- toleranz des Produktes zu verifizieren.

6.5.6 Analyse der menschlichen Zuverl‰ssigkeit

a) Wenn in Sicherheitsanalysen menschliches Fehlverhalten als Ursache katastrophaler oder kritischer Gef‰hrdungen festgestellt wird, ist eine gezielt auf die menschliche Zuverl‰ssigkeit ausgerichtete Analyse durchzuf¸hren.

b) Diese Analyse der menschlichen Zuverl‰ssigkeit ist vorzunehmen, um die Sicherheitsanalyse zur Fest- stellung der Fehlverhaltensarten und deren Auswirkungen zu unterst¸tzen und angemessene Gegen- maflnahmen zur Verh¸tung oder Kontrolle menschlichen Fehlverhaltens zu bestimmen.

c) Die Analyse der menschlichen Zuverl‰ssigkeit ist schon in den fr¸hen Projektphasen einzuleiten, um Empfehlungen f¸r das Hardware- und Softwaredesign, die Vorschiftenentwicklung und das Trainingsvor- bereitungsprogramm festzulegen.

EN ISO 14620-1:2002 (D)

6.5.7 Fehlerart-, -auswirkungs- und -kritikalit‰tsanalyse (FMECA)

Die Ergebnisse der Fehlerart-, -auswirkungs- und -kritikalit‰tsanalyse (FMECA) sind heranzuziehen, um die Gef‰hrdungsanalyse in der Beurteilung der Ausfall-/Fehlerauswirkungen zu unterst¸tzen. FMECA und Gef‰hrdungsanalyse sind als sich erg‰nzende Analysen zu betrachten.

6.5.8

Sneak-Analyse

6.5.8.1

Anwendbarkeit

Ziel der Sneak-Analyse ist die Identifizierung der ÑSneak-Kreiseì, d. h. der unerwarteten Pfade f¸r einen Fluss von Masse, Energie, Daten oder logischer Abl‰ufe, die unter bestimmten Bedingungen eine unerw¸nschte Funktion auslˆsen oder eine erw¸nschte Funktion verhindern kˆnnen. Sneak-Kreise sind nicht das Resultat von Ausf‰llen/Fehlern, sondern latente Zust‰nde oder Bedingungen, die unbeabsichtigt in das Systemdesign eingeflossen sind. W‰hrend der Design- und Entwicklungsphasen sollte die Sneak-Analyse f¸r folgende Funktionen durchgef¸hrt werden:

a) Funktionen, deren Ausfall/Fehler zu katastrophalen Folgen f¸hren w¸rde;

b) Not-, Warn- und zugeordnete Sicherungs-Teilfunktionen;

c) Teilfunktionen, die die Befreiung und Rettung der Flugbesatzung unterst¸tzen.

6.5.8.2 Ergebnisse

a) Die Ergebnisse der Sneak-Analyse sind heranzuziehen, um die Gef‰hrdungsanalyse und die FMECA bei der Feststellung der mˆglichen Ursachen von Gef‰hrdungsereignissen oder Ausf‰llen/Fehlern sowie das Design-Review zu unterst¸tzen.

b) Die Ergebnisse der Funktionsfehleranalyse und Gef‰hrdungsanalyse sind heranzuziehen, um f¸r die be- troffenen Funktionen den detaillierten Umfang der Sneak-Analyse anhand folgender Kriterien festzu- stellen:

1)

Teilfunktionen oder Einheiten, die nicht mit den geltenden Sicherheitsanforderungen ¸bereinstimmen oder nicht auf ‹bereinstimmung mit diesen verifiziert werden kˆnnen, sind zu analysieren;

2)

die Befehls- und Steuerungs-Teilfunktionen sind einzubeziehen;

3)

die Teilfunktionen der elektrischen Energieverteilung sind einzubeziehen;

4)

die passiven Teilfunktionen (z. B. Prim‰r- oder Sekund‰rstrukturen, passive thermische Kontrolle) sind auszuschlieflen.

6.5.9

Zonenanalyse

6.5.9.1

Definition

Siehe 3.1.31.

6.5.9.2 Redundanz und Ziele

Die Zonenanalyse muss durchgef¸hrt werden, wenn Redundanz eingef¸hrt wird, um die Wahrscheinlichkeit eines Funktionsverlustes oder einer unbeabsichtigten Auslˆsung einer sicherheitskritischen Funktion zu redu- zieren. Ziel der Zonenanalyse ist sicherzustellen, dass die Ger‰teinstallation die entsprechenden Sicherheits- anforderungen erf¸llt in Bezug auf:

a) grundlegende Installationsregeln und Raumfahrtpraktiken;

b) Wechselwirkung zwischen Subsystemen;

c) Auswirkung menschlichen Fehlverhaltens;

EN ISO 14620-1:2002 (D)

d) Einfl¸sse externer Ereignisse.

6.5.10

Energieverlaufsanalyse

Die Grundelemente des Energieverlaufs sind Energiequellen, -ziele und ñbarrieren. Die mit dem System zusammenh‰ngenden Energiequellen m¸ssen identifiziert und ihre Intensit‰t muss bewertet werden. Danach muss der Pr¸fer die Sicherheitsziele identifizieren, die durch die einzelnen Energiequellen beeintr‰chtigt werden kˆnnen.

7

Sicherheitsverifikation

7.1 Allgemeines

a) Um sichergehen zu kˆnnen, dass die Sicherheit in das Produkt integriert wurde, muss ein System einge- richtet werden, das es ermˆglicht, alle Gef‰hrdungen und damit verbundenen Risiken zu verfolgen und alle Verifikationen der jeweiligen Gef‰hrdung eindeutig auf klare Ursachen und Kontrollmaflnahmen zu beziehen.

b) Test, Analyse, Inspektion und ÑReview des Designsì sind g‰ngige Techniken zur Verifikation von Design- merkmalen f¸r die Gef‰hrdungskontrolle. Der erfolgreiche Abschluss des Sicherheitsprozesses erfordert eine positive R¸ckmeldung der Abschlussergebnisse f¸r alle mit einer bestimmten Gef‰hrdung ver- bundenen Verifikationspunkte.

7.2 Gef‰hrdungsverfolgung

7.2.1 Gef‰hrdungsberichtssystem

Der Lieferant muss ein Gef‰hrdungsberichtssystem einf¸hren, um den Status aller identifizierten Gef‰hr- dungen verfolgen zu kˆnnen. Das System ist f¸r alle katastrophalen und kritischen Folgen anzuwenden.

7.2.2 Status

a) Der Status ist entweder Ñoffenì oder Ñgeschlossenì.

b) Ein Ñoffener Statusì muss mindestens angezeigt werden mit:

1)

Kontrollmaflnahmen innerhalb der Projektorganisation des Lieferanten festgelegt und genehmigt;

2)

Verifikationsmethoden innerhalb der Projektsicherheits-, Engineering- und Managementorganisation des Lieferanten festgelegt und genehmigt;

3)

Verifikation fertiggestellt und zur Abnahme unterbreitet.

7.2.3 Sicherheitsfortschrittsbesprechung

Der Status der Gef‰hrdungskontroll- und Risikoreduzierungst‰tigkeiten muss auf den Sicherheitsfortschritts- besprechungen ¸berpr¸ft und formal dokumentiert und zur ‹berpr¸fung durch den Kunden bei den Projekt- sicherheits-Reviews vorgelegt werden, siehe 4.5.1.

7.2.4 ‹berpr¸fung und Verf¸gung

Gef‰hrdungen und Sicherheitsrisiken mit katastrophalen und kritischen Folgen m¸ssen zur ‹berpr¸fung und formalen Verf¸gung gegebenenfalls der zust‰ndigen Startorganisation vorgelegt werden.

EN ISO 14620-1:2002 (D)

7.2.5 Dokumentation

a) Die gesamte Gef‰hrdungsdokumentation ist f¸r alle Sicherheits-Reviews und alle wichtigen Projekt- reviews formal herauszugeben.

b) Wenn Verfahren oder Prozesse kritische Schritte in der Gef‰hrdungskontrolle darstellen und die Verfahrens- und/oder Prozessergebnisse nicht durch nachfolgende Tests oder Pr¸fungen unabh‰ngig verifiziert werden, muss sichergestellt werden, dass das Verfahren bzw. der Prozess unabh‰ngig in Echtzeit ¸berpr¸ft wird.

7.2.6 Pr¸fpunkt

Kritische Verfahrens- oder Prozessschritte sind in einem Gef‰hrdungsbericht als verbindlich vorgeschriebener Pr¸fpunkt (MIP) oder einer unabh‰ngigen Beobachtung bed¸rfend zu identifizieren.

7.3

Sicherheitsverifikationsmethoden

7.3.1 Verifikationstechnik und Planung

a) Die Verifikationstechnik (verifikationsbezogenes Engineering) muss die geeignetsten, kosteneffizienten Verifikationsmethoden in ‹bereinstimmung mit den im Gef‰hrdungsbericht dokumentierten Verifikations- anforderungen ausw‰hlen.

b) Nach Wahl der Kontrollmethode muss in integrierter Weise mit der Verifikationsplanung begonnen werden.

7.3.2 Berichte und Methoden

Sicherheitsverifikationsmethoden sind Review des Design, Analyse, Inspektion und Test. F¸r alle Verifika- tionen sind aus Gr¸nden der Nachvollziehbarkeit datierte und unterzeichnete Verifikationsberichte zu erstellen.

7.3.3 Verifikationanforderungen

Mit Bezug auf die jeweils vorliegende Designgrundlage erfolgt die Verifikation der Anforderung durch Ver- gleich der ÑReview des Designì-Anforderung mit einer Spezifikation oder Zeichnung, je nach Fall.

7.3.4 Analyse

a) Alle technischen Sicherheits- und Engineeringanalysen, die durchgef¸hrt oder je nach Konfiguration Ñwie gebautì aktualisiert werden, kˆnnen zur Verifikation eingesetzt werden.

b) Eine ƒhnlichkeitsanalyse ist ein spezieller Fall von Analyse, da die Grundlage f¸r die Beurteilung, dass ƒhnlichkeit vorliegt, durch Analyse geliefert wird. Zum Zwecke der Nachvollziehbarkeit muss eine ƒhnlichkeitsanalyse eine Kopie der betreffenden fr¸heren Verifikation, Verifikationsvorschrift und -anforderung, die zum Zeitpunkt der Erstverifikation g¸ltig waren, oder eine entsprechende Referenz enthalten.

7.3.5 Inspektion

a) Alle Sicherheitsinspektionen vor dem Flug sind im Hinblick auf ihre Aufnahme in die Liste der verbindlich vorgeschriebenen Pr¸fpunkte (MIP) zu beurteilen.

b) In diesem Fall kann der Ausschuss ¸ber die MIP- oder Einzelberichterstattung erfolgen. Startvorberei- tungsinspektionen sind in das entsprechende Startbasisverfahren aufzunehmen.

EN ISO 14620-1:2002 (D)

c) Der Ausschluss ist dann durch das genehmigte Verfahren der Startorganisation gegeben. Sp‰tzugangs- Pr¸fverfahren m¸ssen Gegenstand eines Trainings sein und von qualifiziertem Personal ausgef¸hrt werden.

d) Inspektionen im Flug einschliefllich ÑTele-Scienceì-Inspektionen sind in die Flugvorschriften und Flug- betriebshandb¸cher aufzunehmen.

e) Ein Training der Flugbesatzung und der Missionseinsatzteams ist zwingend. Das Training umfasst produktspezifische Sicherheitseinweisung, Produkttraining und Missionssimulation, soweit nˆtig.

f) Der Ausschluss erfolgt ¸ber sicherheitstechnisch genehmigte Verfahren, dokumentierte Trainingsteil- nahme und eine ausreichende Anzahl von Simulationen.

7.3.6 Tests

Tests sind f¸r alle sicherheitskritischen Funktionen umfassend (Ñend-to-endì) und f¸r sicherheitskritische Ein- heiten, wie in der entsprechenden Sicherheits-Sonderfreigabe (vor oder nach Realisierung) identifiziert, vor- geschrieben.

7.3.7 Verifikation und Genehmigung

F¸r die Auswahl der Verifikation ist der Lieferant zust‰ndig, f¸r die Genehmigung die zust‰ndige Sicherheits- zertifizierungsstelle.

7.4 Qualifikation sicherheitskritischer Funktionen

7.4.1 G¸ltigkeit

Die sicherheitstechnischen Funktionen sind durch umfassende (Ñend-to-endì) Tests zu beglaubigen, die die Anwendung der Betriebsvorschriften, Ñden Faktor Mensch im Regelkreisì und die Verifikation der Wirksamkeit der anzuwendenden Fehlertoleranzanforderungen einbeziehen m¸ssen. Die Tests m¸ssen den Demonstra- tionsnachweis der Soll-, Stˆrfall- und Notbetriebsarten einschlieflen.

7.4.2 Qualifikation

Die sicherheitskritischen Merkmale aller sicherheitskritischen Funktionen m¸ssen durch Tests vollst‰ndig qualifiziert sein. Die Qualifikationstests der sicherheitskritischen Funktionen m¸ssen die Bestimmung der Leistungsreserven unter Ber¸cksichtigung der ung¸nstigsten Kombinationen von induzierten und nat¸rlichen Umgebungen und Betriebsbedingungen beinhalten. Eine Qualifikation Ñdurch ƒhnlichkeitì ist nur nach Genehmigung durch den Kunden auf Einzelbasis zul‰ssig.

7.4.3 Fehlertests

Tests mit induzierten Ausf‰llen/Fehlern sind durchzuf¸hren, soweit aufgrund der Sicherheitsanalyse gefordert, um die Ausfall-/Fehlerauswirkungen zu beurteilen und die Fehlertoleranzkonformit‰t bei sicherheitskritischen Funktionen nachzuweisen.

7.4.4 Verifikation des Design oder Betriebsmerkmale

Die Verifikation der einzelnen sicherheitstechnisch geforderten Design- oder Betriebsmerkmale muss Be- standteil des Entwicklungs-, Qualifikations- und/oder gegebenenfalls Abnahmetestprogramms sein.

EN ISO 14620-1:2002 (D)

7.4.5 Sicherheitsverifikationstest

Wenn aus Kosten- oder technischen Gr¸nden Tests in Originalgrˆfle nicht mˆglich sind, sind nach Genehmi- gung gesonderte, gleichwertige Sicherheitsverifikationstests an technisch repr‰sentativer Hardware oder Modellen durchzuf¸hren.

7.5 Beglaubigung des Gef‰hrdungsausschlusses

7.5.1 Sicherheitssicherungsstelle

Rechtzeitig zur Abnahme durch den Kunden und in Vorbereitung der ‹berf¸hrung zum Startgel‰nde muss die Sicherheitssicherungsstelle beglaubigen, dass:

a) die bisher vom zust‰ndigen Ingenieur durchgef¸hrten Gef‰hrdungsausschl¸sse nach wie vor g¸ltig sind;

b) nichts ¸bersehen wurde;

c) die Verifikationen den Hardware-Status im Zustand Ñwie gebautì/modifizierten Zustand wiederspiegeln;

d) alle zu diesem Zeitpunkt noch offenen Verifikationen f¸r die ‹berf¸hrung zum Startgel‰nde annehmbar sind;

e) alle offenen Verifikationen in das Verifikations-Nachweisverzeichnis eingetragen wurden, das jetzt zu einem Ñlebendenì Dokument wird.

7.5.2 Sicherheitszertifizierungsstelle

Der Ausschluss jeder Gef‰hrdung erfordert die Zustimmung der zust‰ndigen Sicherheitszertifizierungsstelle. Gef‰hrdungen kommen nur dann f¸r einen Ausschluss in Betracht, wenn entweder:

a) die Gef‰hrdung beseitigt wurde; oder

b) die Gef‰hrdung minimiert und entsprechend der geltenden Anforderung kontrolliert wurde und die zuge- hˆrigen Verifikationst‰tigkeiten erfolgreich abgeschlossen wurden; oder

c) eine Sonderfreigabe (vor oder nach Realisierung) von der zust‰ndigen Sicherheitszertifizierungsstelle erteilt wurde.

7.6 Restrisikoreduzierung

Mit katastrophalen und kritischen Folgen verbundene Sicherheitsrisiken, die der Gef‰hrdungsreduzierungs- sequenz unterzogen wurden, werden als Restrisiken bezeichnet. Die Risikoreduzierung ist ó entweder parallel zur Gef‰hrdungsreduzierung oder nach dieser ó durchzuf¸hren, um das Restrisiko soweit herabzu- setzen, dass es mit der quantitativen Sicherheitszielvorgabe vereinbar ist.

8

Betriebssicherheit

8.1 Anforderungsgrundlage

In der Betriebsphase erhalten die Sicherheitsbelange eine noch grˆflere Bedeutung, da alle Probleme in Echt- zeit unter vorgegebenen Randbedingungen zu bew‰ltigen sind.

a) Die Einbindung der Sicherheit in die Betriebsphase muss somit geplant werden.

EN ISO 14620-1:2002 (D)

b) Verantwortlichkeiten, Regeln und Stˆrfallvorschriften m¸ssen vor dem eigentlichen Betrieb f¸r Gef‰hr- dungs-ÑGrenzbedingungenì, die w‰hrend des Boden- und Flugbetriebs auftreten kˆnnen, festgelegt werden.

c) Betriebsbereiche und Leistungsgrenzen f¸r den sicheren Betrieb sind f¸r das Design festzulegen und zu spezifizieren.

d) Das Design darf keine st‰ndige aktive Kontrolle durch Personal erfordern, um innerhalb der festgelegten Betriebsbereiche und Leistungsgrenzen zu bleiben.

e) Die Schnittstellen Mensch/Maschine m¸ssen so ausgelegt und die Personalaufgaben so bemessen sein, dass das Potential f¸r Gef‰hrdungsereignisse infolge menschlichen Fehlverhaltens auf ein Mindestmafl begrenzt bleibt.

f) Die Grenzen f¸r die Belastung der Besatzung durch nat¸rliche und systeminduzierte Umgebungen sind festzusetzen und durch Designmerkmale oder Betriebsauflagen einzuhalten, die Soll-, Stˆrfall- und Not- betriebsarten umfassen, um Verletzungen der Besatzung oder Unf‰higkeit, sicherheitskritische Funk- tionen auszuf¸hren, auszuschlieflen.

8.2 Flugbetriebs- und Missionskontrolle

8.2.1 Tr‰gersystem

Gef‰hrdungen f¸r die ÷ffentlichkeit, f¸r ˆffentliches und privates Eigentum und die Umwelt, die sich aus dem Betrieb oder Funktionsstˆrungen des Tr‰gersystems ergeben, sind durch Auflagen f¸r die Soll- und Abbruch- Flugbahnen, f¸r die Stufentrennung und f¸r das Niedergehen ausgebrannter Stufen auszuschlieflen.

8.2.2 Verschmutzung

Die ¸blichen oder Abbruchvorg‰nge d¸rfen nicht zu einer Verschmutzung der Erdatmosph‰re f¸hren, die eine Gef‰hrdung f¸r die menschliche Gesundheit, Ernten, nat¸rlichen Ressourcen oder Umwelt darstellen.

8.2.3 Flugregeln

F¸r jede Mission sind Flugregeln aufzustellen, die vorausgeplante Entscheidungen aufzeigen, deren Zweck es ist, den bei Eintritt von anomalen Situationen erforderlichen Umfang an Echtzeit-Rationalisierung zu mini- mieren. Diese Flugregeln stellen keine zus‰tzlichen Sicherheitsanforderungen dar, sondern legen Mafl- nahmen zur Vollendung der Mission des Raumfahrzeuges unter Einhaltung der Sicherheitsanforderungen fest.

8.2.4 Kontrolle gef‰hrdender Befehlsgebungen

Die Kontrolle gef‰hrdender Befehlsgebungen muss Folgendes sicherstellen:

a) Alle gef‰hrdenden Befehle sind zu identifizieren.

b) Gef‰hrdende Befehle sind Befehle, die eine Sperre f¸r eine sicherheitskritische Funktion aufheben oder ein abgeschaltetes gef‰hrdendes Subsystem aktivieren kˆnnen.

c) Ausfall-/Fehlerarten im Flugbetrieb ó einschliefllich Hardware, Software und Verfahren ó, die bei der Befehlsgebung von Kontrollzentren oder anderen Bodeneinrichtungen angewendet werden, sind in der Sicherheitsbewertung zu ber¸cksichtigen.

d) Das Systemdesign muss einen Schutz vor f‰lschlicher Annahme von Befehlen vorsehen, die die Sicher- heit von Personen betreffen oder Sch‰den an Hardware oder Software hervorrufen kˆnnen.

EN ISO 14620-1:2002 (D)

e) Nutzlastbefehle, die zu katastrophalen oder kritischen Gef‰hrdungsfolgen f¸hren kˆnnen, m¸ssen vom Missionskontrollzentrum genehmigt und verifiziert werden.

8.2.5 ƒnderungskontrolle des Missionsbetriebs

Die ƒnderungskontrolle des Missionsbetriebs muss Folgendes sicherstellen:

a) Alle ƒnderungen, die im Verlauf der Mission gew¸nscht oder notwendig werden, sind auf ihre Sicherheits- auswirkung zu ¸berpr¸fen.

b) Die zust‰ndige Sicherheitszertifizierungsstelle muss alle gew¸nschten Betriebs‰nderungen mit Auswir- kung auf die Sicherheit genehmigen.

8.2.6 Sicherheits¸berwachung und Kontrolle von Anomalien

a) W‰hrend des Missionsbetriebs sind alle Produktparameter speziell zu beachten, die im Sicherheits- Reviewprozess als Sicherheitsstatusparameter identifiziert wurden.

b) Sicherheitsstatusparameter sind alle Parameter, die es ermˆglichen, den Status der implementierten Gef‰hrdungskontrollmaflnahmen zu bewerten.

8.3

Bodenbetrieb

8.3.1 Anwendbarkeit

Die folgenden Anforderungen gelten f¸r:

a)

Entwicklungs-, Qualifikations- und Abnahmetests;

b)

Montage-, Integrations- und Testabl‰ufe;

c)

Startplatzabl‰ufe;

d)

Servicing und Wiederstartklarmachen; sowie

e)

Transport- und Handhabungsvorg‰nge;

die:

1)

mˆglicherweise f¸r Personal oder Projekthardware gef‰hrdend sind; oder

2)

hohe Risiken f¸r das Programm bedeuten; oder

3)

besonders wertvolle oder kritische Testhardware, Einrichtungen oder Aufw‰nde betreffen.

8.3.2 Einleitung

Der Lieferant muss Verfahren zur Durchf¸hrung von Sicherheitsbereitschafts-Reviews und ñInspektionen vor Einsatzbeginn einf¸hren.

8.3.3 Reviews und Pr¸fungen

Diese Bereitschafts-Reviews und ñPr¸fungen m¸ssen ein Sicherheits-Review und eine Beurteilung der Einrichtungen, Ger‰te, Testmittel, Betriebs-, Test- und Stˆrfallvorschriften, Zugangskontrollen und Personal- eignung auf Konformit‰t mit den Sicherheitsanforderungen umfassen.

EN ISO 14620-1:2002 (D)

8.3.4 Gef‰hrdender Betrieb

Gef‰hrdender Betrieb ist auf ‹bereinstimmung mit den Sicherheitsanforderungen und ñvorschriften sowie auf die mˆgliche Entwicklung von unvorhergesehenen Gef‰hrdungssituationen zu ¸berwachen. Falls erforderlich, m¸ssen vor Einsatzbeginn Stˆrfall- und Notfallvorschriften eingef¸hrt und verifiziert werden. Das Sicherheits- personal muss befugt sein, alle Vorg‰nge zu stoppen, die nicht den Sicherheitsanforderungen entsprechen.

8.3.5 Start- und Landeplatzanforderungen

a) Start-, Lande-, Wiederstartklarmachen- und Missionsabl‰ufe m¸ssen einer Gef‰hrdungsanalyse unter- zogen werden.

b) F¸r den Bodenbetrieb ist Folgendes zu analysieren:

1)

potentielle Gef‰hrdungsfolgen von menschlichem Fehlverhalten und Verfahrensm‰ngeln;

2)

Angemessenheit und Erhaltung der Betriebsreserven;

3)

Mˆglichkeit, dass Menschen Gef‰hrdungen und Gef‰hrdungsauswirkungen ausgesetzt sein werden;

4)

Trainingsbedarf f¸r Betriebspersonal und Flugbesatzung;

5) Angemessenheit der von Flughardware, Bodendienstger‰ten oder Testeinrichtungen gelieferten Informationen und Daten zur Unterst¸tzung der Betriebsabwicklung entsprechend den geltenden Sicherheitsanforderungen.

8.3.6 Anforderungen an Bodendienstger‰te (Servicing-Ger‰te, Checkout- und Testger‰te, Hand- habungs- und Transportger‰te, Nabelverbindungen, Hilfsger‰te)

Die Bodendienstger‰te m¸ssen Designmerkmale zur Vermeidung von Gef‰hrdungsereignissen bei Ausfall oder Funktionsstˆrung der Einrichtung enthalten.

EN ISO 14620-1:2002 (D)

Literaturhinweise

[1]

EN 13701:2001, Raumfahrttechnik ó Glossar

[2]

The Oxford English Dictionary (Second edition)

[3]

NUREG-CR-2300-Volumn 1 1983, A guide to the performance of probabilistic risk assessments for nuclear power plants

[4]

IEC 60050:1992, Internationales Elektrotechnisches Wˆrterbuch

[5]

ISO/IEC Guide 2:1996, Standardization and related activities. General vocabulary

[6]

EN ISO 9000:2000, Qualit‰tsmanagementsysteme ó Grundlagen und Begriffe (ISO 9000:2000)

[7]

ISO/CD 14621-1, Space systems ó Electrical, electronic and electromechanical (EEE) parts ó Part 1: Part management 1)

[8]