Braunschweiger Verkehrskolloquium Heinrich-Büssing -Spezial Fahrerassistenzsysteme in rechtlicher und normativer Sicht

Größe: px
Ab Seite anzeigen:

Download "Braunschweiger Verkehrskolloquium Heinrich-Büssing -Spezial Fahrerassistenzsysteme in rechtlicher und normativer Sicht"

Transkript

1 Fahrerassistenzsysteme Technische Sicherheits- und Qualitätsanforderungen Braunschweiger Verkehrskolloquium Heinrich-Büssing -Spezial Fahrerassistenzsysteme in rechtlicher und normativer Sicht Technische Sicherheits- und Qualitätsanforderungen

2 Fahrerassistenzsysteme Technische Sicherheits- und Qualitätsanforderungen Normen zu Safety Aspekten von Elektronik Automotive Safety Integrity Level (ASIL) für Fahrerassistenzsysteme nach ISO DIS Das Spektrum der Sicherheitsanforderungen, z. B. Management, Work-Products, Tools, Feldverhalten Technische Sicherheitsanforderungen handhaben Selbstverständliche Qualitätsanforderungen, auch für Nicht- Sicherheitssysteme Zusammenfassung Assistenz-F2

3 Sicherheit Sicherheit: Freiheit von unvertretbaren Risiken (DIN EN : ; Abschnitt 3.5.2) Risiko = Häufigkeit eines Schadens x Schadenausmaß (in Anlehnung an DIN EN : ; Abschnitt 3.1.5) Sicherheit wird direkt als Qualitätsmerkmal angesehen oder als Teil der Zuverlässigkeit, die Qualitätsmerkmal ist Sicherheit hat im Englischen zwei Entsprechungen Safety (Rechtsanspruch) Security Funktionale Sicherheit ist der Teil der Gesamtsicherheit, der davon abhängig ist, dass ein System oder ein Betriebsmittel korrekte Antworten auf seine Eingangszustände liefert. (DIN EN Beiblatt 1: ; Abschnitt 3.1) Sicherheitsintegrität: Wahrscheinlichkeit, dass ein sicherheitsbezogenes System die geforderten Sicherheitsfunktionen unter allen festgelegten Bedingungen innerhalb eines festgelegten Zeitraumes anforderungsgemäß ausführt (DIN EN : ; Abschnitt 3.5.2) Sicherheitsintegrität = Zuverlässigkeit der Sicherheitsfunktion Qualität Zuverlässigkeit Security Sicherheit Safety Integrity Organizational Safety Safety Functional Safety Gerätesicherheit Assistenz-F3

4 Sicherheit bedeutet... Safety Schutz von Menschen Umwelt Anlagen vor negativen Auswirkungen der Technik Security Schutz der Information vor Zugriffen Diebstahl Manipulation Assistenz-F4

5 Stand der Technik IEC (7 Teile) Industrie übergreifend Sie ist die Mutter der folgenden anwendungsspezifischen Normen: IEC (3 Teile) Prozessindustrie wie Chemie, konventionelle Kraftwerke (z. B. Gasturbinen) IEC (1 Teil); ISO (2 Teile) Maschinen IEC 61513, IEC 62138, IEC Kerntechnik EN Elektrische Ausrüstung von Feuerungsanlagen DIN EN 50126, DIN EN 50128, DIN EN Eisenbahn ISO (ISO TC23 SC19, 4 Teile) Landwirtschaftliche Fahrzeuge ISO (ISO TC22 SC3, 10 Teile) Straßenfahrzeuge 1.5 anerkannte Regel der Technik technische Festlegung, die von einer Mehrheit repräsentativer Fachleute als Wiedergabe des Standes der Technik angesehen wird ANMERKUNG Ein normatives Dokument zu einem technischen Gegenstand wird zum Zeitpunkt seiner Annahme als der Ausdruck einer anerkannten Regel der Technik anzusehen sein, wenn es in Zusammenarbeit der betroffenen Interessen durch Umfrage- und Konsensverfahren erzielt wurde. Aus DIN EN 45020:2006 DIN EN Assistenz-F5

6 Sicherheitsstandards und Software Die Botschaft der Sicherheitsstandards Engineering statt Basteln! Assistenz-F6

7 Anliegen der Sicherheitsstandards Zur Vollständigkeit, Verständlichkeit und Realisierbarkeit der Aufgabe beitragen (Top Down Strukturierung, Review der Anforderungsspezifikation) Fehler im Design und Development vermeiden (Engineering, insbesondere SW Engineering) Trotzdem aufgetretene Fehler entdecken (Verifikation und Validierung (V&V), Assessment) Gefährliches kaputt gehen von Bauelementen in Grenzen halten (Bauelemente-Auswahl, Selbstüberwachung, Redundanz) Vorkehrungen treffen, um im Design und Development gemachte Fehler, die nicht entdeckt wurden, zu beherrschen (Selbstüberwachung, Diversität) Gute Prozesse etablieren bei Produzenten und Benutzern (Management Prozesse, Schnittstellenvereinbarungen) Assistenz-F7

8 Fahrerassistenzsysteme Technische Sicherheits- und Qualitätsanforderungen Normen zu Safety Aspekten von Elektronik Automotive Safety Integrity Level (ASIL) für Fahrerassistenzsysteme nach ISO DIS Das Spektrum der Sicherheitsanforderungen, z. B. Management, Work- Products, Tools, Feldverhalten Technische Sicherheitsanforderungen handhaben Selbstverständliche Qualitätsanforderungen, auch für Nicht- Sicherheitssysteme Zusammenfassung Assistenz-F8

9 Die ISO Übersicht Titel der ISO ist Road vehicles Functional Safety. Die Norm hat zehn Teile. Der jetzt vorliegende Draft International Standard (DIS) erschien im Juli Der Standard ist für die Anwendung auf sicherheitsrelevante elektrische/elektronische Systeme (E/E-Systeme) in serienproduzierten Personenkraftfahrzeugen mit einem Gesamtgewicht von bis zu kg vorgesehen. Assistenz-F9

10 Die Teile der ISO Teil 1 enthält die Definitionen der Begriffe Teil 2 enthält die Vorgaben für die Arbeit des Managements Teil 3 befasst sich mit der Konzeptphase Teil 4 enthält die Vorgaben an das integrale E/E System (Hardware- / Software System) Teil 5 ist der Hardware Teil Teil 6 ist der Software Teil Teil 7 befasst sich mit den Anforderrungen an Produktion und Betrieb Teil 8 enthält die Vorgaben an die unterstützenden Prozesse Teil 9 befasst sich mit Analysen zum ASIL und zur Sicherheit Teil 10 ist informativ, enthält also keine normativen Vorgaben für die praktische Anwendung wegen der übergeordneten Gesichtspunkte hilfreich Assistenz-F10

11 1. Vocabulary 2. Management of functional safety 2-5 Overall Safety Management 2-6 Safety management during item development 2-7 Safety management after release for production 3. Concept phase 3-5 Item definition 3-6 Initiation of the safety lifecycle 3-7 Hazard analysis and risk assessment 3-8 Functional safety concept 4-5 Initiation of product development at the system level 4-6 Specification of the Technical safety requirements 4. Product development: System level 4-7 System design 4-8 Item Integration and Testing 5. Hardware level 5-5 Initiation of product development at the HW level 5-6 Specification of HW safety requirements 5-7 HW design 5-8 HW architectural metrics 5-9 Evaluation of violation of the safety goal due to random HW failures 5-10 HW integration and testing 4-11 Release for Production 4-10 Functional Safety Assessment 4-9 Safety Validation 6. Software level 6-5 Initiation of product development at the SW level 6-6 Specification of SW safety requirements 6-7 SW architectural design 6-8 SW unit design and implementation 6-9 SW unit testing 6-10 SW Integration and testing 6-11 Verification of SW Safety requirements 7. Production and Operation 7-5 Production 7-6 Operation, service (maintenance and repair) and decommissioning Core Processes 8-5 Interfaces within distributed developments 8-6 Specification and management of safety requirements 8-7 Configuration management 8-8 Change management 8-9 Verification 8. Supporting Processes 8-10 Documentation 8-11 Qualification of software tools 8-12 Qualification of software components 8-13 Qualification of hardware components 8-14 Proven in use argument 9-5 Requirements decomposition with respect to ASIL tailoring 9-6 Criteria for coexistence of elements 9. ASIL-oriented and safety-oriented analysis 9-7 Analysis of dependent failures 9-8 Safety analyses 10. Guideline on ISO (Informative)

