Funktionale Sicherheit für KMUs - Teil 2/2

Der sichere Weg

Im Teil 1 wurden die einzelnen Normen und deren Zusammenhänge diskutiert, der Sicherheitslebenszyklus dargestellt und der Spannungsbogen zwischen Flexibilität, Agilität und von der Norm geforderten formalen Notwendigkeiten aufgezeigt. Der zweite Teil soll eine Hilfestellung für frühe SRS-Projektphasen geben und sich mit der Frage nach den richtigen Inhalten einer SRS befassen.


Innovationsphase im Lebenszyklus
Bild: Mesco

Formell beginnt ein Projekt zur Entwicklung einer funktional sicheren Komponente mit der SRS (Safety Requirement Specification). Ein flexibler oder auch unsystematischer Prozess zur Findung dieser Requirements kann auch bedeuten, dass möglicherweise entscheidende Elemente übersehen werden. Gleichzeitig stellt die SRS die Basis für eine Investition in Produktmanagement, Entwicklung und Vertrieb über mehrere hunderttausend Euro dar. Es lohnt sich also, hier etwas genauer hinzusehen. Dieser Beitrag soll eine Hilfestellung für diese frühen Projektphasen geben und sich mit der Frage nach den richtigen Inhalten einer SRS befassen. Wie stellt man sicher, dass marktgerechte Produkte entwickelt werden bzw. welche Produkte überhaupt entwickelt werden sollen?

Produktstrategien

Wenn die gewünschte Entwicklung ein Me-too-Produkt werden soll, stehen Produktionskosten, Entwicklungsumlagen und Verwaltungsgemeinkosten technischen Eigenschaften gegenüber im Vordergrund. Macht es überhaupt Sinn, Entwicklungskapazitäten für solch ein Produkt zu binden? Benötigt der Aktor-/Sensorhersteller dieses Produkt überhaupt im Portfolio oder kann das Produkt u.U. von einem Marktbegleiter zugekauft werden? Gilt es dagegen ein Produkt zu entwickeln, dass technisches Neuland bedeutet oder für einen gerade sich öffnenden Markt gedacht ist, stellt sich die Frage, ob der Aktor-/Sensorhersteller überhaupt die Marktsichtbarkeit hat, um solch eine Innovation im Markt gegenüber etablierten Lösungen zu positionieren? Lohnt es sich, für eine kundenspezifische Entwicklung/Adaption Entwicklungskapazitäten zu binden und dafür andere Produkte zu verzögern? Aktuell zeichnet sich im Bereich der mobilen Automation ein Trend ab, dass Subsystemlieferanten funktional sichere Aktoren und Sensoren fordern, inklusive der dementsprechenden funktional sicheren Kommunikationswege (z.B. CANopen Safety, J1939 Safety). Systemlieferanten, welche die funktionale Sicherheit für ihr Gesamtsystem nachweisen müssen, wollen auf Produkte zurückgreifen, die sie in die Sicherheitsbetrachtung sinnvoll integrieren können. Für den Sensor-/Aktorhersteller bedeutet dies eine Produktentwicklung, welche die Merkmale eines funktional sicheren Produktes aufweist, und die nach den durch die Normen geforderten Prozessen entwickelt wurde. Der Kunde erhält eine Applikationsbeschreibung, einen Diagnosedeckungsgrad, einen Wert für die MTTFd (Mean time to dangerous failure) und eine common cause Analyse. Die Kunden eines Aktor-/Sensorherstellers finden sich in beiden Lagern: sowohl bei den Subsystemlieferanten als auch den Systemlieferanten. Ein weiterer Trend sind die immer preiswerter und stärker werdenden Synchronmotoren und deren Anwendung in sicherheitsrelevanten Applikationen. Hier gilt es, ein System funktional sicher auszulegen, Aktor (Synchronmotor) und Sensor (Drehgeber und Steuerungseinheit) - sprich das Drive System - müssen als Gesamtsystem funktional sicher ausgelegt werden. Obgleich Standardprodukte die Basis einer möglichen Integration sind, ist das Ziel einer Zertifizierung nur durch eine enge Kooperation der Aktor-/Sensorhersteller zu erreichen. Anforderungen aus der Steuereinheit oder aus dem Aktor finden sich in der SRS des Drehgebers wieder. Genau analysiert und diskutiert werden muss auch die Frage nach den funktional sicheren Parametern. Um das Beispiel Antriebssystem aufzugreifen, muss die Position funktional sicher sein oder die Geschwindigkeit, oder beides? Gibt es noch weitere Parameter, die ebenfalls funktional sicher sein müssen? Diese strategischen Überlegungen zum Gesamtportfolio, die (Entwicklungs-)Roadmap und dem Going-to-Market, also dem vertrieblichen Auftreten im Markt, sind Entscheidungen, die auf höchster Führungsebene getroffen werden müssen.

