Skip to main content

Nicht sicherheitsrelevante Programme (NonSafe PRGs)

Ab Compiler- und Runtime Version V3.5.4.0 dürfen PRGs innerhalb einer Safety SIL2 Applikation auch nicht sicherheitsrelevanten Code enthalten. Standardmäßig enthalten alle PRGs sicherheitsrelevanten Code. Dies wird durch das gelbe Icon sil2_icon_safe.png neben dem Standardsymbol der POU angezeigt.

Abbildung 7. Applikation mit sicherheitsrelevanten PRGs
Applikation mit sicherheitsrelevanten PRGs


Sind die o.g. Anforderungen an die Compilerversion und die Laufzeitsystemversion erfüllt, gibt es im Eigenschaften-Dialog des PRG eine eigene Registerkarte SIL2 Eigenschaften mit der Checkbox Sicherheitsrelevantes PRG, mit der die Eigenschaft enthält sicherheitsrelevanten Code des PRGs deaktiviert werden kann. Sie öffnen den Eigenschaften-Dialog eines PRG über den Kontextmenübefehl Eigenschaften.

Enthält ein PRG keinen sicherheitsrelevanten Code, wird das auch optisch mit einem grauen Symbol sil2_icon_unsafe.png neben dem Standardsymbol der POU gekennzeichnet.

Abbildung 8. Gerätebaum mit einem sicherheitsrelevanten PRG und einem nicht sicherheitsrelevanten PRG
Gerätebaum mit einem sicherheitsrelevanten PRG und einem nicht sicherheitsrelevanten PRG


Hinweise zur Verwendung von nicht sicherheitsrelevanten Programmen

Die nachfolgenden Hinweise beschreiben die empfohlene Verwendung von nicht sicherheitsrelevanten Programmen. Ergänzend dazu ist das Handbuch des Steuerungsherstellers zu beachten.

Allgemein

  • Nicht sicherheitsrelevante PRGs dienen primär dem Zweck, innerhalb einer grundsätzlich sicherheitskritischen Applikation einzelne nicht sicherheitsrelevante Teilfunktionen auszuführen.

    Diese nicht sicherheitsrelevanten PRGs dürfen keinen Einfluss auf die sicherheitsrelevanten Teile haben. Die Rückwirkungsfreiheit auf sichere Daten wird über einen Speicherschutz realisiert.

  • Unter einen als „nicht sicherheitsrelevant“ markierten PRG dürfen keine POUs angehängt werden (wie Methoden, Aktionen usw.).

  • Nicht sicherheitsrelevante PRGs dürfen nicht im POU-Pool deklariert werden. Gemeinsam genutzte POUs sollten in Bibliotheken verwaltet werden.

Datenzugriff und Aufrufhierarchie

Lokale und globale Daten

Die Lage der lokalen Daten von POUs unterscheiden sich je nach Typ:

  • Funktion

    Lokale Variablen liegen auf dem Stack

  • FB-Instanz

    Lokale Variablen eines FBs liegen in der FB-Instanz.

Für Globale Daten können die folgenden POU-Typen betrachtet werden:

  • GVL (sowie EVL)

    Globale Variablen (Standarddatentypen, FB-Instanzen, DUTs)

  • PRG

    Globale Variablen (Standarddatentypen, FB-Instanzen, DUTs)

Allgemein zeigt folgende Tabelle, welche Zugriffe auf Daten erlaubt sind:

Kontext \ Zugriffsart

Sicherheitsrelevante Daten

Nicht sicherheitsrelevante Daten

Lesen

Schreiben

Lesen

Schreiben

Sicherheitsrelevanter Code

OK

OK

OK

OK

Nicht sicherheitsrelevanter Code

OK

Nicht zulässig

OK

OK

Aufrufhierarchie

Die Verwendung von nicht sicherheitsrelevanten PRGs (also Aufrufe in oder Aufrufe aus diesen POUs) unterliegt bestimmten Beschränkungen, da nicht erlaubte Zugriffe zum sicheren Zustand der Steuerung führen.

Tabelle 3. Aufrufhierarchie

Aufruf von / Aufruf nach

Safe PRG

Funktion (Safe-verwendbar)

Safe FB-Instanz

NonSafe PRG

Funktion (NonSafe-verwendbar)

NonSafe FB-Instanz

Safe PRG

OK

OK

OK

Nicht OK

Nicht OK

Nicht OK

Funktion (Safe-verwendbar)

OK

OK

OK

Nicht OK

Nicht OK

Nicht OK

Safe FB-Instanz

OK

OK

OK

Nicht OK

Nicht OK

Nicht OK

NonSafe PRG

Nicht OK

Nicht OK

Nicht OK

OK

OK

OK

Funktion (NonSafe-verwendbar)

Nicht OK

Nicht OK

Nicht OK

OK

OK

OK

NonSafe FB-Instanz

Nicht OK

Nicht OK

Nicht OK

OK

OK

OK



Eine FB-Instanz wird grundsätzlich als sicherheitsrelevant angenommen. Ausnahmen hiervon sind:

  • FB wird in einem NonSafe PRG instanziiert.

  • FB wird in einer EVL instanziiert.

  • FB-Instanz wird mittels „attribute location“ verschoben.

  • FB-Deklaration in einer nicht sicherheitsrelevanter Bibliothek.

Beispiel 6. Beispiel 1

TON aus Standardbibliothek (Safe) wird in PRG (Safe) instanziiert .

Ergebnis: TON-Instanz liegt in sicherem Speicher.



Beispiel 7. Beispiel 2

TON aus Standardbibliothek (Safe) wird in NonSafe PRG instanziiert.

Ergebnis: TON-Instanz liegt in unsicherem Speicher.



Beispiel 8. Beispiel 3

PD aus Util-Bibliothek (NonSafe) wird in PRG (Safe) instanziiert .

Ergebnis: PD-Instanz liegt in unsicherem Speicher.

Wichtig

Die Verwendung eines Bausteins aus einer nicht sicheren Bibliothek in einem sicheren PRG ist nicht erlaubt.



Beispiel 9. Beispiel 4

PD aus Util-Bibliothek (NonSafe) wird in NonSafe PRG instanziiert.

Ergebnis: PD-Instanz liegt in unsicherem Speicher.