12 ISO DIS Functional safety Functional safety requirement specification Part 3 Figure 3 - Hierarchy of safety goals and functional safety requirements 3-7 Results of hazard analysis and risk assessment 3-7 Safety goal A ASIL 3-7 Safety goal B ASIL Safety goal n ASIL 3-8 Functional safety requirement Assigned ASIL Allocated to subsystem 3-8 Functional safety requirement Assigned ASIL Allocated to subsystem 3-8 Functional safety requirement Assigned ASIL Allocated to subsystem Assistenz-F12

13 Defekt Ausfall (en: failure; random HW failure) inhärenter Fehler (en: fault) Spezifikationsfehler Missbrauch (en: misuse) Gefährdungsanalyse und Risikobeurteilung nicht gefährdend Versagen (en: failure; systematic failure) CCF (ISO ; 1.14) Controllability (ISO ; ) Gefährdung (en: hazard) potentielle Schadensquelle (IEC ; 3.1.2) Safety Analyses (ISO , 8) Schaden (en: harm) (IEC ; 3.1.1) Hazard Analyses (ISO , 7) Benutzungsweise des Steuergerätes Gefährlicher Vorfall (en: hazardous event) (IEC ; 3.1.4) Benutzungsweise des Fahrzeugs * sich in Sicherheit bringen; fliehen Risk Assessment (ISO ,???) Risiko (IEC ; 3.1.6) Schadenshäufigkeit (en: Probability of occurrence of harm) Schadensausmaß (en: Severity of harm) Sicherheit (en: safety) Freiheit von unvertretbaren Risiken (IEC ; ) Der Gefahr entgehen* Risikozumutung Gefahr (en: danger) Sachlage, bei der das Risiko größer als das Grenzrisiko ist. (VDI/VDE 3542 Blatt 4)

14 ASIL Determination

15 Fahrerassistenzsysteme Technische Sicherheits- und Qualitätsanforderungen Lieferantenabstimmung über die ASILs verschiedener Assistenzsysteme (Veröffentlichung angekündigt bei Euroforum, Elektronik-Systeme im Automobil, Vortragsreihe Sichere Automobilelektronik, München ; die Veröffentlichung ist bisher nicht erfolgt ) OEM-Abstimmung über die ASILs verschiedener Assistenzsysteme Beide Abstimmungen kommen zu ähnlichen Ergebnissen Assistenz-F15

16 Konservativ Entscheiden Sicherheitstechnische Entscheidungsleitlinie In Zweifelsfällen müssen sicherheitstechnische Entscheidungen konservativ erfolgen, d. h. die (sicherheits-) technisch höherwertige Variante wird gewählt. Wenn kaufmännische oder terminorientierte Entscheidungen kurzfristig angelegt sind, widersprechen sie häufig den sicherheitstechnisch notwendigen Entscheidungen. Assistenz-F16

17 Fahrerassistenzsysteme Technische Sicherheits- und Qualitätsanforderungen Normen zu Safety Aspekten von Elektronik Automotive Safety Integrity Level (ASIL) für Fahrerassistenzsysteme nach ISO DIS Das Spektrum der Sicherheitsanforderungen, z. B. Management, Work-Products, Tools, Feldverhalten Technische Sicherheitsanforderungen handhaben Selbstverständliche Qualitätsanforderungen, auch für Nicht- Sicherheitssysteme Zusammenfassung Assistenz-F17

18 Ist die ISO ausschließlich Sache der Elektroniker und Softwerker? Weil der Standard IS maßgeblich nicht nur nebenbei das Management adressiert ist das Management von diesem Standard betroffen (hauptsächlich Band 2) Weil die Aufgabenstellung für die Elektronik kein Selbstzweck ist sondern aus dem Fahrzeugkonzept resultiert sind die Fahrzeugfachleute von der ISO betroffen (hauptsächlich Band 3 und 4) Weil die Elektronik nicht nur den Elektronikern genügen soll, sind für das Akzeptieren der Elektronik auch die Fahrzeugfachleute erforderlich (hauptsächlich Band 4) Weil das Beurteilen der Gefährdung, die bei einer Fehlfunktion der Elektronik entsteht, Fahrzeug Sachverstand erfordert, sind von der ISO auch die Fahrzeugfachleute betroffen (hauptsächlich Band 3 und Band 9) Weil die Produktion nicht von Elektronik- oder Software Entwicklern erfolgt, ist auch die Produktion von der ISO betroffen (hauptsächlich Band 7) Assistenz-F18

19 Work Products nach ISO ISO nennt ca. 160 unterschiedliche Informationen; Beispiele Application manual Assessment report for capability of the production process Baseline for HW Baseline for SW Calibration data spec Change management plan Change report Change request Change request plan Code: Source Coding guideline Configuration data Configuration management plan Confirmation plan SW tool classification analysis SW tool documentation SW tool qualification plan SW tool qualification report System architecture System architecture assessment report on coping with the HW random failures System design spec System level integration and testing plan System requirements Assistenz-F19

20 Notwendigkeit / Bedarf Tool Qualifizierung Das für den ISO FDIS, Teil 8, Erwartete Den Tool Impact (TI) feststellen, das ist the possibility that a malfunction of a particular software tool can introduce or fail to detect errors in a safety-related item or element being developed. Die Tool error Detection (TD) feststellen, das ist the confidence in measures that prevent the software tool from malfunctioning and producing corresponding erroneous output, or in measures that detect that the software tool has malfunctioned and has produced corresponding erroneous output. Aus Tool Impact (TI) und Tool error Detection (TD) gemäß folgender Tabelle den notwendigen Tool Confidence Level (TCL) ermitteln: TD1 TD2 TD3 TI1 TCL1 TCL1 TCL1 TI2 TCL1 TCL2 TCL3 Assistenz-F20

21 Feldverhalten; Beispiel für Anforderungen in und 61508

22 Fahrerassistenzsysteme Technische Sicherheits- und Qualitätsanforderungen Normen zu Safety Aspekten von Elektronik Automotive Safety Integrity Level (ASIL) für Fahrerassistenzsysteme nach ISO DIS Das Spektrum der Sicherheitsanforderungen, z. B. Management, Work- Products, Tools, Feldverhalten Technische Sicherheitsanforderungen handhaben Selbstverständliche Qualitätsanforderungen, auch für Nicht- Sicherheitssysteme Zusammenfassung Assistenz-F22

23 Vorgaben in Sicherheitsstandards Mengengerüst ISO 26262: 2009 [ASIL D] IEC 61508: [SIL 3] Teil Vorgaben Teil Vorgaben Teil Vorgaben 1./. 4./. 4./ IEC 61508: 2010 [SIL 3] Summe Assistenz-F23

24 Vorgaben in Software-Sicherheitsstandards Mengengerüst Standard Anzahl Gezählt mit Vorgaben IEC 61508, Teil 3, Ausgabe RiskCAT 61508, V5.9f IEC 61508, Teil 3, Ausgabe RiskCAT 61508, V6.2a ISO DIS 26262, Teil 6 (PKW) 291 RiskCAT 26262, V6.1a DIN EN (Bahn) 488 RiskCAT 50128, V6.1f IEC (Nuklear) 842 RiskCAT 60880, V5.9f Gezählt sind Mandatory und Highly Recommended Prescriptions Assistenz-F24

25 Vorschlag für die Arbeit mit Standards Für alle Arbeiten Vor Beginn der Arbeiten einen Überblick über den zur Diskussion stehenden Standard verschaffen, so wie es z. B. in Fachgesprächen oder Seminaren geschieht. Die für den anstehenden Arbeitsschritt relevanten Vorgaben aus dem Standard auswählen oder sich vergewissern, dass die Standards für den Arbeitsschritt keine Anleitung bieten. Das kann bei der aktuellen IEC z. B. für Hardwareaspekte der Fall sein. Von den ausgewählten Vorgaben eine Checkliste generieren oder sie ins Requirements Management aufnehmen. Werden für den anstehenden Arbeitsschritt relevante Vorgaben übergangen, die Motivation für das Übergehen notieren. Entwicklung von Produkten und Befähigung durch Prozesse Die ausgewählten Vorgaben bei der Entwicklung von Produkten und Bereitstellung von Prozessen berücksichtigen Verifikation & Validierung, QM, Beurteilung Das Erfüllen der ausgewählten Vorgaben in der Checkliste bzw. im Requirements Management notieren. Das erfüllende Work Product (mit einem Satz) referenzieren Die Übereinstimmung mit jeder Vorgabe, den Themen und der Norm insgesamt bewerten

