Es ist notwendig zu wissen, was im Programm passiert, besonders wenn etwas nicht nach unseren Erwartungen läuft.
Ein Logger ermöglicht es uns, Ereignisse aufzuzeichnen und zu verfolgen, die während der Ausführung eines Programms auftreten. Dies kann besonders nützlich sein, um eventuell auftretende Probleme zu debuggen und zu beheben. Darüber hinaus kann ein Logger so konfiguriert werden, dass er Ereignismeldungen mit unterschiedlichem Schweregrad ausgibt, wie z. B. Fehler, Warnungen und Informationsmeldungen.

Logger als Programmmodul (Funktionsblock) muss eine Reihe von Anforderungen erfüllen:
1. Logger muss zuverlässig funktionieren und bereits als erstes Modul im Programm verfügbar sein, da wir es verwenden werden, um Ereignisse aus anderen Modulen aufzuzeichnen. Einträge in der Logdatei können beim Programmieren und Testen dieser Module helfen.

2. Nach dem Start des Systems, nur wenn der Logger erfolgreich initialisiert wurde und bereit ist, Nachrichten aufzuzeichnen, können wir auch den Rest des Programms starten. Andernfalls müssen wir in der Visualisierung eine Fehlermeldung generieren, dass der Logger nicht gestartet werden konnte und nicht funktioniert.

3. Geloggte Meldungen müssen nach dem Neustart des Systems bestehen bleiben. (Oft sind die letzten Meldungen vor dem Systemabsturz sehr wichtig, um die Ursache des Problems zu finden, daher müssen wir in der Lage sein, sie aufzuzeichnen und aufzubewahren.)

4. Geloggte Meldungen sollten zusammen mit den Systemmeldungen, die normalerweise vom System geloggt werden, zeitsynchronisiert und chronologisch sortiert werden, um mögliche Abhängigkeiten zwischen Systemereignissen und unseren Anwendungsereignissen zu erkennen. Es lohnt sich zu überlegen, ob wir für unsere Meldungen denselben Speicher / Logdatei verwenden möchten, den das System für die Meldungen der Systemereignisse verwendet.

5. Der Inhalt der Logdatei ist in erster Linie für Entwickler bestimmt, sodass wir uns nicht um die Übersetzung der Meldungen in die Landessprachen der Kunden kümmern müssen. Die Logdatei muss auch nicht von der Visualisierung aus zugänglich sein. (In die Visualisierung werden weitere Tools implementiert, die den Bediener über Maschinen-, System- und Bedienerereignisse informieren, wie z.B. aktuelle Alarme, historische Alarme und Ereignisse usw.)

6. Der Logger muss eine schnelle Aufzeichnung ermöglichen, die so schnell wie der schnellste SPS-Zyklus ist, um jedes Ereignis aufzeichnen zu können.

7. Wenn unser Programm in mehrere Task-Klassen aufgeteilt ist, bei denen eine schnellere und höher priorisierte Klasse eine langsamere und weniger priorisierte Klasse unterbricht, müssen wir eine inkonsistente Datenaufzeichnung verhindern. Inkonsistente Datenaufzeichnung kann auftreten, wenn eine Instanz des Logger-Moduls Nachrichten von einem langsamen Task-Programm aufzeichnet und von einem schnelleren Task-Programm unterbrochen wird, das auch möchte, dass diese Logger-Instanz eine andere Nachricht aufzeichnet. Auf diese Weise kann die aufgezeichnete Nachricht fälschlicherweise aus zwei Teilen bestehen, die sich jeweils mit einem anderen Ereignis befassen. Und es ist möglicherweise nicht offensichtlich, wenn wir die Logdatei analysieren.

8. Wir müssen in der Lage sein, Nachrichten nach einem Stromausfall aufzuzeichnen. Aus der Logdatei müssen wir wissen, dass der Stromausfall aufgetreten ist und ob das System nach dem Stromausfall ordnungsgemäss gestoppt wurde. Normalerweise benötigt das System eine unterbrechungsfreie Stromversorgung (USV), um bei einem Stromausfall ordnungsgemäss zu stoppen. Und unser Logger-Modul muss in der Lage sein, die Nachrichten zu schreiben und zu speichern, während das System aufgrund des Stromausfalls gestoppt wird.