Anzeige

Auswahl-/Entscheidungsprozess

Formal gesehen beginnt die Entwicklung einer funktional sicheren Komponente mit der Phase 9 des Sicherheitslebenszyklus und der Erstellung der SRS. Wie in Teil 1 geschildert, kann die SRS am besten mit dem Lastenheft einer Standard-Produktentwicklung gleichgesetzt werden. Bevor es aber darum geht das Lastenheft zu erstellen, stellt sich die Frage, welche Produkte überhaupt in Angriff genommen werden sollen. Die nachfolgenden Betrachtungen helfen, die Innovationsphase, also den Beginn des Produktlebenszyklus zu bewältigen. Ausgangspunkt ist dabei, dass auch eher schwammige Gebiete wie Innovation und Produktdefinition von einem prozessgetriebenen Ansatz profitieren können und vor der eigentlichen Produktentwicklung ablaufen. Für folgende Betrachtungen wird die Innovationsphase in die folgende Abschnitte unterteilt:

  • • Produktideen sammeln
  • • Produktsteckbriefe erstellen
  • • Produktideen priorisieren und entscheiden
  • • Lastenheft bzw. SRS erstellen

Produktsteckbrief

Der Produktmanager erfasst laufend Portfolio-relevante Ideen, wie neue Produktideen oder Verbesserungen an laufenden Produkten. Diese können vom Produktmanager selbst stammen oder ihm zugetragen werden. Meist entstehen weit mehr Produktideen, als mit den gegebenen Ressourcen umsetzbar sind. Nachdem der Abgleich mit der Portfolio- und Produktstrategie erfolgt ist, und die technische und wirtschaftliche Machbarkeit plausibel erscheint, bietet es sich an, Produktsteckbriefe zu entwerfen. In diesen werden Produktidee, Kundennutzen, Key-Requirements und Terminziele beschrieben, sowie eine erste Wirtschaftlichkeitsbetrachtung (Stückzahlschätzung, Marktpreis, Zielkosten) durchgeführt. Das Ausformulieren des Produktsteckbriefs hilft, etwaige Inkonsistenzen zu erkennen und ist eine wichtige Grundlage, um eine fundierte Entscheidung, unter Einbindung aller betroffenen Unternehmensbereiche, treffen zu können. Ein aus Vertriebssicht attraktives Functional Safety (FS) Produkt kann u.U. mit den gegebenen R&D-Ressourcen gar nicht umgesetzt werden, weil z.B. das normative Know-how nicht vorhanden ist, FS-Manager nicht verfügbar oder die Test-Ingenieure in anderen Projekten gebunden sind. In solchen Fällen, könnte der Zukauf oder die Einbindung von externen Ressourcen die bessere Alternative sein. Neben den Standardfragen und Requirements für eine spezifische Produktentwicklung gelten für funktional sichere Produkte noch weitere Fragestellungen. Zum einen soll ein funktional sicheres Produkt längere Zeit unverändert angeboten werden, da Änderungen am Produkt in der Regel zu einer kostspieligen Nachzertifizierung führen. Es lohnt sich daher, gerade bei diesen Produkten genügend Sorgfalt und Struktur in die Innovationsphase zu legen. Zum anderen ist die längere Ressourcenbindung für eine FS-Entwicklung zu beachten. Steht der Business Case alleine oder dient das FS-Produkt der Unterstützung von nicht-FS Produkten? Ist es in einem gegebenen Markt oder bei einem gegebenen Kunden notwendig? Muss das FS-Produkt in eine Plattform Strategie integriert werden, so dass Aufwände auch auf andere Produkte umgelegt werden können? Da eine Produktentscheidung bereichsübergreifende Auswirkungen hat und zu häufige Ad-hoc-Entscheidungen das Tagesgeschäft negativ beeinflussen, haben sich ein Turnus von einem Monat als untere Grenze für Innovationsmeetings und Innovationsentscheidungen bei KMUs bewährt. Generell sollte diese Entscheidung aber auf einer übergeordneten Ebene stattfinden, so dass die Auswirkungen im gesamten Unternehmen auch in vollem Umfang berücksichtigt werden. Es ist daher keine Seltenheit, dass von ursprünglich mehreren Dutzend ungefilterten Produkt- und Verbesserungsideen am Ende dieser Phase nur wenige übrig bleiben. Selbst für erfahrene Produktmanager ist es nicht trivial die Produktanforderungen zu selektieren und zu Papier zu bringen. Typische Fehler sind das Anhäufen aller denkbaren Anforderungen. Die Kunst liegt im Weglassen, da nur so auch die wichtigen Aspekte Kosten- und Zeit adressiert werden.