26 Ablauf bei der Arbeit mit Standards Aufgabenstellung Entwicklung Prozess/Produkt Work Products V&V Ergebnisse bewerten Vorgaben filtern Verifikationsplan Validationsplan V & V V&V Ergebnisse Überprüfungsplan Handlungsanleitung Vorgaben filtern QS Plan Überprüfungsergebnisse Hersteller Überprüfer Qualitätssicherung Überprüfung QS Ergebnisse QS Ergebnisse bewerten Überprüferg. bewerten Assistenz-F26

27 Ablauf bei der Arbeit mit Standards Aufgabenstellung Entwicklung Prozess/Produkt Work Products V&V Ergebnisse bewerten Verifikationsplan Validationsplan V & V V&V Ergebnisse Vorgaben filtern RiskCAT QS Plan Qualitätssicherung QS Ergebnisse QS Ergebnisse bewerten Überprüfungsergebnisse Überprüfungsplan Überprüfung Überprüferg. bewerten Assistenz-F27

28 Funktionen und Aufbau von RiskCAT 1. Festlegen der erforderlichen Zuverlässigkeit / Sicherheit 2. Information über die Vorgaben 3. Auswählen von Vorgaben 4. Vergleichen von Vorgaben 5. Export der ausgewählten Vorgaben 6. Unterstützung, z. B. Begriffe nachschlagen RiskCAT Datenbank RiskCAT Programm z. B. zur IEC 61508, ISO 13849, ISO Projekt speichern / zurückladen Ausgewählte Vorgaben Rich text format für das Einbinden in Kundendokumente Schnittstellen zu Artisan Studio CaliberRM DOORS QualiCAT Assistenz-F28

29 Standard Vorgaben importiert in der UML / SysML Enzwicklungsumgebung Artisan Studio

30 Standard Vorgaben importiert im Requirements Management Tool Doors

31 Unterschiede in den Anforderungen bei verschiedenen ASILs Anzahl der Anforderungen Verbindlichkeitsgrad Erfüllungsschärfe Assistenz-F31

32 Ablauf bei der Arbeit mit Standards Aufgabenstellung Entwicklung Prozess/Produkt Work Products Vorgaben filtern Handlungsanleitung Verifikationsplan Validationsplan QS Plan Prüfung (V & V) Qualitätssicherung V&V Ergebnisse QS Ergebnisse Ergebnisse bewerten QualiCAT Vorgaben filtern Überprüfungsergebnisse Überprüfungsplan Überprüfung Assistenz-F32

33 Bewerten der erreichten Übereinstimmung

34 Bewerten der erreichten Übereinstimmung

35 Fahrerassistenzsysteme Technische Sicherheits- und Qualitätsanforderungen Normen zu Safety Aspekten von Elektronik Automotive Safety Integrity Level (ASIL) für Fahrerassistenzsysteme nach ISO DIS Das Spektrum der Sicherheitsanforderungen, z. B. Management, Work- Products, Tools, Feldverhalten Technische Sicherheitsanforderungen handhaben Selbstverständliche Qualitätsanforderungen, auch für Nicht- Sicherheitssysteme Zusammenfassung Assistenz-F35

36 Sicherheits-Standards Sicherheits-Standards wie die IEC oder IEC dürfen nur Sicherheits-Aspekte festlegen. Sie dürfen das einfach nur dem Stand der Technik Entsprechende (Software-) Engineering nicht beschreiben. Dann und wann schreiben Arbeitsgruppen ihnen besonders wichtige allgemeine Dinge trotzdem in Sicherheits-Standards. Damit das ISO oder IEC Sekretariat das dann nicht streicht Ein dem Stand der Technik entsprechendes (Software-) Engineering wird selbstverständlich und deshalb meist auch unerwähnt vorausgesetzt. Nach dem Stand der Technik Übliches zu unterlassen nur weil es im Sicherheits-Standard nicht explizit benannt ist ist unzulässig. Im folgenden Abschnitt daher ein Ausflug zu Selbstverständlichkeiten Assistenz-F36

37 Fahrerassistenzsysteme Selbstverständlichkeiten Keep it simple Erlernbares Verhalten Durchschaubares Verhalten Konsistentes Verhalten Assistenz-F37

38 ISO/IEC JTC1/SC7

39 Functional Safety Management eine Anleitung zur Umsetzung VDI/VDE

40 Functional Safety Management eine weitere Anleitung zur Umsetzung Beschreibung des Zwecks des Zuverlässigkeitsprogramms im Handout VDI 4003

41 Functional Safety Management eine weitere Anleitung zur Umsetzung MIL 882

42 Fahrerassistenzsysteme Technische Sicherheits- und Qualitätsanforderungen Normen zu Safety Aspekten von Elektronik Automotive Safety Integrity Level (ASIL) für Fahrerassistenzsysteme nach ISO DIS Das Spektrum der Sicherheitsanforderungen, z. B. Management, Work- Products, Tools, Feldverhalten Technische Sicherheitsanforderungen handhaben Selbstverständliche Qualitätsanforderungen, auch für Nicht- Sicherheitssysteme Zusammenfassung Assistenz-F42

43 Zusammenfassung aus England The right process, tools and people (qualified/trained) will turn out embedded systems faster and more reliably (better tested) than the low cost ad-hoc systems used now. Doing it properly is not expensive. It just requires discipline. (Aus einer von Chris Hills, Phaedrus Systems Ltd, vom 17. September 2008) Using the techniques commonly associated with safety critical and high reliability embedded development you can get reliable embedded systems to market on time and on budget at a lower cost than the usual low cost ad-hoc systems currently used. (Chris Hills, Phaedrus Systems Ltd, in der Ankündigung einer Roadshow vom 17. September 2008) Assistenz-F43

Aktuelle Herausforderungen der Automobil-Industrie beim Rollout der ISO 26262. Polarion Live User Conference 2013 Heiko Lerch, ITK Engineering AG

Aktuelle Herausforderungen der Automobil-Industrie beim Rollout der ISO 26262. Polarion Live User Conference 2013 Heiko Lerch, ITK Engineering AG Aktuelle Herausforderungen der Automobil-Industrie beim Rollout der ISO 26262 Polarion Live User Conference 2013 Heiko Lerch, ITK Engineering AG Auf einen Blick Expandierend Gründung: 1994 Zertifiziert

Mehr

Abbildung 1: Tool-Qualification-Kits für Testwell CTC++ Test Coverage Analyser

Abbildung 1: Tool-Qualification-Kits für Testwell CTC++ Test Coverage Analyser Qualification-Kit für Testwell CTC++ In der sicherheitskritischen Softwareentwicklung müssen die im Projekt eingesetzten Werkzeuge zunächst klassifiziert werden (Tool Classification). Diese Klassifizierung

Mehr

Entwicklung Safety-relevanter Steuergeräte auf Basis des V-Modells

Entwicklung Safety-relevanter Steuergeräte auf Basis des V-Modells AUTOMOTIVE INFOKOM MOBILITÄT, ENERGIE & UMWELT LUFTFAHRT RAUMFAHRT VERTEIDIGUNG & SICHERHEIT Entwicklung Safety-relevanter Steuergeräte auf Basis des V-Modells Stephen Norton VMEA 12.11.2015 CoC SAFETY

Mehr

Funktionale Sicherheit ISO 26262 Schwerpunkt Requirements Engineering,

Funktionale Sicherheit ISO 26262 Schwerpunkt Requirements Engineering, Funktionale Sicherheit ISO 26262 Schwerpunkt Requirements Engineering, Manfred Broy Lehrstuhl für Software & Systems Engineering Technische Universität München Institut für Informatik ISO 26262 Functional

Mehr

Anlage zur Akkreditierungsurkunde D ZE 12007 01 06

Anlage zur Akkreditierungsurkunde D ZE 12007 01 06 Deutsche Akkreditierungsstelle GmbH Anlage zur Akkreditierungsurkunde D ZE 12007 01 06 nach DIN EN ISO/IEC 17065:2013 Gültigkeitsdauer: 06.05.2014 bis 05.05.2019 Ausstellungsdatum: 06.05.2014 Urkundeninhaber:

