ISO13849; 4.6.2; "Verwendung [...] rechnergestützter Werkzeuge mit Betriebs bewährung"

[uwe__]

Zuviel Werbung?
-> Hier kostenlos registrieren

hi,

was meint die Norm mit "Verwendung geeigneter Programmiersprachen und rechnergestützter Werkzeuge mit Betriebsbewährung;"

Sollen alle verwendeten Programme analog zu IEC 61508-3 7.4.4 ( offline tools T1-T3) validiert werden?

Für welche Tools gilt dies?

• Der Compiler (vermutlich sollte der zumindest zertifiziert sein?)
• Die verwendete IDE?
• Support tools wie die PCAN Treiber?
• Das Testframework?

Gibt es dazu Beispiele wie man soetwas macht, was man testen muss und wie man das dokumentiert?

 

[s_kraut]

Hi

die ISO 13849-1 zieht die IEC 61508 nur heran, wenn es sein muss. Ähnlich wie der Teufel und das Weihwasser.
Im oberen PL-Bereich also beispielsweise.

Wenn du die IEC 61508 heranziehst, dann musst du halt organisatorisch recht gut aufgestellt sein. Unabhängigkeitsgrade der Verifizierer, Audits, ggf. durch unabhängige Organisation und sowas.

Ich weiß ja nicht was du vor hast. Daher schwer, dir was konkretes zu antworten - außer dass es am Markt durchaus zertifizierte und Bewährte Werkzeuge zu kaufen gibt.
Wenn nicht sogar zertifizierte LAN-Kabel

Zum Thema Dokumentation bieten sowohl IEC 61508 als auch ISO 13849-2 einiges an.

Zum Thema was man Testen muss für welchen SIL bietet die IEC 61508 einiges an, es hängt wohl maßgeblich davon ab welche Prooftest-Coverage man erreichen möchte.

Wenn ich nochmal die Fragen lese dann kann ich als Einstiegslektüre ISBN
978-0-12-820700-0
978-3-8007-3305-7
978-3-662-57189-7
3-8007-2309-3
empfehlen.

 

[uwe__]

Zuviel Werbung?
-> Hier kostenlos registrieren

Anwendung, Hintergrund:​

Die Anwendung ist eine Motorsteuerung über CAN. Die selbst entwickelte Hardware wird schon bei einem Kunden verwendet der diese im nicht-safety bereich nutzt und jetzt haben weitere Kunden ein interesse daran mit safetyfeatures. Das ganze ist noch in einem so frühen stadium, dass die requirements noch nicht ganz feststehen, eines wird jedoch voraussichtlich sein, dass wenn ein übergeordnetes Steuergerät kommandiert, dass der Motor stehen bleiben soll dieser das auch macht mit safe torque off (STO). Das Kommunikationsprotokoll ist auch bisher schon J1939-76 was eine sichere kommunikation ermöglicht. Die Hardware wurde schon an sich angeschaut und mit der Architektur und den FIT werten hat man ein Kategorie 2 System, das den PL d erreichen könnte. Die Software soll wie bisher in C geschrieben werden. Bisher wird die kostenlose vom Hersteller bereitgestellte Toolchain ( Atmel Studio mit gcc ) verwendet.

Zurück zur Eingangsfrage​

Bei der Verifikation soll dann die Safetyfunktion getestet werden. Wenn man den genannten PCAN-Treiber/Adapter verwenden würde so könnte dieser prinzipiell Nachrichten verfälschen, duplizieren ect. und man würde nicht sicher wissen, ob man die safetyfunktion die man gerade testen will auch getestet hat oder ob es von einer der anderen funktionen abgefangen wurde (z.B. keine Nachricht wurde geschickt anstelle einer Nachricht mit falscher CRC).
Damit man das jetzt sicher hinkriegt muss man die Betriebsbewährung feststellen.

• Man könnte jetzt sagen, dass das CAN-Tool schon in vielen anderen projekten eingesetzt wurde und bisher keine Probleme aufgefallen sind - bei dieser Argumentation ist imo aber das problem, dass ich bei vielen früheren Projekten nicht eindeutig sagen könnte, dass Nachrichten nicht sporadisch verfälscht wurden weil meist schnell periodisch der gewünschte Systemzustand übertragen wird und kurze aussetzer damit kaum auffallen.
• Man könnte jetzt das CAN-Tool Testen z.B. indem man einen loopback mit datenveränderung macht ( ähnlich Linux canfdtest ) wo die gegenstelle ein Mikrocontroller (uC) ist der nur dies macht und wenn er ein Problem sieht z.B. eine LED schaltet und abbricht. Müsste dieser Test dann nicht auch in einem Zeitlichen umfang stattfinden der dem PL entspricht ( 10^6 Stunden fehlerfrei ) was viel ist? Ausserdem würde der Test Probleme im CAN-Protokoll an sich nicht aufdecken (Verhalten bei falsches bytestuffing, ect. ) was nochmals aufwendiger werden würde.

Wie kann ich an diesem Beispiel die Betriebsbewährtheit zeigen?

 

[sps_21]

• Man könnte jetzt das CAN-Tool Testen z.B. indem man einen loopback mit datenveränderung macht ( ähnlich Linux canfdtest ) wo die gegenstelle ein Mikrocontroller (uC) ist der nur dies macht und wenn er ein Problem sieht z.B. eine LED schaltet und abbricht. Müsste dieser Test dann nicht auch in einem Zeitlichen umfang stattfinden der dem PL entspricht ( 10^6 Stunden fehlerfrei ) was viel ist? Ausserdem würde der Test Probleme im CAN-Protokoll an sich nicht aufdecken (Verhalten bei falsches bytestuffing, ect. ) was nochmals aufwendiger werden würde.

Wie kann ich an diesem Beispiel die Betriebsbewährtheit zeigen?

IMHO: Gar nicht. Wenn ich mir die Ausgangslage durchlese ist das chancenlos. Wie du schon ob. anmerkst sind die zeitlichen Umfänge erheblich. Und die musst mit deinen Tools adäquat nachweisen - das ist Betriebsbewährtheit.

Woher ich das weiß? Ich hatte in den 90ern mit Entwicklern von Sicherheitssteueurungen engen Kontakt. Die erste S95-F konnte auf der Betriebsbewährtheit der S95 aufsetzen, aber das waren noch andere Zeiten und das ist wahrlich kein kleiner Konzern. Gut, mittlerweile hat man die Anforderungen gesenkt.

Alternativ kannst du die spezielle Fehlerfreiheit od. stets korrekte Reaktion deines Systems beweisen. Das bedingt eine Modellierung der Software in speziellen Tools, weil nur die dafür zertifiziert sind.