Im Vergleich mit der unstrukturierten Bitübertragungsschicht ist damit bereits ein erhebliches Maß an Übertragungssicherheit gegeben, das übrigens häufig auch von erfahrenen Administratoren und Entwicklern unterschätzt wird. Der Grund für diese Unterschätzung ist vermutlich darin zu suchen, dass auch in höheren Schichten häufig noch Sicherheitsmechanismen verwendet werden, was der Sicherungsschicht in gewisser Weise das Misstrauen ausspricht.
Beispiele für Sicherungsverfahren:
CRC (Cyclic Redundancy Check)
Für jeden Datenblock wird nach einem bestimmten Verfahren ein sogenannter CRC-Wert berechnet, der an den Datenblock angefügt wird. Der Empfänger wendet dasselbe Berechnungsverfahren auf Datenblock einschließlich des angefügten CRC-Werts an.
Ist das Ergebnis Null, kann angenommen werden, dass der Datenblock unverfälscht ist.
CRC ist so ausgelegt, dass Fehler bei der Übertragung der Daten, wie sie beispielsweise durch Rauschen auf der Leitung verursacht werden könnten, mit hoher Wahrscheinlichkeit entdeckt werden. CRCs von seriellen Datenübertragungen können sehr einfach in Hardware realisiert werden. Zum Beispiel werden Datenübertragungen über Ethernet, sowie die meisten Festplatten-Übertragungen (ATA, SATA) mit CRC-Verfahren geprüft.
Das CRC-Verfahren ist nur für die Erkennung von zufälligen Fehlern ausgelegt. Es ist nicht geeignet, die Integrität der Daten zu bestätigen. Das heißt, es ist verhältnismäßig leicht, durch beabsichtigte Modifikation einen Datenstrom zu erzeugen, der den gleichen CRC-Wert wie eine gegebene Nachricht hat. Wenn eine solche Sicherheit gefordert ist, müssen kryptografische Hash-Verfahren wie beispielsweise SHA zum Einsatz kommen.
Der Name des Verfahrens beruht darauf, dass der angefügte Wert keinen Informationsgehalt besitzt, der nicht bereits in dem zugrunde liegenden Datenblock enthalten ist. Er ist deshalb redundant.
Wie funktioniert CRC?
Die Berechnung des CRC-Werts beruht auf Polynomdivision: Die Folge der zu übertragenden Bits wird als Polynom betrachtet.
Beispiel: Die Bitfolge 1,0,0,1,1,1,0,1 entspricht dem Polynom
Die Bitfolge der Coderepräsentation der Daten wird durch ein vorher festzulegendes Generatorpolynom (das CRC-Polynom) Modulo mod(2) geteilt, wobei ein Rest bleibt. Dieser Rest ist der CRC-Wert. Bei der Übertragung des Datenblocks hängt man den CRC-Wert an den originalen Datenblock an und überträgt ihn mit.
Um zu verifizieren, dass die Daten keinen Fehler beinhalten, wird der empfangene Datenblock mit angehängtem CRC-Wert als Binärfolge interpretiert, erneut durch das CRC-Polynom Modulo geteilt und der Rest ermittelt. Wenn kein Rest bleibt, ist entweder kein Fehler aufgetreten oder es ist ein (sehr unwahrscheinlicher) Fehler aufgetreten, der in Polynomdarstellung das CRC-Polynom als Faktor hat.
Zwischen Sender und Empfänger muss dasselbe CRC-Polynom und Rechenverfahren benutzt werden. Zusätzlich muss vereinbart werden, wo im Datenstrom sich die zusätzlich zu den Daten übertragene Prüfsumme befindet.
Beispiel:
Es folgt ein Beispiel, in dem für einen Binärcode von 5 Bit der CRC berechnet und überprüft werden soll.
Das Generatorpolynom (CRC-Polynom) lautet 110101 (1x5 + 1x4 + 0x3 + 1x2 + 0x1+ 1x0) und ist somit 5. Grades. Der zu übertragenden Bitfolge, welche auch als Rahmen (engl. frame) bezeichnet wird, werden n Nullen angehängt (Rahmen mit Anhang), wobei n demGrad des Generatorpolynoms entspricht (bzw. der Anzahl der Bits des Generatorpolynoms minus eins).
Generatorpolynom: | 110101
|
Rahmen: | 11011 (Nutzdaten)
|
Rahmen mit Anhang: | 1101100000 (das Generatorpolynom hat r Stellen, also werden r − 1 = n Nullen ergänzt; hier ist r = 6)
|
Nun wird der Rahmen mit Anhang von links her durch das Generatorpolynom dividiert. Dabei wird die XOR-Funktion verwendet. Wenn man dies im ersten Schritt anwendet, wird aus 110110 XOR 110101 die Zahl 000011 (wobei gilt: 1 XOR 1 = 0; 1 XOR 0 = 1; 0 XOR 1 = 1; 0 XOR 0 = 0). Es folgt das vollständige Beispiel:
↓ immer mit der ersten gemeinsamen 1 anfangen
1101100000
110101
------
0000110000
110101
------
101 (Rest)
An den Rahmen ohne Anhang wird nun der Rest angehängt. Dieser muss ebenfalls aus n Bit bestehen (wobei n wiederum dem Grad des Generatorpolynoms entspricht). Damit hängen wir nun '00101' an den Rahmen an.
Übertragener Rahmen: 1101100101
Diese Nachricht kann jetzt beispielsweise über ein Netzwerk übertragen werden. Wenn die Nachricht beim Empfänger eintrifft, kann dieser überprüfen, ob sie korrekt angekommen ist.
Mittels Division durch das Generatorpolynom kann jetzt die fehlerhafte Übertragung erkannt werden:
Korrekte Übertragung der Nachricht: | 1101100101
|
Das Generatorpolynom (wie oben): | 110101
|
1101100101
110101
------
110101
110101
------
000000
Der Rest der Division ist gleich null. Es ist also kein Fehler aufgetreten. |
Fehlerhaft übertragene Nachricht (Beispiel): | 1001100101
|
Das Generatorpolynom (wie oben): | 110101
|
1001100101
110101
------
100110
110101
------
100111
110101
------
100100
110101
------
100011
110101
------
10110
Der Rest der Division (10110) ist ungleich null. Also ist ein Fehler aufgetreten. Bei der Überprüfung auf Richtigkeit können folgende vier Fälle auftreten:
1. Der Rest der Division ist null und die Nachricht ist richtig
2. Der Rest der Division ist null und die Nachricht ist fehlerhaft (dieser Fall ist unwahrscheinlich, kann aber vorkommen, wenn das Fehlerpolynom ein Vielfaches des Generatorpolynoms ist oder wenn der Fehler im Datenteil und im CRC-Wert ist)
3. Der Rest der Division ist ungleich null und die Nachricht ist fehlerhaft
4. Der Rest der Division ist ungleich null und die Nachricht ist richtig (dieser Fall tritt ein, wenn lediglich der angehängte Rest fehlerhaft übertragen wird; dies ist jedoch ebenfalls unwahrscheinlich, da der übertragene Rest im Vergleich zur Gesamtlänge des Pakets kurz ist)
Verschiedene CRC-Verfahren
Name | Polynom | Länge | MHD | Anmerkungen |
CRC-CCITT (CRC-4) | x4 + x + 1 | 15 |
| Identisch mit dem (15,11)-Hamming-Code |
USB (CRC-5) | x5 + x2 + 1 | 31 |
| Identisch mit dem (31,26)-Hamming-Code |
Bluetooth | x5 + x4 + x2 + 1 = (x + 1)(x4 + x + 1) | 15 |
| Verkürzter (15,10)-Hamming-Code. |
SD/MMC-Card (CRC-7) | x7 + x3 + 1 | 127 | 3 | Identisch mit dem (127,120)-Hamming-Code |
CRC-8 (Dallas/Maxim 1-Wire Bus) | x8 + x5 + x4 + 1 = (x + 1)(x7 + x6 + x5 + x3 + x2 + x + 1) | 127 | 4 | Beschrieben bei Dallas/Maxim |
CRC-8 (ITU-T) | x8 + x2 + x + 1 | 127 | 4 | ISDN Header Error Control |
CRC-8 (SAE-J1850) | x8 + x4 + x3 + x2 + 1 | 255 | 3 | Verwendet bei AES/EBU |
CRC-12 | x12 + x11 + x3 + x2 + x1 + 1 |
|
|
|
CAN-CRC | x15 + x14 + x10 + x8 + x7 + x4 + x3 + 1 = (x + 1)(x7 + x3 + 1)(x7 + x3 + x2 + x + 1) | 127 | 6 |
|
CRC-CCITT (CRC-16) | x16 + x12 + x5 + 1 | 32767 | 4 | Verwendet bei HDLC, X.25 |
CRC-XModem (CRC-XModem) | x16 + x12 + x5 + 1 | 32767 | 4 | Identisch mit CRC-CCITT |
IBM-CRC-16 | x16 + x15 + x2 + 1 | 32767 | 4 |
|
CRC-DNP (CRC-16) | x16 + x13 + x12 + x11 + x10 + x8 + x6 + x5 + x2 + 1 |
|
|
|
CRC-16 VÖV 04.05.1 | x16 + x14 + x13 + x11 + x10 + x9 + x8 + x6 + x5 + x1 + 1 |
|
|
|
CRC-24 (IETF RFC2440) | x24 + x23 + x18 + x17 + x14 + x11 + x10 + x7 + x6 + x5 + x4 + x3 + x + 1 |
|
|
|
CRC-24 (Mode-S) | x24 + x23 + x22 + x21 + x20 + x19 + x18 + x17 + x16 + x15 + x14 + x13 + x12 + x10 + x3 + 1 |
|
| Bei Framelänge bis 112 Bits fehlerkorrigierend bis 5 Bit |
| x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1 | 232 − 1 | 3 | Verwendet bei Ethernet |
CRC-64 (ISO 3309) | x64 + x4 + x3 + x + 1 |
|
|
|
In Visual Basic sieht eine Lösung für die Prüfung mit CRC 32 übersichtlich aus:
Public Function CRC32(Str As String) As Long
Dim i As Long
Dim j As Long
Dim nPowers(0 To 7) As Integer
Dim nCRC As Long
Dim nByte As Integer
Dim nBit As Boolean
For i = 0 To 7
nPowers(i) = 2 ^ i
Next 'i
For i = 1 To Len(Str) nByte = Asc(Mid$(Str, i, 1))
For j = 7 To 0 Step -1
nBit = CBool((nCRC And 32768) = 32768) Xor _
((nByte And nPowers(j)) = nPowers(j))
nCRC = (nCRC And 32767&) * 2&
If nBit Then
nCRC = nCRC Xor &H8005&
End If
Next 'j
Next 'i
CRC32 = nCRC
End Function
| | |
Die Funktion wird einfach in die Telegrammbearbeitung eingebunden, die Fehlerbehandlung muss dann noch zusätzlich programmiert werden.
Die Polynomdivision lässt sich, nach dem im obigen Beispiel verwendeten normalen Divisionsverfahren, überraschend einfach in Hardware realisieren. In Bild 1 dargestellt ist ein Schieberegister, in das von rechts das zu dividierende Polynom h hinein geschoben wird. Wenn eine 1 in der vordersten Schieberegisterzelle erscheint, wird das Generatorpolynom (im ersten Bild das Polynom 1 0 0 1 1 1) mit dieser 1 multipliziert (Und-Gatter) und an der entsprechenden Position von dem zu dividierenden Polynom h subtrahiert (Xor-Gatter). Der verbleibende Rest zusammen mit der nächstfolgenden Stelle von h wird anschließend um eine Position nach links geschoben. Wenn in der vordersten Schieberegisterzelle eine 0 erscheint, wird das 0-fache des Generatorpolynoms subtrahiert, d.h. es geschieht nichts, außer dass der Schieberegisterinhalt geschoben wird. Es ist leicht zu sehen, dass durch diese Hardware genau das o.a. Divisionsverfahren realisiert wird. Wenn das zu dividierende Polynom h zu Ende ist, d.h. keine Stellen mehr in das Schieberegister eingegeben werden, steht im Schieberegister der Divisionsrest. Die Schaltung kann sowohl zur Codierung als auch zur Fehlererkennung verwendet werden. Zur Fehlererkennung wird durch eine Oder-Schaltung überprüft, ob der Divisionsrest gleich Null oder ungleich Null ist. Zur Codierung wird der Divisionsrest an die Nachricht angehängt. Vor Beginn einer Division muss das Schieberegister gelöscht werden.
|
|
|
|
Schaltung zur Polynomdivision |
|
vereinfachte Schaltung
Die Schaltung von kann vereinfacht werden, wenn das Generatorpolynom festliegt. Dann können alle Und-Gatter mit einer 1 am Eingang durch eine einfache Drahtverbindung ersetzt werden. Alle Und-Gatter mit einer 0 am Eingang liefern am Ausgang konstant 0 und können daher wegfallen; die entsprechenden Xor-Gatter mit dieser 0 am Eingang können durch Drahtverbindungen ersetzt werden. Das vorderste Xor-Gatter kann ebenfalls entfallen, da sein Ausgang nicht verwendet wird (er ist im übrigen immer 0). Das zweite Bild zeigt die vereinfachte Schaltung, ein rückgekoppeltes Schieberegister (Linear Feed-Back Shift Register – LFSR), für das Generatorpolynom 1 0 0 1 1 1. |  |
Busmechanismen auf der Sicherungsschicht
Werden mehrere Teilnehmer an einer Übertragungsphysik (an einer Busleitung) eingesetzt, muss auf Schicht 2 auch ein Verfahren realisiert werden, um zu verhindern, dass mehrere Teilnehmer gleichzeitig Signale auf die Leitung geben, das Buszugriffsverfahren.
Hier wird unterschieden zwischen deterministischen Verfahren, d.h. Verfahren mit maximalen Übertragungszeiträumen z.B. für Steuerungsaufgaben und nichtdeterministischen Verfahren, bei denen keine maximale Reaktionszeit definiert werden kann.
Deterministische Verfahren sind das Master/Slave- und das Tokenbus- oder Tokenringverfahren, nichtdeterministisch CSMA/CD bei Ethernet oder CSMA/CA beim CAN-Bus.
In der Automatisierungstechnik werden primär deterministische Verfahren eingesetzt, da bei steuerungs- und sicherheitstechnischen Aufgaben die Reaktionszeit bei Anforderung einer Funktion definiert sein muss.
Beispiel ist hier eine Abschaltfunktion in einer
Endschalteranlage auf einem Fördergerät. Hier spielt die Reaktionszeit eine große Rolle.
Master-Slave
Ein Teilnehmer ist der Master, alle anderen sind die Slaves. Der Master hat als einziger das Recht, unaufgefordert auf die gemeinsame Ressource zuzugreifen. Der Slave kann von sich aus nicht auf die gemeinsame Ressource zugreifen; er muss warten, bis er vom Master gefragt wird.
Hauptvorteil ist, dass der Master die Zugriffsverhältnisse beherrscht: um ihn wird das System aufgebaut, was die Planung einfach macht.
Master-Slave-Architekturen können auch mit dem TokenBus kombiniert werden, wobei dann nur die Master den Token weiter geben.
Ein großer Nachteil ist, dass die Kommunikation zwischen Slaves nicht möglich ist. Weiterhin ist das Abfragen (Polling) der Slaves durch den Master ineffizient. Dies bedingt eine hohe Übertragungsgeschwindigkeit, um akzeptable Übertragungszeiten zu erreichen.
Sicherungsschicht beim Profibus
PROFIBUS Protokolle (OSI-Modell)
OSI-Schicht | Englisch | PROFIBUS |
7 | Anwendung | Application |
| DPV0 | DPV1 | DPV2 |
| Management |
6 | Darstellung | Presentation | -- |
5 | Sitzung | Session |
4 | Transport | Transport |
3 | Netzwerk | Network |
2 | Sicherung | Data Link | FDL |
1 | Bitübertragung | Physical | EIA-485 | Optisch | MBP |
Sicherungsschicht bei Profibus
Die Sicherungsschicht FDL (Fieldbus Data Link) arbeitet mit einem hybriden Zugriffsverfahren, das Token-Passing mit einem Master-Slave-Verfahren kombiniert. In einem PROFIBUS-Netzwerk sind die Steuerungen oder Prozessleitsysteme die Master und die Sensoren und Aktoren die Slaves.
DP-Anwendungsschicht
Die DP-Anwendungsschicht wurde in drei Schritten definiert. Das ursprünglich 1993 festgeschriebene DP-Protokoll wird heute umgangssprachlich als „DP-V0“ bezeichnet, die beiden Erweiterungen entsprechend „DP-V1“ und „DP-V2“. In den einzelnen Stufen wurden folgende Funktionen definiert:
§ In DP-V0 der zyklische Austausch der Daten und Diagnosen. Geräte, die diesen Funktionsumfang unterstützen, finden vor allem in der allgemeinen Automatisierungstechnik und Maschinensteuerung Einsatz.
§ In DP-V1 der azyklische Datenaustausch und die Alarmbehandlung. Geräte, die diese Erweiterungen unterstützen, finden sich vor allem in der Verfahrenstechnik.
§ In DP-V2 der isochrone Datenaustausch, der Slave-Querverkehr und die Uhrzeitsynchronisation. Mit dieser Erweiterung wurde vor allem Anforderungen aus der Fertigungstechnik und Robotersteuerung Rechnung getragen.
Das PA-Protokoll wurde im Rahmen der Entwicklungsstufe DP-V1 definiert.