Mehr

Auswirkungen der ISO 26262 auf die Strukturen von Requirements- und Test- Datenbanken während der Entwicklung

Auswirkungen der ISO 26262 auf die Strukturen von Requirements- und Test- Datenbanken während der Entwicklung Auswirkungen der ISO 26262 auf die Strukturen von Requirements- und Test- Datenbanken während der Entwicklung Vorschlag zum Aufbau einer Datenbank, anhand ausgewählter Work Products in der Konzeptphase

Mehr

Validierung von Software-Werkzeugen. Matthias Hölzer-Klüpfel

Validierung von Software-Werkzeugen. Matthias Hölzer-Klüpfel Validierung von Software-Werkzeugen Matthias Hölzer-Klüpfel Was ist Validierung ISO 9000:2000 Bestätigung durch Bereitstellung eines objektiven Nachweises, dass die Anforderungen für einen spezifischen

Mehr

Security for Safety in der Industrieautomation Konzepte und Lösungsansätze des IEC 62443

Security for Safety in der Industrieautomation Konzepte und Lösungsansätze des IEC 62443 Security for Safety in der Industrieautomation Konzepte und Lösungsansätze des IEC 62443 Roadshow INDUSTRIAL IT SECURITY Dr. Thomas Störtkuhl 18. Juni 2013 Folie 1 Agenda Einführung: Standard IEC 62443

Mehr

Safer Software Formale Methoden für ISO26262

Safer Software Formale Methoden für ISO26262 Safer Software Formale Methoden für ISO26262 Dr. Stefan Gulan COC Systems Engineering Functional Safety Entwicklung Was Wie Wie genau Anforderungen Design Produkt Seite 3 Entwicklung nach ISO26262 Funktionale

Mehr

Fred Stay 2013-06-04/05. Management der Funktionalen Sicherheit KROHNE Academy Automatisierungstechnik in der Prozessindustrie

Fred Stay 2013-06-04/05. Management der Funktionalen Sicherheit KROHNE Academy Automatisierungstechnik in der Prozessindustrie Fred Stay 2013-06-04/05 Management der Funktionalen Sicherheit KROHNE Academy Automatisierungstechnik in der Prozessindustrie 1. Warum brauchen wir ein FSM 2. Vermeidung/Beherrschung von Fehlern 3. Praxisbeispiel:

Mehr

Prozessanforderungen bei der Entwicklung von sicherheitsrelevanten Funktionen. Tina Heimer, Carmeq GmbH

Prozessanforderungen bei der Entwicklung von sicherheitsrelevanten Funktionen. Tina Heimer, Carmeq GmbH Prozessanforderungen bei der Entwicklung von sicherheitsrelevanten Funktionen Tina Heimer, Carmeq GmbH Carmeq GmbH Carmeq konzipiert, entwickelt und integriert softwarebestimmte Systeme für die Automobilindustrie.

Mehr

Funktionale Sicherheit Testing unter

Funktionale Sicherheit Testing unter Funktionale Sicherheit Testing unter den Bedingungen der Safety Integrity Levels Präsentation auf dem Neu-Ulmer Test-Engineering Day Sebastian Stiemke, MissingLinkElectronics, Neu-Ulm 1 Inhalt Idee hinter

Mehr

Werkzeugunterstützung der Prüfung sicherheitsgerichteter. SW auf Normenkonformität

Werkzeugunterstützung der Prüfung sicherheitsgerichteter. SW auf Normenkonformität Echtzeit 2013 - Funktionale Sicherheit Werkzeugunterstützung der Prüfung sicherheitsgerichteter Software auf Normenkonformität Echtzeit2013-F1 Werkzeugunterstützung der Prüfung sicherheitsgerichteter SW

Mehr

Darstellung und Anwendung der Assessmentergebnisse

Darstellung und Anwendung der Assessmentergebnisse Process flow Remarks Role Documents, data, tool input, output Important: Involve as many PZU as possible PZO Start Use appropriate templates for the process documentation Define purpose and scope Define

Mehr

Funktionale Sicherheit in Automotive und Luftfahrt (ISO26262 und DO 178BC) Otto Alber, Peter Wittmann 09.10.2013

Funktionale Sicherheit in Automotive und Luftfahrt (ISO26262 und DO 178BC) Otto Alber, Peter Wittmann 09.10.2013 Funktionale Sicherheit in Automotive und Luftfahrt (ISO26262 und DO 178BC) Otto Alber, Peter Wittmann 09.10.2013 Einleitung Modell-basierte Entwicklung bei Silver Atena Erfahrung mit Modell-basierter Entwicklung

Mehr

Normerfüllung in der Praxis am Beispiel "Tool Qualification" Dr. Anne Kramer, sepp.med gmbh

Normerfüllung in der Praxis am Beispiel Tool Qualification Dr. Anne Kramer, sepp.med gmbh Normerfüllung in der Praxis am Beispiel "Tool Qualification" Dr. Anne Kramer, sepp.med gmbh Über uns Mittelständischer IT-Service Provider 30 Jahre Industrieerfahrung Unsere Referenzen Medizintechnik Pharma

Mehr

How to Survive an Audit with Real-Time Traceability and Gap Analysis. Martin Kochloefl, Software Solutions Consultant Seapine Software

How to Survive an Audit with Real-Time Traceability and Gap Analysis. Martin Kochloefl, Software Solutions Consultant Seapine Software How to Survive an Audit with Real-Time Traceability and Gap Analysis Martin Kochloefl, Software Solutions Consultant Seapine Software Agenda Was ist Traceability? Wo wird Traceability verwendet? Warum

Mehr

Einführung in die ISO 26262

Einführung in die ISO 26262 Einführung in die ISO 26262 Herausforderungen für das Management von Verifikations- und Validationsdaten Dr. Ralf Nörenberg HighQSoft GmbH 19.08.2012 HighQSoft GmbH www.highqsoft.de Einführung in die ISO

Mehr

Funktionale Sicherheit und Cyber Security

Funktionale Sicherheit und Cyber Security Funktionale Sicherheit und Cyber Security Unterschiede, Schnittstellen und Lösungen V0.05 2015-10-20 Agenda Keine Funktionale Sicherheit ohne Cyber Security Prozesse und Methoden Safety Mechanismen Security

Mehr

Modellbasierter Entwurf sicherheitskritischer Anwendungen. Von Moritz Borgmann Für VL Eingebettete Systeme Sommer Semester 2009

Modellbasierter Entwurf sicherheitskritischer Anwendungen. Von Moritz Borgmann Für VL Eingebettete Systeme Sommer Semester 2009 Modellbasierter Entwurf sicherheitskritischer Anwendungen Von Moritz Borgmann Für VL Eingebettete Systeme Sommer Semester 2009 Einführung Einführung Modellbasierter Entwurf und der IEC 61508 Ausblick Zusammenfassung,

Mehr

TFS als ALM Software. Erfahrungsbericht aus der MedTec Ecke. Lukas Müller

TFS als ALM Software. Erfahrungsbericht aus der MedTec Ecke. Lukas Müller TFS als ALM Software Erfahrungsbericht aus der MedTec Ecke Lukas Müller Agenda Tecan Umfeld und Prozesse Einsatzgebiet TFS Tecan Erweiterungen von TFS Erfahrungsaustausch Head Office in der Schweiz, >1100

Mehr

Qualitätssicherung von Software (SWQS)

Qualitätssicherung von Software (SWQS) Qualitätssicherung von Software (SWQS) Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FOKUS 20.6.2013: Sicherheitsnormen Folie 2 Fragen zur Wiederholung Wie funktioniert ein

Mehr

ISO EN DIN 61508. Referenzen

ISO EN DIN 61508. Referenzen ISO EN DIN 61508 Referenzen P. Löw, R. Pabst, E. Petry: FunkConale Sicherheit in der Praxis: Anwendung von DIN EN 61508 und ISO/DIS 26262 bei der Entwicklung von Serienprodukten, dpunkt Verlag, 1. Auflage,

Mehr

ALM Days 2012. Normenkonforme Software-Entwicklung für Medizinprodukte mit dem Microsoft Team Foundation Server

ALM Days 2012. Normenkonforme Software-Entwicklung für Medizinprodukte mit dem Microsoft Team Foundation Server ALM Days 2012 ALM Days 2012 Normenkonforme Software-Entwicklung für Medizinprodukte mit dem Microsoft Team Foundation Server Dipl.- Ing. Birgit Stehlik, Dipl.-Ing. Sven Wittorf, M.Sc. 1 Medizinische Software

