Regeln - Übersicht und Beschreibung

Funktion

Ermittelt Code, der nicht ausgeführt wird, beispielweise wegen einer RETURN oder CONTINUE Anweisung.

Begründung

Unerreichbarer Code sollte in jedem Fall vermieden werden. Häufig weist die Prüfung darauf hin, dass noch Testcode enthalten ist, der wieder entfernt werden sollte.

Wichtigkeit

Hoch

PLCopen-Regel

CP2

Funktion

Ermittelt POUs, GVLs oder Datentypdeklarationen, die keinen Code enthalten.

Begründung

Leere Objekte sollten vermieden werden. Sie sind oft ein Zeichen dafür, dass ein Objekt nicht vollständig implementiert ist.

Ausnahme: In manchen Fällen wird dem Rumpf eines Funktionsblocks kein Code geben, wenn dieser nur über Schnittstellen verwendet werden soll. In anderen Fällen wird eine Methode nur anlgelegt, weil sie von einer Schnittstelle gefordert wird, ohne dass für die Methode eine sinnvolle Implementierung möglich ist. In jedem Fall sollte eine solche Situation kommentiert werden.

Wichtigkeit

Mittel

Funktion

Ermittelt Codezeilen, die ein Semikolon (;), aber keine Anweisung enthalten.

Begründung

Eine leere Anweisung kann ein Anzeichen für fehlenden Code sein.

Ausnahme

Es gibt sinnvolle Verwendungen leerer Anweisungen. Beispielsweise kann es sinnvoll sein, in einer CASE-Anweisung alle Fälle explizit auszuprogrammieren, auch die, in denen nichts zu tun ist. Wenn eine solche leere CASE-Anweisung mit einem Kommentar versehen ist, erzeugt die statische Codeanalyse keine Fehlermeldung.

Wichtigkeit

Niedrig

Funktion

Ermittelt Ausgänge, die an mehr als einer Position geschrieben werden.

Begründung

Die Wartbarkeit leidet, wenn ein Ausgang an verschiedenen Stellen im Code geschrieben wird. Es ist dann unklar, welcher Schreibzugriff derjenige ist, der tatsächlich Auswirkungen im Prozess hat. Gute Praxis ist es, die Berechnung der Ausgangsvariablen in Hilfsvariablen durchzuführen und an einer Stelle am Ende des Zyklus den berechneten Wert zuzuweisen.

Ausnahme

Es wird kein Fehler ausgegeben, wenn eine Ausgangsvariable in verschiedenen Zweigen von IF- bzw. CASE-Anweisungen geschrieben wird.

Wichtigkeit

Hoch

PLCopen-Regel

CP12

Funktion

Ermittelt Variablen, auf die von mehr als einer Task geschrieben wird.

Begründung

Eine Variable, die in mehreren Tasks geschrieben wird, kann unter Umständen ihren Wert unerwartet ändern. Das kann zu verwirrenden Situationen führen. Stringvariablen und auf einigen 32-Bit-Systemen auch 64-Bit-Integer-Variablen können sogar einen inkonsistenten Zustand bekommen, wenn die Variable gleichzeitig in zwei Tasks geschrieben wird.

Ausnahme

In bestimmten Fällen kann es nötig sein, dass mehrere Tasks eine Variable schreiben. Stellen Sie dann sicher, beispielsweise durch die Verwendung von Semaphoren, dass der Zugriff nicht zu einem inkonsistenten Zustand führt.

Wichtigkeit

Hoch

PLCopen-Regel

CP10

Funktion

Ermittelt Stellen, an denen der ADR-Operator bei einer Konstanten angewendet wird.

Begründung

Durch einen Pointer auf eine konstante Variable hebt man die CONSTANT-Eigenschaft der Variable auf. Über den Pointer kann die Variable verändert werden, ohne dass der Compiler dies meldet.

Ausnahme

In seltenen Fällen kann es sinnvoll sein, einen Pointer auf eine Konstante an eine Funktion zu übergeben. Es muss dann allerdings gewährleistet sein, dass diese Funktion den übergebenen Wert nicht ändert. Verwenden Sie in diesem Fall wenn möglich VAR_IN_OUT CONSTANT.

Wichtigkeit

Hoch

Funktion

Ermittelt Bereichsüberschreitungen von Unterbereichstypen. Zugewiesene Literale werden bereits vom Compiler geprüft. Wenn Konstanten zugeordnet sind, müssen die Werte innerhalb des definierten Bereichs liegen. Wenn Variablen zugeordnet sind, müssen die Datentypen identisch sein.

Begründung

Wenn Unterbereichstypen verwendet werden, dann sollte sichergestellt werden, dass dieser Unterbereich nicht verlassen wird. Der Compiler überprüft solche Unterbereichsverletzungen nur für Zuweisungen von Konstanten.

Wichtigkeit

Niedrig

Funktion

Ermittelt Funktions-, Methoden- und Eigenschaftenaufrufe, bei denen der Rückgabewert nicht verwendet wird.

Begründung

Wenn eine Funktion oder eine Methode einen Rückgabewert liefert, dann sollte dieser auch ausgewertet werden. Häufig wird im Rückgabewert mitgeliefert, ob die Funktion erfolgreich ausgeführt werden konnte. Wenn keine Auswertung erfolgt, ist später nicht mehr erkennbar, ob der Rückgabewert übersehen wurde, oder ob er tatsächlich nicht benötigt wird.

Ausnahme

Wenn ein Rückgabewert beim Aufruf nicht von Interesse ist, dann kann dies dokumentiert und die Zuweisung weglassen werden. Fehlerrückgaben sollten nie ignoriert werden!

Wichtigkeit

Mittel

PLCopen-Regel

CP7/CP17

Funktion

Ermittelt Arrays, die nur eine einzige Komponente enthalten.

Begründung

Ein Array mit einer Komponente kann durch eine Variable vom Basistyp ersetzt werden. Der Zugriff auf diese Variable ist deutlich schneller als der Zugriff mit Index auf eine Variable.

Ausnahme

Häufig wird die Länge eines Arrays über eine Konstante festgelegt und ist ein Parameter für ein Programm. Das Programm kann dann mit Arrays von verschiedener Länge arbeiten und muss nicht geändert werden, wenn die Länge nur 1 beträgt. Eine solche Situation sollte entsprechend dokumentiert werden.

Wichtigkeit

Niedrig

Funktion

Ermittelt Strukturen, Unions oder Enumerationen mit höchstens einer Komponente.

Begründung

Eine solche Deklaration kann für einen Leser verwirrend sein. Eine Struktur mit nur einem Element kann durch einen Aliastyp ersetzt werden. Eine Enumeration mit einem Element kann durch eine Konstante ersetzt werden.

Wichtigkeit

Niedrig

PLCopen-Regel

CP22/CP24

Funktion

Ermittelt Variablen, auf die nicht schreibend zugegriffen wird und die deshalb als Konstante deklariert werden könnten.

Begründung

Wenn eine Variable nur an der Deklarationsstelle geschrieben und sonst nur lesend verwendet wird, dann nimmt die statische Analyse an, dass die Variable auch nicht geändert werden soll. Eine Deklaration als Konstante führt dann erstens dazu, dass auch bei Programmänderungen überprüft wird, dass die Variable nicht verändert wird. Zweitens führt die Deklaration als Konstante unter Umständen zu schnellerem Code.

Wichtigkeit

Niedrig

Funktion

Ermittelt Variablen, die den gleichen Namen haben wie andere Variablen (Beispiel: globale und lokale Variablen mit gleichen Namen), oder wie Funktionen, Aktionen, Methoden oder Eigenschaften (Properties) innerhalb des gleichen Zugriffsbereichs.

Begründung

Gleiche Namen können beim Lesen des Codes verwirrend sein und sie können zu Fehlern führen, wenn unbeabsichtigt auf das falsche Objekt zugegriffen wird. Es wird empfohlen, Namenskonventionen zu verwenden, deren Einhaltung solche Situationen vermeidet.

Wichtigkeit

Mittel

PLCopen-Regel

N5/N9

Funktion

Ermittelt Zuweisungen auf Funktionsbausteininstanzen. Bei Instanzen mit Pointer- oder Referenzvariablen können diese Zuweisungen riskant sein.

