ISO 25119: Die Norm beschreibt die Anforderungen an die Sicherheit für Traktoren und Maschinen der Land- und Forstwirtschaft. Die Norm ist eine branchen-spezifische Umsetzung der IEC 61508. Die Norm besteht aus 4 Teilen. Wie auch andere Funktionale Sicherheitsnormen legt die ISO 25119 verschiedene Kritikalitätslevel fest. Die Norm definiert dafür die Agricultural Performance Level (AgPL) QM, a – e. Die AgPL a bis e entsprechen dabei den Performance Level (PL) a bis e, wie sie in der ISO13849 definiert sind.

Bezüglich der Software wird aus dem AgPL noch ein SRL (Software Requirement Level) abgeleitet. Kapitel 7.3.5 im Teil 2 der Norm definiert den Zusammenhang zwischen AgPL und den SRLs (B, 1, 2, 3).

Aufbau der ISO 25119:

Die ISO25119 besteht aus vier Teilen. Der erste Teil definiert vor allem die Management Aspekte eines Funktionalen Sicherheitsprojektes. Im zweiten Teil wird das notwendige Sicherheitskonzept sowie die Anforderungen an die Risiko- und Gefahrenanalyse diskutiert. Der dritte Teil beschäftigt sich mit der Hardware- und Software-Entwicklung sowie den Test. Im vierten Teil werden die Funktionalen Sicherheitsaspekte in der Produktion, dem Betrieb und bei Änderungen besprochen.

Entwicklung auf Systemebene gemäß  ISO 25119

Die ISO25119 verwendet das V-Modell als Grundlage der Entwicklung. Dies unterscheidet sich kaum von Funktionalen Sicherheitsnormen. Wie in der ISO26262 der Automobilbranche, verlangt auch die ISO25119 ein Funktionales Sicherheitskonzept und ein Technisches Safety Konzept. Die Norm zeigt in der V-Modell Darstellung (Figure 1 der ISO25119-3) die Beziehung zwischen den System Requirements, der System Architektur und den beiden Konzepten. Allerdings benötigt man auch in der ISO25119 einiges an Erfahrung, um an dieser Stelle nicht eine unnötige Komplexität in die Dokumentationsstruktur zu bekommen.

Das Funktionale Sicherheitskonzept soll die funktionalen System Requirements enthalten und das Technische Sicherheitskonzept enthält als wesentlichen Bestandteil die Systemarchitektur, bzw. das System Design. Dieser Punkt ist für die Praxis ganz wichtig, wenn man am Ende eine nachvollziehbare Traceability erstellen möchte.

ISO 25119 Software Entwicklung

Bei der ISO 25119 Software Entwicklung steht die Planung des Software Entwicklungsprozesses an erster Stelle, sowie auch in allen Funktionalen Sicherheitsstandards. Die Planung wird im Software Projekt Plan dokumentiert.

Dann definiert die ISO 25119 Software Entwicklung eine Ebene von Software Requirements. In den allermeisten Fällen werden dies textuelle Requirements sein welche in einer Datenbank am Besten verwaltet werden können. Die Norm fordert auch ein Review der Requirements.

Die nächsten beiden Schritte im Lebenszyklus sind die Software Architektur, sowie das Software Komponenten Design und die Implementierung. Bezüglich der Anforderungen an die Software Architektur und das Design, bleibt die ISO25119 vergleichsweise allgemein. Relative viele Anforderungen werden an die Implementierung der Software gestellt.

Das Testen wird in der ISO 25119 in drei Bereiche unterteilt:

• Software Komponententesting
• Software Integrationtesting
• Software Sicherheitstests

Für die Software Komponententests, wird für SRL 2 und SRL 3 Projekte der Nachweis einer strukturellen Source Code Coverage gefordert. Da nicht explizit eine der Nachweis einer 100% strukturellen Coverage gefordert wird, muss die Praxis zeigen, wieviel hier die Projekte tatsächlich an Aufwand reinstecken. Wenn man ein vorausschauendes Projektmanagement betreibt und wenn man eine gute Qualität erreichen will, sollte man sich aber auf dem Markt nach Tools umschauen, welche einem die Messung der strukturellen Coverage abnehmen.

Mit den Software Integrationstests werden hauptsächlich die zeitlichen Anforderungen und Integrationsaspekte nachgewiesen.

Die Software Sicherheitstests sind die Systemtests. Der Schwerpunkt wird hier auf den Tests im Fahrzeug liegen.

Anforderungen an die Software Parametrisierung

Wie auch andere, neuere Funktionale Sicherheitsnormen, stellt auch die ISO 25119 Anforderungen an die Software Parametrisierung. Aus der Praxiserfahrung sei hier aber angemerkt, dass auch die ISO 25119 das Testproblem, welches sich aus der Software Parametrierung ergibt, nicht ausreichend diskutiert. Das Testproblem besteht darin, dass eine parametrierbare Software praktisch nicht mehr 100% testbar ist, da die möglichen Testvektoren, tendenziell gegen unendlich gehen.

Fazit:

Die in der ISO 25119 ist kompakter geschrieben als die ISO 26262. Die Anforderungen an die Sicherheit der System- und Software Entwicklung sind auch (deutlich) reduziert. Das liegt vor allem daran, das landwirtschaftliche Geräte, sehr häufig auf privatem Gelände eingesetzt werden und die Geschwindigkeit der Fahrzeuge ist auch geringer als beim PKW. Daher ist das Gefahrenpotential, welches sich aus den in der ISO 25119 angesprochenen Maschinen ergibt, geringer als das Gefahrenpotential der in der ISO 26262 adressierten Fahrzeuge.

Weitere HEICON Blog Beiträge zum Thema

• Funktionale Sicherheit und Pragmatismus geht das?
• Guter Safety Software Entwicklungsprozess – Was ist das?
• Funktionale Sicherheit – Was ist das?
• Qualitätssicherung in FuSi-Projekten – Was ist anders?

Gerne unterstützen wir vom HEICON Team bei individuellen Fragen zu Ihrem Projekt mit unseren Leistungen. Senden Sie eine Mail an: info[at]heicon-ulm.de.