Mehr

ABSICHERUNG MODELLBASIERTER SICHERHEITSKRITISCHER AVIONIK SOFTWARE Dr. Elke Salecker

ABSICHERUNG MODELLBASIERTER SICHERHEITSKRITISCHER AVIONIK SOFTWARE Dr. Elke Salecker ABSICHERUNG MODELLBASIERTER SICHERHEITSKRITISCHER AVIONIK SOFTWARE Dr. Elke Salecker MOTIVATION Fahrzeug-Software wird modellbasiert mit Simulink/TargetLink entwickelt & DO331/DO-178C ermöglicht modellbasierte

Mehr

ISO 15504 Reference Model

ISO 15504 Reference Model Process flow Remarks Role Documents, data, tools input, output Start Define purpose and scope Define process overview Define process details Define roles no Define metrics Pre-review Review yes Release

Mehr

Risk-Managements for Installation, Maintenance and Reprocessing of Medical Devices

Risk-Managements for Installation, Maintenance and Reprocessing of Medical Devices Risk-Managements for Installation, Maintenance and Reprocessing of Medical Devices Laws, Guidelines and Standards Medizinproduktegesetz (MPG) Medizinprodukte-Betreiberverordnung (MBetreibV) Sicherheitsplanverordnung

Mehr

Herausforderung Funktionale Sicherheit Summer School: Trends und Impulse in der Elektromobilität. Dr. Jochen Hagel MBtech Group GmbH & Co.

Herausforderung Funktionale Sicherheit Summer School: Trends und Impulse in der Elektromobilität. Dr. Jochen Hagel MBtech Group GmbH & Co. Herausforderung Funktionale Sicherheit Summer School: Trends und Impulse in der Elektromobilität Dr. Jochen Hagel MBtech Group GmbH & Co. KGaA Inhalt Warum ist Funktionale Sicherheit zur Zeit in aller

Mehr

Speziell angepasste Gefahrenanalyse / Risikobewertung für die Automobilindustrie nach ISO DIS 26262-3 Gudrun Neumann, SGS Germany GmbH

Speziell angepasste Gefahrenanalyse / Risikobewertung für die Automobilindustrie nach ISO DIS 26262-3 Gudrun Neumann, SGS Germany GmbH Speziell angepasste Gefahrenanalyse / Risikobewertung für die Automobilindustrie nach ISO DIS 26262-3 Gudrun Neumann, SGS Germany GmbH Stand: 22/06/2010 1 Vorstellung SGS Daten & Fakten SGS - Société Générale

Mehr

Übersicht. Normung von Software in der Medizin. Vorstellung der DKE. Vorstellung der Normungsgremien. Normen im Bereich Software.

Übersicht. Normung von Software in der Medizin. Vorstellung der DKE. Vorstellung der Normungsgremien. Normen im Bereich Software. Normung von Software in der Medizin Übersicht Vorstellung der DKE Vorstellung der Normungsgremien Normen im Bereich Software Zukunftstrends 20.09.2013/1 Vorstellung der DKE Gemeinnütziger Verband ohne

Mehr

Modellbasierte Software- Entwicklung eingebetteter Systeme

Modellbasierte Software- Entwicklung eingebetteter Systeme Modellbasierte Software- Entwicklung eingebetteter Systeme Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität und Fraunhofer Institut für offene Kommunikationssysteme FOKUS Folie

Mehr

ISO 15504 Reference Model

ISO 15504 Reference Model Prozess Dimension von SPICE/ISO 15504 Process flow Remarks Role Documents, data, tools input, output Start Define purpose and scope Define process overview Define process details Define roles no Define

Mehr

Keynote Der offene Ansatz: Open Source basiertes ALM ganz praktisch

Keynote Der offene Ansatz: Open Source basiertes ALM ganz praktisch Keynote ALMconf 2010 in Stuttgart 26. bis 28. Oktober 2010 Thomas Obermüller elego Software Solutions GmbH - 2010 1 Welcome & Outline Open Source basiertes ALM ganz praktisch Agenda Application Lifecycle

Mehr

SPiCE und Test: Was hat das denn miteinander zu tun?

SPiCE und Test: Was hat das denn miteinander zu tun? SPiCE und Test: Was hat das denn miteinander zu tun? TAV Düsseldorf 15./16.2.2007 Arbeitskreis Test eingebetteter Systeme Dr. Uwe Hehn Uwe.Hehn@methodpark.de Gliederung Reifegradmodelle Übersicht über

Mehr

Implementierung von IEC 61508

Implementierung von IEC 61508 Implementierung von IEC 61508 1 Qualität & Informatik -www.itq.ch Ziele Verständnis für eine mögliche Vorgehensweise mit IEC 61508 schaffen Bewusstes Erkennen und Behandeln bon Opportunitäten unmittelbaren

Mehr

Sicherheit / Sicherung - unterschiedliche Begriffsbestimmung, gemeinsame Fachaspekte

Sicherheit / Sicherung - unterschiedliche Begriffsbestimmung, gemeinsame Fachaspekte Sicherheit / Sicherung - unterschiedliche Begriffsbestimmung, gemeinsame Fachaspekte F. Seidel, BfS Salzgitter (Juli 2002) 1) Begriffsbestimmung (Vergleich unter Nutzung nationaler und internationaler

Mehr

Prüftechnische Umsetzung der Anforderungen zur Validierung von sicherheitsrelevanter Automobilelektronik

Prüftechnische Umsetzung der Anforderungen zur Validierung von sicherheitsrelevanter Automobilelektronik Prüftechnische Umsetzung der Anforderungen zur Validierung von sicherheitsrelevanter Automobilelektronik Referent Klaus Nicolai Volkswagen AG Business Unit Braunschweig Gliederung Funktionale Sicherheit

Mehr

Von Requirements zutests. gç~åüáãkpåüìäò]èì~äáíóé~êâkçé

Von Requirements zutests. gç~åüáãkpåüìäò]èì~äáíóé~êâkçé Von Requirements zus gç~åüáãkpåüìäò]èì~äáíóé~êâkçé QualityPark Ihr Partner im Lifecycle Management Process Management Requirements Engineering IT & Development Process Expertise Process Implementation

Mehr

Dokumentation (ISO 26514) Prof. Sissi Closs Donnerstag,, 5. November 2009

Dokumentation (ISO 26514) Prof. Sissi Closs Donnerstag,, 5. November 2009 Der neue ISO-Standard Standard für f r Software- Dokumentation (ISO 26514) Prof. Sissi Closs Donnerstag,, 5. November 2009 ISO/IEC 26514 Software and systems engineering User documentation requirements

Mehr

Automotive SPiCE und IEC 61508 Synergie oder Widerspruch?

Automotive SPiCE und IEC 61508 Synergie oder Widerspruch? Safety Competence Center Vienna Automotive SPiCE und IEC 61508 Synergie oder Widerspruch? Pierre Metz, Gabriele Schedl copyright SYNSPACE, SCC fh campus wien All rights reserved Problemfelder Produktsicherheit

Mehr

Sicherheit und Qualität digitaler Leittechnik eine wesentliche Voraussetzung für Kraftwerke der Zukunft

Sicherheit und Qualität digitaler Leittechnik eine wesentliche Voraussetzung für Kraftwerke der Zukunft Sicherheit und Qualität digitaler Leittechnik eine wesentliche Voraussetzung für Kraftwerke der Zukunft Dr. Guido Rettig Chairman of the Board TÜV NORD AG 1 Vertikale und horizontale Kommunikation in der

Mehr

Definitionen von Begriffen im Kontext Sicherheit (safety)

Definitionen von Begriffen im Kontext Sicherheit (safety) Definitionen von Begriffen im Kontext Sicherheit (safety) Udo Voges Forschungszentrum Karlsruhe Institut für Angewandte Informatik Postfach 3640 76021 Karlsruhe Tel. +49-(0)7247-82-5725 email: voges@iai.fzk.de

Mehr

DIGICOMP OPEN TUESDAY AKTUELLE STANDARDS UND TRENDS IN DER AGILEN SOFTWARE ENTWICKLUNG. Michael Palotas 7. April 2015 1 GRIDFUSION