Empfehlungen der Redaktion

Lastenheft/SRS

Für das Lastenheft bzw. die SRS liegt idealerweise ein Template vor, das eine Struktur mit Mindestinhalten für die typischen Produkte der Organisation vorgibt. Da industrielle Produkte in der Regel nicht völlig eigenständig betrieben, sondern in ein überlagertes Automatisierungssystem integriert werden, ergeben sich bereits hieraus viele Anforderungen, wie z.B. Schnittstellen, Bussysteme, Befestigungsarten, Aufbauform, Versorgungsspannungsbereiche. Wenn bei einem FS-Produkt das Lastenheft auch die SRS beinhaltet, sind einige zusätzliche Anforderungen zu berücksichtigen. Einerseits sind konkrete sicherheitsrelevante Eigenschaften zu definieren und erhöhte formale Anforderungen an die Erstellung der SRS zu erfüllen. Für ein FS-Produkt sind typischerweise die Sicherheitsfunktion, SIL bzw. PL, der sichere Zustand, die Betriebsart (Continuous Mode, High Demand, Low Demand), die maximale Ausfallrate und die Fehlerreaktionszeit zusätzlich zu definieren. Auch hier gilt: Je besser das Zielsystem bekannt ist, umso treffender können die Produkteigenschaften formuliert werden. Formale Kriterien bei Erstellung der SRS sind u.a. klare, präzise und widerspruchsfreie Anforderungen, die verifizierbar und testbar sind. Den einzelnen Requirements müssen zudem eine eindeutige Identifikationsnummer zugeordnet werden, um eine Nachverfolgbarkeit über alle späteren entstehenden Designdokumente und Testprotokolle zu ermöglichen. Auch muss die SRS durch ein Review verifiziert werden, bei dessen Durchführung sich die Verwendung einer SRS-spezifischen Checkliste bewährt hat. Mit Freigabe der SRS ist die Phase 9 des Sicherheitslebenszyklus nach IEC61508 abgeschlossen. Nun kann der Übergang in die Phase 10, die Entwicklung der sicherheitsgerichteten Komponente, erfolgen.

Fazit

Prozessorientierung bei der Produktentwicklung trägt maßgeblich dazu bei, Entwicklungsrisiken zu vermeiden, die Produktqualität zu verbessern, die Product LifeCycle Costs zu reduzieren, externe Auditierungs- und Zertifizierungskriterien zu erfüllen und schlussendlich die Time-to-Market zu verkürzen. Es bedarf Erfahrung, Expertise und Pragmatismus um die geforderten Strukturen aufzubauen bzw. anzupassen und eine typische Überauslegung der Anforderungen zu vermeiden. Prozesse und Strukturen müssen nicht behindern, sondern können gerade dazu dienen, geistige Freiräume zu schaffen, in denen wahre Innovationen entsteht.

Anzeige

 
Beckhoff Banner: 190722_Beckhoff_wb109_EtherCAT-Messtechnikmodule_EK11-18G_160x600_ID2079