9. Wir (die Entwickler) müssen Zugriff auf die Logdatei haben und in der Lage sein, die Logdatei von der Maschine auf unseren PC zu kopieren. Und dies zum Beispiel per Fernzugriff.
Auch wenn die SPS nicht mehr starten kann, muss die Logdatei zugänglich sein (z. B. über einen CF-Kartenleser).

10. Wir müssen überwachen, dass die Logdatei nicht den gesamten freien Speicherplatz auf dem lokalen Speicher belegt. Es ist notwendig, die Grösse der Logdatei und den verbleibenden freien Speicherplatz auf dem Speicher zu überwachen. Es ist auch vorteilhaft, beispielsweise alle 24 Stunden neue Logdateien zu erstellen und alte Logdateien auf einen Server zu kopieren, wenn dieser verfügbar ist.

11. Beim Aufruf des Logger-Moduls zum Schreiben einer Meldung in die Logdatei ist darauf zu achten, dass die einmal geschriebene Meldung nicht in jedem SPS-Zyklus wiederholt geschrieben wird, wenn die Bedingung zum Schreiben dieser Meldung noch gesetzt ist. Dies würde die Logdatei schnell mit unnötig sich wiederholenden Meldungen füllen. (Im Fall einer Ringpuffer-Logdatei würde es sogar ältere und möglicherweise wichtige Aufzeichnungen überschreiben.)

12. Wir finden in der Logdatei nur die Meldungen, die wir dort geschrieben haben :-). Es ist also eine gute Idee, eher mehr Ereignisse aufzuzeichnen. Die wichtigsten Nachrichten sind natürlich diejenigen, die uns wissen lassen, dass etwas nicht wie erwartet gelaufen ist. Darüber hinaus kann es auch wichtig sein zu wissen, wie das Programm ausgeführt wird – die Reihenfolge, in der Funktionen aufgerufen werden und welche Werte sie zurückgeben und wie die Schritte der Zustandsmaschine geschaltet werden usw. Beispielsweise können wir mehrere Schweregrade der Meldungen unterscheiden wie: Erfolg, Info, Warnung, Fehler.
Wenn das Programm bereits gut debuggt und getestet wurde, müssen wir keine Erfolgs- und Infomeldungen mehr aufzeichnen, um die Logdatei nicht mit unwichtigen Informationen zu überladen. Dennoch ist es sinnvoll, diese Option beizubehalten. Aus diesem Grund ist es gut, einen konfigurierbaren Schweregrad von Nachrichten zu haben, die der Logger in die Protokolldatei schreiben soll. Idealerweise sollten wir die Ebenen nicht nur in aufsteigender Reihenfolge aktivieren und deaktivieren können, sondern einzeln.
Das Aktivieren und Deaktivieren der Logger-Schweregrade muss von ausserhalb des Programms (z. B. in einer Konfigurationsdatei) möglich sein, damit wir das Programm nicht neu kompilieren müssen, wenn wir mehrere Ereignisse aufzeichnen möchten.
Es ist auch nützlich, Ereignisse mit niedrigerem Schweregrad zurückverfolgen zu können, wenn ein Ereignis mit dem Schweregrad Fehler auftritt. Dazu sollte das Logger-Modul über einen lokalen Ringpuffer verfügen, in dem alle Schweregrad-Ereignisse aufgezeichnet werden, und der Ringpuffer sollte im Fehlerfall in die Logdatei kopiert werden.

13.Von Zeit zu Zeit müssen wir die Logdatei überprüfen, ob keine Fehlermeldungen vorhanden sind.Wenn ja, müssen wir die Ursache untersuchen und lösen.Die Logdatei sollte auf einem stabilen System keine Fehlermeldungen enthalten.

14. Das Logger-Modul soll den Bediener auch über einen Alarm auf der Visualisierung benachrichtigen, wenn eine Fehlermeldung in der Logdatei aufgezeichnet wurde. Lediglich eine allgemeine Alarmmeldung wie „Ein Fehler wurde aufgezeichnet!“ mit einer Alarmhilfe wie „Kontaktieren Sie den Softwareentwickler!“ sollte auf der Visualisierung angezeigt werden. Denn der Fehler in der Logdatei ist nicht für den Systembetreiber bestimmt, sondern für den Softwareentwickler.

15. Um ein Problem im Programm leicht lokalisieren zu können, ist es gut, wenn jedes in der Logdatei protokollierte Ereignis eine eigene eindeutige Identifikationsnummer hat.