DIGICOMP OPEN TUESDAY AKTUELLE STANDARDS UND TRENDS IN DER AGILEN SOFTWARE ENTWICKLUNG. Michael Palotas 7. April 2015 1 GRIDFUSION DIGICOMP OPEN TUESDAY AKTUELLE STANDARDS UND TRENDS IN DER AGILEN SOFTWARE ENTWICKLUNG Michael Palotas 7. April 2015 1 GRIDFUSION IHR REFERENT Gridfusion Software Solutions Kontakt: Michael Palotas Gerbiweg

Mehr

Projektrisikomanagement im Corporate Risk Management

Projektrisikomanagement im Corporate Risk Management VERTRAULICH Projektrisikomanagement im Corporate Risk Management Stefan Friesenecker 24. März 2009 Inhaltsverzeichnis Risikokategorien Projekt-Klassifizierung Gestaltungsdimensionen des Projektrisikomanagementes

Mehr

Sammlung zu. Definition Betriebsbewährtheit. Neue Generation Signaltechnik - NeGSt. NeGSt. AP 2100, Arbeitsgruppe 1

Sammlung zu. Definition Betriebsbewährtheit. Neue Generation Signaltechnik - NeGSt. NeGSt. AP 2100, Arbeitsgruppe 1 Neue Generation Signaltechnik - NeGSt Sammlung zu Definition Betriebsbewährtheit NeGSt AP 2100, Arbeitsgruppe 1 Anerkannte Regeln der Technik 31. Juli 2013 Datei: NeGSt_ARdT_Sammlung_Betriebsbewaehrt_V1-00_20130731

Mehr

Functional Safety IBM Rational DOORS Traceability & Normen

Functional Safety IBM Rational DOORS Traceability & Normen Functional Safety IBM Rational DOORS Traceability & Normen Inhalt: DOORS Import von und Traceability zu Normen Tailoring und Export in RiskCAT Import in DOORS Anzeigen der Attribute Einrichten von Link-Control

Mehr

on Software Development Design

on Software Development Design Werner Mellis A Systematic on Software Development Design Folie 1 von 22 How to describe software development? dimensions of software development organizational division of labor coordination process formalization

Mehr

Requirements Management mit RequisitePro. Rational in der IBM Software Group. Der Rational Unified Process als Basis für die Projektarbeit

Requirements Management mit RequisitePro. Rational in der IBM Software Group. Der Rational Unified Process als Basis für die Projektarbeit IBM Software Group IBM Rational mit RequisitePro Hubert Biskup hubert.biskup@de.ibm.com Agenda Rational in der IBM Software Group Der Rational Unified Process als Basis für die Projektarbeit mit Rational

Mehr

Transfer von Prozessen des Software-Produktlinien Engineering in die Elektrik/Elektronik- Architekturentwicklung von Fahrzeugen

Transfer von Prozessen des Software-Produktlinien Engineering in die Elektrik/Elektronik- Architekturentwicklung von Fahrzeugen Transfer von Prozessen des Software-Produktlinien Engineering in die Elektrik/Elektronik- entwicklung von Fahrzeugen Martin Jaensch, Dr. Bernd Hedenetz, Markus Conrath Daimler AG Prof. Dr. Klaus D. Müller-Glaser

Mehr

Risikominimierung bei der Einführung neuer Produkte und Dienstleistungen im Pflegesektor

Risikominimierung bei der Einführung neuer Produkte und Dienstleistungen im Pflegesektor Risikominimierung bei der Einführung neuer Produkte und Dienstleistungen im Pflegesektor WiMi-Care Zwischenworkshop Alexander Steffen 04. November 2010 Agenda 01. Einleitung 02. Normen als Grundlage 03.

Mehr

Product Lifecycle Manager

Product Lifecycle Manager Product Lifecycle Manager ATLAS9000 GmbH Landauer Str. - 1 D-68766 Hockenheim +49(0)6205 / 202730 Product Lifecycle Management ATLAS PLM is powerful, economical and based on standard technologies. Directory

Mehr

Testdokumentation nach Norm IEC 61508. Volkswagen AG, Bussines Unit Braunschweig

Testdokumentation nach Norm IEC 61508. Volkswagen AG, Bussines Unit Braunschweig Testdokumentation nach Norm IEC 61508 mit Hilfe des TDM Formats Klaus Nicolai Volkswagen AG, Bussines Unit Braunschweig Gliederung Funktionale Sicherheit Quellen technischer Anforderungen Baugruppentest

Mehr

ProSafe-RS sicherheitsgerichtete Technik

ProSafe-RS sicherheitsgerichtete Technik ProSafe-RS sicherheitsgerichtete Technik Hochverfügbare Technologie des Yokogawa PLS Die Yokogawa-Leitsysteme CENTUM CS und CS 3000 sind bereits seit über zehn Jahren auf dem Markt und kommen in vielen

Mehr

Prozessindustrie EN 61508 / EN 61511. VL PLT2, SS 2012 Professur für Prozessleittechnik

Prozessindustrie EN 61508 / EN 61511. VL PLT2, SS 2012 Professur für Prozessleittechnik Funktionale Sicherheit in der Prozessindustrie EN 6508 / EN 65 VL PL2, SS 202 Professur für Prozessleittechnik ik Übersicht PL-Schutzeinrichtungen Sicherheitsgrundnorm h it EN 6508 Funktionale Sicherheit

Mehr

TOGAF The Open Group Architecture Framework

TOGAF The Open Group Architecture Framework TOGAF The Open Group Architecture Ein Überblick Gesellschaft für Informatik, Regionalgruppe München Dr. Michael Bulenda München, 7.12.2009 Vorstellung Dr. M. Bulenda Seit 2001 bei Cirquent IT Management

Mehr

Functional Safety. Systems Engineering als Schlüsseldisziplin in Projekten mit funktionaler Sicherheit

Functional Safety. Systems Engineering als Schlüsseldisziplin in Projekten mit funktionaler Sicherheit Systems Engineering als Schlüsseldisziplin in Projekten mit funktionaler Sicherheit Mittelstraße 25/1 88471 Laupheim Fon: 07392-9393525 Fax: 07392-9393526 Mailto: tf@thomasfranzen.com Beispiele nicht sicherer

Mehr

Anforderungen, KEFs und Nutzen der Software- Prozessverbesserung

Anforderungen, KEFs und Nutzen der Software- Prozessverbesserung Process flow Remarks Role Documents, data, tool input, output Important: Involve as many PZU as possible PZO Start Use appropriate templates for the process documentation Define purpose and scope Define

Mehr

Software als Medizinprodukt

Software als Medizinprodukt Software als Medizinprodukt DI Dr. Gerhard Wrodnigg, MSc. TÜV AUSTRIA SERVICES Software als Medizinprodukt Wann ist Software ein Medizinprodukt? Änderung der RL 93/42/EWG durch 2007/47/EG Qualification

Mehr

Executive Summary Funktionale Sicherheit ISO 26262 ZVEI UG2 Adhoc AG Funktionale Sicherheit ISO 26262

Executive Summary Funktionale Sicherheit ISO 26262 ZVEI UG2 Adhoc AG Funktionale Sicherheit ISO 26262 Executive Summary Funktionale Sicherheit ISO 26262 ZVEI UG2 Adhoc AG Funktionale Sicherheit ISO 26262 Fachverband Electronic Components and Systems Impressum Executive Summary Funktionale Sicherheit ISO

Mehr

CeBIT 17.03.2015. CARMAO GmbH 2014 1

CeBIT 17.03.2015. CARMAO GmbH 2014 1 CeBIT 17.03.2015 CARMAO GmbH 2014 1 HERZLICH WILLKOMMEN Applikationssicherheit beginnt lange bevor auch nur eine Zeile Code geschrieben wurde Ulrich Heun Geschäftsführender Gesellschafter der CARMAO GmbH

Mehr

2. Klassifizierung von PLT-Schutzeinrichtungen gemäß VDI/VDE-Richtlinie 2180-1

2. Klassifizierung von PLT-Schutzeinrichtungen gemäß VDI/VDE-Richtlinie 2180-1 Safety Integrity Level (SIL)-Einstufungen Inhaltsübersicht 1. Einleitung 2. Klassifizierung von PLT-Schutzeinrichtungen gemäß VDI/VDE-Richtlinie 2180-1 3. Weitere Ansätze und Hilfsmittel zur Klassifizierung

Mehr