Begründung

Dies ist eine Performance-Warnung. Wenn eine Instanz einer anderen Instanz zugewiesen wird, dann werden alle Elemente und Unterelemente von der einen Instanz in die andere kopiert. Pointer auf Daten werden mitkopiert, jedoch nicht deren referenzierte Daten, so dass die Zielinstanz und die Quellinstanz nach der Zuweisung die gleichen Daten enthalten. Je nach Größe der Instanzen kann eine solche Zuweisung sehr lange dauern. Wenn eine Instanz beispielsweise zur Bearbeitung an eine Funktion übergeben werden soll, dann ist es sehr viel performanter, einen Pointer auf die Instanz zu übergeben.

Um selektiv Werte von einer Instanz in eine andere zu kopieren, kann eine Kopiermethode sinnvoll sein:

fb2.CopyFrom(fb1)

Wichtigkeit

Mittel

Funktion

Ermittelt Zugriffe eines Funktionsbausteins auf globale Daten über die FB_init-Methode. Der Wert dieser Variablen hängt von der Reihenfolge der Initialisierungen ab!

Begründung

Je nach Deklarationsstelle der Instanz eines Bausteins kann es sein, dass bei Verletzung der Regel auf eine nicht-initialisierte Variable zugegriffen wird.

Wichtigkeit

Hoch

Funktion

Ermittelt Lücken in Strukturen oder Funktionsbausteinen, verursacht durch die Alignment-Anforderungen des aktuell eingestellten Zielsystems. Wenn möglich, sollten Sie die Lücken durch Umsortieren der Strukturelemente oder durch Auffüllen mit einem Dummy-Elemententfernen. Wenn dies nicht möglich ist, dann können Sie die Regel für die betroffenen Strukturen durch das Attribut {attribute 'analysis' := '...'} deaktivieren.

Begründung

Durch unterschiedliche Alignment-Anforderungen auf verschiedenen Plattformen, kann es für solche Strukturen zu einem unterschiedlichen Layout im Speicher kommen. Der Code kann sich dann je nach Plattform unterschiedlich verhalten.

Wichtigkeit

Niedrig

Funktion

Ermittelt Zuweisungen auf Pointer, die keine Adresse (ADR-Operator, Zeigervariablen) oder Konstante 0 sind.

Begründung

Wenn ein Pointer einen Wert enthält, der keine gültige Adresse ist, dann kommt es bei der Dereferenzierung des Pointers zu einer Access Violation Exception.

Wichtigkeit

Hoch

Funktion

Ermittelt Bitzugriffe auf vorzeichenbehaftete Variablen. Die Norm IEC 61131-3 erlaubt allerdings nur Bitzugriffe auf Bitfelder. Sehen Sie hierzu auch die strikte Regel SA0148.

Begründung

Vorzeichenbehaftete Datentypen sollten nicht als Bitfelder verwendet werden und umgekehrt. Die Norm IEC 61131-3 sieht solche Zugriffe nicht vor. Diese Regel muss eingehalten werden, wenn der Code protierbar sein soll.

Ausnahme

Ausnahme für Flag-Enumerationen: Wenn eine Enumeration mit Hilfe des Pragmaattributs {attribute 'flags'} als Flag deklariert ist, wird für Bitzugriffe mit den Operationen OR, AND oder NOT der Fehler SA0018 nicht ausgegeben.

Wichtigkeit

Mittel

Funktion

Ermittelt Operationen auf Integer-Variablen, bei denen möglicherweise ein abgeschnittener Wert an eine Variable vom Datentyp REAL zugewiesen wird.

Begründung

Die statische Codeanalyse gibt einen Fehler aus, wenn das Ergebnis einer Integerberechnung einer REAL- oder LREAL-Variablen zugewiesen wird. Der Programmierer soll dabei auf eine möglicherweise fehlerhafte Interpretation einer solchen Zuweisung aufmerksam gemacht werden:

fLEAL := nDINT1 * nDINT2.

Da der Wertebereich von LREAL größer ist als der von DINT, könnte angenommen werden, dass das Ergebnis der Rechnung in jedem Fall in LREAL dargestellt wird. Das ist aber nicht der Fall. Der Prozessor berechnet das Ergebnis der Multiplikation als Integer und castet anschließend das Ergebnis nach LREAL. Ein Überlauf in der Integer-Berechnung würde verloren gehen. Um das Problem zu umgehen, muss die Rechnung bereits als REAL-Operation erfolgen:

fLREAL := TO_LREAL(nDINT1) * TO_LREAL(nDINT2)

Wichtigkeit

Hoch

Funktion

Ermittelt Zuweisungen von Adressen von temporären Variablen (Variablen auf dem Stack) zu nicht-temporären Variablen.

Begründung

Lokale Variablen einer Funktion oder einer Methode werden auf dem Stack angelegt und existieren nur während der Abarbeitung der Funktion oder Methode. Zeigt ein Pointer nach Abarbeitung der Methode oder Funktion auf eine solche Variable, dann kann über diesen Pointer in undefinierten Speicher gegriffen, oder auf eine falsche Variable in einer anderen Funktion zugegriffen werden. Diese Situation ist in jedem Fall zu vermeiden.

Wichtigkeit

Hoch

Funktion

Ermittelt alle Funktionen und Methoden, die einen Ausführungsstrang ohne Zuweisung auf den Rückgabewert enthalten.

Begründung

Ein nicht zugewiesener Rückgabewert in einer Funktion oder Methode deutet auf fehlenden Code hin. Auch wenn der Rückgabewert in jedem Fall einen Standardwert hat, ist es immer sinnvoll, diesen nochmal explizit zuzuweisen, um Unklarheiten zu vermeiden.

Wichtigkeit

Mittel

Funktion

Ermittelt komplexe Rückgabewerte, die mit einer einfachen Registerkopie des Prozessors nicht zurückgegeben werden können. Dazu gehören Strukturen und Arrays sowie Rückgabewerte vom Typ STRING (unabhängig von der Größe des belegten Speicherplatzes).

Begründung

Dies ist eine Performance-Warnung. Wenn große Werte als Ergebnis einer Funktion, Methode oder einer Eigenschaft zurückgeliefert werden, dann werden diese vom Prozessor bei der Ausführung des Codes mehrfach umkopiert. Das kann zu Laufzeitproblemen führen und sollte wenn möglich vermieden werden. Eine bessere Performance wird erreicht, wenn ein strukturierter Wert als VAR_IN_OUT an eine Funktion oder Methode übergeben wird und in der Funktion oder Methode gefüllt wird.

Wichtigkeit

Mittel

Funktion

Ermittelt nicht getypte Literale/Konstanten (z.B. nCount : INT := 10;).

Begründung

TwinCAT vergibt die Typen für Literale je nach ihrer Verwendung. In einigen Fällen kann dies zu unerwarteten Situationen führen, die besser über ein getyptes Literal geklärt werden. Zum Beispiel:

nDWORD := ROL(DWORD#1, i);

Wichtigkeit

Niedrig

Funktion

Ermittelt Aufzählungskonstanten, die nicht mit einem qualifizierten Namen verwendet werden, d.h. ohne dass der Name der Enumeration vorangestellt ist.

Begründung

Qualifizierte Zugriffe machen den Code besser lesbar und besser wartbar. Ohne Erzwingen qualifizierter Variablennamen könnte bei Erweiterung des Programms eine weitere Enumeration eingefügt werden, die eine gleichnamige Konstante wie die einer bereits existierenden Enumeration enthält (siehe im Beispiel unten: “eRed”). Dann käme es zu einem nicht-eindeutigen Zugriff in diesem Codestück. Wir empfehlen in jedem Fall nur Enumerationen zu verwenden, die das {attribute ‘qualified-only’} tragen.

Wichtigkeit

Mittel

Funktion

Ermittelt String-Zuweisungen und -Initialisierungen, die keine ausreichende String-Länge verwenden.

Begründung

Wenn Strings unterschiedlicher Länge zugewiesen werden, dann wird möglicherweise ein String abgeschnitten. Das Ergebnis ist dann nicht das erwartete.

Wichtigkeit

Mittel

Funktion

Ermittelt die Mehrfachverwendung eines Namens/Bezeichners einer Variable oder eines Objekts (POU) innerhalb des Gültigkeitsbereichs eines Projekts. Die folgenden Fälle werden abgedeckt:

• Der Name einer Enumerationskonstanten ist identisch mit dem Namen in einer anderen Enumeration innerhalb der Applikation oder in einer eingebundenen Bibliothek.
• Der Name einer Variablen ist identisch mit dem Namen eines anderen Objekts in der Applikation oder in einer eingebundenen Bibliothek.
• Der Name einer Variablen ist identisch mit dem Namen einer Enumerationskonstanten in einer Enumeration in der Applikation oder in einer eingebundenen Bibliothek.
• Der Name eines Objekts ist identisch mit dem Namen eines anderen Objekts in der Applikation oder in einer eingebundenen Bibliothek.

Begründung

Gleiche Namen können beim Lesen des Codes verwirrend sein. Sie können zu Fehlern führen, wenn unbeabsichtigt auf das falsche Objekt zugegriffen wird. Definieren und befolgen Sie deshalb Namenskonventionen zur Vermeidung solcher Situationen.

Ausnahme

Enumerationen, die mit dem Attribut 'qualified_only' deklariert sind, sind von der SA0027-Prüfung ausgenommen, da auf ihre Elemente nur qualifiziert zugegriffen werden kann.

Wichtigkeit

Mittel

Funktion

Ermittelt die Stellen, durch die zwei oder mehr Variablen denselben Speicherplatz belegen.

Begründung

Wenn zwei Variablen auf dem gleichen Speicherplatz liegen, dann kann sich der Code sehr unerwartet verhalten. Dies ist in jedem Fall zu vermeiden. Wenn es unumgänglich ist, einen Wert in verschiedenen Interpretationen zu verwenden, zum Beispiel einmal als DINT und einmal als REAL, dann sollten Sie eine UNION definieren. Auch über einen Pointer können Sie auf einen Wert anders getypt zugreifen, ohne dass der Wert umgewandelt wird.

Wichtigkeit

Hoch

Funktion

Ermittelt die Codestellen (in der Implementierung), an denen sich die Notation eines Bezeichners zur Notation in dessen Deklaration unterscheidet.

Begründung

Die Norm IEC 61131-3 definiert Bezeichner als nicht case-sensitiv. Das heißt, eine Variable die als “varx” deklariert wurde, kann im Code auch als “VaRx” verwendet werden. Dies ist jedoch verwirrend und irreführend und sollte daher vermieden werden.

Wichtigkeit

Mittel

Funktion

Ermittelt Programme, Funktionsbausteine, Funktionen, Datentypen, Schnittstellen, Methoden, Eigenschaften, Aktionen etc., die innerhalb des kompilierten Programmcodes nicht aufgerufen werden.

Begründung

Nicht verwendete Objekte vergrößern das Projekt unnötig und können beim Lesen des Codes verwirren.

Wichtigkeit

Niedrig

PLCopen-Regel

CP2

Funktion

Ermittelt Enumerationskonstanten, die nicht im kompilierten Programmcode verwendet werden.

Begründung

Nicht verwendete Enumerationskonstanten vergrößern die Enumerationsdefinition unnötig und können beim Lesen des Programms verwirren.

Wichtigkeit

Niedrig

PLCopen-Regel

CP24

Funktion

Ermittelt Variablen, die deklariert sind, aber innerhalb des kompilierten Programmcodes nicht verwendet werden.

Begründung

Nicht verwendete Variablen machen ein Programm weniger gut lesbar und wartbar. Nicht verwendete Variablen belegen unnötig Speicher und kosten bei der Initialisierung unnötig Laufzeit.

Wichtigkeit

Mittel

PLCopen-Regel

CP22/CP24

Funktion

Ermittelt Eingangsvariablen, die innerhalb des jeweiligen Funktionsbausteins nicht zugewiesen werden.

Begründung

Nicht verwendete Variablen machen ein Programm weniger gut lesbar und wartbar. Nicht verwendete Variablen belegen unnötig Speicher und kosten bei der Initialisierung unnötig Laufzeit.

Wichtigkeit

Mittel

PLCopen-Regel

CP24

Funktion

Ermittelt Ausgangsvariablen, die innerhalb des jeweiligen Funktionsbausteins nicht zugewiesen werden.

Begründung

Nicht verwendete Variablen machen ein Programm weniger gut lesbar und wartbar. Nicht verwendete Variablen belegen unnötig Speicher und kosten bei der Initialisierung unnötig Laufzeit.

Wichtigkeit

Mittel

PLCopen-Regel

CP24

Funktion

Ermittelt Werte, die einer Enumerationsvariablen zugewiesen sind. Einer Enumerationsvariablen dürfen nur definierte Enumerationskonstanten zugewiesen werden.

Begründung

Eine Variable vom Typ einer Enumeration sollte auch nur die vorgesehenen Werte haben, anderfalls funktioniert Code, der diese Variable verwendet möglicherweise nicht richtig. Wir empfehlen, Enumerationen immer mit dem {attribute 'strict'} zu verwenden. Dann prüft bereits der Compiler die korrekte Verwendung der Enumerationskomponenten.

Wichtigkeit

Hoch

Funktion

Ermittelt Eingangsvariablen (VAR_INPUT), auf die innerhalb der POU schreibend zugegriffen wird.

Begründung

Nach der Norm IEC 61131-3 darf eine Eingabevariable nicht innerhalb eines Bausteins verändert werden. Ein solcher Zugriff ist außerdem eine Fehlerquelle und macht den Code schlecht wartbar. Es weist daraufhin, dass eine Variable als Eingang und gleichzeitig als Hilfsvariable verwendet wird. Eine solche Doppelverwendung sollte vermieden werden.

Wichtigkeit

Mittel

Funktion

Ermittelt Ausgangsvariablen (VAR_OUTPUT), auf die innerhalb der POU lesend zugegriffen wird.

Begründung

Nach 61131-3 ist es verboten, einen Ausgang innerhalb eines Bausteins zu lesen. Es weist darauf hin, dass der Ausgang nicht nur als Ausgang sondern gleichzeitig als temporäre Variable für Zwischenergebnisse verwendet wird. Eine solche Doppelverwendung sollte vermieden werden.

Wichtigkeit

Niedrig

Funktion

Ermittelt Codestellen, an denen möglicherweise durch Null dividiert wird.

Begründung

Eine Division durch 0 ist nicht erlaubt. Eine Variable durch die dividiert wird, sollte immer vorher auf 0 überprüft werden. Andernfalls kann es zu einer "Divide by Zero"-Exception zur Laufzeit kommen.

Wichtigkeit

Hoch

Funktion

Ermittelt möglicherweise schleifeninvarianten Code, d.h. Code innerhalb einer FOR-, WHILE- oder REPEAT-Schleife, der bei jedem Schleifendurchlauf zum gleichen Ergebnis führt, also unnötigerweise immer wieder ausgeführt wird. Dabei werden nur Berechnungen berücksichtigt, keine einfachen Zuweisungen.

Begründung

Dies ist eine Performance-Warnung. Code, der in einer Schleife ausgeführt wird, aber in jedem Schleifendurchlauf das gleiche tut, kann außerhalb der Schleife durchgeführt werden.

Wichtigkeit

Mittel

Funktion

Ermittelt die Verwendung unterschiedlicher Zugriffspfade für die gleiche Variable.

Begründung

Unterschiedlicher Zugriff auf das gleiche Element reduziert die Lesbarkeit und Wartbarkeit eines Programms. Wir empfehlen die konsequente Verwendung von {attribute 'qualified-only'} für Bibliotheken, globale Variablenlisten und Enumerationen. Dadurch wird der vollqualifizierte Zugriff erzwungen.

Wichtigkeit

Niedrig

Funktion

Ermittelt globale Variablen, die nur in einer einzigen POU verwendet werden.

Begründung

Eine globale Variable, die nur an einer Stelle verwendet wird, sollte auch an dieser einen Stelle deklariert sein.

Wichtigkeit

Mittel

PLCopen-Regel

CP26

Funktion

Ermittelt Deklarationen mit REFERENCE TO <Schnittstelle> und Deklarationen von VAR_IN_OUT-Variablen mit dem Typ einer Schnittstelle (implizit über REFERENCE TO realisiert).

Begründung

Ein Schnittstellentyp ist immer implizit eine Referenz auf eine Instanz eines Funktionsbausteins, der diese Schnittstelle implementiert. Eine Referenz auf eine Schnittstelle ist demnach eine Referenz auf eine Referenz und kann zu sehr unerwünschtem Verhalten führen.

Wichtigkeit

Hoch

Funktion

Ermittelt implizit erzeugte Pointer-Datentyp-Konvertierungen.

Begründung

Pointer sind in TwinCAT nicht streng getypt und können einander beliebig zugewiesen werden. Dies wird häufig genutzt und deswegen auch nicht vom Compiler gemeldet. Allerdings kann es dadurch auch ungewollt zu unerwarteten Zugriffen kommen. Wenn ein POINTER TO BYTE einem POINTER TO DWORD zugewiesen wird, ist es möglich, dass über den letzten Pointer ungewollt Speicher überschrieben wird. Lassen Sie diese Regel deshalb in jedem Fall prüfen und unterdrücken Sie die Meldung nur in den Fällen, in denen Sie bewusst anders getypt auf einen Wert zugreifen wollen.

Implizite Datentyp-Konvertierungen werden mit einer anderen Meldung gemeldet.

Ausnahme

BOOL ↔ BIT

Wichtigkeit

Hoch

PLCopen-Regel

CP25

Funktion

Ermittelt implizit durchgeführte Konvertierungen von kleineren auf größere Datentypen.

Begründung

Der Compiler erlaubt jegliche Zuweisungen von unterschiedlichen Typen, wenn der Wertebereich des Quelltyps vollständig im Wertebereich des Zieltyps enthalten ist. Allerdings baut der Compiler eine Konvertierung so spät wie möglich in den Code ein. Bei einer Zuweisung der folgenden Art:

nLINT := nDINT * nDINT;

führt der Compiler die implizite Konvertierung erst nach der Multiplikation durch:

nLINT := TO_LINT(nDINT * nDINT);

Ein Überlauf wird daher abgeschnitten. Wenn Sie das verhindern wollen, können Sie die Konvertierung bereits für die Elemente durchführen lassen:

nLINT := TO_LINT(nDINT) * TO_LINT(nDINT);

Es kann daher sinnvoll sein, sich Stellen melden zu lassen, an denen der Compiler implizite Konvertierungen einbaut, um zu prüfen, ob diese genau so gewollt sind. Außerdem können explizite Konvertierungen zu besserer Portierbarkeit auf andere Systeme dienen, wenn diese restriktivere Typprüfungen haben.

Ausnahme

BOOL ↔ BIT

Wichtigkeit

Niedrig

Funktion

Ermittelt implizit durchgeführte Konvertierungen von größeren auf kleinere Datentypen.

Ausnahme

BOOL ↔ BIT

Wichtigkeit

Niedrig

Funktion

Ermittelt implizit durchgeführte Konvertierungen von vorzeichenbehafteten auf vorzeichenlose Datentypen oder umgekehrt.

Wichtigkeit

Niedrig

Funktion

Ermittelt explizit durchgeführte Konvertierungen von einem größeren auf einen kleineren Datentyp.

Begründung

Eine große Zahl von Typkonvertierungen kann bedeuten, dass falsche Datentypen für Variablen gewählt wurden. Es gibt daher Programmierrichtlinien, die eine explizite Begründung für Datentypkonvertierungen fordern.

Wichtigkeit

Niedrig

Funktion

Ermittelt explizit durchgeführte Konvertierungen von vorzeichenbehafteten auf vorzeichenlose Datentypen oder umgekehrt.

Begründung

Ein übermäßiger Gebrauch von Typkonvertierungen kann bedeuten, dass falsche Datentypen für Variablen gewählt wurden. Es gibt daher Programmierrichtlinien, die eine explizite Begründung für Datentypkonvertierungen fordern.

Wichtigkeit

Niedrig

Funktion

Ermittelt ungültige Adress- und Datentypspezifikationen.

Für Adressen sind die folgenden Größenpräfixe gültig. Abweichungen davon führen zu einer ungültigen Adressspezifikation.

• X für BOOL
• B für 1-Byte-Datentypen
• W für 2-Byte-Datentypen
• D für 4-Byte-Datentypen

Begründung

Variablen, die auf direkten Adressen liegen, sollten möglichst mit einer Adresse assoziiert werden, die ihrer Datentypbreite entspricht. Es kann für den Leser des Codes zur Verwirrung führen, wenn beispielsweise ein DWORD auf eine BYTE-Adresse gelegt wird.

Wichtigkeit

Niedrig

Funktion

Ermittelt direkte Adresszugriffe im Implementierungscode.

Begründung

Symbolische Programmierung ist immer zu bevorzugen: Eine Variable hat einen Namen, der auch eine Bedeutung tragen kann. Einer Adresse ist nicht ansehbar, wofür diese verwendet wird.

Wichtigkeit

Hoch

PLCopen-Regel

N1/CP1

Funktion

Ermittelt AT-Deklarationen auf direkte Adressen.

Begründung

Die Verwendung von direkten Adressen im Code ist eine Fehlerquelle und führt zu schlechterer Lesbarkeit und Wartbarkeit des Codes.

Daher wird die Verwendung der Platzhalter %I* oder %Q* empfohlen, bei denen TwinCAT eine flexible und optimierte Adressierung automatisch durchführt.

Wichtigkeit

Hoch

PLCopen-Regel

N1/CP1

Funktion

Ermittelt Vergleichsoperationen auf Variablen vom Typ BOOL.

Begründung

TwinCAT erlaubt solche Vergleiche, diese sind aber zumindest sehr unüblich und können verwirrend sein. Die Norm IEC-61131-3 sieht diese Vergleiche nicht vor, daher sollten Sie sie vermeiden.

Wichtigkeit

Mittel

Funktion

Ermittelt Schiebeoperationen (Bit-Shift) auf vorzeichenbehaftete Variablen. Die Norm IEC 61131-3 erlaubt allerdings nur Schiebeoperationen auf Bitfelder. Sehen Sie hierzu auch die strikte Regel SA0147.

Begründung

TwinCAT erlaubt Schiebeoperationen auf vorzeichenbehafteten Datentypen. Diese Operationen sind aber unüblich und können verwirrend sein. Die Norm IEC-61131-3 sieht solche Operationen nicht vor, daher sollten Sie sie vermeiden.

Ausnahme

Im Falle von Schiebeoperationen auf Bitfeld-Datentypen (Byte, DWORD, LWORD, WORD) wird kein Fehler SA0052 ausgegeben.

Wichtigkeit

Mittel

Funktion

Ermittelt bei bitweiser Verschiebung (Bitverschiebung/Bit-Shift) von Operanden, ob dessen Datentyp-Breite überschritten wurde.

Begründung

Wenn eine Verschiebeoperation über die Datentypbreite hinausgeht, wird eine Konstante 0 erzeugt. Wenn eine Rotationsverschiebung über die Datentypbreite hinausgeht, dann ist das schwer zu lesen und der Rotationswert sollte deswegen gekürzt werden.

Wichtigkeit

Hoch

Funktion

Ermittelt, wo die Vergleichsoperatoren = (Gleichzeit) und <> (Ungleichheit) Operanden vom Typ REAL oder LREAL vergleichen.

Begründung

REAL/LREAL-Werte werden als Gleitzahlen nach dem Standard IEEE 754 implementiert. Dieser Standard bringt es mit sich, dass bestimmte scheinbar einfache Dezimalzahlen nicht exakt dargestellt werden können. Das hat zur Folge, dass es für dieselbe Dezimalzahl unterschiedliche Repräsentationen als LREAL geben kann.

Beispiel:

fLREAL_11 := 1.1;
fLREAL_33 := 3.3;
fLREAL_a := fLREAL_11 + fLREAL_11;
fLREAL_b := fLREAL_33 – fLREAL_11;
bTest := fLREAL_a = fLREAL_b;

bTest wird in diesem Fall FALSE liefern, auch wenn die Variablen fLREAL_a und fLREAL_b beide den Monitoring-Wert “2.2” liefern. Das ist kein Fehler des Compilers, sondern eine Eigenschaft der Gleitkomma-Einheiten aller üblichen Prozessoren. Vermeiden können Sie das, indem Sie einen Mindestwert angeben, um den sich die Werte unterscheiden dürfen:

bTest := ABS(fLREAL_a – fLREAL_b) < 0.1;

Ausnahme

Ein Vergleich mit 0.0 wird nicht von dieser Analyse gemeldet. Für die 0 gibt es im Standard IEEE 754 eine exakte Darstellung und daher funktioniert der Vergleich normalerweise wie erwartet. Für eine bessere Performance ist es daher sinnvoll, hier einen direkten Vergleich zuzulassen.

Wichtigkeit

Hoch

PLCopen-Regel

CP54

Funktion

Ermittelt unnötige Vergleiche mit vorzeichenlosen Operanden. Ein vorzeichenloser Datentyp ist nie kleiner Null.

Begründung

Ein mit dieser Prüfung aufgedeckter Vergleich liefert ein konstantes Ergebnis und das deutet auf einen Fehler im Code hin.

Wichtigkeit

Hoch

Funktion

Ermittelt Literale (Konstanten) außerhalb des für den Operator gültigen Bereichs.

Begründung

Die Meldung wird für Fälle ausgegeben, in denen eine Variable mit einer Konstanten verglichen wird, die außerhalb des Wertebereichs dieser Variablen liegt. Der Vergleich liefert dann konstant TRUE oder FALSE. Dies deutet auf einen Programmierfehler hin.

Wichtigkeit

Hoch

Funktion

Ermittelt Anweisungen mit möglichem Verlust von Dezimalstellen.

Begründung

Ein Codestück der folgenden Art:

nDINT := 1;
fREAL := TO_REAL(nDINT / DINT#2);

kann zu einer Fehlinterpretation führen. Diese Codezeile kann zu der Annahme führen, die Division würde als REAL-Operation durchgeführt und das Ergebnis würde in diesem Fall REAL#0.5 sein. Dies ist jedoch nicht der Fall, die Operation wird als Integer-Operation durchgeführt, das Ergebnis wird auf REAL gecastet und fREAL erhält den Wert REAL#0. Um dies zu vermeiden, sollten Sie durch einen Cast dafür sorgen, dass die Operation als REAL-Operation durchgeführt wird:

fREAL := TO_REAL(nDINT) / REAL#2;

Wichtigkeit

Mittel

Funktion

Ermittelt Operationen auf Variablen vom Typ einer Enumeration. Zuweisungen sind erlaubt.

Begründung

Enumerationen sollten nicht als normale Integer-Werte verwendet werden. Alternativ kann ein Alias-Datentyp definiert oder einen Subrange-Typ verwendet werden.

Ausnahme

Wenn eine Enumeration mit dem Attribut {attribute 'strict'} gekennzeichnet ist, dann meldet bereits der Compiler eine solche Operation.

Wenn eine Enumeration mit Hilfe des Pragmaattributs {attribute 'flags'} als Flag deklariert ist, wird für Operationen mit AND, OR, NOT, XOR kein Fehler SA0058 ausgegeben.

Wichtigkeit

Mittel

Funktion

Ermittelt Vergleiche mit Literalen, die immer das Ergebnis TRUE bzw. FALSE haben und die bereits während der Kompilierung ausgewertet werden können.

Begründung

Eine Operation, die konstant TRUE oder FALSE liefert, ist ein Hinweis auf einen Programmierfehler.

Wichtigkeit

Hoch

Funktion

Ermittelt Operationen, in denen ein Operand mit Wert 0 zu einer ungültigen und nicht sinnvollen Operation führt.

Begründung

Ein solcher Ausdruck kann auf einen Programmierfehler hindeuten. In jedem Fall kostet er unnötig Laufzeit.

Wichtigkeit

Mittel

Funktion

Ermittelt Operationen auf Variablen vom Typ POINTER TO, die nicht = (Gleichheit), <> (Ungleichheit), + (Addition) oder ADR sind.

Begründung

In TwinCAT ist Pointer-Arithmetik grundsätzlich erlaubt und kann auch sinnvoll eingesetzt werden. Als übliche Operation auf Pointer wird daher die Addition eines Pointers mit einem Integerwert eingestuft. Damit ist es möglich, mit Hilfe eines Pointers ein Array mit variabler Länge zu bearbeiten. Alle anderen (unüblichen) Operationen mit Pointer werden mit SA0061 gemeldet.

Wichtigkeit

Hoch

PLCopen-Regel

E2/E3

Funktion

Ermittelt die Verwendung der Literale TRUE bzw. FALSE in Ausdrücken (z.B. b2 := b1 AND NOT TRUE oder IF (bVar = FALSE) THEN).

Begründung

Ein solcher Ausdruck ist offensichtlich unnötig und kann auf einen Fehler hindeuten. In jedem Fall belastet ein solcher Ausdruck unnötig die Lesbarkeit und ggf. auch die Laufzeit.

Wichtigkeit

Mittel

Funktion

Ermittelt 16-Bit-Operationen mit Zwischenergebnissen. Hintergrund: Auf 16-Bit-Systemen können 32-Bit-Zwischenergebnisse abgeschnitten werden.

Begründung

Diese Meldung soll in dem sehr seltenen Fall vor Problemen schützen, wenn Code geschrieben wird, der sowohl auf einem 16-Bit-Prozessor als auch auf einem 32-Bi- Prozessor laufen soll.

Wichtigkeit

Niedrig

Funktion

Ermittelt alle Additionen von Pointern.

Begründung

In TwinCAT ist Pointer-Arithmetik grundsätzlich erlaubt und kann auch sinnvoll eingesetzt werden. Allerdings ist es auch eine Fehlerquelle. Deswegen gibt es Programmiervorschriften, die Pointer-Arithmetik grundsätzlich verbieten. Eine solche Vorschrift kann mit diesem Test überprüft werden.

Wichtigkeit

Mittel

Funktion

Ermittelt Pointer-Additionen, bei denen der zu addierende Wert nicht zur Basis-Datengröße des Pointers passt. Nur Literale der Basisgröße dürfen addiert werden. Es dürfen auch keine Multiplikationen der Basisgröße addiert werden.

Begründung

In TwinCAT (im Gegensatz zu C und C++) wird bei einer Addition eines Pointers mit einem Integerwert nur dieser Integerwert als Anzahl der Bytes addiert, und nicht der Integerwert mit der Basisgröße multipliziert. Zum Beispiel in ST:

pINT := ADR(array_of_int[0]);
pINT := pINT + 2 ; // in TwinCAT zeigt pINT anschließend auf array_of_int[1]

Dieser Code würde in C anders funktionieren:

short* pShort
pShort = &(array_of_short[0])
pShort = pShort + 2; // in C zeigt pShort anschließend auf array_of_short[2]

Daher sollte in TwinCAT immer ein Vielfaches der Basisgröße des Pointers zu einem Pointer addiert werden. Andernfalls zeigt der Pointer möglicherweise auf einen nicht-alignten Speicher, was (je nach Prozessor) beim Zugriff zu einer "Alignment"-Exception führen kann.

Wichtigkeit

Hoch

Funktion

Ermittelt Verwendungen von Zwischenergebnissen in Anweisungen mit einem Datentyp, der kleiner als die Registergröße ist. Der implizite Cast in diesem Fall führt gegebenenfalls zu unerwünschten Ergebnissen.

Begründung

TwinCAT führt aus Performancegründen Operationen auf der Registerbreite des Prozessors aus. Zwischenergebnisse werden nicht abgeschnitten! Das kann zu Fehlinterpretationen führen, wie im folgenden Fall:

usintTest := 0;
bError := usintTest - 1 <> 255;

In TwinCAT ist bError in diesem Fall TRUE, weil die Operation usintTest - 1 typischerweise als 32-Bit-Operation ausgeführt wird und das Ergebnis nicht auf die Größe von Byte gecastet wird. Im Register steht dann der Wert 16#ffffffff und dieser ist ungleich 255.Um dies zu umgehen müssen Sie das Zwischenergebnis explizit casten:

bError := TO_USINT(usintTest - 1) <> 255;

Wichtigkeit

Niedrig

Funktion

Ermittelt Schreibzugriffe auf eine Zählervariablen innerhalb einer FOR-Schleife.

Begründung

Eine Manipulation der Zählervariablen in einer FOR-Schleife kann leicht zu einer Endlosschleife führen. Um die Ausführung der Schleife für bestimmte Werte der Zählervariablen zu unterbinden, arbeiten Sie mit CONTINUE oder einfach mit einem IF.

Wichtigkeit

Hoch

PLCopen-Regel

L12

Funktion

Ermittelt die Verwendung von nicht-temporären Variablen in FOR-Schleifen.

Begründung

Dies ist eine Performance-Warnung. Eine Zählervariable wird in jedem Fall bei jedem Aufruf eines Programmierbausteins initialisiert. Sie können eine solche Variable als temporäre Variable (VAR_TEMP) anlegen, ein Zugriff darauf ist unter Umständen schneller und die Variable belegt keinen dauerhaften Speicherplatz.

Wichtigkeit

Mittel

PLCopen-Regel

CP21/L13

Funktion

Ermittelt FOR-Anweisungen, bei denen die Indexvariable für den Zugriff auf einen Array-Index verwendet wird und den Bereich des Array-Index überschreitet.

Begründung

Arrays werden typischerweise in FOR-Schleifen bearbeitet. Anfangs- und Endwert der Zählervariable sollte dabei typischerweise mit der Unter- und Obergrenze des Arrays übereinstimmen oder zumindest diese nicht überschreiten. Hier wird eine typische Fehlerursache erkannt, wenn Arraygrenzen geändert werden und nicht sorgfältig mit Konstanten gearbeitet wird, oder wenn aus Versehen in der FOR-Schleife ein anderer Wert verwendet wird als bei der Array-Deklaration.

Wichtigkeit

Hoch

Funktion

Ermittelt FOR-Anweisungen, bei denen die Obergrenze nicht mit einem konstanten Wert definiert ist.

Begründung

Wenn die Obergrenze einer Schleife ein variabler Wert ist, dann lässt sich nicht mehr erkennen, wie oft eine Schleife ausgeführt wird. Dies kann zur Laufzeit zu gravierenden Problemen führen, im schlimmsten Fall zu einer Endlosschleife.

Wichtigkeit

Hoch

Funktion

Ermittelt CASE-Anweisungen ohne ELSE-Zweig.

Begründung

Defensive Programmierung fordert das Vorhandensein eines ELSE in jeder CASE-Anweisung. Wenn im ELSE-Fall nichts zu tun ist, dann sollten Sie dies durch einen Kommentar kennzeichnen. Dem Leser des Codes ist dann klar, dass der Fall nicht einfach vergessen wurde.

Ausnahme

Ein fehlender ELSE-Zweig wird nicht als fehlend berichtet, wenn in der CASE-Anweisung eine Enumeration verwendet wird, die mit dem Attribut 'strict' deklariert ist, und wenn in dieser CASE-Anweisung alle Enumerationskonstanten aufgeführt sind.

Wichtigkeit

Niedrig

PLCopen-Regel

L17

Funktion

Ermittelt Codepositionen, wo eine Enumerationsvariable als Bedingung verwendet wird und nicht alle Enumerationswerte als CASE-Zweige behandelt sind.

Begründung

Defensive Programmierung erfordert die Bearbeitung aller möglichen Werte einer Enumeration. Wenn für einen bestimmten Enumerationswert keine Aktion nötig ist, dann sollten Sie dies explizit durch einen Kommentar kennzeichnen. Damit wird deutlich, dass der Wert nicht einfach vergessen wurde.

Wichtigkeit

Niedrig

Funktion

Ermittelt Codepositionen, wo der Datentyp einer Bedingung nicht mit dem des CASE-Zweigs übereinstimmt.

Begründung

Wenn die Datentypen zwischen der CASE-Variable und dem CASE-Fall nicht übereinstimmen, dann könnte das auf einen Fehler hindeuten.

Wichtigkeit

Niedrig

Funktion

Ermittelt CASE-Anweisungen ohne Fälle, d.h. mit nur einer ELSE-Anweisung.

Begründung

Ein CASE-Statement ohne Fälle kostet nur Zeit in der Ausführung und ist schwer zu lesen.

Wichtigkeit

Mittel

Funktion

Ermittelt Codepositionen, wo die RETURN-Anweisung nicht die letzte Anweisung in einer Funktion, Methode, Eigenschaft oder in einem Programm ist.

Begründung

Ein RETURN im Code führt zu schlechterer Wartbarkeit, Testbarkeit und Lesbarkeit des Codes. Ein RETURN im Code wird leicht übersehen. Sie müssen Code, der auf alle Fälle beim Austritt einer Funktion ausgeführt werden sollte, vor jedem RETURN einfügen und das wird oft vergessen.

Wichtigkeit

Mittel

PLCopen-Regel

CP14

Funktion

Ermittelt Zuweisungen in Bedingungen von IF-, CASE-, WHILE- oder REPEAT-Konstrukten.

Begründung

Ein Zuweisung (:=) und ein Vergleich (=) kann leicht verwechselt werden. Eine Zuweisung in einer Bedingung kann daher leicht unabsichtlich erfolgt sein und wird deswegen gemeldet. Auch der Leser des Codes kann dadurch verwirrt werden.

Wichtigkeit

Hoch

Funktion

Ermittelt Variablen, die mehr als n Bytes verwenden, wobei n durch die aktuelle Konfiguration vorgegeben ist.

Den Parameter, der bei dieser Prüfung berücksichtigt wird, können Sie konfigurieren, indem Sie innerhalb der Regelkonfiguration auf die Zeile von Regel 100 doppelklicken (SPS-Projekteigenschaften > Kategorie "Static Analysis" > Registerkarte "Regeln" > Regel 100). In dem aufgehenden Dialog können Sie folgende Einstellungen vornehmen:

• Obergrenze in Bytes (Standardwert: 1024)

Begründung

Manche Programmierrichtlinien legen eine maximale Größe für eine einzelne Variable fest. Dies kann hiermit überprüft werden.

Wichtigkeit

Niedrig

Funktion

Ermittelt Namen mit unzulässiger Länge. Der Name von Objekten muss eine definierte Länge haben.

Die Parameter, die bei dieser Prüfung berücksichtigt werden, können Sie konfigurieren, indem Sie innerhalb der Regelkonfiguration auf die Zeile von Regel 101 doppelklicken (SPS-Projekteigenschaften > Kategorie "Static Analysis" > Registerkarte "Regeln" > Regel 101). In dem aufgehenden Dialog können Sie folgende Einstellungen vornehmen:

• Minimale Anzahl an Zeichen (Standardwert: 5)
• Maximale Anzahl an Zeichen (Standardwert: 30)
• Ausnahmen

Begründung

In manchen Programmierrichtlinien wird eine Mindestlänge für Variablennamen festgelegt. Die Einhaltung kann mit dieser Analyse überprüft werden.

Wichtigkeit

Niedrig

PLCopen-Regel

N6

Funktion

Ermittelt Zugriffe von außen auf lokale Variablen von Programmen oder Funktionsbausteinen.

Begründung

TwinCAT ermittelt Schreibzugriffe von außen auf lokale Variablen von Programmen oder Funktionsbausteinen als Kompilierfehler. Da Lesezugriffe auf lokale Variablen nicht vom Compiler abgefangen werden und dies mit dem Grundsatz der Datenkapselung (Verbergen von Daten) bricht und nicht der Norm IEC 61131-3 entspricht, kann diese Regel verwendet werden, um Lesezugriffe auf lokale Variablen zu ermitteln.

Wichtigkeit

Mittel

Funktion

Ermittelt nicht-atomare Variablen (zum Beispiel mit Datentyp STRING, WSTRING, ARRAY, STRUCT, FB-Instanzen, 64-Bit Datentypen), die in mehr als einer Task verwendet werden.

Begründung

Wenn keine Synchronisation beim Zugriff erfolgt, dann kann es bei gleichzeitigem Lesen in einer Task und Schreiben in einer anderen Task dazu kommen, dass inkonsistente Werte gelesen werden.

Ausnahme

In folgenden Fällen greift diese Regel nicht:

• Wenn das Zielsystem eine FPU (Floating Point Unit) besitzt, wird der Zugriff mehrerer Tasks auf LREAL-Variablen nicht ermittelt und gemeldet.
• Wenn das Zielsystem ein 64-Bit Prozessor ist bzw. "TwinCAT RT (x64)" als Solution-Plattform ausgewählt ist, greift die Regel nicht für 64-Bit Datentypen.

Wichtigkeit

Mittel

Funktion

Ermittelt und meldet Instanzen von Funktionsbausteinen, die mehr als einmal aufgerufen werden. Damit eine Fehlermeldung für eine mehrfach aufgerufene Instanz eines Funktionsbausteins generiert wird, muss im Deklarationsteil des Funktionsbausteins das Attribut {attribute 'analysis:report-multiple-instance-calls'} hinzugefügt werden.

Begründung

Einige Funktionsblöcke sind so designt, dass sie nur einmal im Zyklus aufgerufen werden können. Dieser Test prüft, ob ein Aufruf an mehreren Stellen erfolgt.

Wichtigkeit

Niedrig

PLCopen-Regel

CP16/CP20

Funktion

Ermittelt Methodenaufrufe in der Methode FB_init eines Basis-Funktionsbausteins, die von einem vom Basis-FB abgeleiteten Funktionsbaustein überschrieben werden.

Begründung

In solchen Fällen kann es sein, dass die Variablen in überschriebenen Methoden im Basis-FB nicht initialisiert sind.

Wichtigkeit

Hoch

Funktion

Ermittelt, wo formale Parameter fehlen.

Begründung

Code wird lesbarer, wenn die Formalparameter beim Aufruf angegeben werden.

Wichtigkeit

Niedrig

Funktion

Ermittelt Variablen vom Typ POINTER TO.

Begründung

Die Norm IEC 61131-3 erlaubt keine Pointer.

Wichtigkeit

Niedrig

Funktion

Ermittelt Variablen vom Typ REFERENCE TO.

Begründung

Die Norm IEC 61131-3 erlaubt keine Referenzen.

Wichtigkeit

Niedrig

Funktion

Ermittelt Variablen vom Typ WSTRING.

Begründung

Nicht alle Systeme unterstützen WSTRING. Der Code wird leichter portierbar, wenn auf WSTRING verzichtet wird.

Wichtigkeit

Niedrig

Funktion

Ermittelt Variablen vom Typ LTIME.

Begründung

Nicht alle Systeme unterstützen LTIME. Der Code wird portierbarer, wenn auf LTIME verzichtet wird.

Wichtigkeit

Niedrig

Funktion

Ermittelt Deklarationen eines UNION-Datentyps und Deklarationen von Variablen vom Typ einer UNION.

Begründung

Die Norm IEC-61131-3 kennt keinen Unions. Der Code wird leichter portierbar, wenn auf Unions verzichtet wird.

Wichtigkeit

Niedrig

Funktion

Ermittelt Deklarationen von Variablen vom Typ BIT (möglich innerhalb von Struktur- und Funktionsbausteindefinitionen).

Begründung

Die IEC-61131-3 kennt keinen Datentyp BIT. Der Code wird leichter portierbar, wenn auf BIT verzichtet wird.

Wichtigkeit

Niedrig

Funktion

Ermittelt die Verwendung objektorientierter Funktionalitäten, wie beispielsweise:

• Funktionsbaustein-Deklarationen mit EXTENDS oder IMPLEMENTS
• Eigenschaften- und Schnittstellendeklarationen
• Verwendung des THIS- oder SUPER-Zeigers

Begründung

Nicht alle Systeme unterstützen Objektorientierte Programmierung. Der Code wird leichter portierbar, wenn auf Objektorientierung verzichtet wird.

Wichtigkeit

Niedrig

Funktion

Ermittelt Programmaufrufe.

Begründung

Nach der Norm IEC 61131-3 können Programme nur in der Taskkonfiguration aufgerufen werden. Der Code wird leichter portierbar, wenn auf Programmaufrufe an anderen Stellen verzichtet wird.

Wichtigkeit

Niedrig

Funktion

Ermittelt die Verwendung einer globalen Variablen im Funktionsbaustein, ohne dass sie dort als VAR_EXTERNAL deklariert ist (erforderlich laut Norm).

Begründung

Nach der Norm IEC 61131-3 ist der Zugriff auf globale Variablen nur über einen expliziten Import durch eine VAR_EXTERNAL-Deklaration erlaubt.

Wichtigkeit

Niedrig

PLCopen-Regel

CP18

Funktion

Ermittelt die Verwendung von Ausdrücken bei der Deklaration von Arraygrenzen.

Begründung

Nicht alle Systeme erlauben Ausdrücke als Arraygrenzen.

Wichtigkeit

Niedrig

Funktion

Ermittelt die Verwendung der (TwinCAT spezifischen) Operatoren INI, ADR, BITADR.

Begründung

TwinCAT-spezifische Operatoren verhindern die Portierbarkeit des Codes.

Wichtigkeit

Niedrig

Funktion

Ermittelt Bitshift-Operationen, die nicht auf Bitfeld-Datentypen (BYTE, WORD, DWORD, LWORD) erfolgen.

Begründung

Die Norm IEC 61131-3 erlaubt nur Bitzugriffe auf Bitfeld-Datentypen. Der TwinCAT 3 Compiler erlaubt jedoch auch Bitshift-Operationen mit nicht vorzeichenbehafteten Datentypen.

Wichtigkeit

Niedrig

Funktion

Ermittelt Bitzugriffe, die nicht auf Bitfeld-Datentypen (BYTE, WORD, DWORD, LWORD) erfolgen.

Begründung

Die Norm IEC 61131-3 erlaubt nur Bitzugriffe auf Bitfeld-Datentypen. Der TwinCAT 3 Compiler erlaubt jedoch auch Bitzugriffe auf nicht vorzeichenbehaftete Datentypen.

Wichtigkeit

Niedrig

Funktion

Ermittelt Initialisierungen, die nicht Konstanten zuweisen.

Begründung

Initialisierungen sollten möglichst konstant sein und sich nicht auf andere Variablen beziehen. Insbesondere sollten Sie Funktionsaufrufe in der Initialisierung vermeiden, weil es dadurch zu einem Zugriff auf nicht initialisierte Daten kommen kann.

Wichtigkeit

Mittel

Funktion

Ermittelt alle Codestellen, an denen dereferenzierte Pointer im Deklarationsteil von POUs verwendet werden.

Begründung

Pointer und Referenzen sollten nicht für Initialisierungen verwendet werden, weil es dadurch zur Laufzeit zu "Access Violations" kommen kann, wenn der Pointer nicht initialisiert worden ist.

Wichtigkeit

Mittel

Funktion

Ermittelt alle Referenzvariablen, die zur Initialisierung im Deklarationsteil von POUs verwendet werden.

Begründung

Pointer und Referenzen sollten nicht für Initialisierungen verwendet werden, weil es dadurch zur Laufzeit zu “Access Violations” kommen kann, wenn der Pointer nicht initialisiert worden ist.

Wichtigkeit

Mittel

Funktion

Ermittelt Codestellen, an denen möglicherweise ein Null-Pointer dereferenziert wird.

Begründung

Ein Pointer sollte vor jeder Dereferenzierung daraufhin geprüft werden, ob er ungleich 0 ist. Anderfalls kann es zu einer “Access Violation” zur Laufzeit kommen.

Wichtigkeit

Hoch

Funktion

Ermittelt die Verwendung von Schnittstellen, die vor der Verwendung möglicherweise nicht initialisiert wurden.

Begründung

Eine Interface-Referenz sollte vor ihrer Verwendung auf <> 0 geprüft werden, weil es sonst beim Zugriff zur Laufzeit zu einer "Access Violation" kommen kann.

Wichtigkeit

Hoch

Funktion

Ermittelt alle verwendeten Referenzvariablen, die möglicherweise vor der Verwendung nicht initialisiert werden und nicht durch den Operator __ISVALIDREF überprüft wurden. Diese Regel wird im Implementierungsteil von POUs angewendet.

Begründung

Eine Referenz sollte vor dem Zugriff auf Gültigkeit geprüft werden, weil es sonst beim Zugriff zur Laufzeit zu einer "Access Violation" kommen kann.

Wichtigkeit

Hoch

Funktion

Ermittelt Anweisungen, die auskommentiert sind.

Begründung

Code wird oft zu Debugging-Zwecken auskommentiert. Wenn ein solcher Kommentar freigegeben wird, dann ist zu einem späteren Zeitpunkt nicht mehr klar, ob der Code gelöscht werden sollte oder ob er nur zu Debug-Zwecken auskommentiert wurde und versehentlich nicht mehr einkommentiert wurde.

Wichtigkeit

Hoch

PLCopen-Regel

C4

Funktion

Ermittelt die Bausteine, die die aktivierten Metriken an der Unter- oder Obergrenze verletzen.

Begründung

Code, der bestimmte Metriken einhält, ist leichter lesbar, leichter wartbar und leichter zu testen.

Wichtigkeit

Hoch

PLCopen-Regel

CP9

Funktion

Ermittelt rekursive Aufrufe von Programmen, Aktionen, Methoden und Eigenschaften. Ermittelt auch mögliche Rekursionen durch virtuelle Funktionsaufrufe und Schnittstellenaufrufe.

Begründung

Rekursionen führen zu nicht-deterministischem Verhalten und sind daher eine Fehlerquelle.

Wichtigkeit

Mittel

PLCopen-Regel

CP13

Funktion

Ermittelt ungepackte Strukturen, die in gepackten Strukturen verwendet werden.

Begründung

Eine ungepackte Struktur legt der Compiler normalerweise auf eine Adresse, die alignten Zugriff auf alle Elemente innerhalb der Struktur erlaubt. Wenn Sie diese Struktur in einer gepackten Struktur anlegen, dann ist ein alignter Zugriff nicht mehr möglich, und ein Zugriff auf ein Element in der ungepackten Struktur kann zur Laufzeit zu einer “Misalignment Exception” führen.

Wichtigkeit

Hoch

Funktion

Ermittelt Stellen im Programm, die nicht kommentiert sind. Kommentare sind erforderlich bei:

• der Deklaration von Variablen. Die Kommentare stehen darüber oder rechts davon.
• der Deklaration von POUs, DUTs, GVLs oder Schnittstellen. Die Kommentare stehen über der Deklaration (in der ersten Zeile).

Begründung

Eine vollständige Kommentierung wird von vielen Programmierrichtlinien gefordert und erhöht die Lesbarkeit und Wartbarkeit des Codes.

Wichtigkeit

Niedrig

PLCopen-Regel

C2

Funktion

Ermittelt Codestellen, an denen verschachtelte Kommentare sind.

Begründung

Verschachtelte Kommentare sind schwer zu lesen und sollten deswegen vermieden werden.

Wichtigkeit

Niedrig

PLCopen-Regel

C3

Funktion

Ermittelt Codestellen, an denen der Mehrzeilenkommentar-Operator (* *) verwendet wird. Erlaubt sind nur die beiden Einzeilenkommentar-Operatoren // für Standardkommentare und /// für Dokumentationskommentare.

Begründung

Einige Programmierrichtlinien verbieten mehrzeilige Kommentare im Code, weil Anfang und Ende eines Kommentars aus dem Blickfeld geraten könnten und die schließende Kommentarklammer durch einen Fehler gelöscht werden könnte.

Wichtigkeit

Niedrig

PLCopen-Regel

C5

Funktion

Die Prüfung ermittelt, ob eine definierte Anzahl an Eingabevariablen (VAR_INPUT), Ausgabevariablen (VAR_OUTPUT) oder VAR_IN_OUT-Variablen in einem Baustein überschritten wird.

Die Parameter, die bei dieser Prüfung berücksichtigt werden, können Sie konfigurieren, indem Sie innerhalb der Regelkonfiguration auf die Zeile von Regel 166 doppelklicken (SPS-Projekteigenschaften > Kategorie "Static Analysis" > Registerkarte "Regeln" > Regel 166). In dem aufgehenden Dialog können Sie folgende Einstellungen vornehmen:

• Maximale Anzahl an Eingängen (Standardwert: 10)
• Maximale Anzahl an Ausgängen (Standardwert: 10)
• Maximale Anzahl an Ein-/Ausgängen (Standardwert: 10)

Begründung

Es geht um die Überprüfung von individuellen Programmierrichtlinien. Viele Programmierrichtlinien sehen für Bausteine eine maximale Anzahl an Parametern vor. Zu viele Parameter machen den Code unleserlich und die Bausteine schwer zu testen.

Wichtigkeit

Mittel

PLCopen-Regel

CP23

Funktion

Ermittelt Funktionsbausteininstanzen, die als temporäre Variable deklariert sind. Dies betrifft Instanzen, die in einer Methode oder in einer Funktion oder als VAR_TEMP deklariert sind, und die deshalb in jedem Abarbeitungszyklus bzw. bei jedem Bausteinaufruf neu initialisiert werden.

Begründung

Funktionsbausteine haben einen Zustand, der meist über mehrere SPS-Zyklen hinweg erhalten bleibt. Eine Instanz auf dem Stack existiert nur für die Dauer des Funktionsaufrufs. Es ist daher nur selten sinnvoll, eine Instanz als temporäre Variable anzulegen. Zweitens sind Funktionsbausteininstanzen häufig groß und verbrauchen sehr viel Platz auf dem Stack (der auf Steuerungen meist begrenzt ist). Drittens kann die Initialisierung und häufig auch die Terminierung eines Funktionsbausteins ziemlich viel Zeit in Anspruch nehmen.

Wichtigkeit

Mittel

Funktion

Ermittelt Zuweisungen auf Variablen, die keine Auswirkungen im Code haben.

Begründung

Wenn einer Variablen mehrfach Werte zugewiesen werden, ohne dass die Variable zwischen den Zuweisungen ausgewertet wird, wirken sich die ersten Zuweisungen nicht auf das Programm aus.

Wichtigkeit

Niedrig

Funktion

Ermittelt die Ausgänge von Methoden und Funktionen, die beim Aufruf der Methode oder Funktion nicht angegeben werden.

Begründung

Ignorierte Ausgänge können ein Hinweis auf nicht behandelte Fehler oder sinnlose Funktionsaufrufe sein, da Ergebnisse nicht verwendet werden.

Wichtigkeit

Mittel

Funktion

Ermittelt Codestellen, an denen die Adresse einer Ausgangsvariablen (VAR_OUTPUT, VAR_IN_OUT) eines Funktionsbausteins ermittelt wird.

Begründung

Es ist nicht erlaubt, in folgender Weise die Adresse eines Funktionsbausteinausgangs zu verwenden:

• Via ADR-Operator
• Via REF=

Ausnahme

Es wird kein Fehler gemeldet, wenn der Ausgang innerhalb desselben Funktionsbausteins verwendet wird.

Wichtigkeit

Mittel

Funktion

Ermittelt Deklarationen von Enumerationen, die nicht mit dem Attribut {attribute 'strict'} versehen sind.

Begründung

Das Attribut {attribute 'strict'} bewirkt, dass Compilerfehler ausgegeben werden, wenn der Code gegen strikte Programmierregeln für Enumerationen verstößt. Standardmäßig wird beim Anlegen einer neuen Enumeration die Deklaration automatisch mit dem Attribut 'strict' versehen.

Wichtigkeit

Hoch

Funktion

Ermittelt Codestellen, die bei einer UTF-8-Kodierung verdächtig sind.

Erfasste Konstrukte

1. Indexzugriff auf einen Single-Byte-String
• Beispiel: sVar[2]
• Meldung: Verdächtige Operation auf String: Indexzugriff '<expression>'
2. Adresszugriff auf einen Single-Byte-String
• Beispiel: ADR(sVar)
• Meldung: Verdächtige Operation auf String: Möglicher Indexzugriff '<expression>'
3. Aufruf einer String-Funktion der Tc2_Standard-Bibliothek außer CONCAT und LEN
• Beispiel: FIND(sVar, 'a');
• Meldung: Verdächtige Operation auf String: Möglicher Indexzugriff '<expression>'
4. Einzelnes Byte-Literal, das Nicht-ASCII-Zeichen enthält
• Beispiele:
  sVar := '99€';
sVar := 'Ä';
• Meldung: Verdächtige Operation auf String: Literal '<literal>' enthält Nicht-ASCII-Zeichen

Wichtigkeit

Mittel