Fall 01
vorhersagen → beobachten → belegen
Belegen: rollen und transport
Technischer Kontext. Client und Server sowie RTU, TCP, Unit-ID oder Slave-Adresse eindeutig festlegen, bevor Datenadressen untersucht werden. Beginnen Sie mit einem schriftlichen Normalzustand und bestimmen Sie, welche Anforderung, welcher Zustand, welches physische Ergebnis oder welcher Kommunikationswert unabhängig bestätigt. Ändern Sie nicht zuerst die Konfiguration; der Anfangszustand ist Teil des Nachweises und muss reproduzierbar bleiben.
Kontrollierter Aufbau. Verwenden Sie den Schritt „Vertrag aufschreiben“: Endpunkte, Transport, Identität, Funktion, Startadresse, Anzahl, Datentyp, Reihenfolge, Skalierung und Einheit dokumentieren. Der Abnahmenachweis soll dieses Ergebnis zeigen: Beide Seiten beschreiben denselben Datenpunkt ohne stillschweigende Annahmen. Halten Sie Anfangsbedingungen, genauen Reiz und Beobachtungspunkt fest, damit eine andere Person den Fall ohne Erinnerungshilfe wiederholen kann.
Fehlerfall. Führen Sie „Keine physische Verbindung“ als begrenzte Abweichung ein oder analysieren Sie sie. Prüfen Sie versorgung, leitung, polarität, stecker, switch, abschluss und bias Die Arbeitshypothese lautet: Der Fehler liegt unterhalb der Modbus-Anwendung. Die nächste Beweisaktion ist: Zuerst die physische Schicht wiederherstellen. Ändern Sie vor der Beobachtung nur eine Bedingung und bewahren Sie bei zeitabhängigen Fällen Zeitstempel oder Messwerte auf.
Prüfung und Wiederherstellung. Die häufigste Falle ist mit zufälligen einstellungen beginnen, bevor der vertrag feststeht. Wiederholen Sie nach Beseitigung der Ursache den Normalfall und mindestens eine passende Stopp-, Timeout-, Trennungs- oder Wiederanlaufgrenze. Entfernen Sie temporäre Kräfte und Umgehungen, stellen Sie einen bekannten Zustand her und bewahren Sie den Nachweis für absichtlichen Betrieb und Wiederherstellung auf.
Laut erklären: Was ist ein Modbus-Simulator? Eine kurze belastbare Antwort lautet: Er bildet Client-Server-Anfragen, Datenbereiche und Antworten in kontrollierten Bedingungen nach, damit Zuordnung und Diagnose ohne Produktionsgerät geübt werden können.
Fall 02
vorhersagen → beobachten → belegen
Belegen: funktionscode und datenmodell
Technischer Kontext. Coils, Discrete Inputs, Input Registers und Holding Registers nach Funktion, Richtung und Zugriffsrecht unterscheiden. Beginnen Sie mit einem schriftlichen Normalzustand und bestimmen Sie, welche Anforderung, welcher Zustand, welches physische Ergebnis oder welcher Kommunikationswert unabhängig bestätigt. Ändern Sie nicht zuerst die Konfiguration; der Anfangszustand ist Teil des Nachweises und muss reproduzierbar bleiben.
Kontrollierter Aufbau. Verwenden Sie den Schritt „Physische und Netzwerkschicht prüfen“: Versorgung, Medium, Link, RS-485-Topologie oder IP-Erreichbarkeit kontrollieren. Der Abnahmenachweis soll dieses Ergebnis zeigen: Die untere Schicht ist belegt, aber noch nicht mit Anwendungserfolg verwechselt. Halten Sie Anfangsbedingungen, genauen Reiz und Beobachtungspunkt fest, damit eine andere Person den Fall ohne Erinnerungshilfe wiederholen kann.
Fehlerfall. Führen Sie „Gerät erreichbar, aber keine gültige Antwort“ als begrenzte Abweichung ein oder analysieren Sie sie. Prüfen Sie rolle, port oder serielle parameter, unit-id, funktionscode und geräteprotokoll Die Arbeitshypothese lautet: Der Transportweg funktioniert, während Sitzung oder Anfrage scheitert. Die nächste Beweisaktion ist: Exakten Status und Geräteprotokoll auswerten. Ändern Sie vor der Beobachtung nur eine Bedingung und bewahren Sie bei zeitabhängigen Fällen Zeitstempel oder Messwerte auf.
Prüfung und Wiederherstellung. Die häufigste Falle ist ein link-licht als beweis für richtige daten verwenden. Wiederholen Sie nach Beseitigung der Ursache den Normalfall und mindestens eine passende Stopp-, Timeout-, Trennungs- oder Wiederanlaufgrenze. Entfernen Sie temporäre Kräfte und Umgehungen, stellen Sie einen bekannten Zustand her und bewahren Sie den Nachweis für absichtlichen Betrieb und Wiederherstellung auf.
Laut erklären: Was ist der Unterschied zwischen Modbus RTU und Modbus TCP? Eine kurze belastbare Antwort lautet: Beide verwenden verwandte Anwendungsdaten, unterscheiden sich jedoch bei Transport, Adressierung, Rahmenbildung und Inbetriebnahme der Verbindung.
Fall 03
vorhersagen → beobachten → belegen
Belegen: adressnotation
Technischer Kontext. Die dokumentierte Referenz und den tatsächlich übertragenen nullbasierten Offset ausdrücklich gegenüberstellen. Beginnen Sie mit einem schriftlichen Normalzustand und bestimmen Sie, welche Anforderung, welcher Zustand, welches physische Ergebnis oder welcher Kommunikationswert unabhängig bestätigt. Ändern Sie nicht zuerst die Konfiguration; der Anfangszustand ist Teil des Nachweises und muss reproduzierbar bleiben.
Kontrollierter Aufbau. Verwenden Sie den Schritt „Identität bestätigen“: Adresse, Unit-ID, Gerätefamilie, Revision und Serverrolle mit der Zielanlage vergleichen. Der Abnahmenachweis soll dieses Ergebnis zeigen: Die Anfrage erreicht das beabsichtigte Gerät. Halten Sie Anfangsbedingungen, genauen Reiz und Beobachtungspunkt fest, damit eine andere Person den Fall ohne Erinnerungshilfe wiederholen kann.
Fehlerfall. Führen Sie „Exception-Antwort“ als begrenzte Abweichung ein oder analysieren Sie sie. Prüfen Sie funktionscode, startadresse, anzahl und zugriffsrecht Die Arbeitshypothese lautet: Der Server hat die Anfrage verstanden und begründet abgelehnt. Die nächste Beweisaktion ist: Exception-Code statt Timeout-Vermutung verwenden. Ändern Sie vor der Beobachtung nur eine Bedingung und bewahren Sie bei zeitabhängigen Fällen Zeitstempel oder Messwerte auf.
Prüfung und Wiederherstellung. Die häufigste Falle ist ein anderes erreichbares gerät untersuchen. Wiederholen Sie nach Beseitigung der Ursache den Normalfall und mindestens eine passende Stopp-, Timeout-, Trennungs- oder Wiederanlaufgrenze. Entfernen Sie temporäre Kräfte und Umgehungen, stellen Sie einen bekannten Zustand her und bewahren Sie den Nachweis für absichtlichen Betrieb und Wiederherstellung auf.
Laut erklären: Warum ist die Modbus-Adresse oft um eins verschoben? Eine kurze belastbare Antwort lautet: Handbücher zeigen häufig Referenznummern, während das Telegramm einen nullbasierten Offset überträgt. Beide Notationen müssen ausdrücklich abgeglichen werden.
Fall 04
vorhersagen → beobachten → belegen
Belegen: datentyp und reihenfolge
Technischer Kontext. Ein oder mehrere 16-Bit-Wörter mit Vorzeichen, Byte- und Wortreihenfolge, Skalierung und Einheit als gemeinsamen Vertrag behandeln. Beginnen Sie mit einem schriftlichen Normalzustand und bestimmen Sie, welche Anforderung, welcher Zustand, welches physische Ergebnis oder welcher Kommunikationswert unabhängig bestätigt. Ändern Sie nicht zuerst die Konfiguration; der Anfangszustand ist Teil des Nachweises und muss reproduzierbar bleiben.
Kontrollierter Aufbau. Verwenden Sie den Schritt „Eine bekannte Anfrage senden“: Einen begrenzten Datenpunkt mit dokumentierter Funktion und Adresse lesen. Der Abnahmenachweis soll dieses Ergebnis zeigen: Antwortstatus und Rohwörter sind reproduzierbar. Halten Sie Anfangsbedingungen, genauen Reiz und Beobachtungspunkt fest, damit eine andere Person den Fall ohne Erinnerungshilfe wiederholen kann.
Fehlerfall. Führen Sie „Wert ändert sich, ist aber falsch“ als begrenzte Abweichung ein oder analysieren Sie sie. Prüfen Sie adressbasis, datentyp, byte- und wortreihenfolge, vorzeichen, skalierung und einheit Die Arbeitshypothese lautet: Die Übertragung gelingt, die Interpretation jedoch nicht. Die nächste Beweisaktion ist: Ein bekanntes Bit- oder Wortmuster vergleichen. Ändern Sie vor der Beobachtung nur eine Bedingung und bewahren Sie bei zeitabhängigen Fällen Zeitstempel oder Messwerte auf.
Prüfung und Wiederherstellung. Die häufigste Falle ist mehrere adressen und parameter gleichzeitig ändern. Wiederholen Sie nach Beseitigung der Ursache den Normalfall und mindestens eine passende Stopp-, Timeout-, Trennungs- oder Wiederanlaufgrenze. Entfernen Sie temporäre Kräfte und Umgehungen, stellen Sie einen bekannten Zustand her und bewahren Sie den Nachweis für absichtlichen Betrieb und Wiederherstellung auf.
Laut erklären: Warum ist ein REAL- oder DINT-Wert falsch? Eine kurze belastbare Antwort lautet: Mehrwort-Typ, Vorzeichen, Byte- oder Wortreihenfolge, Skalierung oder Adresse kann falsch interpretiert sein, obwohl die Anfrage erfolgreich war.
Fall 05
vorhersagen → beobachten → belegen
Belegen: aktualität und qualität
Technischer Kontext. Ein zuletzt gültiger Wert darf nach Timeout oder Verbindungsverlust nicht unbemerkt als aktueller Prozesszustand gelten. Beginnen Sie mit einem schriftlichen Normalzustand und bestimmen Sie, welche Anforderung, welcher Zustand, welches physische Ergebnis oder welcher Kommunikationswert unabhängig bestätigt. Ändern Sie nicht zuerst die Konfiguration; der Anfangszustand ist Teil des Nachweises und muss reproduzierbar bleiben.
Kontrollierter Aufbau. Verwenden Sie den Schritt „Technische Bedeutung prüfen“: Rohdaten in Typ, Reihenfolge, Skalierung und Einheit umwandeln und mit einem bekannten Zustand vergleichen. Der Abnahmenachweis soll dieses Ergebnis zeigen: Der Wert stimmt nicht nur syntaktisch, sondern physikalisch. Halten Sie Anfangsbedingungen, genauen Reiz und Beobachtungspunkt fest, damit eine andere Person den Fall ohne Erinnerungshilfe wiederholen kann.
Fehlerfall. Führen Sie „Unregelmäßiger Timeout“ als begrenzte Abweichung ein oder analysieren Sie sie. Prüfen Sie buslast, abfragezyklus, leitung, fehlerzähler, antwortzeit und serverressourcen Die Arbeitshypothese lautet: Zeitreserve, physische Qualität oder Abfragerate kann instabil sein. Die nächste Beweisaktion ist: Zähler und Zeitstempel über ein Ereignisfenster erfassen. Ändern Sie vor der Beobachtung nur eine Bedingung und bewahren Sie bei zeitabhängigen Fällen Zeitstempel oder Messwerte auf.
Prüfung und Wiederherstellung. Die häufigste Falle ist einen plausiblen zahlenwert ohne referenz akzeptieren. Wiederholen Sie nach Beseitigung der Ursache den Normalfall und mindestens eine passende Stopp-, Timeout-, Trennungs- oder Wiederanlaufgrenze. Entfernen Sie temporäre Kräfte und Umgehungen, stellen Sie einen bekannten Zustand her und bewahren Sie den Nachweis für absichtlichen Betrieb und Wiederherstellung auf.
Laut erklären: Beweist eine Antwort die richtige Gerätefunktion? Eine kurze belastbare Antwort lautet: Nein. Zusätzlich müssen technische Einheit, Aktualität und ein unabhängiger Prozess- oder Gerätezustand übereinstimmen.
Fall 06
vorhersagen → beobachten → belegen
Belegen: fehler und wiederkehr
Technischer Kontext. Exception, Timeout, Neustart und Wiederverbindung so testen, dass Anwendung und Bediener einen definierten Zustand erhalten. Beginnen Sie mit einem schriftlichen Normalzustand und bestimmen Sie, welche Anforderung, welcher Zustand, welches physische Ergebnis oder welcher Kommunikationswert unabhängig bestätigt. Ändern Sie nicht zuerst die Konfiguration; der Anfangszustand ist Teil des Nachweises und muss reproduzierbar bleiben.
Kontrollierter Aufbau. Verwenden Sie den Schritt „Ausfall und Wiederkehr testen“: Verbindung kontrolliert trennen, Timeout beobachten und Kommunikation wiederherstellen. Der Abnahmenachweis soll dieses Ergebnis zeigen: Stale-Anzeige, sichere Reaktion und vollständige Wiederverbindung sind definiert. Halten Sie Anfangsbedingungen, genauen Reiz und Beobachtungspunkt fest, damit eine andere Person den Fall ohne Erinnerungshilfe wiederholen kann.
Fehlerfall. Führen Sie „Nach Wiederverbindung bleibt der Wert alt“ als begrenzte Abweichung ein oder analysieren Sie sie. Prüfen Sie timeout-regel, qualitätsstatus, neuabfrage, verbindungsaufbau und anwendungszustand Die Arbeitshypothese lautet: Die Kommunikation ist zurück, aber der Datenvertrag wurde nicht vollständig erneuert. Die nächste Beweisaktion ist: Die gesamte Wiederkehrsequenz als Regressionstest ausführen. Ändern Sie vor der Beobachtung nur eine Bedingung und bewahren Sie bei zeitabhängigen Fällen Zeitstempel oder Messwerte auf.
Prüfung und Wiederherstellung. Die häufigste Falle ist nur den erfolgreichen start testen. Wiederholen Sie nach Beseitigung der Ursache den Normalfall und mindestens eine passende Stopp-, Timeout-, Trennungs- oder Wiederanlaufgrenze. Entfernen Sie temporäre Kräfte und Umgehungen, stellen Sie einen bekannten Zustand her und bewahren Sie den Nachweis für absichtlichen Betrieb und Wiederherstellung auf.
Laut erklären: Wie diagnostiziert man einen Modbus-Timeout? Eine kurze belastbare Antwort lautet: Von physischer Verbindung und Identität über Transportparameter und Anfrage bis zur Serverlast schichtweise prüfen und Zeitstempel bewahren.