zu konzipieren und umzusetzen. Gerne unterstützen wir Sie auch persönlich sprechen Sie uns an.

zu konzipieren und umzusetzen. Gerne unterstützen wir Sie auch persönlich sprechen Sie uns an. Rexroth unterstützt Maschinen- und Anlagenhersteller mit Know-how und individueller Beratung. Der Leitfaden 10 Schritte zum Performance Level hilft Ihnen, systematisch und normgerecht Risiken zu bewerten,

Mehr

Integriertes und sicherheitsbezogenes Vorgehen zur Entwicklung eines Fahrdynamikregelsystems. Safety & Security 2010

Integriertes und sicherheitsbezogenes Vorgehen zur Entwicklung eines Fahrdynamikregelsystems. Safety & Security 2010 Integriertes und sicherheitsbezogenes Vorgehen zur Entwicklung eines Fahrdynamikregelsystems Safety & Security 2010 Dr. N. Zambou, Stuttgart 2010.06.23 Motivation de Havilland DH82A Tiger Moth elevator

Mehr

Innovatives Risikomanagement für die (Software-) Entwicklung von Medizingeräten der Zukunft

Innovatives Risikomanagement für die (Software-) Entwicklung von Medizingeräten der Zukunft 1 Innovatives Risikomanagement für die (Software-) Entwicklung von Medizingeräten der Zukunft MedConf, München Dr. Henrik J. Putzer Marco Radzio Frühe Medizingeräte Trepanation des Schädels bereits bei

Mehr

FUNKTIONALE SICHERHEIT VON ELEKTRISCHEN ANLAGEN IN INDUSTRIELLEN BETRIEBSSTÄTTEN VON OTTO WALCH

FUNKTIONALE SICHERHEIT VON ELEKTRISCHEN ANLAGEN IN INDUSTRIELLEN BETRIEBSSTÄTTEN VON OTTO WALCH FUNKTIONALE SICHERHEIT VON ELEKTRISCHEN ANLAGEN IN INDUSTRIELLEN BETRIEBSSTÄTTEN VON OTTO WALCH Der störungsfreie und sichere Betrieb von industriellen Anlagen ist von großer Bedeutung, sowohl für die

Mehr

Änderungen von Instandhaltungsprogrammen - Nachweisverfahren nach DIN 27201-1 im Kontext der CSM-Verordnung 352/2009/EG

Änderungen von Instandhaltungsprogrammen - Nachweisverfahren nach DIN 27201-1 im Kontext der CSM-Verordnung 352/2009/EG RöschConsult Group Änderungen von Instandhaltungsprogrammen - Nachweisverfahren nach DIN 27201-1 im Kontext der CSM-Verordnung 352/2009/EG Internationale Schienenfahrzeugtagung Dresden 2012 Prof. Dr.-Ing.

Mehr

RöschConsult Group. Einfluß der europäischen Normen der Instandhaltung auf die Schweiz. IHRUS Luzern, 03.11.2011!!!!! Prof. Dr.-Ing.

RöschConsult Group. Einfluß der europäischen Normen der Instandhaltung auf die Schweiz. IHRUS Luzern, 03.11.2011!!!!! Prof. Dr.-Ing. RöschConsult Group Einfluß der europäischen Normen der Instandhaltung auf die Schweiz IHRUS Luzern, 03.11.2011!!!!! Prof. Dr.-Ing. Wolfgang Rösch 2 RöschConsult Group Ingenieurbüro und Unternehmensberatung

Mehr

Funktionale Sicherheit

Funktionale Sicherheit Funktionale Sicherheit Funktionale Sicherheit von Medizingeräten Medical Device Day 21. Juni 2012, Erlangen Matthias Hölzer-Klüpfel Risiko und Sicherheit Wann ist Software ein Medizinprodukt? Sicherheit

Mehr

Gibt es einen Paradigmenwechsel in der Prozess- und Anlagensicherheit?

Gibt es einen Paradigmenwechsel in der Prozess- und Anlagensicherheit? Gibt es einen Paradigmenwechsel in der Prozess- und Anlagensicherheit? Th. Gmeinwieser, Büro Deutschland Folie 1 Paradigmenwechsel Was ist gemeint? Gibt es in der Prozess- und Anlagensicherheit Tendenzen,

Mehr

IV Software-Qualitätssicherung

IV Software-Qualitätssicherung Softwaretechnik- Praktikum: 12. Vorlesung Jun.-Prof Prof.. Dr. Holger Giese Raum E 3.165 Tel. 60-3321 Email: hg@upb.de Übersicht I II III IV V Einleitung Ergänzungen zur Software-Entwicklung Software Management

Mehr

Customer-specific software for autonomous driving and driver assistance (ADAS)

Customer-specific software for autonomous driving and driver assistance (ADAS) This press release is approved for publication. Press Release Chemnitz, February 6 th, 2014 Customer-specific software for autonomous driving and driver assistance (ADAS) With the new product line Baselabs

Mehr

Präsentation DIN-EN 81-1/A1: 2005 DIN-EN 81-2/A1: 2005 (PESSRAL) 15. Juni 2008 VI. Schwelmer Liftsymposium

Präsentation DIN-EN 81-1/A1: 2005 DIN-EN 81-2/A1: 2005 (PESSRAL) 15. Juni 2008 VI. Schwelmer Liftsymposium Präsentation DIN-EN 81-1/A1: 2005 DIN-EN 81-2/A1: 2005 (PESSRAL) 15. Juni 2008 VI. Schwelmer Liftsymposium PESSRAL: Programmable Electronic Systems in Safety Related Applications for Lifts (Programmierbare

Mehr

Innovatives Risikomanagement für die Entwicklung von Medizingeräten der Zukunft

Innovatives Risikomanagement für die Entwicklung von Medizingeräten der Zukunft 1 Innovatives Risikomanagement für die Entwicklung von Medizingeräten der Zukunft electronic goes medical, München Dr. Henrik J. Putzer Marco Radzio Frühe Medizingeräte Trepanation des Schädels bereits

Mehr

ITILin60Minuten. Jörn Clausen joernc@gmail.com. Captain Barbossa: And thirdly, the code is more what you d call guidelines than actual rules.

ITILin60Minuten. Jörn Clausen joernc@gmail.com. Captain Barbossa: And thirdly, the code is more what you d call guidelines than actual rules. ITILin60Minuten Jörn Clausen joernc@gmail.com Captain Barbossa: And thirdly, the code is more what you d call guidelines than actual rules. Elizabeth Swann: Hang the code, and hang the rules. They re more

Mehr

Data Processing, On-Board Software & Dependability (ASG72, ASG73)

Data Processing, On-Board Software & Dependability (ASG72, ASG73) Data Processing, On-Board Software & Dependability (ASG72, ASG73) Aktuelle Aktivitäten und Möglichkeiten der Zusammenarbeit Name: Norbert Binzer, Abt. ASG72 DLR - Raumfahrt-Industrietage in Friedrichshafen

Mehr

Softwareprozesse systematisch verbessern ISO15504(SPICE) und Automotive SPICE. Heinrich Dreier Elmshorn 17.04.2008

Softwareprozesse systematisch verbessern ISO15504(SPICE) und Automotive SPICE. Heinrich Dreier Elmshorn 17.04.2008 Softwareprozesse systematisch verbessern ISO15504(SPICE) und Automotive SPICE Heinrich Dreier Elmshorn 17.04.2008 Einleitung Softwareprozesse verbessern Einleitung Softwareprozesse verbessern SPI Software

Mehr

den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015

den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015 Agile Methoden als Diagnose-Tool für den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015 Über mich Berufliche Erfahrung 3 Jahre Projektabwicklung 2 Jahre

Mehr

Validierung und Verifikation!

Validierung und Verifikation! Martin Glinz Thomas Fritz Software Engineering Kapitel 7 Validierung und Verifikation 2005-2013 Martin Glinz. Alle Rechte vorbehalten. Speicherung und Wiedergabe für den persönlichen, nicht kommerziellen

Mehr

Safety related development process for automotive suppliers

Safety related development process for automotive suppliers April 2005 1 Safety related development process for automotive suppliers Dr. Wolfgang Reinelt ZF Lenksysteme GmbH, Schwäbisch Gmünd, Germany Email: Wolfgang.Reinelt@ZF- Lenksysteme.com Fifth Bieleschweig

Mehr

Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich

Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich Andreas Armbrecht Siemens AG Darmstadt, 01. 02. Dezember 2009 Business Unit Rail Automation Systeme der Eisenbahnautomatisierung

Mehr

QM-Seminar ISO 26262 Modul 4: Hardware 03.03.2016

QM-Seminar ISO 26262 Modul 4: Hardware 03.03.2016 Anmeldung zu offenen FuSi-Seminaren i-q Schacht & Kollegen Qualitätskonstruktion GmbH Herrn Jörg Schacht Behringersdorf Hirschbergstraße 10A 90571 SCHWAIG b.nürnberg Ihre Anmeldung können Sie:

Mehr

Armaturen in der Anlagensicherheit. Funktionale Sicherheit Safety Integrity Level SIL

Armaturen in der Anlagensicherheit. Funktionale Sicherheit Safety Integrity Level SIL Armaturen in der Funktionale Sicherheit Safety Integrity Level SIL mail: karlheinz.gutmann@de.endress.com 1 Funktionale Sicherheit - ein aktuelles Thema und ein wichtiger Beitrag zur Anlagen mit einem

Mehr

Automotive SPICE 3.0 What`s new? tecmata GmbH. Flörsheim, tecmata GmbH. tecmata GmbH

Automotive SPICE 3.0 What`s new? tecmata GmbH. Flörsheim, tecmata GmbH. tecmata GmbH Automotive SPICE 3.0 What`s new? tecmata GmbH Flörsheim, 20.09.2016 Kernkompetenz Systemtest Requirements- Engineering Implementation Integrationstest Funktionale Sicherheit Embedded Software Engineering

Mehr

ITIL in 60 Minuten. Jörn Clausen. joernc@gmail.com. Captain Barbossa: And thirdly, the code is more what you d call guidelines than actual rules.

ITIL in 60 Minuten. Jörn Clausen. joernc@gmail.com. Captain Barbossa: And thirdly, the code is more what you d call guidelines than actual rules. ITIL in 60 Minuten Jörn Clausen joernc@gmail.com Captain Barbossa: And thirdly, the code is more what you d call guidelines than actual rules. Elizabeth Swann: Hang the code, and hang the rules. They re

Mehr

Process Management Office Process Management as a Service

Process Management Office Process Management as a Service Process Management Office Process Management as a Service Unsere Kunden bringen ihre Prozesse mit Hilfe von ProcMO so zur Wirkung, dass ihre IT- Services die Business-Anforderungen schnell, qualitativ

Mehr

Software EMEA Performance Tour 2013. Berlin, Germany 17-19 June

Software EMEA Performance Tour 2013. Berlin, Germany 17-19 June Software EMEA Performance Tour 2013 Berlin, Germany 17-19 June Change & Config Management in der Praxis Daniel Barbi, Solution Architect 18.06.2013 Einführung Einführung Wer bin ich? Daniel Barbi Seit

Mehr

Entwurf. Anwendungsbeginn E DIN EN 62304 (VDE 0750-101):2013-10. Anwendungsbeginn dieser Norm ist...

Entwurf. Anwendungsbeginn E DIN EN 62304 (VDE 0750-101):2013-10. Anwendungsbeginn dieser Norm ist... Anwendungsbeginn Anwendungsbeginn dieser Norm ist.... Inhalt Einführung... 13 1 Anwendungsbereich... 16 1.1 *Zweck... 16 1.2 *Anwendungsbereich... 16 1.3 Beziehung zu anderen Normen... 16 1.4 Einhaltung...

Mehr

PLATO AG Funktionales Sicherheitsprojekt & System-FMEA

PLATO AG Funktionales Sicherheitsprojekt & System-FMEA PLATO AG Funktionales Sicherheitsprojekt & System-FMEA Umsetzung in einem Datenmodell Claudia Lange PLATO AG Die PLATO AG auf einem Blick Software- und Dienstleistungsunternehmen mit Methoden- und Softwarelösungen

Mehr

Einführung in das Qualitätsmanagement. München, 22.10.2012 Andreas Hötzel

Einführung in das Qualitätsmanagement. München, 22.10.2012 Andreas Hötzel Einführung in das Qualitätsmanagement München, 22.10.2012 Andreas Hötzel Agenda: Was ist Qualität?...Qualitätsmanagement?...Qualitätssicherung? Kurze Geschichte des Qualitätsmanagements Einführung in die

Mehr

EEX Kundeninformation 2007-09-05

EEX Kundeninformation 2007-09-05 EEX Eurex Release 10.0: Dokumentation Windows Server 2003 auf Workstations; Windows Server 2003 Service Pack 2: Information bezüglich Support Sehr geehrte Handelsteilnehmer, Im Rahmen von Eurex Release

Mehr

Stages Insights 2015. Einsatz von Stages im Kontext der funktionalen Sicherheit

Stages Insights 2015. Einsatz von Stages im Kontext der funktionalen Sicherheit Stages Insights 2015 Einsatz von Stages im Kontext der funktionalen Sicherheit Dr. Prozesskoordinator Phone: +49 7150-307-204 Mobile: +49 173 364 9320 Email: manuel.melui@knorr-bremse.com www.knorr-bremse.com

Mehr

Risikobasierte Bewertung von Hilfsstoffen

Risikobasierte Bewertung von Hilfsstoffen Risikobasierte Bewertung von Hilfsstoffen Systematische Vorgehensweise beim Risikomanagement-Prozess (in Anlehnung an ICH Q9): Systematische Vorgehensweise beim Risikomanagement-Prozess (in Anlehnung an

Mehr

Stefan Mieth, AIT GmbH & Co. KG

Stefan Mieth, AIT GmbH & Co. KG Stefan Mieth, AIT GmbH & Co KG As a requirements engineer I want to use the TFS 12032015; 16:30 17:30 Requirements Engineering ist neben Testing wohl der Dauerbrenner, wenn es um gerne vernachlässigte

Mehr

2014 PRINCE 2 Foundation PRINCE 2 Practitioner

2014 PRINCE 2 Foundation PRINCE 2 Practitioner Personalprofil Thomas Scherzinger Senior Consultant E-Mail: thomas.scherzinger@arcondis.com AUSBILDUNG BERUFLICHE WEITERBILDUNG BESONDERE TÄTIGKEITEN 2010 Bachelor of Sciences in Wirtschaftsinformatik

Mehr

4. FIT-ÖV - 01. Juli 2009 in Aachen Informationssicherheit im IT Service Management

4. FIT-ÖV - 01. Juli 2009 in Aachen Informationssicherheit im IT Service Management 1 4. FIT-ÖV - 01. Juli 2009 in Aachen Informationssicherheit im IT Service Management Bernhard Barz, regio it aachen 2 Gliederung Informationssicherheit Anforderungen der ÖV Informationssicherheit im IT

Mehr

Fachtagung Safety in Transportation Leitfaden für die IT Sicherheit auf Grundlage IEC 62443

Fachtagung Safety in Transportation Leitfaden für die IT Sicherheit auf Grundlage IEC 62443 Fachtagung Safety in Transportation Leitfaden für die IT Sicherheit auf Grundlage IEC 62443 DKE UK 351.3.7 Hans-Hermann Bock 1 Braunschweig, 06.11.2013 Anwendungsbereich der Vornorm (1) Diese Vornorm ist

Mehr

Requirements-Engineering Requirements-Engineering

Requirements-Engineering Requirements-Engineering -Engineering Copyright Chr. Schaffer, Fachhochschule Hagenberg, MTD 1 Was ist ein Requirement? IEEE-Standard (IEEE-726 83) A condition or capability needed by a user to solve a problem or achieve an objective.

Mehr

HIR Method & Tools for Fit Gap analysis

HIR Method & Tools for Fit Gap analysis HIR Method & Tools for Fit Gap analysis Based on a Powermax APML example 1 Base for all: The Processes HIR-Method for Template Checks, Fit Gap-Analysis, Change-, Quality- & Risk- Management etc. Main processes

Mehr

Einbinden der Why-Because-Analyse bei der Untersuchung von Produktsicherheitsmängeln

Einbinden der Why-Because-Analyse bei der Untersuchung von Produktsicherheitsmängeln Einbinden der Why-Because-Analyse bei der Untersuchung von Produktsicherheitsmängeln Ernesto De Stefano Untersuchung von Produktsicherheitsmängeln Wann wird die Why-Because-Analyse eingesetzt? 1 Sicherheitsmangel

Mehr